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).
The discussion on [4] has missed the point, as [4] is not specifically about
NFKC. 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.
I apologize for the delayed response.
Thanks,
--David
Responses inline. Thanks
On 2010-09-10, at 8:19 PM, <david.black at emc.com> <david.black at emc.com>
wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
> please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq
> .
>
> Please resolve these comments along with any other comments you may receive.
>
> Summary:
> This draft is on the right track, but has open issues, described in the
> review.
>
> This draft describes a framework for international character support in
> mailbox names. That easy-to-state requirement has a large scope of
> consequences, as it also requires:
> - international character support in message headers;
> - extensions to message delivery status and notification handling; and
> - i18n protocol extensions to SMTP, POP and IMAP.
> Even so, the resulting email path coverage scope is not end-to-end, as
> important aspects of MUA behavior and interaction with users are out-of-scope
> (and I believe properly so).
>
> The draft is well written, and does a good job of describing the overall
> framework of email transfer and the entities involved. Unfortunately, that
> descriptive style carries over into the specification of the framework and
> interactions involved in international character support, and that
> descriptive (rather than prescriptive) style leads the open issues:
>
> [1] The second sentence in the second paragraph of Section 7.2 begins with
> "That form SHOULD presumably use UTF-8". I don't understand that, as
> "presumably" is not consistent with the RFC 2119 specification of "SHOULD".
> The paragraph gets worse further on with a statement that something "can be
> done" to realize this "SHOULD presumably" requirement. I cannot figure out
> what this paragraph is specifying or recommending; it should be rewritten.
> As part of the rewrite, please carefully separate functionality that is
> acceptable in transition from functionality that is part of the longer term
> "target" and say something about how to go about retiring the transition
> functionality from use.
It was legacy from RFC 4952, which was deliberately more tentative then needs
to be.
Yes, the word "presumably" will be removed, and we also change
"..non-ASCII characters in headers [RFC2045] [RFC2231]."
to read
""...non-ASCII characters in headers [RFC2045] [RFC2231], but even these should
be based on UTF-8. rather than other encodings, if at all possible
[IAB-idn-encoding]."
>
> [2] The last paragraph of Section 8.1 has a similar problem - "In this
> context, one can easily imagine modifications" is a fine introduction to a
> fairy tale, but does not belong in a framework RFC, even an Informational
> one. Again, I cannot figure out what is being recommended here - on its
> face, the language is entirely hypothetical, but I suspect that there's
> something that should be said about when the techniques in this paragraph
> should be used and for what purposes. Please rewrite.
This is what we intended for the flexibility and "fixes" needed for message
submission server to deal with what MUAs may supply. Also the behaviour of
message submission server is out of framework scope. We recommend to add a new
paragraph (as new first paragraph in section 8.1) to explain the situation:
<t>The IETF has traditionally avoided specifying the precise
behavior of MUAs to provide maximum flexibility in the
associated user interfaces. The
<xref target="RFC5321">SMTP standard</xref>, Section 6.4,
gives wide latitude to MUAs and Submission servers as to
what might be supplied by the user as long as the result
conforms with "on the wire" standards once it is injected
into the public Internet. In that tradition, the discussion
in the remainder of this section is provided as general
guidance rather than normative requirements.</t>
>
> [3] Section 10.1 seems problematic. The open issue is that the draft
> declines to say anything definitive about how to deal with existing ("running
> code" use of the backspace character). I suggest adding a discussion of
> making the backspace character an exception to the prohibition of Unicode C0
> controls for transition purposes.
The technique of backspace character is not in practice at least in Unicode
IMHO. And this would create lots of issues on mail delivery and other areas.
Since EAI mail is new and allow UTF-8 only, I would recommend not to encourage
this practice further.
>
> [4] Also in Section 10.1, the second bullet under the principles assumes that
> the mailbox name is normalized, as that was recommended by the first bullet.
> The other case should also be covered - if the mailbox name is not
> normalized, the draft should recommend that the normalized form of the
> mailbox name be an alias. A non-obvious situation where this applies is to
> mailbox names that are not normalized wrt all applicable normalization forms,
> e.g., names that are in normal form with respect to NFC, but not with respect
> to NFKC.
NFKC could maps out some characters that could be part of a person's name.
It is also hard, next to impossible, to generate all non normalized forms.
Given there will be new compatible equivalents when new version of Unicode
introduced.
We could strength the text in section 10.1:
Old:
The practice SHOULD be phased out as this extension becomes
widely deployed but backward-compatibility considerations
may require that it continue to be recognized.
New:
Because RFC 5321 (and its predecessor, RFC 2821) prohibit
the use of this character in ASCII mailbox names and it is
even more problematic (for canonicalization and
normalization reasons) in non-ASCII strings, backspace MUST
NOT appear in UTF8MSTPbis mailbox names.
Thanks
Joseph
>
> The following item should also be dealt with, but does not rise to the level
> of an open issue:
>
> [A] In Section 10.1, the warnings against unnormalized strings, use of
> spaces, punctuation, etc. seem weak, and would benefit from an example to
> make the point. Even though there's another draft referenced on MUA issues,
> the example I suggest involves a user sends a message to another user and
> expecting a reply. In order for this example to work as intended, the first
> user's email address needs to survive the second user's MUA, which may
> normalize or fail to deal well with whitespace, punctuation, etc.,
> independent of care taken in implementation of the first user's MUA.
>
> -- Nits --
>
> Please add citations of the i18n IMAP and POP specs to the last paragraph in
> Section 7.1.
>
> idnits 2.12.05 found a lot to complain about, but only the following three
> items appear to deserve attention:
>
> == 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.
>
> -- 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?
>
> == Unused Reference: 'RFC2033' is defined on line 1038, but no explicit
> reference was found in the text
>
> I suspect that the disclaimer is needed courtesy of text taken from older
> documents, but that need should be double-checked.
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA 01748
> +1 (508) 293-7953 FAX: +1 (508) 293-7786
> david.black at emc.com Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[email protected] Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
