W3C home > Mailing lists > Public > uri@w3.org > April 2009

RE: Fwd: I-D Action:draft-duerst-mailto-bis-06.txt

From: Cheney, Austin <Austin.Cheney@travelocity.com>
Date: Mon, 27 Apr 2009 11:31:33 -0500
Message-ID: <B0051B92EF44B94EB56966E82840100908D917C7@sgtulmsp06.Global.ad.sabre.com>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
Cc: <uri@w3.org>, "Larry Masinter" <masinter@adobe.com>, <jwz@jwz.org>
Martin,

Thank you for the reply!

> I would assume that the examples are indeed non-normative, because they 
> are examples. But what do you mean by "are a syntax that ..."? Do you 
> refer to the "<" and ">" that enclose the example URIs? This is 
> explained at the end of section 1:

I understand that "<" and ">" are used as mere syntax delimiters to separate application instructions from content.  This is perhaps a failing more of email, as a content distribution medium, to properly allocate conventions for describing such instructions as at this time there appear no standards for content description or format in email.  In regards to standardized syntax specification languages this format is non-normative without some additional syntax assistance, except for SGML.

Could the delimiters be something that pretends to reflect a language even if such a language is not immediately in use?  It would seem more beneficial to future integration of content description mechanisms if a compatible syntax were already in place even if the elaboration of that syntax is nothing more than beautification at this time.  My thoughts are that unsolvable security faults that are plaguing the web may motivate development of technologies to migrate communications and services over email where content security or privacy is relevant.

So, for future compatibility with an XML processor this would be better:
<mailto to="addr1@an.example%2C%20addr2@an.example">addr1@an.example, addr2@an.example</mailto>

The only difference is the use of a space instead of ":?" to separate an instruction name from its attribute elaborators, using quotes to contain an attribute value, and a closing tag.  It should be noted that the mailto URI scheme appears to be used primarily for the establishment of providing predefined header data for an email communication opposed to the formatting of the data during transport.  If that is true then it is a standard application convention for internet data processing, such as RFC 5322, and not a networking standard for data distribution, such as RFC 5321.  While this difference is hardly relevant to the operational functionality of mailto across channels of distribution it does provide room for flexibility with regards to syntax format.


> It should be very clear that "mailto:" is normative. It should also be 
> obvious that, because this is in wide use, it would be a really bad idea 
> to define something else (such as "smtp:").

I am aware that the mailto scheme is documented as RFC 2368 and is a standard de facto that has been adopted nearly universally even if not elevated to STD status.  Since there is no standard for any sort of content description, format, or instruction definition in the body of an email message it would seem that any such standard that does appear must either consume the mailto scheme or will obsolete it.  So, even if mailto is normative, the context of its use is not normative in email.  Its use is, at least more, normative in HTML which is a standard for providing processing instructions onto content.

Allowing a URI scheme such as smtp://cheney@mailmarkup.org is using URI syntax proper without specifying any additional processing requirements.  The benefit of allowing this is that it does not obsolete anything.  It is merely a practice that is not in use, but is otherwise no different than http://mailmarkup.org from purely the syntax perspective of the URI specification.

While I know very little of X.400 protocols it seems the format of data described by those protocols is not URI syntax compliant.  This fine though since the context of usage of mailto is for user-agent processing and not distribution.  Since there is a hand off and repackaging of header data between the user agent and the format used by the distribution protocol, whether it be SMTP or X.400, it should not pose a conflict to allow a content author to write something such as x400://cheney@mailmarkup.org and expect the user agent to properly process the data according the protocol or claim no support for the protocol.  The benefit to the mailto scheme is that it does not specify a protocol, and so the user agent will process it using the default enabled protocol without any sort of rule override.

> I think these are interesting ideas, but in general, the IETF 
> standardizes stuff that works (at least to a certain extent) rather than 
> ideas.

I agree, however, it is in the best interest of the document authors and the consuming vendors that the standards are as rigidly backwards compatible and expressively future compatible as possible.  When a proposed standard is not future compatible with a piece of consuming technology then problems occur that delay the process of new technology adoption.  This is especially true if the consuming technology already exists and is merely awaiting approval for submission.  The ideal standard exists to specify a usage, limitation, or constraint that provides as little conflict or obstruction to existing practices and is so very rigid with regard to adoption or consumption that it exists forever unbroken by the emergence of new technologies.  Such an ideal standard would only be obsolete by the emergence of a new practice that either renders the ideal standard obsolete in practice or yields a method of superior breadth or efficiency.  I would like the format or conventions used to process or write the mailto scheme to be defined in a manner that is more broadly adoptable so that consumable technologies do not render it obsolete through conflicts of execution.

> If you want to further pursue the idea of combining SMTP with a markup 
> language to achieve more than mere message routing, it may be best to 
> write up this idea as an Internet-Draft.

