Subject: [Gen-art] Gen-ART LC review of draft-ietf-eai-utf8headers-09.txt

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 22 Mar 2008 07:31:22 -0500

I have been selected as the General Area Review Team (Gen-ART) reviewer for
this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve
these comments along with any other Last Call comments you may receive.

Thanks,

Spencer

Document: draft-ietf-eai-utf8headers-09.txt
Reviewer: Spencer Dawkins
Review Date:  2008-03-22
IETF LC End Date: 2008-03-24
IESG Telechat date: (if known)
Summary: This draft is on the right track for publication as an Experimental 
RFC.

There are issues in the following review identified as "technical:" that 
need to be looked at.

Comments identified as "clarity:" are probably nits, but affected the 
meaning enough that I wanted to include them in the review.

Comments identified as "nit:" are not part of the review but are provided 
for editor convenience.

From idnits 2.08.04:

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The document seems to lack the recommended RFC 2119 boilerplate, even 
if
     it appears to use RFC 2119 keywords -- however, there's a paragraph 
with
     a matching beginning. Boilerplate error?

     (The document does seem to have the reference to RFC 2119 which the
     ID-Checklist requires).

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative 
references
     to lower-maturity documents in RFCs)

  == Missing Reference: 'CFWS' is mentioned on line 338, but not defined

  -- Possible downref: Undefined Non-RFC (?) reference : ref. 'CFWS'

  == Unused Reference: 'ASCII' is defined on line 606, but no explicit
     reference was found in the text

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII'

  == Outdated reference: A later version (-07) exists of
     draft-ietf-eai-downgrade-05

  == Outdated reference: A later version (-09) exists of
     draft-klensin-net-utf8-07

Comments:

1.  Introduction

1.1.  Role of this specification

   Full internationalization of electronic mail requires several
   capabilities:

   o  The capability to transmit non-ASCII content, provided for as part
      of the basic MIME specification [RFC2045], [RFC2046].
   o  The capability to express those addresses, and information related

Clarity: which addresses are "those addresses"? This is the first use of
"addresses in the document. Guessing that the bullets were reordered without
taking this into account - the third bullet says "envelope addresses".

      to and based on them, in mail header fields, defined in this

Nit: "related to and based on" is correct but doesn't parse easily. Suggest
s/related to/related to them/ or something similar.

      document.  And, finally,
   o  The capability to use international characters in envelope
      addresses, discussed in [RFC4952] and specified in
      [EAI-SMTP-extension].

   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/?

   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?

2.  Background and History

   The traditional format of email messages [RFC2822] allows only ASCII
   characters in the header fields of messages.  This prevents users
   from having email addresses that contain non-ASCII characters.  It
   further forces non-ASCII text in common names, comments, and in free
   text (such as in the Subject: field) to be encoded (as required by
   MIME format [RFC2047]).  This specification describes a change to the
   email message format that is related to the SMTP message transport

technical: there seem to be multiple occurrances of "transport" that should
be "transfer"... I won't flag them, but please /

   change described in the associated document [RFC4952] and
   [EAI-SMTP-extension], and that allows non-ASCII characters in most
   email header fields.  These changes affect SMTP clients, SMTP
   servers, mail user agents (MUAs), list expanders, gateways to other
   media, and all other processes that parse or handle email messages.

   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.

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...

   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.

   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].

clarity: is this "replaces the corresponding definitions in [RFC2822]"?

   Those syntax rules not referred to this section remain as the

clarity: s/to this/to in this/

   original definition in [RFC2822].

4.1.  UTF8 Syntax and Normalization

   These are taken from [RFC3629], but kept in this document for reasons
   of convenience.

clarity: this might be "These are normatively defined in [RFC3629], but..."

   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.

4.2.  Changes on MIME headers

   Background: Normally, transfer of message/global will be done in
   8-bit-clean channels, and body parts will have "identity" encodings,
   that is, no decoding is necessary.  In the case where a message
   containing a message/global is downgraded from 8-bit to 7-bit as
   described in [RFC1652]., an encoding may be applied to the message;
   if the message travels multiple times between a 7-bit environment and

