Post Office Protocol Version 3 (POP3) Support for UTF-8
draft-ietf-eai-rfc5721bis-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-03-11
|
08 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2012-11-26
|
08 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2012-11-26
|
08 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2012-11-22
|
08 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2012-11-21
|
08 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2012-11-21
|
08 | (System) | IANA Action state changed to In Progress |
2012-11-21
|
08 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2012-11-21
|
08 | Amy Vezza | IESG has approved the document |
2012-11-21
|
08 | Amy Vezza | Closed "Approve" ballot |
2012-11-21
|
08 | Amy Vezza | Ballot approval text was generated |
2012-11-16
|
08 | Pete Resnick | Ballot writeup was changed |
2012-11-15
|
08 | Ben Campbell | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Ben Campbell. |
2012-10-21
|
08 | Jiankang Yao | New version available: draft-ietf-eai-rfc5721bis-08.txt |
2012-09-27
|
07 | Cindy Morgan | State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2012-09-27
|
07 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-09-27
|
07 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-09-27
|
07 | Ralph Droms | [Ballot comment] Barry tells me the working group considered and rejected marking this document as "updates RFC 2449". I'd like the working group to … [Ballot comment] Barry tells me the working group considered and rejected marking this document as "updates RFC 2449". I'd like the working group to reconsider that decision, considering this text from the IANA considerations: Section 2 and 3 of this specification update two capabilities ("UTF8" and "LANG") to the POP3 capability registry [RFC2449]. Section 5 of this specification also adds one new response code ("UTF8") to the POP3 response codes registry [RFC2449]. It seems to me anyone implementing POP3 from scratch or updating an existing implementation should read this document as part of that implementation. |
2012-09-27
|
07 | Ralph Droms | Ballot comment text updated for Ralph Droms |
2012-09-27
|
07 | Adrian Farrel | [Ballot comment] Please ask the RFC editor to remove section 8 before publication. --- When a new document obsoletes an old one, it is really … [Ballot comment] Please ask the RFC editor to remove section 8 before publication. --- When a new document obsoletes an old one, it is really nice to include a short section stating the changes. I think it is unfortunate that this document doesn't include such a section. |
2012-09-27
|
07 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2012-09-26
|
07 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2012-09-25
|
07 | Sean Turner | [Ballot comment] Along the same lines as Stephen's suggestion in response to Chris: s7: A bit more precise ?: OLD: A mechanism to protect … [Ballot comment] Along the same lines as Stephen's suggestion in response to Chris: s7: A bit more precise ?: OLD: A mechanism to protect the integrity of the session, such as Transport Layer Security (TLS) [RFC2595] can be used to defeat such attacks. NEW: A mechanism to protect the integrity of the session can be used to defeat such attacks, e.g., issuing the STLS [RFC2595] command before issuing the LANG command. |
2012-09-25
|
07 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2012-09-25
|
07 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-09-25
|
07 | Stephen Farrell | [Ballot comment] (Sorry, ignore the previous mail, I attached the wrong comment to the wrong document.) I checked the diff with 5721 but its not … [Ballot comment] (Sorry, ignore the previous mail, I attached the wrong comment to the wrong document.) I checked the diff with 5721 but its not that useful since there are a lot of changes. Apologies in advance if I comment on something that's unchanged from there and feel free to ignore such comments. - 2.1: Why mustn't clients issue the STLS command after UTF8? I don't get that. |
2012-09-25
|
07 | Stephen Farrell | Ballot comment text updated for Stephen Farrell |
2012-09-25
|
07 | Stephen Farrell | [Ballot comment] I checked the diff with 5738 but its not that useful since there are a lot of changes. Apologies in advance if I … [Ballot comment] I checked the diff with 5738 but its not that useful since there are a lot of changes. Apologies in advance if I comment on something that's unchanged from there and feel free to ignore such comments. - section 1: "Most of this specification" is an odd phrase. It'd be nicer if you could be more precise, or maybe just better to s/Most of this/This/ - p4, 3rd last para says that the "server MUST NOT send UTF-8 in quoted strings to the client unless the client has indicated support using the "ENABLE UTF8=ACCEPT" command." Earlier you said that the "UTF8=ONLY" capability implies this, so I guess that this MUST NOT also doesn't apply in that case. But is that clear enough? Maybe s/using the "ENABLE UTF8=ACCEPT" command/using the "ENABLE UTF8=ACCEPT" command or "UTF8=ONLY" capability/ would be better? - section 7 says that signatures might "not be applicable" to the variant version, which reads oddly to me. I think it'd be better to say that signatures may not longer be verifiable with the variant message. (The next two questions maybe apply to all four documents in this set, but I'll ask 'em here anyway.) - I have a security question, the answer to which isn't clear to me, but maybe you can help. Is there any situation where a mailbox name or a user id might contain non-ascii characters and where the IMAP server will treat those as equivalent to some mapping to ascii? For example if joerg can use an umlaut or not, but has only set up one of the two, is there ever a threat that I could get access to joerg's mail by setting up an account with the one he's not using? I guess I'm wondering if it might be worth adding a warning about that kind of mapping. I don't know if that belongs here or not, or is already somewhere else, since its really like the general problem of "cousin" domains in phishing (paypa1 etc), but I guess some discussion somewhere would be good. - Can EAI make it more likely that a sender would encrypt a message for the wrong recipient? If so, is that worth noting? Not sure where'd be right for that, but I wondered. |
2012-09-25
|
07 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2012-09-25
|
07 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2012-09-24
|
07 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2012-09-24
|
07 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-09-24
|
07 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-09-24
|
07 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-09-23
|
07 | Russ Housley | [Ballot comment] The abstract should mention that this document obsoletes RFC 5721. |
2012-09-23
|
07 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-09-22
|
07 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2012-09-21
|
07 | Pete Resnick | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-09-21
|
07 | Pete Resnick | [Ballot comment] In section 3.1: The character encoding format of maildrops may not be UTF-8 or ASCII. That sentence is wrong. Please correct. |
2012-09-21
|
07 | Pete Resnick | Ballot comment text updated for Pete Resnick |
2012-09-21
|
07 | Pete Resnick | Ballot has been issued |
2012-09-21
|
07 | Pete Resnick | [Ballot Position Update] New position, Yes, has been recorded for Pete Resnick |
2012-09-21
|
07 | Pete Resnick | Created "Approve" ballot |
2012-09-21
|
07 | Pete Resnick | Placed on agenda for telechat - 2012-09-27 |
2012-09-20
|
07 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-09-17
|
07 | Pearl Liang | IANA has reviewed draft-ietf-eai-rfc5721bis-07 and has the following comments: IANA understands that, upon approval of this document, there are three IANA actions which must be … IANA has reviewed draft-ietf-eai-rfc5721bis-07 and has the following comments: IANA understands that, upon approval of this document, there are three IANA actions which must be completed. First in the POP3 Capabilities subregistry of the Post Office Protocol version 3 (POP3) Extension Mechanism registry located at: http://www.iana.org/assignments/pop3-extension-mechanism/pop3-extension- mechanism.xml The entry for CAPA Tag "UTF8" currently reads: CAPA TAG: UTF8 CAPA Args: USER Added Cmds: UTF8 Cmds Affected: USER, PASS, APOP, LIST, TOP, RETR List: both Diffs: no Cmd Valid: AUTHORIZATION Reference: [RFC5721] It should be changed to the following: CAPA TAG: UTF8 CAPA Args: USER Added Cmds: UTF8 Cmds Affected: USER, PASS, APOP, LIST, TOP, RETR List: both Diffs: no Cmd Valid: AUTHORIZATION Reference: [ RFC-to-be ] Second, also in the POP3 Capabilities subregistry of the Post Office Protocol version 3 (POP3) Extension Mechanism registry located at: http://www.iana.org/assignments/pop3-extension-mechanism/pop3-extension- mechanism.xml The entry for CAPA Tag "LANG" currently reads: CAPA TAG: LANG CAPA Args: none Added Cmds: LANG Cmds Affected: all List: both Diffs: no Cmd Valid: AUTHORIZATION TRANSACTION Reference: [RFC5721] It should be changed to the following: CAPA TAG: LANG CAPA Args: none Added Cmds: LANG Cmds Affected: all List: both Diffs: no Cmd Valid: AUTHORIZATION TRANSACTION Reference: [ RFC-to-be ] Third, in the POP3 Response Codes subregistry of the Post Office Protocol version 3 (POP3) Extension Mechanism registry located at: http://www.iana.org/assignments/pop3-extension-mechanism/pop3-extension- mechanism.xml a new POP3 Response Code should be registered as follows: Response Code: UTF8 Response Types: -ERR Commands: LIST, TOP, RETR Reference: [ RFC-to-be ] IANA understands that these three actions are the only ones that need to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. |
2012-09-13
|
07 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Almost Ready. Reviewer: Yoav Nir. |
2012-09-07
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Yoav Nir |
2012-09-07
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Yoav Nir |
2012-09-06
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ben Campbell |
2012-09-06
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ben Campbell |
2012-09-06
|
07 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (POP3 Support for UTF-8) to Proposed … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (POP3 Support for UTF-8) to Proposed Standard The IESG has received a request from the Email Address Internationalization WG (eai) to consider the following document: - 'POP3 Support for UTF-8' as Proposed Standard Please note: This document is one a set of four interdependent documents: draft-ietf-eai-5738bis draft-ietf-eai-popimap-downgrade draft-ietf-eai-rfc5721bis draft-ietf-eai-simpledowngrade These documents should be reviewed, evaluated, and understood together. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-09-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification extends the Post Office Protocol version 3 (POP3) to support UTF-8 encoded international string in user names, passwords, mail addresses, message headers, and protocol-level textual strings. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5721bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5721bis/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-09-06
|
07 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2012-09-06
|
07 | Amy Vezza | Last call announcement was changed |
2012-09-06
|
07 | Pete Resnick | Last call was requested |
2012-09-06
|
07 | Pete Resnick | Ballot approval text was generated |
2012-09-06
|
07 | Pete Resnick | State changed to Last Call Requested from AD Evaluation |
2012-09-04
|
07 | Pete Resnick | Document Shepherd Writeup - draft-ietf-eai-rfc5721bis-07 (EAI-POP) Date: 2012-08-22 Shepherd: John C Klensin, john-ietf@jck.com 1. What type of … Document Shepherd Writeup - draft-ietf-eai-rfc5721bis-07 (EAI-POP) Date: 2012-08-22 Shepherd: John C Klensin, john-ietf@jck.com 1. What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. This set of documents are all protocol specifications, following up earlier Experimental treatment of POP3 and IMAP access to messages with internationalized envelopes and/or header fields. 2. 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 Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. These documents make up a set of four that are interdependent and should be reviewed, evaluated, and understood together. Their abstracts have been examined and verified to sufficiency to describe the individual documents. The abstract for this particular document reads: This specification extends the Post Office Protocol version 3 (POP3) to support UTF-8 encoded international string in user names, passwords, mail addresses, message headers, and protocol-level textual strings. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Short answer: No. Longer answer: The WG had extensive and constructive discussions about the role of "downgrading" (e.g., converting a message stored on the server that contains non-ASCII header or envelope information) in the transition to an all-i18n environment. Some of those issues and tradeoffs are discussed in draft-ietf-eai-popimap-downgrade and draft-ietf-eai-simpledowngrade. In some cases, the best strategy may be to "hide" those messages that cannot be delivered without change to legacy clients either with or without some attempt at an error message. A complete treatment of those options is impossible because the optimal strategies will depend considerably on local circumstances. Consequently the base IMAP and POP3 documents are no longer dependent on particular downgrading choices and that two methods presented are, to a considerable extent, just examples. They are recommended as alternative Standards Track documents because they are protocol specifications and their sometimes-subtle details have have been carefully worked out, even though the WG has no general recommendation to make between them (or other strategies). While opinions differ in the WG about which downgrading mechanisms are likely to see the most use, if any, consensus is strong that these four documents represent the correct output. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Some development and interoperability testing has occurred and is progressing. There are strong commitments in various countries to implement and deploy the EAI (more properly, SMTPUTF8) messages and functions specified in RFCs 6530 through 6533. Those messages will be inaccessible to many users without POP3 and IMAP support, so these specifications are quite likely to be implemented and deployed in a timely fashion. Reviewers who made particular contributions prior to IETF Last Call are acknowledged in the documents. See Section 3 for additional information. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd: John C Klensin Responsible Area Director: Pete Resnick Note that Pete Resnick is listed as a co-author on one of these documents as a result of contributions well before he became AD (and primarily to its the Experimental predecessor. He has not been actively involved in an author or editor role since joining the IESG. 3. Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd, with assistance from the other co-chair, did extensive, line by line and paragraph by paragraph reviews during the WG LC window with the intention of identifying and eliminating as many issues that might otherwise be spotted during IETF review as possible. Those reviews were posted to the WG mailing list; the documents being submitted include changes made on that basis. 4. Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This particular document shepherd has almost always been concerned about breadth and quality of reviews in the IETF. HOwever, the co- chairs have identified areas of expertise and perspective needed for reviews of the specifications in these documents and their relationship to the widely-deployed and well-tested IMAP and POP3 specifications and are confident that the reviews are adequate. Although considerable improvements have been made in readability and editorial and technical quality, the base IMAP (draft-ietf-eai-5738bis) and POP (draft-ietf-eai-rfc5721bis) documents represent an orderly and uncontroversial evolution from their Experimental predecessors. It is probably worth pointing out, as draft-ietf-eai-5738bis does, that the transition to general adoption of SMTPUTF8 mail will not be an easy one in many environments. In the case of the transport and mail header specifications of RFCs 6530ff, the model that permits a sender to test whether the potential receiver can handle the message is clear, as is an orderly response if it is not (even if that response may not be completely satisfactory from the user's standpoint). That same relationship does not apply to these specifications because, for many environments, a POP3 or IMAP server must be prepared to deal with clients who do not have the needed capabilities and there is no completely satisfactory way with either protocol to either tell a client that it cannot access a message that is known to be waiting nor to deliver an intact version of the message (where "intact" includes, e.g., being able to pass signature verification on body parts and/or headers). 5. Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. It is our strong belief that all such issues and perspectives have been addressed by the WG and reviews already obtained. 6. Describe any specific concerns or issues that the Document Shepherd has 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. All such substantive issues have been identified and resolved within the WG and incorporated into the documents. I do expect that IETF Last Call will turn up demands to solve problems that the WG has concluded are impossible (some discussed above) but it is unlikely that any will be a significant surprise. The WG has strong consensus that some interoperability difficulties can be anticipated during the period in which these protocols are deployed. Those difficulties are inevitable in the absence of an effective flag day (possible for POP and IMAP in some installations but not generally). The alternative is to not deploy changes of this sort at all, but the adoption of RFCs 6530-6533 eliminated that possibility. To the extent possible, the transitional issues have been removed from this document, discussed briefly in draft-ietf-eai-5738bis and treated at more length in the two "downgrade" documents. That strategy should most easily permit the transitional issues and protocols to be put aside once the base IMAP and POP two protocols (and the internationalization of email envelope and header field protocols more generally) are widely deployed. The WG has an outstanding question about the status of this document (and draft-ietf-eai-5738bis) relative to whether or not they update the base IMAP and POP specifications. The WG's conclusion is that they do not -- these specifications are extensions, not required changes to the base specifications -- and the documents for IETF Last Call were produced on that basis. The WG also notes that SMTP extensions and mail header field additions have generally not been identified as updating the base email specifications. However, the topic raises a more general issue that we believe the IESG should address. If the IESG concludes that all such extension documents should be listed as updating the corresponding base specifications, the WG has no objection to these documents being modified accordingly. 7. Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Authors of all four documents have been queried to verify that they have examined BCP 78 and 79 and are in compliance with them. The three authors who have not yet replied are expected to be in Vancouver and acknowledgments will be extracted from them there. 8. Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been filed on any of the four documents. 9. 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? The WG's meeting participants and mailing list have included a rather large proportion of people who are anxious to see well-defined standards in this area agreed upon and deployed, but who behave as if they have little interest or expertise in the details of the technology (some of them are probably correct about the latter). Of those who have participated technically and more actively, the consensus that these documents are ready to go seems rather solid. In particular, multiple inquiries and WG Last Calls have not turned up any significant controversy or unresolved issues. 10. 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 publicly available.) No 11. Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet- Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. o "obsoletes RFC5721" appears in page header but not in abstract. RFC 5721 is an experimental document. The relationship is mentioned in the Introduction and the authors and WG do not believe any significant value would be added by cluttering the Abstract with the information. o Disclaimer for pre-RFC5378 work. This document contains significant text from RFC 5721 which included that disclaimer because work started on it significantly before RFC 5378 became effective. The disclaimer appears to be necessary. o The document contains an unnecessary reference to RFC 2047. That reference should be removed when a version is produced subsequent to IETF Last Call. o The document references draft-ietf-eai-5738bis-03 but the current correct version is -07. Because draft-ietf-eai-5738bis-07 is being put through IETF Last Call concurrent with this document and the reference will be replaced by the RFC Editor with an RFC number, the discrepancy is considered trivial. 12. Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such review criterial apply to any of these four documents. 13. Have all references within this document been identified as either normative or informative? Yes 14. 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 plan for their completion? There are no normative references to unpublished documents. 15. Are there downward normative references references (see RFC 3967)? These documents are intended for Proposed Standard. There are no normative references to Experimental or Informational documents. 16. Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. See discussion of nits checking above. RFC 5721 is obsoleted by this document. That status is shown in the header and mentioned in the Introduction. 17. Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). No new registries are created. Modifications to existing registries are clearly specified. 18. List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new IANA registries are created by any of this set of documents. 19. Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There does not appear to be any formal language in this document that would require such checks. |
2012-09-04
|
07 | Pete Resnick | Ballot writeup was changed |
2012-09-04
|
07 | Pete Resnick | Ballot writeup was generated |
2012-09-04
|
07 | Pete Resnick | Last call announcement was changed |
2012-09-04
|
07 | Pete Resnick | Last call announcement was generated |
2012-09-04
|
07 | Pete Resnick | Last call announcement was generated |
2012-09-03
|
07 | Pete Resnick | State changed to AD Evaluation from Publication Requested |
2012-08-27
|
07 | Pete Resnick | State changed to Publication Requested from AD is watching |
2012-08-24
|
07 | Joseph Yee | Changed shepherd to John Klensin |
2012-08-24
|
07 | Barry Leiba | Changed protocol writeup |
2012-07-31
|
07 | Jiankang Yao | New version available: draft-ietf-eai-rfc5721bis-07.txt |
2012-07-16
|
06 | Jiankang Yao | New version available: draft-ietf-eai-rfc5721bis-06.txt |
2012-06-12
|
05 | Jiankang Yao | New version available: draft-ietf-eai-rfc5721bis-05.txt |
2012-04-10
|
04 | Jiankang Yao | New version available: draft-ietf-eai-rfc5721bis-04.txt |
2011-11-16
|
03 | (System) | New version available: draft-ietf-eai-rfc5721bis-03.txt |
2011-07-11
|
02 | (System) | New version available: draft-ietf-eai-rfc5721bis-02.txt |
2011-03-30
|
01 | (System) | New version available: draft-ietf-eai-rfc5721bis-01.txt |
2011-02-06
|
03 | Alexey Melnikov | Responsible AD has been changed to Pete Resnick from Alexey Melnikov |
2010-11-26
|
03 | Alexey Melnikov | Draft Added by Alexey Melnikov in state AD is watching |
2010-09-28
|
00 | (System) | New version available: draft-ietf-eai-rfc5721bis-00.txt |