--On Sunday, September 19, 2010 15:30 -0400 [email protected]
wrote:
> Joseph,
>
> The proposed changes for [1], [2] and [3] are ok with me.
> Specifically for [3], I agree that prohibition of backspace
> characters is the better approach (I had read the draft as
> implying that such a prohibition was not feasible).
Sorry. I hope the new text is clear, but there is an absolute
prohibition on C0 controls (including, but not limited to
backspace) in 2821 which was reaffirmed in 5321. All EAI is
doing is _not_ overriding that prohibition.
> The discussion on [4] has missed the point, as [4] is not
> specifically about NFKC.
I/we responded to the use of NFKC in your report because
application of some types of compatibility normalization is a
particularly problematic case. If you (or anyone else copied)
don't understand the issue there, I'm happy to explain, but I
don't think it properly belongs in this document. But, more
generally and more or less as you put it, Unicode normalization
is indeed a problem area ... no matter how much guidance is
supplied.
Your report also appeared to us to call for installing all of
the alternate representations of a string as aliases. That is
pretty much a non-starter due to multiplicative explosion and
the issue discussed below.
> Here's a suggested change that would
> respond to [4], although the draft is ok with me if this is
> not done (Unicode normalization is problem area where
> interoperability issues are possible no matter how much
> guidance is supplied, so this is a judgment call about the
> amount of guidance to supply):
>
> OLD
> o It may be wise to support other forms of the same
> local-part string, either as aliases or by normalization
> of strings reaching the delivery server, in the event
> that the sender does not send the strings in normalized
> form.
>
> NEW
> o It may be wise to support other forms of the same
> local-part string, either as aliases or by normalization
> of strings reaching the delivery server, in the event
> that the sender does not send the strings in normalized
> form or that the recipient's local-part string is not in
> normalized form.
Well, frankly, if someone tries to keep a local-part string only
in unnormalized form (at least NFC/NFD) they are basically nuts
_unless_ their goal is to make the address hard to access for
filtering purposes (there are traditions of deliberately making
addresses deliberately obscure and hard to access that which go
back to the time when email was still being transported over
FTP).
I consequently can live this change as harmless. I am not
convinced that it is a good idea. There are two reasons:
-- we've historically (in pre-EAI email specs) been
reluctant to give too-specific advice about the
formation of address local parts, just because local
needs differ. That situation is one of the reasons why
there are strong prohibitions about anything other than
the final delivery server trying to parse and reorganize
or rewrite addresses in RFC 5321 and its predecessors.
Even the "no control characters" mandate in 2821 was
controversial for that reason: there are just too many
edge cases and specific local needs. There may be
reasons today to start changing our minds about that
strategy and give more advice (and a few of the
historical reasons for not doing so have receded into
obscurity), but this document is perhaps not the right
place to start making that change: EAI is very much
about a pure extension to traditional Internet email,
not a back door for introducing new policies or concepts
that are not strictly required for i18n purposes.
-- The WG Charter contains a benchmark for an
Informational document described as "Advice for
non-ASCII & ASCII addresses". We don't know what is
going to be in that document yet and I anticipate some
difficulty getting consensus on any but the weakest of
recommendations (I hope I'm wrong). Especially because
there is no EAI I-D on the subject yet, if we make a
specific recommendation in 4952bis --even one as
seemingly innocuous as "make sure one of the aliases is
in normalized form"-- there is some small possibility of
its being inconsistent with whatever recommendations
will appear in that more focused document, presumably
requiring re-opening this one. I think we would need to
take a more specific recommendation than the existing
one back to the WG for signoff. While the risk is
small, the advantages of the difference between the
deliberately somewhat vague text that now appears in the
document and your suggestion don't seem to me to justify
either the added risk or the added time and effort.
YMMD, of course, and, if the IESG were to insist on your
suggested textual change, I assume the WG would agree to make
it.
Incidentally, your "nits" list slipped through the cracks for
-08, largely because we were concentrating on the more
substantive issues. They have been addressed in my working
copy of the I-D; I can post that more or less immediately if the
Alexey, Russ, or other IESG members wish. Specifically:
>> Please add citations of the i18n IMAP and POP specs to the
>> last paragraph in Section 7.1.
Those citations were omitted deliberately as the result of an
ongoing discussion with the RFC Editor about how often to repeat
citations. In addition, since we do not expect this document to
be held for the IMAP and POP ones, the citation would need to
point to a not-particularly-useful "work in progress" reference.
So I/we thought it better to send the user who needed to know
back to Section 5, where those specs are put into context. This
is, of course, easily changed if the IESG or RFC Editor disagree.
Incidentally, in checking the Section 5 text, I noticed that we
had a citation to the base POP3 protocol but not one for the
base IMAP protocol. That has also been fixed in the working
copy.
>...
>> == The 'Obsoletes: ' line in the draft header should list
>> only the _numbers_ of the RFCs which will be obsoleted by
>> this document (if approved); it should not include the
>> word 'RFC' in the list.
This, and some of the others below, somehow slipped through the
cracks into -08. While it is clearly the sort of thing that the
RFC Editor can handle, I've fixed it in my working copy of the
XML.
>> -- The document has a disclaimer for pre-RFC5378 work, but
>> was first submitted on or after 10 November 2008. Does it
>> really need the disclaimer?
The document draws most of its text from RFC 4952, which is a
pre-November 2008 document. So, yes, the disclaimer is needed.
>> == Unused Reference: 'RFC2033' is defined on line 1038, but
>> no explicit reference was found in the text
Yes. A discussion of LMTP was removed fairly late in the
process. The definition has been removed from the working
version. But, again, the RFC Editor is extremely good at
catching this sort of thing.
>> I suspect that the disclaimer is needed courtesy of text
>> taken from older documents, but that need should be
>> double-checked.
It has been. See above.
best,
john
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