clarity: "if the message crosses a boundary between a 7-bit environment and
an envitonment implementing UTF8SMTP multiple times..." (if I understand
correctly, you're not talking about "traveling between" the same two
environments multiple times - right?)

   an environment implementing UTF8SMTP, multiple levels of encoding may
   occur.  This is expected to be rarely seen in practice, and the
   potential complexity of other ways of dealing with the issue are
   thought to be larger than the complexity of allowing nested encodings
   where necessary.

4.3.  Syntax extensions to RFC 2822

   The following rules are intended to extend the corresponding rules in

clarity: "The following rules extend ..."

   [RFC2822] to allow UTF8 characters.

   This means that all the [RFC2822] constructs that build upon these
   will permit UTF-8 characters, including comments and quoted strings.

clarity: this paragraph should probably be split here, because it's making
two different points.

   Besides, in order to allow UTF8 characters in <addr-spec> we have to
   change the syntax of <atext>.  However, it would also lead
   <message-id> to allow UTF8 characters, which is not allowed due to
   the limitation described in Section 4.5.  So <utf8-atext> is added to
   meet this requirement.

clarity: this text seems to be written from the protocol writer's
perspective. It might be clearer to protocol readers if it said "We do not
change the syntax of <atext> in order to allow UTF8 characters in
<addr-spec>, because this would also allow UTF8 characters in <message-id>,
which is not allowed due to the limitation described in Section 4.5.
Instead, <utf8-atext> is added to meet this requirement."

   Note, however, this does not remove any constraint on the character
   set of protocol elements; for instance, all the allowed values for
   timezone in the Date: headers are still expressed in ASCII.  And
   also, none of this revised syntax affects what is allowed in a

clarity: perhaps s/affects/changes/

   <message-id>, which will still remain in pure ASCII.

4.4.  Change on addr-spec syntax

   Internationalized email addresses are represented in UTF-8.  Thus,
   all header fields containing <mailbox>es are updated to permit UTF-8
   as well as an additional, optional all-ascii alternate address.  Note
   that MSAs and MTAs may downgrade internationalized messages as
   needed.  The procedure for doing so in described in

nit: s/so in/so is/

   [EAI-downgrading].

   Below list a few possible <mailbox> representation as example.

nit: "The following list shows a few possible <mailbox> representations
as examples."

      "DISPLAY_NAME" <ASCII@ASCII>
         ; traditional mailbox format

      "DISPLAY_NAME" <non-ASCII@non-ASCII>
         ; UTF8SMTP but no ALT-ADDRESS parameter provided,
         ; message will bounce if UTF8SMTP extension is not supported

      <non-ASCII@non-ASCII>
             ; without DISPLAY_NAME and quoted string
             ; UTF8SMTP but no ALT-ADDRESS parameter provided,
         ; message will bounce if UTF8SMTP extension is not supported

      "DISPLAY_NAME" <non-ASCII@non-ASCII <ASCII@ASCII>>
         ; UTF8SMTP with ALT-ADDRESS parameter provided,
         ; ALT-ADDRESS can be used if downgrade is necessary

clarity: since you show a "no DISPLAY_NAME" example for non-ASCII@non-ASCII,
it might be helpful to show two more "no DISPLAY_NAME" examples for the
traditional format, and for UTF8SMTP with ALT-ADDRESS. I'm an extremist on
symmetry, of course, so do what seems appropriate to you.

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.

   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 ;-)

   added at the last MTA.

   <item-value> on "Received:" syntax is augmented to allow UTF-8 email
   address on "For" clause. <angle-addr> is augmented to include UTF-8
   email address on previous chapter.  To allow UTF-8 email address also
   on syntax corresponding of <addr-spec> on original syntax, <utf8-
   addr-spec> is added to <item-value>.

