Subject: [EAI] review of rfc5335bis-06

From: Joseph Yee <[email-masked]>
Date: Tue, 7 Dec 2010 01:04:10 -0500

Read RFC5335bis-06, did some mind parsing of the current ABNF, this revision is in good shape.

Just one comment on the ABNF

Section 4.3
	qcontent       =/ uQcontent

The extension is not necessary.  "qcontent" used by "quoted-string" (in RFC5322),  and "quoted-string" used by "local-part" (RFC5322); however RFC5335bis replace "local-part" with "uLocal-Part".  "uLocal-Part" has "uQuoted-String" which can do what "quoted-string" does.  "quoted-string" used by "local-part" only and no where else in RFC5322.  "qcontent" used by "quoted-string" only too.

Since "local-part" is replaced, keeping the "qcontent =/ uQcontent" cause no harm.

Note: I have no idea how to handle the escape on UTF-8 characters now (or how to present it properly in ABNF) on uQuoted-Pair.  John and Alexey had the discussion on separate thread.  

----
Editorial thought on ABNF
Section 4.4 has ABNF comment whenever the new definition replace or extend other (including self) definition.  Section 4.3 does the same on extension (ctext) but not replacement (comment, word).  I think it would be great to add ABNF comments for them, but ok if editors think it's not necessary.

------------
Other editorial changes

----
Section 4.2

s/downgraded/down-converted/

----
Section 4.3, 2nd paragraph (the paragraph after the first ABNF, page 6)
The text is hard to read, takes me quite some time to understand the impact on whole and special impact on <message-id>.

Suggested text (need more help from wordsmith, welcome all suggestions)
With these extensions defined on top of [RFC5322], the constructs build upon these allowed UTF-8 characters in all header values, including comments and quoted strings.  However, not all header values allow UTF-8 characters, the value of <msg-id> must be ASCII only which bounded by the definition of <atext> (see Section 4.5).  To accommodate such definitions, <atext> remains its printable-ASCII only definition for <msg-id>, new rule <uAtext> added for other header values which permit UTF-8 characters.

-----
Section 4.6, the paragraph of "Interoperability considerations" at page 10

original text
Systems unaware of internationalized
      headers will typically treat a message/global body part as an
      unknown attachment, while they will understand the structure of a
      message/rfc822.

suggestion
All systems understand the structure of message/rfc822, and any systems that are unaware of internationalized headers will treat the message/global body part as an unknown attachment.

Changing the order makes the flow better with the following sentence.

----
Section 5, 3rd paragraph
Although the word "downgrade" is not in the paragraph, the mechanism described in this paragraph is downgrade.  We can reword it to how MUA & MSA may change address on sender's behave and yada yada yada, even so this is out of scope.  This paragraph does not describe the right concern for header-bis anymore, and need to take out on next revision.

Best,
Joseph