XEP-0032: Jabber URI Scheme

Abstract:A URI scheme for Jabber communications.
Authors:Peter Saint-Andre, Peter Millard
Copyright:© 1999 - 2014 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:Retracted
Type:Standards Track
Version:0.4
Last Updated:2003-09-02

WARNING: This document has been retracted by the author(s). Implementation of the protocol described herein is not recommended. Developers desiring similar functionality are advised to implement the protocol that supersedes this one (if any).


Table of Contents


1. Introduction
2. Syntax
3. URI Characters and Escape Sequences
    3.1. Scheme Component
    3.2. Node Identifier Component
    3.3. Domain Identifier Component
    3.4. Query Component
4. Use Cases
    4.1. Sending a Message
    4.2. Sending Presence
    4.3. Managing Subscriptions
5. Author Note

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History


1. Introduction

Note: This document has been superseded by RFC 5122 [1].

It is widely acknowledged that it would be good to be able to express a Jabber Identifier (JID) (see Definition of Jabber Identifiers (XEP-0029) [2]) as a Uniform Resource Identifier (see RFC 3986 [3]). In addition, there would be value in being able to interact with a JID through a URI scheme (e.g., by sending a message or a presence update).

Although XMPP enables a wide range of functionality, the authors propose that a Jabber URI scheme needs to support only a limited subset of the possible Jabber functionality. In particular, we see the following as core functions that need to be supported:

2. Syntax

The syntactic components of a Jabber URI are as follows:

<xmpp>:[<node-identifier>@]<domain-identifier>[?<query>]

This scheme is similar to the mailto URI scheme [4]. One similarity is that a Jabber URI is, in the terminology of RFC 3986, not hierarchical but opaque. A URI that is hierarchical in nature uses the slash ("/") character in order to separate hierarchical components, as is familiar from HTTP and FTP URIs. By contrast, an opaque URI such as a mailto URI contains only the scheme (e.g., 'mailto'), a colon, an address (e.g., 'user@host'), and an optional query component.

Per the JID definition in XEP-0029, the node identifier is optional (i.e., a mere domain identifier is a valid JID). However, the proposed Jabber URI scheme forbids the inclusion of a resource identifier in the JID, even though XEP-0029 defines this as valid. This is partly because the authors see no compelling reason to include a resource identifier in the Jabber URI scheme, and also because including a resource would necessitate the inclusion of a slash character in an opaque URI, which is contrary to RFC 3986. Finally, the query component is optional.

3. URI Characters and Escape Sequences

RFC 3986 limits the characters included in a URI to US-ASCII characters, and further defines a number of US-ASCII characters as reserved or otherwise excluded. Reserved characters are special characters used as delimiters withing URIs and whose usage is limited to their reserved purpose as defined in RFC 3986 or a specific URI scheme. Excluded characters are control characters, spaces, and other common (non-URI-specific) delimiters such as angle brackets, double quotes, the number sign, and the percent sign. Reserved characters must be escaped if their usage in a specific context would conflict with their reserved purpose, and excluded characters must always be escaped. The set of disallowed charaacters for any specific URI component consists of the reserved and excluded characters for that component. These are defined below for each component of a Jabber URI.

3.1 Scheme Component

The scheme component for a Jabber URI is 'xmpp'. This component is delimited from the remainder of the URI by a colon character (':').

3.2 Node Identifier Component

The node identifier component of a Jabber URI is equivalent to the "userinfo" component of a generic URI. Section 2.3 of XEP-0029 stipulates that a node identifier may contain any Unicode character higher than #x20 with the exception of the following:

#x22 (") | #x26 (&) | #x27 (') | #x2F (/) | 
#x3A (:) | #x3C (<) | #x3E (>) | #x40 (@) | 
#x7F (del) | #xFFFE (BOM) | #xFFFF (BOM)

In addition, Section 2.2 of RFC 3986 stipulates that the following additional characters are reserved:

#x24 ($) | #x2B (+) | #x2C (,) | #x3B (;) | #x3D (=) | #x3F (?)

Section 2.4.3 of RFC 3986 further stipulates that the following characters are excluded from URIs in their unescaped form:

#x23 (#) | #x25 (%)

Finally, because the generic URI syntax does not provide a way to specify a character encoding other than US-ASCII (see Section 2.1 of RFC 3986), the characters in the node identifier component of a Jabber URI must contain only US-ASCII characters.

Therefore, in order to ensure that a Jabber URI containing a node identifier is a valid URI, the characters disallowed by RFC 3986 (reserved, excluded, and non-ASCII characters) must be escaped in the node identifier component of a Jabber URI.

3.3 Domain Identifier Component

A domain identifier is a standard DNS hostname as specified in RFC 952 [5].

3.4 Query Component

The query component of a Jabber URI may contain any US-ASCII character higher than #x20 with the exception of the following:

#x22 (") | #x23 (#) | #x24 ($) | #x25 (%) | 
#x26 (&) | #x27 (') | #x2B (+) | #x2C (,) | 
#x2F (/) | #x3A (:) | #x3B (;) | #x3C (<) | 
#x3D (=) | #x3E (>) | #x3F (?) | #x40 (@) | 
#x7F (del) | #xFFFE (BOM) | #xFFFF (BOM)

4. Use Cases

Thus the most basic Jabber URI is user@host (sometimes referred to as a "bare JID") prepended by 'xmpp:', as shown in the following example.

xmpp:user@host
    

A URI containing bare JID and no query component should trigger an application to present a user with an appropriate interface to complete an action such as sending a message, sending presence, or managing a subscription. In order to make this possible, some basic queries must be included in the protocol.

The authors propose three allowable query types in a Jabber URI: message, presence, and subscribe [6]. These three basic URIs are described below by way of use cases.

4.1 Sending a Message

If no parameters are passed along with the message query type, an application should present a user with an appropriate interface to complete the sending of a message.

Example 1. Invoking an Interface to Send a Message to a JID

xmpp:user@host?message
    

The query component may include parameters that further specify the message to be sent to the intended recipient. The following parameters are allowed:

Example 2. Sending a Message with a Subject, Body, and Thread

xmpp:user@host?message&subject=hi&body=Hello%20World&thread=abc123
    

4.2 Sending Presence

If no parameters are passed along with the presence query type, an application should present a user with an appropriate interface to complete the act of sending presence.

Example 3. Invoking an Interface to Send Presence to a JID

xmpp:user@host?presence
    

The query component may include parameters that further specify the presence to be sent to the intended recipient (e.g., a user-defined status message). The following parameters are allowed:

Example 4. Sending a Specific Presence

xmpp:user@host?presence&show=dnd&status=taking%20a%20nap
    

4.3 Managing Subscriptions

If no parameters are passed along with the subscribe query type, an application should present a user with an appropriate interface to complete the subscription request.

Example 5. Invoking an Interface to Send a Subscription Request to a JID

xmpp:user@host?subscribe
    

The query component may include parameters that further specify the subscription request to be sent to the intended recipient. Only the 'type' parameter is deemed useful in the limited Jabber URI spec, with valid values of 'subscribe', 'subscribed', 'unsubscribe', or 'unsubscribed'.

Example 6. Sending a Subscription Request

xmpp:user@host?subscribe&type=subscribe
    

Example 7. Accepting a Subscription Request

xmpp:user@host?subscribe&type=subscribed
    

Example 8. Unsubscribing from Another User's Presence

xmpp:user@host?subscribe&type=unsubscribe
    

Example 9. Cancelling Another User's Subscription to Your Presence

xmpp:user@host?subscribe&type=unsubscribed
    

5. Author Note

Peter Millard, co-author of this specification from version 0.1 through version 0.4, died on April 26, 2006.


Appendices


Appendix A: Document Information

Series: XEP
Number: 0032
Publisher: XMPP Standards Foundation
Status: Retracted
Type: Standards Track
Version: 0.4
Last Updated: 2003-09-02
Approving Body: XMPP Council
Dependencies: None
Supersedes: None
Superseded By: RFC 5122
Short Name:
Source Control: HTML
This document in other formats: XML  PDF


Appendix B: Author Information

Peter Saint-Andre

Email: stpeter@jabber.org
JabberID: stpeter@jabber.org
URI: https://stpeter.im/

Peter Millard

See Author Note


Appendix C: Legal Notices

Copyright

This XMPP Extension Protocol is copyright © 1999 - 2014 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/> or obtained by writing to XMPP Standards Foundation, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA).

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.


Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.


Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".


Appendix G: Notes

1. RFC 5122: Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) <http://tools.ietf.org/html/rfc5122>.

2. XEP-0029: Definition of Jabber Identifiers <http://xmpp.org/extensions/xep-0029.html>.

3. RFC 3986: Uniform Resource Identifiers (URI): Generic Syntax <http://tools.ietf.org/html/rfc3986>.

4. The mailto URI scheme is described in RFC 2368: http://www.ietf.org/rfc/rfc2368.txt.

5. http://www.ietf.org/rfc/rfc952.txt

6. These query types are URI queries as defined in RFC 3986 and are not to be confused with the <query/> element often included as the child of an <iq/> element in XMPP.


Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

Version 0.4 (2003-09-02)

Retracted the document, since it is superseded by draft-ietf-xmpp-uri, an Internet-Draft produced by the IETF's XMPP WG. (psa)

Version 0.3 (2002-10-16)

Changed 'jabber:' scheme to 'xmpp:' scheme; further specified use cases; removed references to official Jabber namespaces. (psa)

Version 0.2 (2002-05-10)

Added information about syntax, allowable characters, and potential conflict with official Jabber namespaces. (psa)

Version 0.1 (2002-05-08)

Initial version. (psa)

END