Extensible Messaging and Presence Protocol (XMPP): Address Format
draft-ietf-xmpp-6122bis-24
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-09-02
|
24 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-09-02
|
24 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-08-19
|
24 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2015-08-17
|
24 | (System) | RFC Editor state changed to AUTH from EDIT |
2015-07-06
|
24 | Dan Romascanu | Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Dan Romascanu. |
2015-06-24
|
24 | Ben Campbell | Last call announcement was changed |
2015-06-24
|
24 | Ben Campbell | Here is my AD Evaluation of draft-ietf-xmpp-dna-10. I have a few minor comments, but nothing that needs to delay the last call. -- Section 4.1: … Here is my AD Evaluation of draft-ietf-xmpp-dna-10. I have a few minor comments, but nothing that needs to delay the last call. -- Section 4.1: Does the "(Section 4.3: No Mutual PKIX authentication)" belong where it is, or before the first dialback assertion? -- 4.3, step 6: Do I understand correctly that this step involves A sending a valid and trusted server cert, when it was previously unable to send a valid and trusted client cert? Is that a reasonable assumption? Whether yes or no, does it deserve a mention in the text? (It's likely I am missing something that should be obvious.) -- step 7: The reference to xep-0344 is informative. Should it be normative? If not, then perhaps a stronger mention of skipping subsequent steps should be included here? (it’s only mentioned in terms of the reference.) -- 4.4.1, steps 3 and later: The text says that A sends an initial stream header to B. Should that be considered B or C for the rest of the flow? I guess in the example, B==C, but is that required? (perhaps B and C coordinate dialback keys?) Maybe it doesn't matter from A's perspective. |
2015-06-24
|
24 | Ben Campbell | Last call announcement was changed |
2015-06-23
|
24 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2015-06-18
|
24 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2015-06-18
|
24 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2015-06-17
|
24 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2015-06-17
|
24 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2015-06-16
|
24 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-06-16
|
24 | (System) | RFC Editor state changed to EDIT |
2015-06-16
|
24 | (System) | Announcement was received by RFC Editor |
2015-06-15
|
24 | (System) | IANA Action state changed to In Progress |
2015-06-15
|
24 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Revised I-D Needed |
2015-06-15
|
24 | Amy Vezza | IESG has approved the document |
2015-06-15
|
24 | Amy Vezza | Closed "Approve" ballot |
2015-06-11
|
24 | Ben Campbell | Ballot approval text was generated |
2015-06-11
|
24 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2015-06-11
|
24 | Peter Saint-Andre | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2015-06-11
|
24 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-24.txt |
2015-06-11
|
23 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-06-11
|
23 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-06-11
|
23 | Benoît Claise | [Ballot comment] Thanks for this operation-related sentence, based on Dan Romascanu's review: Because it is possible that previously-valid JIDs might no longer be … [Ballot comment] Thanks for this operation-related sentence, based on Dan Romascanu's review: Because it is possible that previously-valid JIDs might no longer be valid (or previously-invalid JIDs might now be valid), operators of XMPP services are advised to perform careful testing before migrating accounts and other data (see Section 6.1 of [I-D.ietf-precis-saslprepbis] for guidance). |
2015-06-11
|
23 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2015-06-11
|
23 | Joel Jaeggli | [Ballot comment] I see that the reference to services are advised to perform careful testing before migrating accounts and other data (see Section … [Ballot comment] I see that the reference to services are advised to perform careful testing before migrating accounts and other data (see Section 6.1 of [I-D.ietf-precis-saslprepbis] for guidance). was added due to last call discuss. I think that's good. |
2015-06-11
|
23 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-06-10
|
23 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2015-06-10
|
23 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2015-06-10
|
23 | Brian Haberman | [Ballot comment] I have cleared my DISCUSS based on the changes proposed by PSA. Thanks for the quick turnaround. |
2015-06-10
|
23 | Brian Haberman | [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss |
2015-06-10
|
23 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2015-06-10
|
23 | Brian Haberman | [Ballot discuss] This should be a relatively straightforward DISCUSS and may not result in any changes to the document... I see this definition in the … [Ballot discuss] This should be a relatively straightforward DISCUSS and may not result in any changes to the document... I see this definition in the draft: domainpart = IP-literal / IPv4address / ifqdn ; ; the "IPv4address" and "IP-literal" rules are ; defined in RFC 3986, and the first-match-wins ; (a.k.a. "greedy") algorithm described therein ; applies to the matching process ; ; note well that reuse of the IP-literal rule from ; RFC 3986 implies that IPv6 addresses are enclosed ; in square brackets (i.e., beginning with '[' and ; ending with ']') RFC 3986 was updated by RFC 6874 to allow zone identifiers in address literals when the address is not globally scoped. Was this considered in the drafting of this update? RFC 6874 updates the ABNF to be: IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture ) "]" ZoneID = 1*( unreserved / pct-encoded ) IPv6addrz = IPv6address "%25" ZoneID I suspect you will get varying results depending on how many implementers follow the Updates chain of 3986. |
2015-06-10
|
23 | Brian Haberman | [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman |
2015-06-09
|
23 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-06-09
|
23 | Barry Leiba | [Ballot comment] I would make the RFC 6365 reference normative. The ABNF definition for localpart would benefit from citing [draft-ietf-precis-saslprepbis] by "UsernameCaseMapped profile". … [Ballot comment] I would make the RFC 6365 reference normative. The ABNF definition for localpart would benefit from citing [draft-ietf-precis-saslprepbis] by "UsernameCaseMapped profile". Similarly for "OpaqueString profile" in the definition of "resourcepart". (And, by the way, I wouldn't put quotation marks around the profile names.) The first paragraph of Section 3.2 defines a particular parsing order, which will affect a JID such as in example 15, way down below. I think it's worth explicitly saying that here, to reduce the likelihood that such JIDs might be mis-parsed. You do mention it in the note explaining example 15, but it'd be useful to highlight it here. In Section 3.3.1, I find the "i.e."s to be distracting clutter, and mildly recommend rendering those lines like this: U+0022 (QUOTATION MARK): " U+0026 (AMPERSAND): & In example 21, it might be more fun to use PILE OF POO (U+1F4A9) instead. Or maybe not... |
2015-06-09
|
23 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2015-06-08
|
23 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2015-06-08
|
23 | Alissa Cooper | [Ballot comment] = Section 6.1 = "Because this document obsoletes RFC 6122, which registered the "Nodeprep" and "Resourceprep" profiles, IANA is requested … [Ballot comment] = Section 6.1 = "Because this document obsoletes RFC 6122, which registered the "Nodeprep" and "Resourceprep" profiles, IANA is requested at the least to mark those profiles as not current (preferably with a pointer to this document)." "At the least" implies that IANA may take some further action at its own discretion, which doesn't seem right. I would suggest deleting that phrase. |
2015-06-08
|
23 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2015-06-08
|
23 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2015-06-05
|
23 | Ben Campbell | Changed consensus to Yes from Unknown |
2015-06-04
|
23 | Jean Mahoney | Request for Telechat review by GENART is assigned to Dan Romascanu |
2015-06-04
|
23 | Jean Mahoney | Request for Telechat review by GENART is assigned to Dan Romascanu |
2015-06-03
|
23 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2015-06-03
|
23 | Ben Campbell | Placed on agenda for telechat - 2015-06-11 |
2015-06-03
|
23 | Ben Campbell | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2015-06-03
|
23 | Ben Campbell | Ballot has been issued |
2015-06-03
|
23 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2015-06-03
|
23 | Ben Campbell | Created "Approve" ballot |
2015-06-03
|
23 | Ben Campbell | Ballot approval text was generated |
2015-06-03
|
23 | Ben Campbell | Ballot approval text was generated |
2015-06-03
|
23 | Peter Saint-Andre | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2015-06-03
|
23 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-23.txt |
2015-06-03
|
22 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2015-05-29
|
22 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2015-05-29
|
22 | Pearl Liang | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-xmpp-6122bis-22. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-xmpp-6122bis-22. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: IANA understands that, upon approval of this document, there is a single action which must be completed. In the Stringprep Profiles registry located at: http://www.iana.org/assignments/stringprep-profiles the entires for: Nodeprep and Resourceprep will each have their status set to "Not Current" and the reference changed to [ RFC-to-be ]. IANA understands that this is the only action required 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. This message is only to confirm what actions will be performed. |
2015-05-24
|
22 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Mahalingam Mani |
2015-05-24
|
22 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Mahalingam Mani |
2015-05-21
|
22 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Matt Lepinski |
2015-05-21
|
22 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Matt Lepinski |
2015-05-21
|
22 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2015-05-21
|
22 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2015-05-21
|
22 | Jean Mahoney | Closed request for Last Call review by GENART with state 'Withdrawn' |
2015-05-21
|
22 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2015-05-21
|
22 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2015-05-20
|
22 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2015-05-20
|
22 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Extensible Messaging and Presence Protocol … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Extensible Messaging and Presence Protocol (XMPP): Address Format) to Proposed Standard The IESG has received a request from the Extensible Messaging and Presence Protocol WG (xmpp) to consider the following document: - 'Extensible Messaging and Presence Protocol (XMPP): Address Format' as Proposed Standard 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 2015-06-03. 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 document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the ASCII range. This document obsoletes RFC 6122. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ballot/ No IPR declarations have been submitted directly on this I-D. |
2015-05-20
|
22 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-05-20
|
22 | Ben Campbell | Last call was requested |
2015-05-20
|
22 | Ben Campbell | IESG state changed to Last Call Requested from AD Evaluation |
2015-05-20
|
22 | Ben Campbell | Last call announcement was generated |
2015-05-20
|
22 | Ben Campbell | Ballot writeup was changed |
2015-05-20
|
22 | Ben Campbell | Ballot writeup was changed |
2015-05-20
|
22 | Ben Campbell | Ballot writeup was generated |
2015-05-20
|
22 | Ben Campbell | Ballot approval text was generated |
2015-05-20
|
22 | Ben Campbell | IESG state changed to AD Evaluation from Publication Requested |
2015-05-11
|
22 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-22.txt |
2015-04-30
|
21 | Joe Hildebrand | 1. Summary The document shepherd is Matthew Miller. The responsible Area Director is Ben Campbell. This document defines the address format for the Extensible Messaging … 1. Summary The document shepherd is Matthew Miller. The responsible Area Director is Ben Campbell. This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the ASCII range. This document obsoletes RFC 6122. This document replaces the XMPP address format, and as such is intended to be a Proposed Standard. 2. Review and Consensus This document received review from a small but active number of individuals from the Working Group and the XMPP Community. There is consensus to publish this document. The XMPP Community did raise the concern that some addresses which are valid using RFC 6122 are no longer valid using this document. However, the consensus of the XMPP Community and the Working Group is that: this document adequately describes the concerns and potential ways to resolve such issues; and that such JIDs are exceedingly rare, if they have ever been encountered. 3. Intellectual Property There are no IPR declarations against this document. The author has confirmed that to the best of his knowledge, all IPR (for which there is none) has been disclosed. The Working Group did not explicitly discuss any IPR concerns. Because this document is heavily reusing technology from draft-ietf-precis-framework, and adapting existing address format specifics from RFC 6122, there is very little concern about IPR issues in addition to those that apply to draft-ietf-precis-framework and RFC 6122. There are no IPR disclosures against draft-ietf-precis-framework and RFC 6122. 4. Other Points This document does have requests on IANA, but does not require more than IETF consensus at best. It does request IANA update the existing Nodeprep and Resourceprep profile be marked "not current" and update the reference for those profiles to point to this document. The external reference to UNICODE is necessary as this document is entirely about internationalized identifiers (and therefore is entirely about UNICODE), and is consistent with the other PRECIS-related documents. The external reference to UTR36 is necessary to describe security concerns, particularly the Address Mimicking problem. The outdated references to draft-ietf-precis-framework and draft-ietf-precis-nickname are expected to be resolved by the RFC Editor before AUTH48 concludes. The information downward reference to RFC 3490 is intentional as it is used to discuss interoperability concerns with existing XMPP software, which still use the stringprep profiles Nodeprep and Resourceprep. The informational downward reference to RFC 3920 is intentional as it illustrates the history of the XMPP address format, and is used to describe interoperability concerns for existing software which still uses the stringprep profiles Nodeprep and Resourceprep. The informational downward reference to RFC 3921 is intentional as it describes specific "JID slots" for server dialback (now defined in XSF XEP-0220) and privacy lists (now defined in XSF XEP-0016). |
2015-04-30
|
21 | Joe Hildebrand | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2015-04-30
|
21 | Joe Hildebrand | IESG state changed to Publication Requested |
2015-04-30
|
21 | Joe Hildebrand | IESG process started in state Publication Requested |
2015-04-30
|
21 | Joe Hildebrand | Intended Status changed to Proposed Standard from None |
2015-04-30
|
21 | Matthew Miller | Changed document writeup |
2015-04-30
|
21 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-21.txt |
2015-04-30
|
20 | Matthew Miller | Changed document writeup |
2015-04-30
|
20 | Matthew Miller | Changed document writeup |
2015-04-09
|
20 | Ben Campbell | Notification list changed to xmpp-chairs@ietf.org, draft-ietf-xmpp-6122bis.ad@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-6122bis@ietf.org, mamille2@cisco.com, draft-ietf-xmpp-6122bis.shepherd@ietf.org from "Matthew Miller" <mamille2@cisco.com> |
2015-04-09
|
20 | Ben Campbell | Shepherding AD changed to Ben Campbell |
2015-03-26
|
20 | Ben Campbell | Notification list changed to "Matthew Miller" <mamille2@cisco.com> |
2015-03-26
|
20 | Ben Campbell | Document shepherd changed to Matthew Miller |
2015-03-23
|
20 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-20.txt |
2015-03-09
|
19 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-19.txt |
2014-12-02
|
18 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-18.txt |
2014-11-26
|
17 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-17.txt |
2014-11-21
|
16 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-16.txt |
2014-10-23
|
15 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-15.txt |
2014-10-10
|
14 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-14.txt |
2014-09-10
|
13 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-13.txt |
2014-03-31
|
12 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-12.txt |
2014-02-12
|
11 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-11.txt |
2014-01-23
|
10 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-10.txt |
2013-11-15
|
09 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-09.txt |
2013-10-18
|
08 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-08.txt |
2013-04-25
|
07 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-07.txt |
2013-03-27
|
06 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-06.txt |
2012-11-06
|
05 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-05.txt |
2012-09-23
|
04 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-04.txt |
2012-08-08
|
03 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-03.txt |
2012-04-14
|
02 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-02.txt |
2012-04-09
|
01 | Peter Saint-Andre | New version available: draft-ietf-xmpp-6122bis-01.txt |
2011-11-17
|
00 | (System) | New version available: draft-ietf-xmpp-6122bis-00.txt |