Skip to main content

Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)
draft-saintandre-xmpp-iri-04

Revision differences

Document history

Date Rev. By Action
2012-08-22
04 (System) post-migration administrative database adjustment to the Yes position for Lisa Dusseault
2012-08-22
04 (System) post-migration administrative database adjustment to the No Objection position for Bill Fenner
2012-08-22
04 (System) post-migration administrative database adjustment to the No Objection position for Brian Carpenter
2006-05-11
04 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2006-05-08
04 Amy Vezza IESG state changed to Approved-announcement sent
2006-05-08
04 Amy Vezza IESG has approved the document
2006-05-08
04 Amy Vezza Closed "Approve" ballot
2006-05-06
04 Ted Hardie State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Ted Hardie
2006-05-01
04 Bill Fenner [Ballot Position Update] Position for Bill Fenner has been changed to No Objection from Discuss by Bill Fenner
2006-04-03
04 Lisa Dusseault [Ballot Position Update] Position for Lisa Dusseault has been changed to Yes from Discuss by Lisa Dusseault
2006-03-31
04 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-03-31
04 (System) New version available: draft-saintandre-xmpp-iri-04.txt
2006-03-31
04 (System) Removed from agenda for telechat - 2006-03-30
2006-03-30
04 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2006-03-30
04 Bill Fenner
[Ballot comment]
I slept on this, and decided it's non-blocking.  Anyone who understands the character vs. encoding thing will be able to figure out what's …
[Ballot comment]
I slept on this, and decided it's non-blocking.  Anyone who understands the character vs. encoding thing will be able to figure out what's intended.

I'm confused by the description of encoding of a query component.

  If included in an XMPP IRI, the query component MUST first be encoded
  as a [UTF-8] string and then (if necessary) transformed to conform to
  the "iquerycomp" rule specified above

The iquerycomp rule ends up talking about iunreserved, from the IRI spec.  However, iunreserved talks about Unicode code points, not UTF-8 encoded strings.  Taking this literally it sounds like the query component "a⪋a" (where ⪋ is, of course, less-than above double-line equal above greater-than) would first be turned into "a<8b>a" (using the notation from [IRI]) and then made part of the IRI.  I would have thought that the IRI would contain three unicode characters, "a", "⪋", and "a", but this implies that it would have 5 characters, 3 representing characters that are not in the original.

This problem applies to the fragment identifier as well, since the same phrasing is used.

I *think* that what's meant is simply that the sequence of Unicode characters that make up the query or fragment identifier is included in the IRI in as characters, and then the IRI is encoded to whatever character encoding is appropriate.
2006-03-30
04 Bill Fenner
[Ballot discuss]
The ABNF is not valid; %x22 or DQUOTE ("imported" from RFC4234) is the way to represent what this document tries to use …
[Ballot discuss]
The ABNF is not valid; %x22 or DQUOTE ("imported" from RFC4234) is the way to represent what this document tries to use '"' for (in the resallow production in both the IRI and URI segments)
2006-03-30
04 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman
2006-03-30
04 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2006-03-30
04 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2006-03-30
04 Brian Carpenter [Ballot Position Update] Position for Brian Carpenter has been changed to No Objection from Discuss by Brian Carpenter
2006-03-29
04 Bill Fenner
[Ballot discuss]
The ABNF is not valid; %x22 or DQUOTE ("imported" from RFC4234) is the way to represent what this document tries to use …
[Ballot discuss]
The ABNF is not valid; %x22 or DQUOTE ("imported" from RFC4234) is the way to represent what this document tries to use '"' for (in the resallow production in both the IRI and URI segments)

I'm confused by the description of encoding of a query component.

  If included in an XMPP IRI, the query component MUST first be encoded
  as a [UTF-8] string and then (if necessary) transformed to conform to
  the "iquerycomp" rule specified above