clarity: you lost me here. Guessing "We add <utf8-addr-spec> to
<item-value>, corresponding to <addr-spec> in current syntax, to allow UTF-8
email addresses."

   item-value      =/      utf8-addr-spec

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.

   The type message/global is similar to message/rfc822, except that it
   contains a message that can contain UTF-8 characters in the headers
   of the message or body parts. headers.  If this type is sent to a

clarity (I think): s/body parts.headers/body parts/

   7-bit-only system, it has to be encoded in [RFC2045].  Note that a
   system compliant with MIME that doesn't recognize message/global
   would treat it as "application/octet-stream" as described in Section
   5.2.4 of [RFC2046].

   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.

   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.

   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.

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 :-)

   [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? 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 23 Mar 2008 20:43:43 +0100

Soencer,

thanks for your review!

Some comments... I'm not addressing editorials...

> 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.
> 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.

> here... if they haven't been written yet, just saying "will be addressed"
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.
> 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).
>   characters; the rules in [RFC2822] for header field names are not
And this sentence is saying that. How can we express this more clearly?
> 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.
> to carry", which matches the phrasing you use for other headers below.
I think your suggestion is reasonable here.
> 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...
> 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...
> both choices are interoperable. If that text is correct, I don't 
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...
> 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.
>
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.
> 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
>
>
> 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....
> actually refer to this reference, anyway :-)
It's a part of the history, and we can probably safely lose it.
> 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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 23 Mar 2008 17:23:43 -0500

Hi, Harald,

Thanks for the quick feedback (Gen-ART reviewers like this because we can 
remember writing the review, and at least part of what we were thinking 
about :-)

Looks like mostly goodness. If we're in synch, I dropped it from this 
e-mail.

Spencer

> and covered 2 drafts; this may be why you did not find it.

Exactly right (I was scanning by subject). While I'm amazed that the downref 
isn't being called out in the Last Call announcement, I think RFC tracks and 
standards levels are so arbitrary that they are useless, so I'm not 
complaining - I was trying to figure out if there really had been a Last 
Call announcement sent, that's all.

> And this sentence is saying that. How can we express this more clearly?

Ah. You filled in the missing piece for me here. Perhaps something like

"This protocol does NOT change the [RFC2822] rules for defining header field 
names. The bodies of header fields are allowed to contain UTF-8 characters, 
but the header field names themselves must contain ASCII characters."

> 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...

"The most useful choice" seems very reasonable. The current text seems to 
contradict other text in the same paragraph.

> 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.

Thanks for the clear explanation here. This is headed in the right 
direction - I wasn't impressed with guidance that says "take extra care", 
but saying "must accommodate 998 characters (which may require more than 998 
octets, depending on the character set in use), and must not overflow 
buffers, ..." seems clear enough to me.

> Hope this helped....

Extremely. Thanks for explaining, too.

Spencer

---

From: John C Klensin <[email-masked]>
Date: Sun, 23 Mar 2008 19:35:43 -0400

One addition to Harald's comments...

--On Sunday, 23 March, 2008 20:43 +0100 Harald Tveit Alvestrand
<[email-masked]> wrote:

>>   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.

Spencer, I'm a little confused by your even asking the question,
so let me try for a slightly different answer in case you were
asking a different question.   Two of the advantages we have
with ASCII (and the closely-related ISO 8859 code character
sets) are that every character is the same length as every other
character and that every character is exactly one octet.    As a
consequence of that relationship, we have clutter in many places
in the RFC space, and probably in implementations, in which
"character" and "octet" are used interchangeably when referring
to lengths. 

I note that you carefully, and correctly, said "same octet
length" above and not the "same length in characters".   But RFC
821 talks about lengths in characters and, to my astonishment
and shame, so does section 4.5.3.1 of rfc2821bis (I've just
flagged that to the relevant ADs and will try to get it fixed
before the thing is published).   But that is the definitional
problem, and perhaps the new risk, in a nutshell.

Now, if one goes to UTF-32, the characters are all the same
length, but four octets instead of one.  An implementation that
counts characters, but allocates buffers in octets (assuming
that they are the same thing) is obviously headed for trouble,
but computing the length from the character count or vice versa
is pretty straightforward.