The technology is already written, tested, and protected.  I even included required support for the mailto scheme into the first, and only, version of the specification.  The specification has not been submitted yet as licensing decisions from the owner are not final at this time.  I don't want my technology to allow a conflict with the mailto scheme or any other practice if such can be helped.

> I can add a sentence or two regarding the fact that the provisions in 
> the document apply to other mail-sending protocols (and formats) as 
> appropriate, if that helps.

That would help me a great deal to know that mailto is not assumed RFC 822/5322 dependant or HTTP dependant.  I do not believe this would conflict with my ideas that I mentioned previously, but such conflicts MUST NOT be a concern for the mailto scheme.

Thanks,
Austin Cheney
http://design.dev.sabre.com/group/uit/


-----Original Message-----
From: "Martin J. Dürst" [mailto:duerst@it.aoyama.ac.jp] 
Sent: Monday, April 27, 2009 3:21 AM
To: Cheney, Austin
Cc: uri@w3.org; Larry Masinter; jwz@jwz.org
Subject: Re: Fwd: I-D Action:draft-duerst-mailto-bis-06.txt

Hello Austin,

Many thanks for your comments.

On 2009/04/22 4:44, Austin Cheney wrote:
> It seems in this draft, revision 06, that the examples are a syntax that are
> non-normative.

I would assume that the examples are indeed non-normative, because they 
are examples. But what do you mean by "are a syntax that ..."? Do you 
refer to the "<" and ">" that enclose the example URIs? This is 
explained at the end of section 1:

    In this document, URIs are enclosed in '<' and '>' as described in
    Appendix C of [STD66].  Extra whitespace and line breaks added to
    present long URIs are not part of the actual URI.

Or do you mean something else?

> It would be better if the syntax were formatted in a
> standard convention, such as XML or even JSON.  This should be done in a
> manner that is not protocol dependent.  It would be more appropriate to
> define the concept generally and then use a separate numbered section of the
> document to mention processing requirements specific to a protocol and a
> sub-point for requirements specific to a markup language in the context of
> that transmission protocol.
>
> Within the definition of URI syntax the mailto: protocol extension appears
> non-normative.  To be more conforming it SHOULD be used as smtp://.  Such
> usage identifies the protocol name and uses URI syntax to separate the
> protocol identification from the following resource or identification data.
> In other words, this example appears to be a valid URI:
> smtp://cheney@mailmarkup.org.

It should be very clear that "mailto:" is normative. It should also be 
obvious that, because this is in wide use, it would be a really bad idea 
to define something else (such as "smtp:").

Also, "mailto:" seems appropriate because mail is definitely not only 
transferred with smtp, but also with other protocols (e.g. X.400, 
proprietary systems of mobile carriers,...). There are quite a few other 
URI schemes that don't use a protocol name for their scheme name.


> This importance of this consideration rests in the future extensibility of
> SMTP as a service oriented protocol with superior server processing and
> security capabilities than HTTP allows opposed to merely a message routing
> mechanism.  If a markup language is adopted for standard use over SMTP
> exclusively the conventions used in that markup language MUST conform to
> protocol independent standards in order to communicate seamlessly with
> transmissions or documents in the HTTP protocol or other protocols.
>
> In other words, if a markup language is adopted for the SMTP protocol then
> communications SHOULD be able to seamless move between SMTP and HTTP based
> communications if the user-agent software is capable of processing such.
> All that is required is a properly formatted absolute URI.  If standards
> exist to define methods that are acceptable in one condition but are
> conflicting in an alternate peer condition transmission collisions are
> likely to arise where the only solutions are bloated work-arounds.  To be
> further specific, if standards are adopted as corner-cases for protocol
> specific processing they MUST be explicitly and intentionally limited to
> that protocol or not be considered a standard.
>
> Additionally, if a markup language is adopted for SMTP then it may be
> necessary to allow user to user hyperlinks using URI syntax in parallel with
> URI syntax for webpages over HTTP.  Both methods point to a destination that
> may or may not require interactivity, input, or responses.  It cannot and
> MUST NOT be presumed that SMTP is limited to sending communications opposed
> to opening a transmission for engaging in a sessioned data service.

I think these are interesting ideas, but in general, the IETF 
standardizes stuff that works (at least to a certain extent) rather than 
ideas.

If you want to further pursue the idea of combining SMTP with a markup 
language to achieve more than mere message routing, it may be best to 
write up this idea as an Internet-Draft.


> In order to ensure the convention addressed by this draft has the longest
> and most stable life-span possible please ensure its use in different
> communication modes is stable to the URI standard, the language of the
> specification is not protocol specific, and the intention of the document is
> enhancement of the URI standard and not a function of HTML.

The update we are working on is to integrate improvements with respect 
to internationalization, and clean up a few other things.

I can add a sentence or two regarding the fact that the provisions in 
the document apply to other mail-sending protocols (and formats) as 
appropriate, if that helps.

Regards,    Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp
Received on Monday, 27 April 2009 16:42:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:42 GMT