The iquerycomp rule ends up talking about iunreserved, from the IRI spec.  However, iunreserved talks about Unicode code points, not UTF-8 encoded strings.  Taking this literally it sounds like the query component "a⪋a" (where ⪋ is, of course, less-than above double-line equal above greater-than) would first be turned into "a<8b>a" (using the notation from [IRI]) and then made part of the IRI.  I would have thought that the IRI would contain three unicode characters, "a", "⪋", and "a", but this implies that it would have 5 characters, 3 representing characters that are not in the original.

This problem applies to the fragment identifier as well, since the same phrasing is used.

I *think* that what's meant is simply that the sequence of Unicode characters that make up the query or fragment identifier is included in the IRI in as characters, and then the IRI is encoded to whatever character encoding is appropriate.
2006-03-29
04 Bill Fenner [Ballot Position Update] New position, Discuss, has been recorded for Bill Fenner by Bill Fenner
2006-03-29
04 Michelle Cotton
IANA Comments:
Upon approval of this document the IANA will register a URI scheme for xmpp.
We understand this to be the only IANA action. …
IANA Comments:
Upon approval of this document the IANA will register a URI scheme for xmpp.
We understand this to be the only IANA action.
Will the URI scheme to be registered go in the Permanent registry?
2006-03-29
04 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko by Jari Arkko
2006-03-29
04 Lisa Dusseault
[Ballot discuss]
Peter has some changes to the draft's Security Considerations to comply fully with RFC4395.  He's actually got this text drafted already, which …
[Ballot discuss]
Peter has some changes to the draft's Security Considerations to comply fully with RFC4395.  He's actually got this text drafted already, which I cut-and-paste here for review.

---

Given that XMPP addresses of the form node@domain.tld are typically created via registration at an XMPP server or provisioned by an administrator of such a server, it is possible that such addresses may also be unregistered or deprovisioned; therefore the XMPP IRI/URI that identifies such an XMPP address may not reliably and consistently be associated with the same principal, account owner, application, or device.

XMPP addresses of the form node@domain.tld/resouce are typically even more ephemeral (since a given XMPP resource identifier is typically associated with a particular, temporary session of an XMPP client at an XMPP server); therefore the XMPP IRI/URI that identifies such an XMPP address probably will not reliably and consistently be associated with the same session.  However, the procedures specified in the "Server Rules for Handling XML Stanzas" section of  effectively eliminate any potential confusion that might be introduced by the lack of reliability and consistency for the XMPP IRI/URI that identifies such an XMPP address

XMPP addresses of the form domain.tld are typically long-lived XMPP servers or associated services; Although naturally it is possible for server or service administrators to de-commission the server or service at any time, typically the IRIs/URIs that identify such servers or services are the most reliable and consistent of XMPP IRIs/URIs.

XMPP addresses of the form domain.tld/resource are not yet common on XMPP networks; however, the reliability and consistency of XMPP IRIs/URIs that identify such XMPP addresses would likely fall somewhere between those that identify XMPP addresses of the form domain.tld and those that identify XMPP addresses of the form node@domain.tld.

Malicious Construction

Malicious construction of XMPP IRIs/URIs is made less likely by the prohibition on port numbers in XMPP IRIs/URIs (since port numbers are to be discovered using DNS-SRV records as specified in [XMPP-CORE]).


Back-End Transcoding

Because the base XMPP protocol is designed to implement the exchange of messages and presence information rather than the retrieval of files or invocation of similar system functions, it is deemed unlikely that the use of XMPP IRIs/URIs would result in harmful dereferencing.  However, if an XMPP protocol extension defines methods for information retrieval, it MUST define appropriate controls over access to that information.  In addition, XMPP servers SHOULD NOT natively parse XMPP IRIs/URIs but instead SHOULD accept only the XML wire protocol specified in [XMPP-CORE] and any desired extensions thereto.

Sensitive Information

The ability to interact with XMPP entities via a web browser or other non-native application may expose sensitive information (such as support for particular XMPP application protocol extensions) and thereby make it possible to launch attacks that are not possible or that are unlikely on a native XMPP network.  Due care must be taken in deciding what information is appropriate for representation in XMPP IRIs or URIs.

