Subject: Re: [EAI] Re: #1518 Normalization - a proposal for resolution

From: John C Klensin <[email-masked]>
Date: Sun, 02 Dec 2007 10:59:29 -0500

Playing devil's advocate, every step we take toward limiting
what can be placed in the local-part string takes us a step
closer to authorizing senders, relays, or downgraders to start
"fixing" those addresses... or having them decide it is a good
thing to do.  From that point of view, I'd rather that the norms
stand firmly behind the "no one else tampers" principle.

As you know, I've argued elsewhere that imposing NFKC is a bad
idea because there may be localized controversy as to whether a
few of the characters are really, properly, canonical
equivalents.  

That said, we know how to ban controls other than SP (perhaps by
property rather than simply the C1 (or C1 and C0) blocks) and
arguably should have done so in 821/ 1123/ 2821 many years ago.
To me, that is conceptually very different from starting to
write rules about graphic characters.

I'd still prefer to see this resolved by a separate "advice to
mail server administrators about forms of addresses" document.
It could even be standards-track if it confined itself to MAY
(except, maybe, for those controls).  But that document isn't on
the WG's task list (something that we could ask to have fixed)
and it isn't obvious to me who would have the extra cycles to
act as editor.

    john

--On Sunday, 02 December, 2007 14:11 +0100 Harald Tveit
Alvestrand <[email-masked]> wrote:

> 
> 
> --On 1. desember 2007 16:16 +0100 Frank Ellermann
> <[email-masked]> wrote:
> 
>> Harald Alvestrand wrote:
>> 
>>> Does that seem appropriate?
>> 
>> Could you somehow smuggle in a note that the set
>> of allowed UTF-8 characters might be reduced in a
>> future version ?
> 
> wouldn't dream of SMUGGLING it in :-)
> 
>> E.g. RFC 3987 defines a sound subset, no C1, no
>> non-characters, no PUA.  We're just not ready to
>> decide what we want yet, it's only an experiment.
>> 
>> Maybe allowing PUA is perfect for folks wishing
>> to use "apples" in their local parts, and maybe
>> allowing Unicode new line characters or similar
>> cases turn out to cause havoc.
> 
> hm - that subset makes some sense to me. It's hard to argue
> for C1, half-surrogates or PUA, or that running the experiment
> with this restriction will make it impossible to change our
> minds later. Other opinions?
> 
> BTW - this ticket shows the dangers of having stayed with a
> document for a long time; it turns out that almost exactly the
> same text was in section 5 already:
> 
>    This document does not specify any requirement for
> normalization.
>    Prudent use of UTF-8 in identifiers will involve sharply
> restricted
>    forms, for instance case-folded NFKC, but this document
> does not
>    require such a form anywhere in the protocol.
> 
> and another forgotten "note in draft".
> Should this be moved to section 4?
> 
>                  Harald
> 
> 
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ima

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima