Re: [EAI] Shepherd report review of mailinglist-02

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

Hello John, others,

On 2012/07/13 8:08, John C Klensin wrote:
> WG participants,
>
> I've responded to some of John L's points below -- read or not
> as you like.  Either way, consider this a heads-up that we will
> ask Pete to start the process of initiating an IETF Last Call in
> circa 24 hours.  So, if there is anything here you don't like,
> this is your last chance to speak up inside the WG.

I'm sorry, but I feel I have to take this chance.

As you can see in detail in a mail that I sent a few minutes ago 
(Subject: Confusion about backwards-compatibility of 3987bis/IRIs), I 
think that the very recent removal of the reference to RFC 3987 (and 
possibly also RFC 6068, but then other URI schemes are also not 
mentioned with a reference) is based on confusion only and is a 
disservice to the reader.

Also, my proposal of different text for the "%-routing problem", which 
is clearer about the source of the problem, in particular that it's an 
implementation problem (correct escaping/unescaping) and not an a-priori 
problem, hasn't been taken into account, and I don't know why.

For your reference, here is the current draft text:

<<<<
    The encoding technique specified in [RFC3986] 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.
<<<<

and here is (roughly) what I proposed (and still think) it be replaced with:

 >>>>
    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.
<<<<

There is some more in 
http://www.ietf.org/mail-archive/web/ima/current/msg04924.html, which 
may also benefit from a more careful consideration.

Regards,   Martin.



> John,
>
> Inline.
>
>      john
>
>
>
> --On Thursday, July 12, 2012 17:45 -0400 John R Levine
> <[e-mail]>  wrote:
>
>> OK, I've posted an -03 that I think takes into consideration
>> everyone's comments.  The comment that lists are inanimate
>> messages while list agents are software was a good one, that
>> let me go through and make the document (I think) considerably
> clearer.
>>
>> Just so you don't think I ignored you:
>>
>>> FWIW, I've never seen a large list handled by putting hundreds
>>> of messages into a single SMTP envelope and handing off to a
>>> conventional submission server.
>>
>> It's quite common now, e.g., one of Mailman's normal config
> options.
>
> Ack.  Thanks for clarifying.
>
>>> In a world in which we encourage explicit confirmation as part
>>> of an email subscription process for other reasons (ones with
>>> which you are thoroughly familiar), putting something that
>>> requires SMTPUTF8 handling into the automated confirmation
>>> message would not be burdensome.
>>
>> I didn't do that for two reasons.  One is that while requiring
>> signup confirmation usually a good idea, there are real
>> situations where it's not needed, and this is the wrong place
>> to argue about list policies.
>
> Absolutely.
>
>> Also, this could apply to lists
>> where the manager is upgrading an existing list to EAI, and
>> getting all of a list's subscribers to reconfirm is, ah,
>> challenging.  So it mentions it as an option, not as advice.
>
> Wfm.  I just wanted to be sure that, if anyone asked, Joseph and
> I could say "yes, we considered doing that and decided no to".
>
>>> We've essentially said that in-transit message downgrading is
>>> impossible unless the message contains no non-ASCII addresses
>>> and has non-ASCII material only in header fields in which
>>> encoded words can be used.  Absent a whole series of
>>> provisions that you haven't discussed, a mailing list
>>> exploder is in no better shape to downgrade messages for
>>> ASCII-only recipients than a relay.
>>
>> Already discussed later on, added references.
>
> Again, thanks.
>
>
>
> _______________________________________________
> IMA mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ima