In particular, advertising XMPP IRIs/URIs in publicly accessible locations (e.g., on websites) may make it easier for malicious users to harvest XMPP addresses from the authority and path components of XMPP IRIs/URIs and therefore to send unsolicited bulk communications to the users or applications represented by those addresses.  Due care should be taken in balancing the benefits of open information exchange against the potential costs of unwanted communications.

To help prevent leaking of sensitive information, passwords and other user credentials are forbidden in the authority component of XMPP IRIs/URIs; in fact they are not needed, since the fact that authentication in XMPP occurs via SASL makes it possible to use the SASL ANONYMOUS mechanism if desired.

Semantic Attacks

Despite the existence of non-hierarchical URI schemes such as MAILTO, by association human users may expect all URIs to include the "//" characters after the scheme name and ":" character.  However, in XMPP IRIs/URIs the "//" characters precede the authority component rather than the path component.  Thus xmpp://guest@example.com indicates to authenticate as "guest@example.com" whereas xmpp:guest@example.com identifies the node "guest@example.com".  Processing applications MUST clearly differentiate between these forms and user agents SHOULD discourage human users from including the "//" characters in XMPP IRIs/URIs since use of the authority component is envisioned to be helpful only in specialized scenarios, not more generally.

Spoofing

The ability to include effectively the full range of Unicode characters in an XMPP IRI may make it easier to execute certain forms of address mimicking (also called "spoofing").  However, XMPP IRIs are no different from other IRIs in this regard, and applications that will present XMPP IRIs to human users must adhere to best practices regarding address mimicking in order to help prevent attacks that result from spoofed addresses (e.g., the phenonmenon known as "phishing").  For details, refer to the Security Considerations of [IRI].
2006-03-29
04 Lisa Dusseault
[Ballot discuss]
Peter has some changes to the draft's Security Considerations to comply fully with RFC4395.  He's actually got this text drafted already, which …
[Ballot discuss]
Peter has some changes to the draft's Security Considerations to comply fully with RFC4395.  He's actually got this text drafted already, which I cut-and-paste here for review.

---

Given that XMPP addresses of the form node@domain.tld are typically created via registration at an XMPP server or provisioned by an administrator of such a server, it is possible that such addresses may also be unregistered or deprovisioned; therefore the XMPP IRI/URI that identifies such an XMPP address may not reliably and consistently be associated with the same principal, account owner, application, or device.

XMPP addresses of the form node@domain.tld/resouce are typically even more ephemeral (since a given XMPP resource identifier is typically associated with a particular, temporary session of an XMPP client at an XMPP server); therefore the XMPP IRI/URI that identifies such an XMPP address probably will not reliably and consistently be associated with the same session.  However, the procedures specified in the "Server Rules for Handling XML Stanzas" section of  effectively eliminate any potential confusion that might be introduced by the lack of reliability and consistency for the XMPP IRI/URI that identifies such an XMPP address

XMPP addresses of the form domain.tld are typically long-lived XMPP servers or associated services; Although naturally it is possible for server or service administrators to de-commission the server or service at any time, typically the IRIs/URIs that identify such servers or services are the most reliable and consistent of XMPP IRIs/URIs.

XMPP addresses of the form domain.tld/resource are not yet common on XMPP networks; however, the reliability and consistency of XMPP IRIs/URIs that identify such XMPP addresses would likely fall somewhere between those that identify XMPP addresses of the form domain.tld and those that identify XMPP addresses of the form node@domain.tld.

Malicious Construction

Malicious construction of XMPP IRIs/URIs is made less likely by the prohibition on port numbers in XMPP IRIs/URIs (since port numbers are to be discovered using DNS-SRV records as specified in [XMPP-CORE]).


Back-End Transcoding

