SMTP Extension for Internationalized Email Addresses
draft-ietf-eai-smtpext-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
13 | (System) | post-migration administrative database adjustment to the No Objection position for Pasi Eronen |
2012-08-22
|
13 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
2008-09-08
|
13 | (System) | This was part of a ballot set with: draft-ietf-eai-utf8headers |
2008-08-12
|
13 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2008-08-12
|
13 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2008-08-12
|
13 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2008-08-11
|
13 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2008-08-11
|
13 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2008-07-18
|
13 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2008-07-18
|
13 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2008-07-18
|
13 | (System) | IANA Action state changed to In Progress |
2008-07-17
|
13 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2008-07-17
|
13 | Cindy Morgan | IESG has approved the document |
2008-07-17
|
13 | Cindy Morgan | Closed "Approve" ballot |
2008-07-17
|
13 | Chris Newman | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Chris Newman |
2008-07-17
|
13 | Pasi Eronen | [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen |
2008-07-13
|
13 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert |
2008-07-08
|
13 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-07-08
|
13 | (System) | New version available: draft-ietf-eai-smtpext-13.txt |
2008-07-04
|
13 | (System) | Removed from agenda for telechat - 2008-07-03 |
2008-07-03
|
13 | Cindy Morgan | from IESG Evaluation by Cindy Morgan |
2008-07-03
|
13 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
2008-07-03
|
13 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2008-07-03
|
13 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2008-07-03
|
13 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2008-07-03
|
13 | Pasi Eronen | [Ballot discuss] The security considerations text in utf8headers needs to include a (normative) reference to RFC 4952. In addition, the text should explictly point … [Ballot discuss] The security considerations text in utf8headers needs to include a (normative) reference to RFC 4952. In addition, the text should explictly point out that many current email security mechanisms, such as DKIM, S/MIME, and OpenPGP are specified for RFC 2822 compliant messages, and may not correctly work with messages that have UTF-8 headers. (There is some text in RFC 4952 about this, but since this is a pretty serious issue, repeating it with 1-2 sentences would IMHO be useful.) |
2008-07-03
|
13 | Pasi Eronen | [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen |
2008-07-03
|
13 | Magnus Westerlund | [Ballot comment] I think the ABNF could be improved and be made easier to verify. I know there are a lot of baggage in the … [Ballot comment] 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 = 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. |
2008-07-03
|
13 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2008-07-02
|
13 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2008-07-02
|
13 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2008-06-30
|
13 | Lars Eggert | [Ballot comment] draft-ietf-eai-utf8headers, Section 4.3., paragraph 21: > [NOTE IN DRAFT: If any header needs to be restricted to disallow > this, … [Ballot comment] 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? |
2008-06-30
|
13 | Lars Eggert | [Ballot discuss] draft-ietf-eai-utf8headers, Section 1.2., paragraph 1: > This document updates section 6.4 of RFC 2045. DISCUSS: Add this to the … [Ballot discuss] draft-ietf-eai-utf8headers, Section 1.2., paragraph 1: > This document updates section 6.4 of RFC 2045. DISCUSS: Add this to the first-page header and abstract. draft-ietf-eai-utf8headers, Section 1.2., paragraph 3: > This document also updates [RFC2822] and MIME DISCUSS: Ditto. And please provide an RFC number for "MIME". |
2008-06-30
|
13 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert |
2008-06-23
|
13 | Chris Newman | [Ballot Position Update] New position, Yes, has been recorded for Chris Newman |
2008-06-23
|
13 | Chris Newman | Ballot has been issued by Chris Newman |
2008-06-23
|
13 | Chris Newman | Created "Approve" ballot |
2008-06-23
|
13 | Chris Newman | State Changes to IESG Evaluation from Waiting for AD Go-Ahead::External Party by Chris Newman |
2008-06-23
|
13 | Chris Newman | Placed on agenda for telechat - 2008-07-03 by Chris Newman |
2008-04-04
|
12 | (System) | New version available: draft-ietf-eai-smtpext-12.txt |
2008-03-26
|
13 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Barry Leiba. |
2008-03-26
|
13 | Chris Newman | State Changes to Waiting for AD Go-Ahead::External Party from Waiting for AD Go-Ahead by Chris Newman |
2008-03-26
|
13 | Chris Newman | Waiting for document shepherd to confirm all last call comments have been addressed (either via document update or response to the person who made the … Waiting for document shepherd to confirm all last call comments have been addressed (either via document update or response to the person who made the comment). |
2008-03-24
|
13 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2008-03-18
|
13 | Amanda Baber | IANA Last Call comments: IANA has questions. Action 1: Upon approval of this document, the IANA will make the following assignments in the "MAIL Parameters" … IANA Last Call comments: IANA has questions. Action 1: Upon approval of this document, the IANA will make the following assignments in the "MAIL Parameters" registry located at http://www.iana.org/assignments/mail-parameters sub-registry "SMTP Service Extensions" Keywords Description Reference ------------------- ---------------------------------- --------- UTF8SMTP Email Address Internationalizatoin [RFC-eai-smtpext-11] Action 2: Upon approval of this document, the IANA will make the following assignments in the "SMTP Enhanced Status Codes" registry located at http://www.iana.org/assignments/TBD sub-registry "class sub-codes" Either the IANA Considerations section or section 2.5 should be expanded to be more clear about exactly what information needs to be inserted into the registry. Action 3: Upon approval of this document, the IANA will make the following assignments in the "MAIL Parameters" registry located at http://www.iana.org/assignments/mail-parameters sub-registry "Mail Transmission Types" sub-registry "WITH protocol types" WITH protocol Description Reference types --------------- ---------------------------- ---------------------- UTF8SMTP UTF8SMTP with Service [RFC-eai-smtpext-11] Extensions UTF8SMTPA UTF8SMTP with SMTP AUTH [RFC4954] [RFC-eai-smtpext-11] UTF8SMTPS UTF8SMTP with STARTTLS [RFC3207] [RFC-eai-smtpext-11] UTF8SMTPSA UTF8SMTP with both [RFC3207] [RFC4954] STARTTLS and SMTP AUTH [RFC-eai-smtpext-11] We understand the above to be the only IANA Actions for this document. |
2008-03-13
|
13 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Barry Leiba |
2008-03-13
|
13 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Barry Leiba |
2008-03-10
|
13 | Amy Vezza | Last call sent |
2008-03-10
|
13 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2008-03-10
|
13 | Chris Newman | Last Call was requested by Chris Newman |
2008-03-10
|
13 | (System) | Ballot writeup text was added |
2008-03-10
|
13 | (System) | Last call text was added |
2008-03-10
|
13 | (System) | Ballot approval text was added |
2008-03-10
|
13 | Chris Newman | State Changes to Last Call Requested from Publication Requested by Chris Newman |
2008-03-10
|
13 | Chris Newman | AD review of draft-ietf-eai-smtpext-11.txt NOTE: Unresolved normative reference to [SMTP-codes] will result in this document getting stuck waiting at some point in the process (most … AD review of draft-ietf-eai-smtpext-11.txt NOTE: Unresolved normative reference to [SMTP-codes] will result in this document getting stuck waiting at some point in the process (most likely the RFC editor queue, although the IESG could decide to block earlier). Otherwise this document is of unusually high quality, I have no issues with the current content. AD review of draft-ietf-eai-utf8headers-09.txt One minor technical issue, treat as ordinary last call comment and fix (after last call) if you agree: Section 4.3 > set of protocol elements; for instance, all the allowed values for > timezone in the Date: headers are still expressed in ASCII. And This is not a good example because the only allowed generate syntax for timezone in RFC 2822 is a numeric offset. I suggest using month-name as an example instead. I started writing a few editorial nits, then realized this needed more extensive editorial work. I decided to instead expect the RFC editor to fix these issues and I plan to include the following in the document ballot: Note to RFC Editor The document draft-ietf-eai-utf8headers-09.txt has a number of grammar issues and may require extensive editorial work, please plan accordingly. |
2008-02-22
|
13 | Chris Newman | Writeup for the documents: draft-ietf-eai-smtpext-11 draft-ietf-eai-utf8heders-09 destined for Experimental status. (the writeup for the linked draft-ietf-eai-dsn-05 is sent separately) (1.a) Who is the Document … Writeup for the documents: draft-ietf-eai-smtpext-11 draft-ietf-eai-utf8heders-09 destined for Experimental status. (the writeup for the linked draft-ietf-eai-dsn-05 is sent separately) (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Harald Alvestrand. Yes. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes. No. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? I believe the WG as a whole understands and agrees that the documents are a solid description of the chosen approach. See below for the "possible conflict". (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) Charles Lindsey and Frank Ellermann have argued strongly against a specific point in the specification: The transmission of EAI messages in a subtype of "message". Charles has indicated that he will re-raise this issue at Last Call time. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. MIME type review was asked for on January 21, 2008; one positive comment has been recieved as of February 22. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes. SMTP: There are normative references to -dsn and -utf8hdr, which are part of this package, as well as mailesc-registry, which should go forward ahead of it. UTF8: There are normative references to -smtpext, which is part of this package. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Yes. No new registries, -SMTP has some new values to register. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes. One minor ABNF error has been identified, and will be corrected with other Last Call comments. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary These two documents form the core specification for an extension to SMTP and RFC 2822 that allow the free use of UTF-8 in message headers without encoding. This includes the use of non-ASCII characters in email addresses, both on the left and right hand sides of the @ character. Working Group Summary The WG was chartered to explore one particular approach to email internationalization, and succeeded in keeping to that charter. There was extensive discussion of one particular design choice - on which MIME type to use. Document Quality The documents have been extensively reviewed by people with mail expertise. There have been reports of implementations, but no interoperability tests have been reported to date. |
2008-02-22
|
13 | Chris Newman | Draft Added by Chris Newman in state Publication Requested |
2008-02-22
|
13 | Chris Newman | [Note]: 'Harald Alvestrand is document shepherd.' added by Chris Newman |
2008-01-28
|
11 | (System) | New version available: draft-ietf-eai-smtpext-11.txt |
2008-01-07
|
10 | (System) | New version available: draft-ietf-eai-smtpext-10.txt |
2007-11-15
|
09 | (System) | New version available: draft-ietf-eai-smtpext-09.txt |
2007-09-04
|
08 | (System) | New version available: draft-ietf-eai-smtpext-08.txt |
2007-06-29
|
07 | (System) | New version available: draft-ietf-eai-smtpext-07.txt |
2007-06-04
|
06 | (System) | New version available: draft-ietf-eai-smtpext-06.txt |
2007-04-11
|
05 | (System) | New version available: draft-ietf-eai-smtpext-05.txt |
2007-03-06
|
04 | (System) | New version available: draft-ietf-eai-smtpext-04.txt |
2007-02-13
|
03 | (System) | New version available: draft-ietf-eai-smtpext-03.txt |
2006-10-25
|
02 | (System) | New version available: draft-ietf-eai-smtpext-02.txt |
2006-07-26
|
01 | (System) | New version available: draft-ietf-eai-smtpext-01.txt |
2006-05-12
|
00 | (System) | New version available: draft-ietf-eai-smtpext-00.txt |