-
Notifications
You must be signed in to change notification settings - Fork 2
/
xep-0032.xml
153 lines (153 loc) · 10.7 KB
/
xep-0032.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jabber URI Scheme</title>
<abstract>A URI scheme for Jabber communications.</abstract>
&LEGALNOTICE;
<number>0032</number>
<status>Retracted</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies/>
<supersedes/>
<supersededby><spec>RFC 5122</spec></supersededby>
<shortname>N/A</shortname>
&stpeter;
&pgmillard;
<revision>
<version>0.4</version>
<date>2003-09-02</date>
<initials>psa</initials>
<remark>Retracted the document, since it is superseded by draft-ietf-xmpp-uri, an Internet-Draft produced by the IETF's XMPP WG.</remark>
</revision>
<revision>
<version>0.3</version>
<date>2002-10-16</date>
<initials>psa</initials>
<remark>Changed 'jabber:' scheme to 'xmpp:' scheme; further specified use cases; removed references to official Jabber namespaces.</remark>
</revision>
<revision>
<version>0.2</version>
<date>2002-05-10</date>
<initials>psa</initials>
<remark>Added information about syntax, allowable characters, and potential conflict with official Jabber namespaces.</remark>
</revision>
<revision>
<version>0.1</version>
<date>2002-05-08</date>
<initials>psa</initials>
<remark>Initial version.</remark>
</revision>
</header>
<section1 topic='Introduction'>
<p><em>Note: This document has been superseded by &rfc5122;.</em></p>
<p>It is widely acknowledged that it would be good to be able to express a Jabber Identifier (JID) (see &xep0029;) as a Uniform Resource Identifier (see &rfc3986;). 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).</p>
<p>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:</p>
<ul>
<li>Sending of basic messages</li>
<li>Sending of basic presence</li>
<li>Sending of subscription requests</li>
</ul>
</section1>
<section1 topic='Syntax'>
<p>The syntactic components of a Jabber URI are as follows:</p>
<code><xmpp>:[<node-identifier>@]<domain-identifier>[?<query>]</code>
<p>This scheme is similar to the mailto URI scheme <note>The mailto URI scheme is described in RFC 2368: <link url='http://www.ietf.org/rfc/rfc2368.txt'>http://www.ietf.org/rfc/rfc2368.txt</link>.</note>. 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.</p>
<p>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.</p>
</section1>
<section1 topic='URI Characters and Escape Sequences'>
<p>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.</p>
<section2 topic='Scheme Component'>
<p>The scheme component for a Jabber URI is 'xmpp'. This component is delimited from the remainder of the URI by a colon character (':').</p>
</section2>
<section2 topic='Node Identifier Component'>
<p>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:</p>
<code>#x22 (") | #x26 (&) | #x27 (') | #x2F (/) |
#x3A (:) | #x3C (<) | #x3E (>) | #x40 (@) |
#x7F (del) | #xFFFE (BOM) | #xFFFF (BOM)</code>
<p>In addition, Section 2.2 of RFC 3986 stipulates that the following additional characters are reserved:</p>
<code>#x24 ($) | #x2B (+) | #x2C (,) | #x3B (;) | #x3D (=) | #x3F (?)</code>
<p>Section 2.4.3 of RFC 3986 further stipulates that the following characters are excluded from URIs in their unescaped form:</p>
<code>#x23 (#) | #x25 (%)</code>
<p>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.</p>
<p>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.</p>
</section2>
<section2 topic='Domain Identifier Component'>
<p>A domain identifier is a standard DNS hostname as specified in RFC 952 <note><link url='http://www.ietf.org/rfc/rfc952.txt'>http://www.ietf.org/rfc/rfc952.txt</link></note>.</p>
</section2>
<section2 topic='Query Component'>
<p>The query component of a Jabber URI may contain any US-ASCII character higher than #x20 with the exception of the following:</p>
<code>#x22 (") | #x23 (#) | #x24 ($) | #x25 (%) |
#x26 (&) | #x27 (') | #x2B (+) | #x2C (,) |
#x2F (/) | #x3A (:) | #x3B (;) | #x3C (<) |
#x3D (=) | #x3E (>) | #x3F (?) | #x40 (@) |
#x7F (del) | #xFFFE (BOM) | #xFFFF (BOM)</code>
</section2>
</section1>
<section1 topic='Use Cases'>
<p>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.</p>
<code>
xmpp:user@host
</code>
<p>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.</p>
<p>The authors propose three allowable query types in a Jabber URI: message, presence, and subscribe <note>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.</note>. These three basic URIs are described below by way of use cases.</p>
<section2 topic='Sending a Message'>
<p>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.</p>
<example caption='Invoking an Interface to Send a Message to a JID'>
xmpp:user@host?message
</example>
<p>The query component may include parameters that further specify the message to be sent to the intended recipient. The following parameters are allowed:</p>
<ul>
<li>body</li>
<li>subject</li>
<li>thread (for conversation tracking)</li>
</ul>
<example caption='Sending a Message with a Subject, Body, and Thread'>
xmpp:user@host?message&subject=hi&body=Hello%20World&thread=abc123
</example>
</section2>
<section2 topic='Sending Presence'>
<p>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.</p>
<example caption='Invoking an Interface to Send Presence to a JID'>
xmpp:user@host?presence
</example>
<p>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:</p>
<ul>
<li>type ('unavailable'; if not specified, the sender is defined to be online and available)</li>
<li>show (one of 'away', 'xa', 'dnd', or 'chat')</li>
<li>status (user-defined status message)</li>
<li>priority (a non-negative integer, with zero as the lowest priority)</li>
</ul>
<example caption='Sending a Specific Presence'>
xmpp:user@host?presence&show=dnd&status=taking%20a%20nap
</example>
</section2>
<section2 topic="Managing Subscriptions">
<p>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.</p>
<example caption='Invoking an Interface to Send a Subscription Request to a JID'>
xmpp:user@host?subscribe
</example>
<p>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'.</p>
<example caption='Sending a Subscription Request'>
xmpp:user@host?subscribe&type=subscribe
</example>
<example caption='Accepting a Subscription Request'>
xmpp:user@host?subscribe&type=subscribed
</example>
<example caption="Unsubscribing from Another User's Presence">
xmpp:user@host?subscribe&type=unsubscribe
</example>
<example caption="Cancelling Another User's Subscription to Your Presence">
xmpp:user@host?subscribe&type=unsubscribed
</example>
</section2>
</section1>
<section1 topic='Author Note' anchor='authornote'>
<p>Peter Millard, co-author of this specification from version 0.1 through version 0.4, died on April 26, 2006.</p>
</section1>
</xep>