Overview and Framework for Internationalized Email
draft-ietf-eai-framework-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the No Objection position for Jari Arkko |
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the Abstain position for David Kessens |
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2007-03-27
|
05 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2007-03-27
|
05 | Amy Vezza | [Note]: 'The Document Shepherd is Harald Alvestrand. A version removing editorial artifacts and dealing with gen-art nits will be posted as -05, but review of … [Note]: 'The Document Shepherd is Harald Alvestrand. A version removing editorial artifacts and dealing with gen-art nits will be posted as -05, but review of -04 should be fine.' added by Amy Vezza |
2007-03-19
|
05 | (System) | IANA Action state changed to No IC from In Progress |
2007-03-19
|
05 | (System) | IANA Action state changed to In Progress |
2007-03-18
|
05 | Amy Vezza | IESG state changed to Approved-announcement sent |
2007-03-18
|
05 | Amy Vezza | IESG has approved the document |
2007-03-18
|
05 | Amy Vezza | Closed "Approve" ballot |
2007-03-18
|
05 | Ted Hardie | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Ted Hardie |
2007-03-18
|
05 | Ted Hardie | [Note]: 'The Document Shepherd is Harald Alvestrand. A version removing editorial artifacts and dealing with gen-art nits will be posted as -05, but review of … [Note]: 'The Document Shepherd is Harald Alvestrand. A version removing editorial artifacts and dealing with gen-art nits will be posted as -05, but review of -04 should be fine.' added by Ted Hardie |
2007-03-17
|
05 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko |
2007-02-14
|
05 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert |
2007-02-09
|
05 | David Kessens | [Ballot Position Update] Position for David Kessens has been changed to Abstain from Discuss by David Kessens |
2007-02-09
|
05 | David Kessens | [Ballot comment] From a procedural point, I am quite unhappy that this draft changed in the middle of the telechat review period. We specifically discourage … [Ballot comment] From a procedural point, I am quite unhappy that this draft changed in the middle of the telechat review period. We specifically discourage this as it causes us to have to do a review twice. It would have been more appropriate to remove the defer review of this document to a telechat where it was actually ready. In '1. Introduction': Without the extensions specified in this document, the mailbox name is restricted to a subset of 7-bit ASCII [RFC2821]. And this is probably a good thing as far as me concerned (note that my native language includes characters that cannot be represented in 7-bit ASCII) In section '1.2. Problem statement': If the names and initials used in email addresses can be expressed in the native languages and writing systems of the users, the Internet will be perceived as more natural, especially by those whose native language is not written in a subset of a Roman-derived script. In addition, the use of internationaled email addresses will serve to fragmentize the email name address namespace, thereby fragmenting and isolating people by making it harder to communicate with people that use different charactersets and thus undermining the usefulness of email. In section '7. Experimental Targets': un-upgraded I cannot wait to see what kind of word the RFC editor is going to use instead of this one ;-). ------ Please see below for the original text of my DISCUSS: Most people are probably aware that I am not a big fan of this effort. However, this was unfortunately chartered as I seem to be the only AD with this position. As such I don't believe that I can stop this work. However, I do feel that there are inaccuracies that need to be fixed. After that has been fixed, I will change my position to an ABSTAIN. In 'Abstract:': Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. There is absolutely no requirement to use peoples own name to be able to fully use email. In fact, there is and has been a long tradition to use something else than one's own name and there are countries who use other scripts but have had no difficulties at all to use email. In section '4.3. Downgrading Mechanism for Backward Compatibility' and the selection of potential intermediate relays is under the control of the administration of the final delivery server. This seems a rather optimistic assumption. The first of these two options, that of rejecting or returning the message to the sender MAY always be chosen. This is a completely unacceptable approach: emails that conform to the spec should be delivered. emails success is based on the fact that it is an extremely robust service and delivery is almost guaranteed. Therefore, some form of backwards compatibility will be required, rejecting or returning messages doesn't follow that approach. In section '9. Security Considerations': It should be noted that one of the proposed fixes for, e.g., domain names in URLs, does not work for email local parts since they are case-sensitive. This text is ambiguous. It is not clear what the 'they' refers to. (and it might need more work as both domain names and local parts are case-insensitive as far as I know - please correct me if I am wrong!) The requirements and mechanisms documented in this set of specifications do not, in general, raise any new security issues. This is factually incorrect as explained in this section itself. Internationalization has issues for domains, and it will introduce the same issues for email while this was previously not a problem. |
2007-02-09
|
05 | (System) | Removed from agenda for telechat - 2007-02-08 |
2007-02-08
|
05 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
2007-02-08
|
05 | Jari Arkko | [Ballot discuss] I believe this is important work and long overdue. I do have a question abou the server downgrade behaviour, however: > Since the … [Ballot discuss] I believe this is important work and long overdue. I do have a question abou the server downgrade behaviour, however: > Since the final delivery SMTP server (or, to be more specific, its > corresponding mail storage agent) cannot safely assume that agents > accessing email storage will always be capable of handling the > extensions proposed here, it MAY either downgrade internationalized > emails or specially identify messages that utilize these extensions, > or both. If this done, the final delivery SMTP server SHOULD include > a mechanism to preserve or recover the original internationalized > forms without information loss to support access by UTF8SMTP-aware > agents. Does this suggest that the final server downgrades mails without knowing that the client is uncapable of reading them in the internationalized form? This seems surprising. Can you elaborate why? And what is the identification mechanism, and how does it affect POP/IMAP access to the messages? |
2007-02-08
|
05 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
2007-02-08
|
05 | Jari Arkko | [Ballot comment] > US-ASCII character repertoire, use of punycode on the right hand The term Punycode is used here without reference or definition. |
2007-02-08
|
05 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2007-02-08
|
05 | Sam Hartman | [Ballot comment] me too on removing the anchors. Besides that a really solid document. Strong disagreement with most of David's discuss, especially the parts that … [Ballot comment] me too on removing the anchors. Besides that a really solid document. Strong disagreement with most of David's discuss, especially the parts that refer to the abstract. |
2007-02-08
|
05 | David Kessens | [Ballot comment] From a procedural point, I am quite unhappy that this draft changed in the middle of the telechat review period. We specifically discourage … [Ballot comment] From a procedural point, I am quite unhappy that this draft changed in the middle of the telechat review period. We specifically discourage this as it causes us to have to do a review twice. It would have been more appropriate to remove the defer review of this document to a telechat where it was actually ready. In '1. Introduction': Without the extensions specified in this document, the mailbox name is restricted to a subset of 7-bit ASCII [RFC2821]. And this is probably a good thing as far as me concerned (note that my native language includes characters that cannot be represented in 7-bit ASCII) In section '1.2. Problem statement': If the names and initials used in email addresses can be expressed in the native languages and writing systems of the users, the Internet will be perceived as more natural, especially by those whose native language is not written in a subset of a Roman-derived script. In addition, the use of internationaled email addresses will serve to fragmentize the email name address namespace, thereby fragmenting and isolating people by making it harder to communicate with people that use different charactersets and thus undermining the usefulness of email. In section '7. Experimental Targets': un-upgraded I cannot wait to see what kind of word the RFC editor is going to use instead of this one ;-). |
2007-02-08
|
05 | David Kessens | [Ballot comment] From a procedural point, I am quite unhappy that this draft changed in the middle of the telechat review period. We specifically discourage … [Ballot comment] From a procedural point, I am quite unhappy that this draft changed in the middle of the telechat review period. We specifically discourage this as it causes us to have to do a review twice. It would have been more appropriate to remove the defer review of this document to a telechat where it was actually ready. In '1. Introduction': Without the extensions specified in this document, the mailbox name is restricted to a subset of 7-bit ASCII [RFC2821]. And this is probably a good thing as far as me concerned (note that my native language includes characters that cannot be represented in 7-bit ASCII) In section '1.2. Problem statement': If the names and initials used in email addresses can be expressed in the native languages and writing systems of the users, the Internet will be perceived as more natural, especially by those whose native language is not written in a subset of a Roman-derived script. In addition, the use of internationaled email addresses will serve to fragmentize the email name address namespace, thereby fragmenting and isolating people by making it harder to communicate with people that use different charactersets and thus undermining the usefulness of email. |
2007-02-08
|
05 | David Kessens | [Ballot discuss] Most people are probably aware that I am not a big fan of this effort. However, this was unfortunately chartered as I seem … [Ballot discuss] Most people are probably aware that I am not a big fan of this effort. However, this was unfortunately chartered as I seem to be the only AD with this position. As such I don't believe that I can stop this work. However, I do feel that there are inaccuracies that need to be fixed. After that has been fixed, I will change my position to an ABSTAIN. In 'Abstract:': Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. There is absolutely no requirement to use peoples own name to be able to fully use email. In fact, there is and has been a long tradition to use something else than one's own name and there are countries who use other scripts but have had no difficulties at all to use email. In section '4.3. Downgrading Mechanism for Backward Compatibility' and the selection of potential intermediate relays is under the control of the administration of the final delivery server. This seems a rather optimistic assumption. The first of these two options, that of rejecting or returning the message to the sender MAY always be chosen. This is a completely unacceptable approach: emails that conform to the spec should be delivered. emails success is based on the fact that it is an extremely robust service and delivery is almost guaranteed. Therefore, some form of backwards compatibility will be required, rejecting or returning messages doesn't follow that approach. In section '9. Security Considerations': It should be noted that one of the proposed fixes for, e.g., domain names in URLs, does not work for email local parts since they are case-sensitive. This text is ambiguous. It is not clear what the 'they' refers to. (and it might need more work as both domain names and local parts are case-insensitive as far as I know - please correct me if I am wrong!) The requirements and mechanisms documented in this set of specifications do not, in general, raise any new security issues. This is factually incorrect as explained in this section itself. Internationalization has issues for domains, and it will introduce the same issues for email while this was previously not a problem. |
2007-02-08
|
05 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2007-02-08
|
05 | Cullen Jennings | [Ballot comment] In section 9 it says that this work "must not leave the Internet less secure than it is". I worry that this is … [Ballot comment] In section 9 it says that this work "must not leave the Internet less secure than it is". I worry that this is too strong - I think this work inherently will make the internet slightly less secure due to the homograph issues discussed. However, I think that is a trade off worth making. I would hate to see the later protocol documents held up because of this text. |
2007-02-08
|
05 | David Kessens | [Ballot Position Update] New position, Discuss, has been recorded by David Kessens |
2007-02-07
|
05 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2007-02-07
|
05 | (System) | New version available: draft-ietf-eai-framework-05.txt |
2007-02-07
|
05 | Sam Hartman | [Ballot Position Update] Position for Sam Hartman has been changed to Yes from No Objection by Sam Hartman |
2007-02-07
|
05 | Sam Hartman | [Ballot comment] me too on removing the anchors. Besides that a really solid document. |
2007-02-07
|
05 | Sam Hartman | [Ballot Position Update] New position, No Objection, has been recorded by Sam Hartman |
2007-02-07
|
05 | Dan Romascanu | [Ballot comment] I support Lars' DISCUSS concerning the need to remove the [anchor ...] comments prior to IESG approval. |
2007-02-07
|
05 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2007-02-06
|
05 | Russ Housley | [Ballot comment] I agree with Lars, the various [anchorX...] notes need to be resolved before IESG approval. I'll let Lars hold the DISCUSS position … [Ballot comment] I agree with Lars, the various [anchorX...] notes need to be resolved before IESG approval. I'll let Lars hold the DISCUSS position on this point. Section 11 should be deleted before publication as an RFC. |
2007-02-06
|
05 | Russ Housley | [Ballot discuss] The authors have agreed to add the following text to the Security Considerations based on the SecDir Review by Paul Hoffman: … [Ballot discuss] The authors have agreed to add the following text to the Security Considerations based on the SecDir Review by Paul Hoffman: > > This work will clearly impact any systems or mechanisms that are > dependent on digital signatures or similar integrity protection for > mail headers (see also the discussion in Section 6.4). Many > conventional uses of PGP and S/MIME are not affected since they are > used to sign body parts but not headers. On the other hand, the > developing work on domain keys identified mail (DKIM [DKIM-Charter]) > will eventually need to consider this work and vice versa: while this > experiment does not propose to address or solve the issues raised by > DKIM and other signed header mechanisms, the issues will have to be > coordinated and resolved eventually if the two sets of protocols are > to co-exist. In addition, to the degree to which email addresses > appear in PKI certificates, standards addressing such certificates > will need to be upgraded to address these internationalized > addresses. Those upgrades will need to address questions of spoofing > by look-alikes of the addresses themselves. > When this text appears, I'll clear this DISCUSS position. |
2007-02-06
|
05 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
2007-02-05
|
05 | Lars Eggert | [Ballot comment] Contains a bunch of other comments ("[[anchorX...]]") that should probably be removed. |
2007-02-05
|
05 | Lars Eggert | [Ballot discuss] Section 6.5., paragraph 1: > [[anchor16: WGLC, "Framework 7": This section tentatively added to > keep track of the relevant text. … [Ballot discuss] Section 6.5., paragraph 1: > [[anchor16: WGLC, "Framework 7": This section tentatively added to > keep track of the relevant text. There may not be consensus for it > in this form (or at all).]] DISCUSS: I didn't expect such a comment in a document that makes it to the IESG. Is there consensus and the anchor should be removed, or is there still no consensus? Section 6.6., paragraph 1: > [[anchor18: WGLC, "Framework 3": This section tentatively added to > keep track of the relevant text. There may not be consensus for it > in this form (or at all).]] DISCUSS: Same issue as above. |
2007-02-05
|
05 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert |
2007-02-05
|
05 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2007-02-02
|
05 | Ted Hardie | [Note]: 'The Document Shepherd is Harald Alvestrand. A version removing editorial artifacts and dealing with gen-art nits will be posted as -05, but review of … [Note]: 'The Document Shepherd is Harald Alvestrand. A version removing editorial artifacts and dealing with gen-art nits will be posted as -05, but review of -04 should be fine.' added by Ted Hardie |
2007-02-02
|
05 | Brian Carpenter | [Ballot comment] Some changes expected following Gen-ART review at http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-eai-framework-04-sparks.txt [anchor...] notes need to be removed |
2007-02-02
|
05 | Brian Carpenter | [Ballot Position Update] New position, No Objection, has been recorded by Brian Carpenter |
2007-02-01
|
05 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Paul Hoffman. |
2007-01-30
|
05 | Ted Hardie | Placed on agenda for telechat - 2007-02-08 by Ted Hardie |
2007-01-30
|
05 | Ted Hardie | State Changes to IESG Evaluation from Waiting for Writeup by Ted Hardie |
2007-01-30
|
05 | Ted Hardie | [Ballot Position Update] New position, Yes, has been recorded for Ted Hardie |
2007-01-30
|
05 | Ted Hardie | Ballot has been issued by Ted Hardie |
2007-01-30
|
05 | Ted Hardie | Created "Approve" ballot |
2007-01-26
|
05 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2007-01-22
|
05 | Yoshiko Fong | IANA Last Call Comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2007-01-18
|
05 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Paul Hoffman |
2007-01-18
|
05 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Paul Hoffman |
2007-01-12
|
05 | Amy Vezza | Last call sent |
2007-01-12
|
05 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2007-01-11
|
05 | Ted Hardie | Last Call was requested by Ted Hardie |
2007-01-11
|
05 | Ted Hardie | State Changes to Last Call Requested from Publication Requested by Ted Hardie |
2007-01-11
|
05 | (System) | Ballot writeup text was added |
2007-01-11
|
05 | (System) | Last call text was added |
2007-01-11
|
05 | (System) | Ballot approval text was added |
2007-01-11
|
05 | Ted Hardie | [Note]: 'The Document Shepherd is Harald Alvestrand.' added by Ted Hardie |
2007-01-11
|
05 | Ted Hardie | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the … (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 is Document Shepherd. He has reviewed the document. (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? The review in the WG has been thorough, and many people who are not WG members are aware of the document. We think that the IETF would benefit from having its attention called to the document, so that people are aware that the EAI experiment is being tried, and so that any issues with the general approach taken can be raised before the WG settles on final specifications for the technical components of the proposal; this is the reason for asking for publication of this document before the technical specifications are finished. (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. The format of email addresses is embedded in a lot of other specifications, and these need to evaluate whether their specifications will be affected by this work, but that is a review of their documents, not a review of this document. (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. There are some sections in the document that might not reflect a solid informed consensus in the WG - notably sections 6.5 and 6.6. However, the WG has elected not to have further discussion on these in WG Last Call, so we can assume that the WG will not object to the text as given - the text mostly serves to point out areas where further work might be needed, and has limited immediate technical impact. (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? As far as concern has been expressed, the WG seems satisfied with this document. (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.) No. (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. Online id-nits checker complains that the domain name "any.thing.goes" does not end in "example"; this is a left-hand side of an email address, so does not constitute a break with the I-D checklist. (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. All normative references are published. The document lists the actual technical specifications it is a framework for as informative references. This is believed to be factually correct - it is not necessary to have the specifications to interpret the framework, and since it is a framework, it cannot be implemented. (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 suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the Yes. (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, there are no such sections. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. Working Group Summary The decision to not provide any means of "automatic encapsulation" of UTF-8 email addresses, but instead insist that the sender specify an alternate address for downgrading purposes, was controversial, but was definitely the decision of the working group. Document Quality This document has helped guide the development of the technical specification. Having the document stable will facilitate finishing the rest. Personnel The Document Shepherd is Harald Alvestrand. The responsible AD is Ted Hardie. |
2007-01-11
|
05 | Ted Hardie | Draft Added by Ted Hardie in state Publication Requested |
2006-12-13
|
04 | (System) | New version available: draft-ietf-eai-framework-04.txt |
2006-11-10
|
03 | (System) | New version available: draft-ietf-eai-framework-03.txt |
2006-10-12
|
02 | (System) | New version available: draft-ietf-eai-framework-02.txt |
2006-06-26
|
01 | (System) | New version available: draft-ietf-eai-framework-01.txt |
2006-05-24
|
00 | (System) | New version available: draft-ietf-eai-framework-00.txt |