Subject: [EAI] WG Co-chair review of 5335bis (headers extension)

From: John C Klensin <[email-masked]>
Date: Mon, 29 Nov 2010 19:01:50 -0500

Hi.

The same preliminary comments that apply to 5336bis apply to
this document as well.  It is in fairly poor shape in some areas
and needs a significant revision --which I hope we can see in
the next few days-- before it will be ready for handoff to the
IESG.  Those who promised to review it for the WG should be
thinking very carefully about why they did not notice these
points.

Like 5336bis, there are artifacts of in-transit downgrading in
this document and some fairly poor and confusing writing...
enough of both to create significant risk of getting bogged down
in IETF Last Call and/or the IESG.

As with the other review, I'm not going to repeat comments made
by others in the last few days except by accident.  I expect the
authors will reflect both those comments and these in a new
version.

(0) To reprise some other comments, the ABNF is "difficult" --
some errors and other things just confusingly structured.
Neither Alexey nor I should have to straighten that sort of
thing out: if the WG doesn't care enough, then we don't care
enough to have these things on the Standards Track.  Except as
the result of other comments, I have not provided additional
comments on the ABNF or references to it -- waiting for a clean
copy.

(1) Abstract.   The first two sentences are either somewhat
redundant or just hard to read.  I think they are ok
technically, but...

(2) Section 1.2 updates RFC 2045 twice, one in the first
paragraph and once in the second.  It cannot update 2045 in the
first paragraph and then "also update[s]" it in the second.

(3) Section 2, first paragraph, should be explicit that "common
names" as used here are the same as "display-names" in 5322.  It
would be even better to use the term display-name throughout and
indicate here that this is usually (but not required to be) the
user's common, ordinary, name.

(4) Section 2, next-to-last paragraph.  It is not clear what
this bit of narrative text is doing here, even though it is
"background".  Please refer to Framework to the extent possible;
if this material belongs in Framework but isn't there, it would
be better to open Framework than to have these apparently-random
comments in this document.  That comment may apply to other
parts of Section 2 as well, this particular paragraph is just
the most problematic.  If the revision of this document does not
remove that basic material, the references need to be checked
and the Note in Draft removed.

(5) Section 3, paragraph 1.  Again more confusing than it needs
to be.  If ASCII strings are UTF-8 strings and ASCII characters
are UTF-8 characters, then some of them cannot be _not_ UTF-8
characters.  And an implicit forward reference from a
terminology section to a piece of ABNF syntax is bad writing at
best.  If you have to invent a special term, do so ("non-ASCII
string" as a string that contains at least one non-ASCII
character is popular in other documents).

(6)  For Section 4.1 and the definition of uText in Section 4.3,
please review my comments about C0 and C1 control characters in
the 5336bis review.   FWIW, I'd personally prefer an informal
definition of UTF-8 and a pointer to 5234 and 3629 rather than
trying to dress this document up with extra ABNF.  Knowing that
UTF-8 can consist of one to four octets per character and how
the octets are structured is really of no use here and hence,
IMO, having those definitions here are not "reasons of
convenience".

(7) In Section 4.1, last paragraph, I think the "no NFKC"
explanation is the exceptional case, i.e., "except" should be
removed from "some names except in unusual...".   I think I
might have written that sentence, but it is still wrong.

(8) Section 4.2, first sentence, "to all subtypes" should be "to
any subtype".  The slash after "message/" should be called to
the attention of the RFC Editor for their preference.

(9) In Section 4.3 note that UTF8-xtra-char includes the C1
controls.  So uAtext excludes the C0 controls but not the C1
controls.  That just makes no sense.   The paragraph starting
"Note" at the end of that section largely repeats the content of
the earlier paragraph in the same section that starts "This
means...".  Please clean this up.

(10) Section 4.4: See my comments in the 5336bis review about
"addr-spec" and "mailbox".  The two documents should be
consistent to the degree possible and _very_ clear.

(11) The examples at the end of Section 4.4 do not conform to
the preferred use of "example" domains.  While we know what
notations like "ASCII@ASCII" mean within the WG, it needs
explanation here, ideally using the expected forms.  Some blank
lines between examples would make this material much more
readable.  And "bounce" should be changed to "rejected" unless
you really mean bounce and bounce exclusively (again, see
comments on 5336bis).

(12) Section 4.5 is hard to follow, especially in the first
paragraph.  If you are just repeating information from 5336bis,
please be explicit about that or, better yet, summarize and
reference.   Don't repeat basic facts about email (e.g.,
material that would be known to anyone who understands 5322)
without indicating that is what you are doing.  Otherwise, you
just confuse people about what is part of this spec (set of
extensions) and what is "normal".

(13) The first bullet under Section 4.6 either has me completely
confused or is just wrong.   If a message contains UTF-8
material in the outermost headers but all body parts use plain
ASCII headers, then it is not a message/global creature at all,
even insofar as message/global is a proper superset of
message/rfc822.  If that message is then embedded,
message/global would be required, but that is not what this
Section says.

(14) The rest of Section 4.6 contains several contradictory
statements.  The parenthetical note in paragraph 2 says "doesn't
recognize... MUST..."  (a MIME requirement not dependent on this
spec) but the "Interoperability considerations" portion of the
template says "will typically".  Under "Encoding considerations"
it says "8-bit or binary... where permitted" but "Restrictions
on usage" says "MUST... unless".   And, fwiw, "MUST unless" is
usually spelled "SHOULD" unless you have a strong reason for
that choice of language.   See earlier notes about contact
information: please use the WG, WG list, etc.

(15) In Section 5, the second and third paragraphs discuss the
same material and appear redundant.  Please merge them.  The
fourth paragraph talks about alternate addresses.  Has No One
reviewed this text in recent weeks?

regards,
    john

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 30 Nov 2010 10:52:09 +0900

> character is popular in other documents).

"non-ASCII-only string" or "not-ASCII-only string" is slightly longer, 
but somewhat more precise.

Regards,    Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 30 Nov 2010 12:30:38 +0900

> but somewhat more precise.

Reconsidering, I think it's important to write these as "non ASCII-only 
string" or "not ASCII-only string". The reverse, "non-ASCII only string" 
or "not-ASCII only string" is not what is meant, and having both hyphens 
is confusing.

Regards,   Martin.