-
Notifications
You must be signed in to change notification settings - Fork 0
/
xep-0073.xml
183 lines (183 loc) · 11.3 KB
/
xep-0073.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
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
<?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>Basic IM Protocol Suite</title>
<abstract>This document defines a recommended suite of Jabber/XMPP protocols to be supported by basic instant messaging and presence applications. Note: This protocol suite has been obsoleted by XEP-0211 and XEP-0212.</abstract>
&LEGALNOTICE;
<number>0073</number>
<status>Obsolete</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>XEP-0030</spec>
<spec>XEP-0077</spec>
<spec>XEP-0078</spec>
<spec>XEP-0086</spec>
<spec>XEP-0115</spec>
</dependencies>
<supersedes/>
<supersededby>
<spec>XEP-0242</spec>
<spec>XEP-0243</spec>
</supersededby>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>1.2.1</version>
<date>2021-03-04</date>
<initials>mw</initials>
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>1.2</version>
<date>2007-10-30</date>
<initials>psa</initials>
<remark><p>Per a vote of the XMPP Council, changed status to Obsolete and referred implementors to XEP-0211 and XEP-0212.</p></remark>
</revision>
<revision>
<version>1.1</version>
<date>2007-02-15</date>
<initials>psa</initials>
<remark><p>Changed support for XEP-0077 from required for servers and recommended for clients to recommended for both servers and clients; changed support for XEP-0078 from required for both servers and clients to recommended for servers and not recommended for clients; changed support for XEP-0086 from required for servers and recommended for clients to recommended for both servers and clients; added XEP-0115 as required for clients.</p></remark>
</revision>
<revision>
<version>1.0</version>
<date>2004-12-09</date>
<initials>psa</initials>
<remark><p>Per a vote of the Jabber Council, advanced status to Active.</p></remark>
</revision>
<revision>
<version>0.10</version>
<date>2004-12-06</date>
<initials>psa</initials>
<remark><p>Per feedback from the Jabber Council, made all of RFC 3920 mandatory (no loophole allowing certain client platforms to not support TLS and SASL).</p></remark>
</revision>
<revision>
<version>0.9</version>
<date>2004-12-01</date>
<initials>psa</initials>
<remark><p>Removed reference to deployments and moved historical paragraph to a footnote.</p></remark>
</revision>
<revision>
<version>0.8</version>
<date>2004-11-18</date>
<initials>psa</initials>
<remark><p>Updated references to reflect publication of RFCs 3920 and 3921.</p></remark>
</revision>
<revision>
<version>0.7</version>
<date>2004-08-18</date>
<initials>psa</initials>
<remark><p>Changed In-Band Registration to recommended for clients; added note about SSL communications over port 5223; clarified wording throughout.</p></remark>
</revision>
<revision>
<version>0.6</version>
<date>2004-03-24</date>
<initials>psa</initials>
<remark><p>Updated to reflect approval of XMPP Core and XMPP IM.</p></remark>
</revision>
<revision>
<version>0.5</version>
<date>2003-11-24</date>
<initials>psa</initials>
<remark><p>Updated to reflect work by the XMPP WG; changed status to Deferred.</p></remark>
</revision>
<revision>
<version>0.4</version>
<date>2003-08-13</date>
<initials>psa</initials>
<remark><p>Renamed.</p></remark>
</revision>
<revision>
<version>0.3</version>
<date>2003-05-20</date>
<initials>psa</initials>
<remark><p>Slight editorial revisions.</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2003-04-06</date>
<initials>psa</initials>
<remark><p>Limited scope to definition of "Jabber IM Basic".</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2003-03-04</date>
<initials>psa</initials>
<remark><p>Initial version.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p><em>Note: This protocol suite is obsolete. For updated protocol suites, refer to &xep0211; and &xep0212;.</em></p>
<p>Given the large number of Jabber/XMPP protocols,
<note>The protocols developed by the Jabber community have matured considerably since 1999. The core protocols were originally created by a small group of developers who worked on early Jabber-related open-source software projects such as the &jabberd; server, the Winjab, Gabber, and Jarl clients, the Net::Jabber and Jabberbeans libraries, and gateways to consumer IM services. In the summer of 2001, the &XSF; was founded to institute a formal standards process within the growing Jabber community (codified in &xep0001;). In late 2002, the &IETF; formed the &XMPPWG;, which formalized the core Jabber protocols under the name Extensible Messaging and Presence Protocol (XMPP). In early 2004, the IETF approved the main XMPP specifications as Proposed Standards within the Internet Standards Process defined by &rfc2026;, resulting in publication of &rfc3920; and &rfc3921;. In the meantime, the XSF has continued to develop additional protocols on top of XMPP in order to address functionality areas that are too application-specific for consideration within the IETF.</note>
it is not always clear to developers exactly which protocols they need to implement in order to interoperate over Jabber/XMPP networks. This document attempts to assist developers by defining a protocol suite for basic instant messaging and presence.</p>
</section1>
<section1 topic='Requirements and Approach' anchor='reqs'>
<p>Defining a protocol suite provides a high-level "bucket" into which we can place specific functionality areas for development and compliance testing. A baseline is provided by RFCs 3920 and 3921, which define XML streams, JID processing, channel encryption, authentication, the three primary XML stanza types (&MESSAGE;, &PRESENCE;, and &IQ;), namespace handling, presence subscriptions, roster management, and privacy lists (permit/deny lists). However, basic Jabber instant messaging and presence applications should support several additional protocols that were not included in the XMPP specifications for either of the following reasons:</p>
<ul>
<li>They were not required to meet the requirements of &rfc2779; (e.g, service discovery)</li>
<li>They were and remain in common use within the Jabber community but did not meet the more stringent requirements of the IETF (e.g., old-style, non-SASL authentication)</li>
</ul>
<p>The Basic IM Protocol Suite does not include more advanced IM functionality, such as groupchat or HTML message formatting; see &xep0117; for such features.</p>
</section1>
<section1 topic='Definition' anchor='def'>
<p>The software developed in the Jabber community is built on the foundation of XML streams, a consistent addressing scheme (JIDs), channel encryption, authentication of an entity (client or server) with a server, three core data elements (&MESSAGE;, &PRESENCE;, and &IQ;), and proper handling of XML namespaces. These foundational building blocks have been formalized within RFC 3920, support for which is REQUIRED by this protocol suite.</p>
<p>However, XMPP Core is not fully congruent with the core of what has traditionally been known as "Jabber", and this divergence needs to be captured in the Basic IM Protocol Suite. For the sake of backward compatibility, support for &xep0078; is RECOMMENDED for servers (but not clients) as a fallback method of authentication by older deployed clients. <note>Older software also used port 5223 for SSL-enabled communications between a client and a server, rather than upgrading port 5222 as is done during TLS negotiation (the equivalent for server-to-server communications was never implemented). Support for this behavior is OPTIONAL on the part of servers for backwards-compatibility with older deployed clients.</note> In addition, support for the error 'code' attribute specified in &xep0086; is RECOMMENDED for both clients and servers.</p>
<p>RFC 3920 does not define everything that is normally expected of even a minimal instant messaging and presence application (in effect, it defines the transport layer rather than the IM and presence application layer). Much of this IM and presence functionality is defined in RFC 3921 in order to meet the requirements of RFC 2779. In particular, RFC 3921 defines roster management, presence subscriptions, and routing and delivery guidelines for clients and servers. Therefore, support for &rfc3921; is REQUIRED.</p>
<p>Furthermore, Jabber instant messaging and presence applications typically include the ability to discover information about other entities on the network, and to reply to queries for information. This behavior is extremely helpful because it ensures that entities on the network can determine each other's capabilities and thus understand how to communicate together. Therefore, support for &xep0030; is REQUIRED by this protocol suite, as is (for clients) the dynamic profile of service discovery specified in &xep0115;.</p>
<p>Traditionally, Jabber servers (and some services) have also offered the ability for clients to register accounts "in-band" (see &xep0077;) in order to bootstrap participation on the network; support for that protocol is RECOMMENDED but any given server deployment MAY disable in-band registration as a matter of service provisioning.</p>
<p>Thus we define the Basic IM Protocol Suite as follows:</p>
<table caption='Required and Recommended Specifications'>
<tr>
<th>Specification</th>
<th>Requirement Level</th>
</tr>
<tr>
<td><strong>RFC 3920: XMPP Core</strong></td>
<td>REQUIRED</td>
</tr>
<tr>
<td><strong>RFC 3921: XMPP IM</strong></td>
<td>REQUIRED</td>
</tr>
<tr>
<td><strong>XEP-0030: Service Discovery</strong></td>
<td>REQUIRED</td>
</tr>
<tr>
<td><strong>XEP-0077: In-Band Registration</strong></td>
<td>RECOMMENDED</td>
</tr>
<tr>
<td><strong>XEP-0078: Non-SASL Authentication</strong></td>
<td>RECOMMENDED for servers; NOT RECOMMENDED for clients</td>
</tr>
<tr>
<td><strong>XEP-0086: Error Condition Mappings</strong></td>
<td>RECOMMENDED</td>
</tr>
<tr>
<td><strong>XEP-0115: Entity Capabilities</strong></td>
<td>REQUIRED for clients</td>
</tr>
</table>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>RFC 3920 requires support for SASL and TLS as must-implement protocols, and that support is not modified herein. The older authentication method specified in <cite>XEP-0078: Non-SASL Authentication</cite> is now deprecated; however, support for it is still recommended in server implementations for the sake of backward compatibility (see &xep0078; regarding the proper order of precedence between SASL authentication and non-SASL authentication).</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This document requires no interaction with the ®ISTRAR;.</p>
</section1>
</xep>