Soencer,
thanks for your review!
Some comments... I'm not addressing editorials...
Spencer Dawkins skrev:
> This document specifies an experimental variant of Internet mail that
> permits the use of Unicode encoded in UTF-8 [RFC3629], rather than
> ASCII, as the base form for Internet email header fields. This form
> is permitted in transmission, if authorized by the SMTP extension
> specified in [EAI-SMTP-extension] or by other transport mechanisms
>
> Technical: isn't this s/transport/transfer/?
Actually the term used in most email discussions is "transport mechanism".
I don't know why the usage is like that, but it is.
>
> capable of processing it.
>
> 1.2. Relation to other standards
>
> This document also updates [RFC2822] and MIME, and the fact that an
> experimental specification updates a standards-track spec means that
> people who participate in the experiment have to consider those
> standards updated.
>
> Process: The ID Tracker is showing this draft in Last Call status, but I
> can't find (in the archive or in my personal folders) any Last Call
> announcement, which I was looking for, in order to check how Chris
> explained
> the downref at Last Call time - I'm expecting that it will be quite
> entertaining. Has anyone else seen such an announcement on IETF Announce?
Note: Intended status is Experimental.
The subject line of the Last Call was
Last Call: draft-ietf-eai-smtpext (SMTP extension for internationalized
email address) to Experimental RFC
and covered 2 drafts; this may be why you did not find it.
>
> Use of this SMTP extension helps prevents the introduction of such
> messages into message stores that might misinterpret, improperly
> display, or mangle such messages. It should be noted that using an
> ESMTP extension does not prevent transfering email messages with
> UTF-8 header fields to other systems that use the email format for
> messages and that may not be upgraded, such as unextended POP and
> IMAP servers. Changes to these protocols to handle UTF-8 header
> fields are addressed in related documents.
>
> technical: I would expect to see references to the "related documents"
> here... if they haven't been written yet, just saying "will be addressed"
> would make sense.
They are referenced in RFC 4952 (which is the overarching definition) as
"works in progress". We can certainly add references here too; I think
there's no doubt that there will be 2 documents, no less and no more, at
this point.
>
> 3. Terminology
>
> Unless otherwise noted, all terms used here are defined in [RFC2821]
> ,[RFC2822] , [RFC4952], or [EAI-SMTP-extension].
>
> nit: should not have spaces before commas here.
>
> The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
> and "MAY" in this document are to be interpreted as described in
> [RFC2119].
>
> 4. Changes on Message Header Fields
>
> This protocol does NOT change the definition of header field names.
>
> technical: I'm confused here. Is this text saying "does not change header
> field names"? I would have thought this specification is exactly changing
> the definition of header field names...
It does not change the definition of header field NAMES (which remain
ASCII), but changes the definition of header field BODIES (which used to
be ASCII, but are now UTF-8).
>
> That is, only the bodies of header fields are allowed to have UTF-8
> characters; the rules in [RFC2822] for header field names are not
> changed.
And this sentence is saying that. How can we express this more clearly?
>
> To permit UTF-8 characters in field values, the header definition in
> [RFC2822] must be extended to support new format. The following ABNF
> is defined to substitute those definition in [RFC2822].
> This specification does not require a specific normalization of the
> Unicode strings, but recommends that good practices for normalization
> be followed. See [Net-UTF8] for a discussion on recommended
>
> clarity: s/discussion/guidance/
>
> practices for normalizing text before sending.
>
> technical: this sounds like [Net-UTF8] is on the border between
> Normative and Informative. You have it under Informative, which may be
> fine, just please consider whether you expect someone using this
> specification to also use [Net-UTF8] in order to interoperate.
we have had long discussions on this.... we do expect relays to relay
mail whether they follow the Net-UTF8 recommendations or not, but we do
expect that people will have less surprises if they follow the
recommendations, just like they will have less surprises if they don't
assume that MailBox@host and mailbox@host are considered different.
> 4.5. Trace field syntax
>
> The "Return-Path" header provides the email return address in the
> mail delivery. Thus, it MUST able to carry UTF8 addresses (see the
>
> technical: this isn't a 2119 MUST, as written (any requirement would
> be on
> an implementation, not on a header). I'd suggest changing to "is
> augmented
> to carry", which matches the phrasing you use for other headers below.
I think your suggestion is reasonable here.
>
> revised syntax of <angle-addr> in Section 4.4 of this document).
> This will not break the rule of trace fied integrity, because it is
>
> technical: I'm not a mail expert, but is "trace fied integrity"
> correct? This draft has the only use of this term that Google finds on
> the IETF website ;-)
It should be "trace field integrity", of course...
>
> 4.6. message/global
>
> technical: "message/global" doesn't seem particularly obvious. If this is
> really Experimental, I'd suggest message/rfcXXXX, or something that gives
> people more of a clue about what the subtype means.
Another long discussion. WG consensus was to go with message/global; in
reality, if the experiment succeeds, we'll never get to change it; if
the experiment fails.... well, we've lost another nice name...
>
>
> Interoperability considerations: The media type provides
> functionality similar to the message/rfc822 content type for email
> messages with international email headers. When there is a need
> to embed or return such content in another message, there is
> generally an option to use this media type and leave the content
> unchanged or downconvert the content to message/rfc822. Both of
> these choices will interoperate with the installed base, but with
> different properties. Systems unaware of international headers
> will typically treat a message/global body part as an unknown
> attachment, while they will understand the structure of a message/
> rfc822. However, systems which understand message/global will
> provide functionality superior to the result of a down-conversion
> to message/rfc822. The most interoperable choice depends on the
> deployed software.
>
> technical: not sure what the last sentence actually means. "We don't know
> what the most interoperable choice will be"? Text in the same
> paragraph says
> both choices are interoperable. If that text is correct, I don't
> understand
> what you're saying here.
Would it be better to say "the most useful choice"? It's likely to be
the difference between a compliant MUA offering to dump the message to a
file and displaying it as a message...
>
> Published specification: RFC XXXX
>
> nit: it's actually safer to put a note saying "Note to RFC Editor:
> please replace XXXX with the RFC number when assigned" in the draft
> when you use this mechanism.
>
> Macintosh file type code(s): A uniform type identifier (UTI) of
> "public.utf8-email-message" is suggested. This conforms to
> "public.message" and "public.composite-content" but does not
> necessarily conform to "public.utf8-plain-text".
>
> technical: out of my league here, but "does not necessarily conform to"
> doesn't seem helpful. Could you provide any details that would help the
> reader understand why not?
>
> 5. Security Considerations
>
> Because UTF-8 often requires several octets to encode a single
> character, internationalized local parts may cause mail addresses to
> become longer. As specified in [RFC2822], each line of characters
> MUST be no more 998 octets, excluding the CRLF.
>
> clarity: s/CRLF/CRLF, even when UTF-8 characters are being used/
>
> Because internationalized local parts may cause email addresses to be
> longer, processes which parse, store, or handle email addresses or
> local parts must take extra care not to overflow buffers, truncate
> addresses, exceed storage allotments, or, when comparing, fail to use
> the entire length.
>
> technical: this is great advice, but I don't understand how UTF-8 changes
> the situation. If you aren't changing the 998-octet requirement, software
> that breaks for UTF-8 would also break for ASCII headers with the same
> octet
> length.
If someone uses another representation internally (for instance UTF-16),
and has a 998-character buffer, that will sometimes fit into 998 octets
of UTF-8, and sometimes not. The same goes in the other direction....
I'm sure others will think of other cases.
>
> In this specification, a user could provide an ASCII alternative
> address for a non-ASCII address. However, it is possible these two
> address go to different mailboxes, or even different persons. This
> might not be a protocol problem, but instead be the user's personal
> choice or administration policy or even be a deliberate attempt to
> deceive or cause confusion.
>
> technical: I'm not sure what the security consideration is. I'm not
> sure how a sender could detect whether a receiver IS deliberately
> attempting to deceive or cause confusion, or what a sender is supposed
> to do if this condition is detected
>
>
> clarity: I'm guessing, but if the last sentence was replaced with "This
> configuration may be based on a user's personal choice, or based on
> administration policy. We recognize that if ASCII and non-ASCII email is
> delivered to two different destinations, based on MTA capability, this
> may
> violate the principle of least astonishment, but this is not a "protocol
> problem".", it might be clearer.
>
> 6. IANA considerations
>
> IANA is requested to register the MIME type message/global, using the
> registration data in section Section 4.6.
>
> technical: OK, but it would be clearer if the registration data made
> sense
> when it moves to an IANA registry. There are places where the
> registration
> refers to "Section 5" for security considerations, for example. These
> should
> probably appear as "Section 5 of RFC XXXX", with a note to replace
> XXXX with
> the RFC number, when it's assigned. The author and contact information
> also reference sections of this draft.
I think that's editorial..... and I agree....
>
> 7. Acknowledgements
>
> Most of the content of this document is provided by John C Klensin.
> Also some significant comments and suggestions were received from
> Charles H. Lindsey, Kari Hurtta, Pete Resnick, Alexey Melnikov, Chris
> Newman, Yangwoo KO, Yoshiro YONEYA, and other members of the JET team
> and were incorporated into the document. The editor is much great
> thanks to their contribution sincerely.
>
> Nit: "The editor sincerely thanks them for their contributions."
>
> 9.2. Informative References
>
>
> [Hoffman-utf8-headers]
> Hoffman, P., "SMTP Service Extensions or Transmission of
> Headers in UTF-8 Encoding",
> draft-hoffman-utf8headers-00.txt (work in progress),
> December 2003.
>
> Technical: I know this is how we refer to Internet Drafts, but "2003"
> isn't
> "work in progress". You might s/work in progress/expired Internet
> Draft/, or
> (probably better) simply move the rest of the full citation to the
> Acknowledgements section - it didn't seem like you really expected
> anyone to
> actually refer to this reference, anyway :-)
It's a part of the history, and we can probably safely lose it.
>
> [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
> Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
> RFC 1652, July 1994.
>
> Technical: I'd think RFC 1652 would be normative - do you have to use the
> service extension to transmit utf8headers?
>
>
Nope. The header extension draft is transport-neutral; by itself, it
doesn't transport anything. The SMTP extension draft has a normative
dependency on 1652...
Hope this helped....
Harald
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf