Re: [EAI] I-D Action: draft-ietf-eai-mailinglistbis-02.txt

["Martin J. Dürst" <[e-mail]>]

Hello John,

On 2012/06/24 13:46, John Levine wrote:
> You can see a diff from -01 here:
>
> http://www.taugh.com/draft-ietf-eai-mailinglistbis-02-from-1.diff.html
>
> I went through all the comments and think I addressed them all (which
> is not the same as accepting all the suggestions.)  Tell me what you
> hate, preferably with text.

I liked most of what I saw! A few comments:

   Schemes that permit both URI and IRI forms should use the URI-encoded
   form described in [RFC3987] abd [RFC6068].

First, "abd" -> "and". Second, "Schemes should" doesn't exactly feel 
right. Even if this isn't a "normative should", a scheme by itself can 
do neither right nor wrong. Better change to "For schemes that permit 
both URI and IRI forms, the URI-encoded form described in [RFC3987] and 
[RFC6068] should be used."
(Passive voice isn't very good either, and I welcome improvements, but I 
think passive voice (leaving the actor open) is still better than making 
something an actor which can't act.)


    The encoding technique specified in [RFC3986] and [RFC3987] is to use
    a pair of hex digits preceded by a percent sign, but percent signs
    have been used informally in mail addresses to do source routing.
    Although few mail systems still permit source routing, a lot of mail
    software still forbids or escapes characters formerly used for source
    routing, which can lead to unfortunate interactions with percent-
    encoded URIs or any URI that includes one of those characters.

I think this still somewhat misses the point. If mail software forbids 
%, that's better than if it would treat it as routing, because the % 
characters in URIs will then be rejected rather than misinterpreted. 
Second, the text doesn't say how things are actually supposed to work, 
just what may go wrong. That's a disservice to implementers who may want 
to get this right. So what about a rewrite along the following lines:

    The encoding technique specified in [RFC3986] and [RFC3987] is to use
    a pair of hex digits preceded by a percent sign, but percent signs
    have been used informally in mail addresses to do source routing.
    The correct processing steps when interpreting a mailto: URI are to
    unescape %-encoding and then to interpret the resulting mail
    addresses and other information. Unfortunately, not all mail software
    does this correctly. As a result, % characters indicating URI
    encoding can be erroneously included in actual mail addresses.
    Although few mail systems still permit source routing, a lot of mail
    software still forbids or escapes characters formerly used for source
    routing, which will make incorrectly un-decoded mail addresses
    undeliverable, or in very rare, accidental cases, delivered to
    the wrong addressee.


    If a
    program interpreting a mailto: URI knew that the MUA in use were able
    to handle UTF-8 data, the program could pass the URI in unencoded
    UTF-8, avoiding problems with misinterpreted percent signs, but at
    this point there is no standard or even informal way for MUAs to
    signal EAI capabilities.

"Handle UTF-8 data" and "EAI capabilities" are not the same, or don't 
have to be, at least in the above scenario. And I personally have at 
least a glimmer of hope that MUAs that are EAI-capable also get the 
%-encoding thing right.

So we may have the following situations:

a) IRI in UTF-8, non-EAI MUA, rejects: fine, because we cannot send EAI
    mail with a non-EAI MUA anyway.

b) IRI in UTF-8, non-EAI MUA, blows up or drops (MSB) bits or other
    havoc: bad!

c) IRI in UTF-8, EAI MUA which grocks it: good!

d) IRI in UTF-8, EAI MUA which only understands %-encoding: We missed
    a chance.

The right text to write really depends on our judgment about the 
frequencies of a) vs. b), and c) vs. d). I'd hope that c) and d) are 
equally frequent, but I have no clue about a) vs. b), sorry. If you give 
me an estimate, I'll try to prepare some text.


                        Also, note that whether internationalized
    domain names should be percent-encoded or puny-coded is currently
    unresolved.

This is an improvement on what was there before, but it's still 
misleading. It's not that this issue is currently unresolved, and in a 
month or two, or in a year or two, or whatever time frame, it will be 
resolved. It's that there are two alternatives, and there are reasons 
for choosing one or the other. So I'd propose to reword this as follows:

                        Also, note that whether internationalized
    domain names should be percent-encoded or puny-coded depends on
    the usage context.
(You can cite RFC 3986 and/or 3987 here if you want.)


References:  [I-D.duerst-iri-bis] seems to be superfluous now.


Regards,   Martin.


> R's,
> John
>
> In article<[e-mail]>  you write:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Email Address Internationalization Working Group of the IETF.
>>
>> 	Title           : Mailing Lists and UTF-8 Addresses
>> 	Author(s)       : John Levine
>>                           Randall Gellens
>> 	Filename        : draft-ietf-eai-mailinglistbis-02.txt
>> 	Pages           : 9
>> 	Date            : 2012-06-23
>
> _______________________________________________
> IMA mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ima
>