Re: [EAI] The mailing list draft

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

Hello John,

Many thanks for your comments.

On 2012/06/19 23:49, John C Klensin wrote:
> Martin,
>
> A few comments (personal, not a co-chair except as noted).  I'll
> let John L respond to the others and get a new draft posted when
> he is ready.
>
> <co-chair hat=on>
> WG members: some of this is controversial.  If you have
> comments, make them.  WG LC on this document will start as soon
> as John gets a new version posted (even if only to avoid WG LC
> on an expired draft).
> </co-chair>

(Given this warning, I was rather afraid there would be a long list of 
thorny issues, but they all seem rather easy.)


> --On Tuesday, June 19, 2012 16:08 +0900 "\"Martin J. Dürst\""
> <[e-mail]>  wrote:
>
>
>> 2.2 in general: It occurred to be that one way of implementing
>> this is to have two mailing list addresses, or in some way
>> almost two mailing list, one old-style and one EAI, where
>> submitted messages are automatically shared. Or is this a bad
>> idea for some reason? If not, a more explicit description
>> might help.
>
> I'm not certain I understand this.  If I do, it is either
> equivalent to advise to simply not permit UTF-8 addresses in
> mailing lists or any EAI-requiring messages to be posted to
> them) or having the expectation of having lots of messages
> delivered twice.  Another reading would take us back to
> requiring that every UTF-8 address be accompanied by an
> alternative, 5821-conforming, address, which takes us right back
> to all of the issues associated with dual addresses and
> in-transit downgrading, including the security-threat issues,
> that we agreed to drop.  Or am I misunderstanding the suggestion?

John Levine got it right, and showed that it wasn't really such a good idea.


>> 3.1:
>>      "The current specification for
>>      mailto does not permit unencoded UTF-8 characters":
>> That's wrong. RFC 6068 (http://tools.ietf.org/html/rfc6068)
>> allows 'raw' Unicode characters everywhere except the LHS of
>> the address,
>> and even for that part, RFC 6068 already "does the right
>> thing",
>> although with a "reserved" caveat. Of course, 'raw' Unicode
>> can only
>> be used in the IRI form, for URIs, %-encoding based on UTF-8
>> is needed.
>
> Sadly, "%" has a different historical interpretation for email
> local-parts than it does in URUs.  That isn't a problem as long
> as all of the decoding and encoding rules are followed
> carefully.  But, having just had another bad experience that
> appears to be due to moving from email address to MAILTO URI to
> email address fouling up "+" in a local part, I have no
> confidence at all about proper handling of "%".

I have absolutely nothing against a very strong warning on this issue, 
because I agree that it is indeed a problem.


> You and John note another aspect of this issue in the text and
> elsewhere in your message.
>
>> ...
>>     "Note that discussion  on
>>      whether internationalized domain names should be
>> percent-encoded or
>>      puny-coded, is ongoing; see [I-D.duerst-iri-bis]."
>> This point is no longer under discussion in the IRI WG.
>> There's no essential change from RFC 3986, where these two
>> forms already are allowed.
>
> <co-chair hat=on>
> I strongly prefer that we not drag the IRI debate into this WG.

I very much agree. That's why I don't think any comments about progress 
(or non-progress) in other WGs should be in our drafts.


> "No longer under discussion in the WG" is different from
> "approved in the IETF.

Of course. I may not have been clear enough, but I didn't want to 
propose to replace "discussion is ongoing" with "no longer under 
discussion". None of this should be in the document.


> If we do have to make an IRI discussion,
> or anything that is contingent on what that WG is doing,
> prerequisite to making progress on the EAI mailinglist document,
> I will propose to abandon that document until and unless the IRI
> work produces IETF consensus Standards Track documents.
> </co-chair>

I think there is no need to have an "IRI discussion". There is RFC 3987, 
which is Standards Track.

>> ...
>
> Thanks for the careful reading.
>
> best,
>     john

Regards,   Martin.