UTF-8 (and technically UTF-16) break both of those original
assumptions.  The characters may be more than one octet long and
one cannot compute the number of octets from the number of
characters (UTF-8 is aggressively variable-length; UTF-16
occupies either two or four octets per character depending on
whether the character has a high enough code point that
surrogate pairs are needed).

>...
>>              Hoffman, P., "SMTP Service Extensions or
>>              Transmission of Headers in UTF-8 Encoding",
>>              draft-hoffman-utf8headers-00.txt (work in
>>              progress), December 2003.
>> 
>> (probably better) simply move the rest of the full citation
>> to the Acknowledgements section - it didn't seem like you
>> really expected  anyone to

> It's a part of the history, and we can probably safely lose it.

It is referenced, and its historical role mentioned, in RFC
4952, so can almost certainly be dropped utf8headers.  

On the more general subject, I've tried raising the issue of
these documents that are referenced for historical reasons and
hence, IMO, should not say "work in progress" and should include
the exact file name so that people can find them if interested.
I've gotten  nowhere, so it is someone else's turn.   What is
really needed, I think, is a policy on these sorts of things,
corresponding modifications to tools like xml2rfc, etc.  I don't
think hiding the references in inline text is that right answer,
but that is just my opinion.

best,
    john

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 24 Mar 2008 12:46:33 +0100

Spencer Dawkins skrev:
> Hi, Harald,
>
> Thanks for the quick feedback (Gen-ART reviewers like this because we 
> can remember writing the review, and at least part of what we were 
> thinking about :-)
>
>> Last Call: draft-ietf-eai-smtpext (SMTP extension for 
>> internationalized email address) to Experimental RFC
>>
> Exactly right (I was scanning by subject). While I'm amazed that the 
> downref isn't being called out in the Last Call announcement, I think 
> RFC tracks and standards levels are so arbitrary that they are 
> useless, so I'm not complaining - I was trying to figure out if there 
> really had been a Last Call announcement sent, that's all.
I actually don't see a downref here - this is an Experimental updating a 
Draft Standard (or Full; I don't remember current status well). If 
anything, this is unusual as an upref, not a downref....
>> ASCII), but changes the definition of header field BODIES (which used 
>> to be ASCII, but are now UTF-8).
>>>
> "This protocol does NOT change the [RFC2822] rules for defining header 
> field names. The bodies of header fields are allowed to contain UTF-8 
> characters, but the header field names themselves must contain ASCII 
> characters."
That seems like a good editorial suggestion to me. Thanks!
>> the difference between a compliant MUA offering to dump the message 
>> to a file and displaying it as a message...
>
> "The most useful choice" seems very reasonable. The current text seems 
> to contradict other text in the same paragraph.
>
>> 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.
>
> direction - I wasn't impressed with guidance that says "take extra 
> care", but saying "must accommodate 998 characters (which may require 
> more than 998 octets, depending on the character set in use), and must 
> not overflow buffers, ..." seems clear enough to me.
I think it's more like "must accomodate 998 octets, and not send more 
than 998 octets, even though the relationship between this number and 
the number of UTF-8 characters is not a simple one". I see that Klensin 
has picked up on this for 2821, too.

Thanks for the review!

                Harald

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 24 Mar 2008 09:09:31 -0500

I sigh in my own general direction ;-)

>> downref isn't being called out in the Last Call announcement, I think RFC 
>> tracks and standards levels are so arbitrary that they are useless, so 
>> I'm not complaining - I was trying to figure out if there really had been 
>> a Last Call announcement sent, that's all.

Of course, you're right - I should not be calling this a downref, because it 
has nothing to do with normatively referring to a document that's at a lower 
maturity level/standards track level.

I should have just said "non-standards-track document updating a 
standards-track document".

And, as the document points out, people who participate in the experiment 
are affected, people who do not participate in the experiment are not, and 
it's not at all clear how to do the experiment without exactly this document 
chain.

So, I'm good.

Thanks,

Spencer