Internationalized Email Headers
Note: This ballot was opened for revision 12 and is now closed.
(Chris Newman) Yes
(Ron Bonica) No Objection
(Lars Eggert) (was Discuss) No Objection
draft-ietf-eai-utf8headers, Section 4.3., paragraph 21: > [NOTE IN DRAFT: If any header needs to be restricted to disallow > this, please raise the issue on the mailing list.] Remove note for publication as an RFC. draft-ietf-eai-smtpext, INTRODUCTION, paragraph 10: > Abstract Should briefly describe what it updates in RFCs 4952, 2821 and 2822. draft-ietf-eai-smtpext, Section 3.7.3., paragraph 7: > [[anchor10: Note: The FOR parameter has been changed to match the > definition in RFC2821bis, permitting only one address in the For > clause. The group working on that document reached mailing list > consensus that the syntax in RFC 2821 that permitted more than one > address was simply a mistake.]] Doesn't look like a note to the RFC Editor - remove?
(Pasi Eronen) (was Discuss) No Objection
(Cullen Jennings) No Objection
(Tim Polk) No Objection
(Dan Romascanu) No Objection
(Mark Townsley) No Objection
(David Ward) No Objection
Magnus Westerlund No Objection
Comment (2008-07-03 for -** No value found for 'p.get_dochistory.rev' **)
I think the ABNF could be improved and be made easier to verify. I know there are a lot of baggage in the ABNF usage in RFC 2821. However, I think the following improvements could be done: 1. putting in rulenames for the rules that didn't have name in RFC 2821, like for VRFY and MAILTO. Otherwise you are not really having correct ABNF. 2. Put in the equivalent of import clause for different rules. What I mean is that for a rule defined in another document, like "atext" atext = <See section 3.2.4 of RFC 2822> That way a reader know where it is comming. It will also not show up as undefined in parsing. Thus allowing one to easier verify the real undefines from the ones that are imported from other documents.