Because the base XMPP protocol is designed to implement the exchange of messages and presence information rather than the retrieval of files or invocation of similar system functions, it is deemed unlikely that the use of XMPP IRIs/URIs would result in harmful dereferencing.  However, if an XMPP protocol extension defines methods for information retrieval, it MUST define appropriate controls over access to that information.  In addition, XMPP servers SHOULD NOT natively parse XMPP IRIs/URIs but instead SHOULD accept only the XML wire protocol specified in [XMPP-CORE] and any desired extensions thereto.

Sensitive Information

The ability to interact with XMPP entities via a web browser or other non-native application may expose sensitive information (such as support for particular XMPP application protocol extensions) and thereby make it possible to launch attacks that are not possible or that are unlikely on a native XMPP network.  Due care must be taken in deciding what information is appropriate for representation in XMPP IRIs or URIs.

In particular, advertising XMPP IRIs/URIs in publicly accessible locations (e.g., on websites) may make it easier for malicious users to harvest XMPP addresses from the authority and path components of XMPP IRIs/URIs and therefore to send unsolicited bulk communications to the users or applications represented by those addresses.  Due care should be taken in balancing the benefits of open information exchange against the potential costs of unwanted communications.

To help prevent leaking of sensitive information, passwords and other user credentials are forbidden in the authority component of XMPP IRIs/URIs; in fact they are not needed, since the fact that authentication in XMPP occurs via SASL makes it possible to use the SASL ANONYMOUS mechanism if desired.

Semantic Attacks

Despite the existence of non-hierarchical URI schemes such as MAILTO, by association human users may expect all URIs to include the "//" characters after the scheme name and ":" character.  However, in XMPP IRIs/URIs the "//" characters precede the authority component rather than the path component.  Thus xmpp://guest@example.com indicates to authenticate as "guest@example.com" whereas xmpp:guest@example.com identifies the node "guest@example.com".  Processing applications MUST clearly differentiate between these forms and user agents SHOULD discourage human users from including the "//" characters in XMPP IRIs/URIs since use of the authority component is envisioned to be helpful only in specialized scenarios, not more generally.

Spoofing

The ability to include effectively the full range of Unicode characters in an XMPP IRI may make it easier to execute certain forms of address mimicking (also called "spoofing").  However, XMPP IRIs are no different from other IRIs in this regard, and applications that will present XMPP IRIs to human users must adhere to best practices regarding address mimicking in order to help prevent attacks that result from spoofed addresses (e.g., the phenonmenon known as "phishing").  For details, refer to the Security Considerations of [IRI].
2006-03-29
04 Lisa Dusseault [Ballot Position Update] New position, Discuss, has been recorded for Lisa Dusseault by Lisa Dusseault
2006-03-29
04 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded for Dan Romascanu by Dan Romascanu
2006-03-29
04 Brian Carpenter
[Ballot discuss]
The draft's author and the Gen-ART reviewer (David Black) have agreed that
the Note in section 2.5 starting "(Note: In pursuit of interoperability,..." …
[Ballot discuss]
The draft's author and the Gen-ART reviewer (David Black) have agreed that
the Note in section 2.5 starting "(Note: In pursuit of interoperability,..."
needs to be replaced with a reference to the newly created non-IANA
registry at http://www.jabber.org/registrar/querytypes.html .

Text suggested by author:

  As noted, there exists a wide variety of XMPP applications (both
  actual and potential), and such applications may define query types
  and keys for use in the query component portion of XMPP URIs.  The
  Jabber Registrar function (see [JEP-0053]) of the Jabber Software
  Foundation maintains a registry of such query types and keys at
  .  To help ensure
  interoperability, any application using the formats defined in this
  document SHOULD submit any associated query types and keys to that
  registry in accordance with the procedures specified in [JEP-0147].

I would also like to see a sentence added to the IANA Considerations
indicating that this non-IANA registry is mentioned in section 2.5.

Text suggested (mainly by author):

  In order to help ensure interoperability, the Jabber Registrar
  function of the Jabber Software Foundation maintains a registry
  of querytypes and keys, located at
  . See Section
  2.5 for details.
2006-03-28
04 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded for Cullen Jennings by Cullen Jennings
2006-03-28
04 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert by Lars Eggert
2006-03-28
04 Brian Carpenter
[Ballot discuss]
The draft author and the Gen-ART reviewer (David Black) have agreed that
the Note in section 2.5 starting "(Note: In pursuit of interoperability,..." …
[Ballot discuss]
The draft author and the Gen-ART reviewer (David Black) have agreed that
the Note in section 2.5 starting "(Note: In pursuit of interoperability,..."
needs to be replaced with a reference to the newly created non-IANA
registry at http://www.jabber.org/registrar/querytypes.html .

I would also like to see a sentence added to the IANA Considerations
indicating that this non-IANA registry is mentioned in section 2.5.
2006-03-28
04 Brian Carpenter [Ballot Position Update] New position, Discuss, has been recorded for Brian Carpenter by Brian Carpenter
2006-03-27
04 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2006-03-26
04 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund by Magnus Westerlund
2006-03-23
04 Ted Hardie [Ballot Position Update] New position, Yes, has been recorded for Ted Hardie
2006-03-23
04 Ted Hardie Ballot has been issued by Ted Hardie
2006-03-23
04 Ted Hardie Created "Approve" ballot
2006-03-22
04 Ted Hardie State Changes to IESG Evaluation from Waiting for Writeup by Ted Hardie
2006-03-22
04 Ted Hardie Placed on agenda for telechat - 2006-03-30 by Ted Hardie
2006-03-22
04 Ted Hardie
Write-up from author:

QUESTIONNAIRE...


1. Have the chairs personally reviewed this version of the ID and do
they believe this ID is sufficiently baked to …
Write-up from author:

QUESTIONNAIRE...


1. Have the chairs personally reviewed this version of the ID and do
they believe this ID is sufficiently baked to forward to the IESG for
publication?

Lisa has reviewed it (some time ago), I'm not sure about Pete.


2. Has the document had adequate review from both key WG members and key
non-WG members? Do you have any concerns about the depth or breadth of
the reviews that have been performed?

The document has been reviewed both by members of the XMPP WG list and
the uri@w3.org list, and all feedback has been incorporated. See the end
of this message for some representative discussion threads.

I have been waiting for final feedback from Martin Duerst, the author of
the IRI spec (RFC 3987), but have not yet received it. In part I hope
that the IETF Last Call will elicit Martin's feedback, since repeated
personal communications have not resulted in his sending final comments.


3. Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

I do not.


4. Do you have any specific concerns/issues with this document that you
believe the ADs and/or IESG should be aware of?

I think that all issues have been addressed. The version previously
presented to the IESG was more IRI-centric and attempted to describe
rules for converting XMPP IRIs into XMPP URIs, but the current version
simply refers to RFC 3987 for the conversion rules.


5. 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 think the consensus is strong. There has been no disagreement
regarding the need for an xmpp: scheme and all discussion of the syntax
and semantics thereof has been incorporated into the document.

Also, as soon as this document advances within the Internet Standards
Process, the ITU plans to add it to H.350 for directory services.


6. Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No.


7. Have the chairs verified that the document adheres to _all_ of the ID
nits?

Not sure. I regularly check my documents against the nits list.


8. Does the document a) split references into normative/informative, and
b) are there normative references to IDs, where the IDs are not also
ready for advancement or are otherwise in an unclear state?

a. Yes.

b. No.


******


MAILING LIST POSTS...

Here is a large collection of relevant mailing list posts...


XMPP WG DISCUSSION (2004-2005)

http://mail.jabber.org/pipermail/xmppwg/2004-June/002124.html
http://mail.jabber.org/pipermail/xmppwg/2004-June/002126.html
http://mail.jabber.org/pipermail/xmppwg/2004-June/002129.html
http://mail.jabber.org/pipermail/xmppwg/2004-June/002130.html
http://mail.jabber.org/pipermail/xmppwg/2004-June/002131.html
http://mail.jabber.org/pipermail/xmppwg/2004-June/002132.html
http://mail.jabber.org/pipermail/xmppwg/2004-June/002133.html
http://mail.jabber.org/pipermail/xmppwg/2004-June/002134.html
http://mail.jabber.org/pipermail/xmppwg/2004-June/002135.html
http://mail.jabber.org/pipermail/xmppwg/2004-June/002136.html

http://mail.jabber.org/pipermail/xmppwg/2004-June/002127.html
http://mail.jabber.org/pipermail/xmppwg/2004-June/002144.html

http://mail.jabber.org/pipermail/xmppwg/2004-July/002153.html

http://mail.jabber.org/pipermail/xmppwg/2004-July/002157.html

http://mail.jabber.org/pipermail/xmppwg/2004-August/002164.html

http://mail.jabber.org/pipermail/xmppwg/2004-August/002165.html

http://mail.jabber.org/pipermail/xmppwg/2004-September/002183.html
http://mail.jabber.org/pipermail/xmppwg/2004-September/002184.html
http://mail.jabber.org/pipermail/xmppwg/2004-September/002185.html

http://mail.jabber.org/pipermail/xmppwg/2004-September/002189.html
http://mail.jabber.org/pipermail/xmppwg/2004-September/002190.html
http://mail.jabber.org/pipermail/xmppwg/2004-September/002191.html

http://mail.jabber.org/pipermail/xmppwg/2004-October/002205.html

http://mail.jabber.org/pipermail/xmppwg/2004-November/002215.html
http://mail.jabber.org/pipermail/xmppwg/2004-November/002216.html
http://mail.jabber.org/pipermail/xmppwg/2004-November/002219.html
http://mail.jabber.org/pipermail/xmppwg/2004-November/002218.html
http://mail.jabber.org/pipermail/xmppwg/2004-November/002220.html
http://mail.jabber.org/pipermail/xmppwg/2004-November/002221.html
http://mail.jabber.org/pipermail/xmppwg/2004-November/002224.html
http://mail.jabber.org/pipermail/xmppwg/2004-November/002225.html
http://mail.jabber.org/pipermail/xmppwg/2004-November/002226.html
http://mail.jabber.org/pipermail/xmppwg/2004-November/002227.html
http://mail.jabber.org/pipermail/xmppwg/2004-November/002228.html
http://mail.jabber.org/pipermail/xmppwg/2004-November/002229.html
http://mail.jabber.org/pipermail/xmppwg/2004-November/002230.html
http://mail.jabber.org/pipermail/xmppwg/2004-November/002231.html
http://mail.jabber.org/pipermail/xmppwg/2004-December/002236.html
http://mail.jabber.org/pipermail/xmppwg/2004-December/002241.html

http://mail.jabber.org/pipermail/xmppwg/2004-November/002222.html
http://mail.jabber.org/pipermail/xmppwg/2004-November/002223.html

http://mail.jabber.org/pipermail/xmppwg/2004-December/002233.html
http://mail.jabber.org/pipermail/xmppwg/2004-December/002234.html
http://mail.jabber.org/pipermail/xmppwg/2004-December/002235.html
http://mail.jabber.org/pipermail/xmppwg/2004-December/002237.html
http://mail.jabber.org/pipermail/xmppwg/2004-December/002242.html
http://mail.jabber.org/pipermail/xmppwg/2004-December/002244.html
http://mail.jabber.org/pipermail/xmppwg/2004-December/002245.html

http://mail.jabber.org/pipermail/xmppwg/2005-January/002250.html
http://mail.jabber.org/pipermail/xmppwg/2005-January/002251.html
http://mail.jabber.org/pipermail/xmppwg/2005-January/002253.html
http://mail.jabber.org/pipermail/xmppwg/2005-January/002254.html
http://mail.jabber.org/pipermail/xmppwg/2005-January/002257.html
http://mail.jabber.org/pipermail/xmppwg/2005-January/002258.html
http://mail.jabber.org/pipermail/xmppwg/2005-January/002256.html
http://mail.jabber.org/pipermail/xmppwg/2005-January/002258.html
http://mail.jabber.org/pipermail/xmppwg/2005-January/002255.html
http://mail.jabber.org/pipermail/xmppwg/2005-February/002267.html
http://mail.jabber.org/pipermail/xmppwg/2005-February/002269.html
http://mail.jabber.org/pipermail/xmppwg/2005-February/002271.html
http://mail.jabber.org/pipermail/xmppwg/2005-February/002272.html
http://mail.jabber.org/pipermail/xmppwg/2005-February/002275.html
http://mail.jabber.org/pipermail/xmppwg/2005-February/002277.html

http://mail.jabber.org/pipermail/xmppwg/2005-January/002259.html
http://mail.jabber.org/pipermail/xmppwg/2005-February/002261.html
http://mail.jabber.org/pipermail/xmppwg/2005-February/002263.html
http://mail.jabber.org/pipermail/xmppwg/2005-February/002264.html
http://mail.jabber.org/pipermail/xmppwg/2005-February/002265.html
http://mail.jabber.org/pipermail/xmppwg/2005-February/002266.html
http://mail.jabber.org/pipermail/xmppwg/2005-February/002268.html

http://mail.jabber.org/pipermail/xmppwg/2005-March/002287.html
http://mail.jabber.org/pipermail/xmppwg/2005-March/002288.html
http://mail.jabber.org/pipermail/xmppwg/2005-March/002290.html
http://mail.jabber.org/pipermail/xmppwg/2005-March/002289.html

http://mail.jabber.org/pipermail/xmppwg/2005-May/002305.html
http://mail.jabber.org/pipermail/xmppwg/2005-June/002307.html
http://mail.jabber.org/pipermail/xmppwg/2005-August/002320.html
http://mail.jabber.org/pipermail/xmppwg/2005-August/002322.html
http://mail.jabber.org/pipermail/xmppwg/2005-September/002325.html
http://mail.jabber.org/pipermail/xmppwg/2005-September/002327.html
http://mail.jabber.org/pipermail/xmppwg/2005-September/002328.html


URI@W3.ORG DISCUSSION

http://lists.w3.org/Archives/Public/uri/2004Aug/0043.html
http://lists.w3.org/Archives/Public/uri/2004Aug/0082.html
http://lists.w3.org/Archives/Public/uri/2004Aug/0083.html

http://lists.w3.org/Archives/Public/uri/2004Sep/0009.html
http://lists.w3.org/Archives/Public/uri/2004Sep/0016.html
http://lists.w3.org/Archives/Public/uri/2004Sep/0023.html
http://lists.w3.org/Archives/Public/uri/2004Sep/0089.html
http://lists.w3.org/Archives/Public/uri/2004Sep/0090.html

http://lists.w3.org/Archives/Public/uri/2004Oct/0045.html

http://lists.w3.org/Archives/Public/uri/2005Aug/0006.html
http://lists.w3.org/Archives/Public/uri/2005Aug/0007.html
http://lists.w3.org/Archives/Public/uri/2005Aug/0008.html
http://lists.w3.org/Archives/Public/uri/2005Aug/0009.html
http://lists.w3.org/Archives/Public/uri/2005Aug/0010.html
http://lists.w3.org/Archives/Public/uri/2005Aug/0011.html
http://lists.w3.org/Archives/Public/uri/2005Aug/0012.html
http://lists.w3.org/Archives/Public/uri/2005Aug/0014.html
http://lists.w3.org/Archives/Public/uri/2005Aug/0016.html
http://lists.w3.org/Archives/Public/uri/2005Sep/0001.html
http://lists.w3.org/Archives/Public/uri/2005Sep/0003.html
http://lists.w3.org/Archives/Public/uri/2005Sep/0004.html
http://lists.w3.org/Archives/Public/uri/2005Sep/0005.html
http://lists.w3.org/Archives/Public/uri/2005Sep/0009.html
http://lists.w3.org/Archives/Public/uri/2005Sep/0011.html
http://lists.w3.org/Archives/Public/uri/2005Sep/0017.html

