Re: [EAI] mailto

[John C Klensin <[e-mail]>]

Hi, Martin,

--On Thursday, 04 November, 2010 20:49 +0900 "\"Martin J.
Dürst\"" <[e-mail]> wrote:

>...
>> (1) EAI thinks an email address is, in Shawn's notation,
>> unicode@unicode (or possibly unicode@string-with-A-labels).
>> It does not permit %-escapes in the domain name and many mail
>> systems will interpret %-signs in the local part as something
>> else entirely, e.g., routing information.
> 
> Yes. Except that it was ascii@ascii, that has been the same
> since ages.

And there have been email implementations for a decade or two
(even if not "ages") who, in the name of "8-bit-clean" or
interpretations of the robustness principle (with which I'm not
personally sympathetic) have been accepting non-ASCII (and often
non-Unicode) strings and trying to make them work.   And they
have worked in local environments and by prior agreement -- the
discussion in draft-iab-idn-encoding applies here too.

>> (2) For an IRI, mailto:unicode@unicode is perfectly
>> reasonable. However, the mapping to a URI, unless it is
>> scheme/protocol dependent, is likely to produce either
>>     mailto:%-escapes@%-escapes
>> or
>>     mailto:%-escapes@string-with-A-labels
>> 
>> Both of which are really bad news if one tries to get from
>> mailto:String to an email address by dropping the mailto and
>> leaving String.
> 
> Yes. But please note that it has never been possible to get
> from "mailto:String" to the email address simply by dropping
> "mailto:". 

You mean "never valid", not "never possible", don't you?  I
could introduce you to several large financial and "e-business"
operations that do it many times a day.  

While I'm often an advocate of "let those who violated the
standard deal with their own messes when we do something that
tightens or enforces the rules" and think it applies here, we
need to understand what we are getting ourselves into with this.

> In particular, RFC 2368 (which is more than 12
> years old and strictly and purely about ASCII-only mail
> addresses only) says, in Section 2:
>...
 
> So your troubling "parallel discussions" may be mostly due to
> some people having read the specs, and others not. I seriously
> recommend you to read RFC 2368; you may (but should not) be
> surprised at how much text comes directly from there.

I have read it and know what it says.  I am not only concerned
about those who have not but about those who deliberately have
ignored its provisions, secure in the belief that we will never
do anything that has bad consequences for them.  See above. 

>> I think that means that any sort of i18n MAILTO processor has
>> to get from those forms back to the non-escaped
>> Unicode-in-UTF-8 strings that EAI expects before passing an
>> internationalized address off to a mail-sending or processing
>> operation.
> 
> Yes. If it simply implements %-decoding, without looking at
> the byte values, it will easily get the UTF-8 strings
> (Unicode-in-UTF-8 is a pleonasm). 

Having run into a file about two weeks ago that had apparently
started life as BIG5 and then had the same transformation that
UTF-8 uses applied to it, and then was shipped with a
content-type of "UTF-8" (according to the guilty party, because
there is no registration for "B5UTF-8" or equivalent) please
forgive me if I sometimes add detail that should not be
necessary.

> So EAI will be happy. What
> may go wrong is where this UTF-8 string hits an non-EAI mail
> agent.

yes

>...
>> If one
>> reads the second paragraph of Section 5 of RFC 6068 (and the
>> warning in the third-to-last paragraph of Section 7),
> 
> I would also like to point to the many examples in Section 6,
> for example:
>...
> While the example section is written for people who generate
> mailto: URIs from mail addresses, it shouldn't be too
> difficult to turn these examples around, implicitly reading
> them e.g.:
>...

Right.  But the point was that some of the key examples are not
present for EAI purposes and may  create some false sense of
security, not that the existing examples are incorrect in any
way.

>...
> If you have any proposals to improve the language and make it
> easier to understand, I'll be happy to integrate them.

And I'll be happy to look at it _after_ EAI completes all of the
decision-making that might bear on it.

>...
>> Note that this is a key difference from web and web-like
>> applications, where the applications can be assumed to be able
>> to deal with decoding the %-escapes themselves.
> 
> No, there is no such key difference. URIs (and IRIs) can
> contain %-escapes, and any software (be that Web-like or not)
> taking apart an URI and using its components has to know how
> to deal with these. This is the same since ages, and RFC 6068
> didn't change anything.

But that was exactly the point.  Web-like applications take URIs
and use their components natively.   Mail applications generally
don't, so we are dealing with the need for a method-specific
decoding intermediary.  And, if the folks who do those are not
familiar with both the MAILTO spec and the mail ones (or read
the MAILTO spec very carefully and conform exactly even without
knowing what they are doing), or if they are in a hurry and
don't care, bad things can happen that are excluded in the
"application deals with URIs directly" cases.

>...

best,
   john