W3C home > Mailing lists > Public > uri@w3.org > June 2005

RE: mailto URIs

From: Bruce Lilly <blilly@erols.com>
Date: Mon, 20 Jun 2005 15:25:36 -0400
To: uri@w3.org
Cc: Paul Hoffman <phoffman@imc.org>, Larry Masinter <LMM@acm.org>
Message-Id: <200506201525.37689.blilly@erols.com>

On Mon June 20 2005 13:43, Paul Hoffman wrote:

> At 10:24 AM -0700 6/20/05, Larry Masinter wrote:
> >(URIC-encoded) 'addr-spec' is reliable
> >(URIC-encoded) 'mailbox-list' MAY be used, but is often
> >    badly implemented
> 
> This would lead to massive lack of interoperability of software that 
> creates or resolves mailto: URIs. Assume that Thunderbird implements 
> reading the new form, so Thunderbird users start to create mailtos 
> for themselves using it on their web pages. A non-Thunderbird-user 
> double-clicks on the link, their MUA launches, and malformed crap 
> appears in the To: field of the new message.

The same could have been said when the change was introduced between
RFCs 1738 and 2368.  Note that in fact RFC 2368 (using RFC 822 EBNF)
says:

     mailtoURL  =  "mailto:" [ to ] [ headers ]
     to         =  #mailbox
[...]
   "#mailbox" is as specified in RFC 822 [RFC822].

and further noting that RFC 822 '#' ENBF syntax in fact specifies a
list, updating to RFC 2822 and ABNF actually *reduces* the potential
for interoperability problems by eliminating generation of constructs
permitted by RFC 822 -- including, but not limited to, empty list
elements permitted by '#' syntax and the liberal inclusion of
whitespace, comments, and line folding explicitly permitted by RFC
822 (note that 2822 deprecates comments in address fields).

The draft proposal as currently written, and as likely to be when
revised according to comments will probably require resetting
status to Proposed Standard.  Documenting implementation issues is
not required until elevation to Draft Standard, so worrying unduly
about such issues now is probably premature (however, note that the
comments on the draft specifically pertain to interoperability,
including backward compatibility with RFC 2368 as well as clarifying
interoperability-unfriendly ambiguities in the 2368 specification).

That said, there's nothing wrong with an implementation note
observing the fact that some deployed implementations may fail to
handle the full 2368 or draft-under-discussion syntax.

> I propose that breaking current MUAs is not a good idea in order to 
> allow comments and lists of names in URIs.

Both were already allowed under RFC 822 syntax rules as used by RFC
2368!  RFC 1738 used RFC 822 syntax for addr-spec, which also
explicitly permits liberal use of comments, whitespace, and line
folding.

> Even creating a new scheme  
> would probably cause confusion, particularly if you name it something 
> like 'mailto-new'. I have heard no demand for this new feature, even 
> though it has been obvious for over a decade.

Paul, I'm puzzled by that statement; as a 2368 co-author, could
you comment on why the feature was introduced in RFC 2368?
 
> >What do you mean by 'insecurely'?
> 
> It would probably be easy to create "new-format" mailto: strings that 
> would cause current MUAs to crash in interesting fashions.

It is useful to distinguish several distinct types of "crashes":
1. those due to lack of backwards compatibility introduced by changes
   to the specification (e.g. 1738 to 2368 changes)
2. those due to faulty implementations of clear specifications
3. those due to implementations of different approaches due to
   ambiguity in the published specification

In the case of #1, the horse has already escaped; we can certainly
close the stable door by incorporating the 2822 restrictions on
generation (conversely, we could make matters worse by introducing
new incompatibilities such as raw untagged utf-8).

In the case of #2, there will always be faulty implementations. There
isn't much that can be done about that; non-conforming implementations
are free to be such as long as conformance isn't claimed (and there is
no enforcement anyway).

Regarding #3, we can carefully review the specification for precision
and clarity -- and that seems to be what's happening, though statements
that something new is being introduced need to be carefully checked
against what the draft under discussion and RFC 2368 actually say.
Received on Monday, 20 June 2005 19:25:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:09 UTC