Network Working Group P. Saint-Andre
Internet-Draft Jabber Software Foundation
Expires: February 11, 2005 August 13, 2004
A Uniform Resource Identifier (URI) Scheme for the Extensible
Messaging and Presence Protocol (XMPP)
draft-saintandre-xmpp-uri-04
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 11, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document defines a Uniform Resource Identifier (URI) scheme for
use in addressing entities that can communicate via the Extensible
Messaging and Presence Protocol (XMPP).
Saint-Andre Expires February 11, 2005 [Page 1]
Internet-Draft XMPP URI August 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Discussion Venue . . . . . . . . . . . . . . . . . . . . . 3
2. Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Form . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Generation of XMPP URIs . . . . . . . . . . . . . . . . . 4
2.4 Processing of XMPP URIs . . . . . . . . . . . . . . . . . 5
2.5 Internationalization . . . . . . . . . . . . . . . . . . . 5
3. xmpp: URI IANA Registration . . . . . . . . . . . . . . . . . 6
3.1 URI scheme name . . . . . . . . . . . . . . . . . . . . . 6
3.2 URI scheme syntax . . . . . . . . . . . . . . . . . . . . 6
3.3 Character encoding considerations . . . . . . . . . . . . 6
3.4 Intended usage . . . . . . . . . . . . . . . . . . . . . . 6
3.5 Security considerations . . . . . . . . . . . . . . . . . 6
3.6 Relevant publications . . . . . . . . . . . . . . . . . . 6
3.7 Person and email address to contact for further
information . . . . . . . . . . . . . . . . . . . . . . . 7
3.8 Author/change controller . . . . . . . . . . . . . . . . . 7
3.9 Applications and/or protocols which use this URI
scheme name . . . . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1 Normative References . . . . . . . . . . . . . . . . . . . . 7
6.2 Informative References . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
A. Revision History . . . . . . . . . . . . . . . . . . . . . . . 9
A.1 Changes from draft-saintandre-xmpp-uri-03 . . . . . . . . 9
A.2 Changes from draft-saintandre-xmpp-uri-02 . . . . . . . . 9
A.3 Changes from draft-saintandre-xmpp-uri-01 . . . . . . . . 9
A.4 Changes from draft-saintandre-xmpp-uri-00 . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
Saint-Andre Expires February 11, 2005 [Page 2]
Internet-Draft XMPP URI August 2004
1. Introduction
The Extensible Messaging and Presence Protocol (XMPP) is a streaming
XML technology that enables near-real-time communications between any
two entities on a network. [XMPP-CORE] specifies that on an XMPP
network itself, the address of an XMPP entity is not to be prepended
with a Uniform Resource Identifier (URI) scheme (as defined in RFC
2396 [URI]). However, many applications external to an XMPP network
may need to address XMPP entities as full URIs; examples are
databases that need to store XMPP addresses and non-native user
agents (e.g., a web browser or calendaring application) that provide
an interface to XMPP services. This memo defines an xmpp: URI scheme
for use by such applications, and conforms to both the requirements
in Registration Procedures for URL Scheme Names [URL-REG] and the
recommendations in Guidelines for new URL Schemes [URL-GUIDE].
1.1 Terminology
This document inherits terminology described in [XMPP-CORE].
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [TERMS].
1.2 Discussion Venue
The author welcomes discussion and comments related to the topics
presented in this document. The preferred forum is the
<xmppwg@jabber.org> mailing list, for which archives and subscription
information are available at
<<http://www.jabber.org/cgi-bin/mailman/listinfo/xmppwg/>>.
2. Narrative
2.1 Rationale
Many types of application can be built using XMPP. The best-known
such application is instant messaging (IM) and presence (as these are
described in [IMP-MODEL] and [IMP-REQS] and defined for XMPP in
[XMPP-IM]). Therefore it might seem appropriate to use the im: and
pres: URI schemes specified by Common Profile for Instant Messaging
(CPIM) [CPIM] and Common Profile for Presence (CPP) [CPP], rather
than to define an XMPP-specific URI scheme. However, while the im:
and pres: URI schemes are appropriate for instant messaging and
presence applications and are therefore mentioned normatively in
[XMPP-IM], they are not necessarily appropriate for all XMPP
applications. Because XMPP is fundamentally an XML streaming
Saint-Andre Expires February 11, 2005 [Page 3]
Internet-Draft XMPP URI August 2004
technology rather than an instant messaging and presence technology
per se, XMPP applications may conform to [XMPP-CORE] but not
[XMPP-IM] and thus not implement instant messaging and presence
semantics. Indeed, XMPP is already used in applications such as
network management, workflow applications, generic publish-subscribe,
remote procedure calls, content syndication, gaming, and middleware.
These applications require an addressing scheme that is not tied to
the particular semantics of the im: and pres: URI schemes.
Therefore, this document defines a generic URI scheme that will
enable applications to address as a URI any entity that can
communicate via XMPP.
Note well that on an XMPP network, entities are to be addressed as
<[node@]domain[/resource]> (i.e., without a URI scheme) rather than
as <xmpp:[node@]domain[/resource]>. The xmpp: URI format is provided
for the sake of non-native interfaces and applications only; native
applications are strongly encouraged not to prepend XMPP addresses
with the xmpp: URI scheme when addressing XML stanzas sent over an
XMPP network.
2.2 Form
The syntax for an xmpp: URI is as follows (where the jid rule is
defined in [XMPP-CORE] and the query rule is defined in [URI]).
"xmpp:" jid [ "?" query ]
An xmpp: URI is opaque rather than hierarchical, and thus is similar
to a mailto: URI as specified in RFC 2368 [MAILTO]. Because an xmpp:
URI is opaque, the XMPP address (or "JID") contained therein SHOULD
include only a node identifier (OPTIONAL) and domain identifier
(REQUIRED) as defined in [XMPP-CORE]; while an xmpp: URI MAY include
the resource identifier portion of a JID if the XMPP entity must be
addressed as such, as a general rule this is not encouraged since the
delimiter used before a resource identifier in XMPP addresses is the
slash character ("/"), which is discouraged by [URI] for opaque URIs.
While the "?" character is allowed in the resource identifier portion
of an XMPP address (according to [XMPP-CORE]), that character can be
used as a delimiter between the jid and the query parts of an xmpp:
URI; therefore, any instances of the "?" character in the resource
identifier portion of an XMPP address that is generated or processed
as an xmpp: URI MUST be escaped as "%3F" (as described in Section
2.2.5 of [URL-GUIDE]).
2.3 Generation of XMPP URIs
When generating an XMPP URI, the generating application SHOULD follow
these steps:
Saint-Andre Expires February 11, 2005 [Page 4]
Internet-Draft XMPP URI August 2004
1. Obtain XMPP address (JID).
2. Perform [IDNA] translation against the JID (in the form of a
UTF-8 string).
3. Verify that the UTF-8 string conforms to the format defined in
[XMPP-CORE], including all appropriate [STRINGPREP] profiles.
4. Convert any bytes that are not US-ASCII (see [ASCII]) to %hexhex
format as described in Section 2.2.5 of [URL-GUIDE].
5. Prepend the 'xmpp:' scheme.
6. Append the query component, if any.
2.4 Processing of XMPP URIs
When processing an XMPP URI, the processing application SHOULD follow
these steps:
1. Obtain URI.
2. Convert any parts in %hexhex format to UTF-8 as described in
Section 2.2.5 of [URL-GUIDE].
3. Verify that the UTF-8 string conforms to the format defined in
[XMPP-CORE], including all appropriate [STRINGPREP] profiles.
4. Perform [IDNA] translation against the UTF-8 string.
5. Extract the XMPP address by removing the 'xmpp:' scheme and the
query component (if any).
At this point, the processing application would either (1) complete
further XMPP handling itself or (2) invoke a helper application to
complete XMPP handling; such XMPP handling would most likely consist
of the following steps:
1. Authenticating with an appropriate XMPP server (e.g., a server
that a user has configured as his or her registered service
provider) if not already authenticated.
2. Optionally determining the nature of the intended recipient
(e.g., via [DISCO]).
3. Optionally presenting an appropriate interface to a user based on
the nature of the intended recipient and/or the contents of the
query component (however, if the application does not understand
the query component, it MUST ignore the query component and treat
the URI as consisting of "xmpp:jid" rather than
"xmpp:jid?query").
4. Generating an XMPP stanza that translates any user or application
inputs into their corresponding XMPP equivalents.
5. Sending the XMPP stanza via the authenticated server connection
for delivery to the intended recipient.
2.5 Internationalization
By definition, an XMPP URI is also an Internationalized Resource
Saint-Andre Expires February 11, 2005 [Page 5]
Internet-Draft XMPP URI August 2004
Identifier (see [IRI]). As specified in [XMPP-CORE], each portion of
a JID (node identifier, domain identifier, resource identifier) is
allowed to be a fully internationalized string in accordance with
various profiles of [STRINGPREP]; any non-US-ASCII characters in such
strings (as well as any byte that is not in the set
a-zA-Z0-9!$*.?_~+=) MUST be properly transformed to %hexhex format as
described in Section 2.2.5 of [URL-GUIDE].
3. xmpp: URI IANA Registration
This section provides the information required to register the xmpp:
URI scheme.
3.1 URI scheme name
xmpp
3.2 URI scheme syntax
The syntax for an xmpp: URI is defined below using Augmented
Backus-Naur Form as specified by [ABNF]. The jid rule is defined in
[XMPP-CORE].
XMPP-URI = "xmpp:" jid [ "?" query ]
3.3 Character encoding considerations
Representation of non-US-ASCII character sets in local-part strings
is limited to the standard methods provided as extensions to RFC 2822
[IMF]. Specifically, for each byte, if the byte is not in the set
a-zA-Z0-9!$*.?_~+= then transform the byte to %hexhex format as
described in Section 2.2.5 of [URL-GUIDE].
3.4 Intended usage
The xmpp: URI is intended to be used by interfaces to an XMPP network
from non-native user agents such as web browsers, as well as by
non-native applications that need to address XMPP entities as full
URIs.
3.5 Security considerations
See Security Considerations (Section 5) of XXXX.
3.6 Relevant publications
[XMPP-CORE]
Saint-Andre Expires February 11, 2005 [Page 6]
Internet-Draft XMPP URI August 2004
3.7 Person and email address to contact for further information
Peter Saint-Andre [mailto:stpeter@jabber.org]
3.8 Author/change controller
This scheme is registered under the IETF tree. As such, the IETF
maintains change control.
3.9 Applications and/or protocols which use this URI scheme name
Applications (other than native native XMPP applications) that
provide an interface to XMPP services or that need to address XMPP
entities as full URIs.
4. IANA Considerations
This entire document addresses IANA considerations.
5. Security Considerations
Detailed security considerations for XMPP are given in [XMPP-CORE].
Providing an interface to XMPP services from non-native applications
introduces new security concerns. For example, the ability to
interact with XMPP entities via a web browser may expose sensitive
information to 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 representing in xmpp: URIs; in
particular, passwords MUST NOT be represented.
6. References
6.1 Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[IMF] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998, <http://www.ietf.org/rfc/rfc2396.txt>.
[URL-GUIDE]
Saint-Andre Expires February 11, 2005 [Page 7]
Internet-Draft XMPP URI August 2004
Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
"Guidelines for new URL Schemes", RFC 2718, November 1999.
[URL-REG] Petke, R. and I. King, "Registration Procedures for URL
Scheme Names", BCP 35, RFC 2717, November 1999.
[XMPP-CORE]
Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", draft-ietf-xmpp-core-22 (work in
progress), January 2004.
[XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence",
draft-ietf-xmpp-im-21 (work in progress), January 2004.
6.2 Informative References
[ASCII] American National Standards Institute, "Coded Character
Set - 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
[CPIM] Peterson, J., "Common Profile for Instant Messaging
(CPIM)", draft-ietf-impp-im-04 (work in progress), August
2003.
[CPP] Peterson, J., "Common Profile for Presence (CPP)",
draft-ietf-impp-pres-04 (work in progress), August 2003.
[DISCO] Hildebrand, J., Millard, P., Eatmon, R. and P.
Saint-Andre, "JEP-0030: Service Discovery", June 2004,
<http://www.jabber.org/jeps/jep-0030.html>.
[IDNA] Faltstrom, P., Hoffman, P. and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[IMP-MODEL]
Day, M., Rosenberg, J. and H. Sugano, "A Model for
Presence and Instant Messaging", RFC 2778, February 2000.
[IMP-REQS]
Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
Presence Protocol Requirements", RFC 2779, February 2000.
[IRI] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRI)", draft-duerst-i18n-iri-06 (work in
progress), February 2004.
Saint-Andre Expires February 11, 2005 [Page 8]
Internet-Draft XMPP URI August 2004
[MAILTO] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL
scheme", RFC 2368, July 1998.
[STRINGPREP]
Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("STRINGPREP")", RFC 3454,
December 2002.
Author's Address
Peter Saint-Andre
Jabber Software Foundation
EMail: stpeter@jabber.org
Appendix A. Revision History
Note to RFC Editor: please remove this entire appendix, and the
corresponding entries in the table of contents, prior to publication.
A.1 Changes from draft-saintandre-xmpp-uri-03
o Removed query component.
o Clarified URI generation and processing rules in accordance with
XMPP WG list discussion.
A.2 Changes from draft-saintandre-xmpp-uri-02
o Corrected several small textual errors.
o Clarified the scope of allowable presence information.
A.3 Changes from draft-saintandre-xmpp-uri-01
o Clarified guidelines for escaping of UTF-8 characters.
o Specified usage of query component.
A.4 Changes from draft-saintandre-xmpp-uri-00
o Modified ABNF to track changes to XMPP Core.
o Clarified a few matters in the text.
Saint-Andre Expires February 11, 2005 [Page 9]
Internet-Draft XMPP URI August 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Saint-Andre Expires February 11, 2005 [Page 10]