http://lists.w3.org/Archives/Public/uri/2005Oct/0018.html
http://lists.w3.org/Archives/Public/uri/2005Nov/0000.html


http://lists.w3.org/Archives/Public/uri/2006Jan/0006.html


******


CVS HISTORY...

This document and its predecessor are under source control in case you
want to see the full history. :-)

current document...

http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/ietf/draft-saintandre-xmpp-iri-03.xml
http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/ietf/draft-saintandre-xmpp-iri-02.xml
http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/ietf/draft-saintandre-xmpp-iri-01.xml
http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/ietf/draft-saintandre-xmpp-iri-00.xml

earlier document...

http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/ietf/draft-saintandre-xmpp-uri-09.xml
http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/ietf/draft-saintandre-xmpp-uri-08.xml
http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/ietf/draft-saintandre-xmpp-uri-07.xml
http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/ietf/draft-saintandre-xmpp-uri-06.xml
http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/ietf/draft-saintandre-xmpp-uri-05.xml
http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/ietf/draft-saintandre-xmpp-uri-04.xml
http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/ietf/draft-saintandre-xmpp-uri-03.xml
http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/ietf/draft-saintandre-xmpp-uri-02.xml
http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/ietf/draft-saintandre-xmpp-uri-01.xml
http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/ietf/draft-saintandre-xmpp-uri-00.xml

******
2006-03-15
04 (System) State has been changed to Waiting for Writeup from In Last Call by system
2006-03-10
04 Ted Hardie Shepherding AD has been changed to Ted Hardie from Scott Hollenbeck
2006-02-14
04 Amy Vezza Last call sent
2006-02-14
04 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2006-02-14
04 Scott Hollenbeck State Changes to Last Call Requested from AD Evaluation by Scott Hollenbeck
2006-02-14
04 Scott Hollenbeck Last Call was requested by Scott Hollenbeck
2006-02-14
04 (System) Ballot writeup text was added
2006-02-14
04 (System) Last call text was added
2006-02-14
04 (System) Ballot approval text was added
2006-02-14
04 Scott Hollenbeck State Changes to AD Evaluation from Expert Review by Scott Hollenbeck
2006-02-14
04 Scott Hollenbeck Will start IETF last call while expert review is conducted in parallel.
2006-02-13
04 Scott Hollenbeck State Changes to Expert Review from AD Evaluation by Scott Hollenbeck
2006-02-13
04 Scott Hollenbeck Expert review on the uri-review@ietf.org mailing list is required per RFC 4395.
2006-02-13
04 Scott Hollenbeck
AD Evaluation Comments:

The normative reference to RFC 2234 should be replaced with a reference to RFC 4234. 4234 has replaced 2234.

There is …
AD Evaluation Comments:

The normative reference to RFC 2234 should be replaced with a reference to RFC 4234. 4234 has replaced 2234.

There is a minor ABNF error in the specification included in section 2.2 and 3.2:

resallow  = "!" / '"' / "$" / "'" / "(" / ")" / "*" / "+" /
20: error: Illegal character "'"

it might be better to use "%d34" to describe the '"' character.

Next step: expert review per the registration procedures defined in RFC 4395.  A slight delay might be introduced as Ted is currently working to have an interim reviewer appointed by the IESG.  The IESG will review an appointment request during the 16 February telechat.

Please hold on fixing these until after expert review and IETF last call have been completed.
2006-02-06
04 Scott Hollenbeck State Changes to AD Evaluation from Publication Requested by Scott Hollenbeck
2006-02-06
04 Scott Hollenbeck Draft Added by Scott Hollenbeck in state Publication Requested
2005-12-01
03 (System) New version available: draft-saintandre-xmpp-iri-03.txt
2005-09-30
02 (System) New version available: draft-saintandre-xmpp-iri-02.txt
2005-09-07
01 (System) New version available: draft-saintandre-xmpp-iri-01.txt
2005-06-08
00 (System) New version available: draft-saintandre-xmpp-iri-00.txt