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 08:21:35 UTC