moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

updated RFC references

Browse Source
This commit is contained in:
stpeter 2011-04-12 08:37:30 -06:00
parent 0d4e0b9b16
commit 716f9d9117
43 changed files with 525 additions and 355 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
xep-0013.xml
View File

@ -100,7 +100,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Although not required to do so by &rfc3920; and &rfc3921;, many existing Jabber/XMPP instant messaging servers will store messages received while a user is offline and deliver them when the user is next online. Such messages are commonly called "offline messages". The current means of retrieving one's offline messages is simple: one sends available presence to the server and, as a consequence, the server sends a one-time "flood" of all the messages that have been stored while one was offline. This simplification has the following deficiencies:</p>
<p>Although not required to do so by &xmppcore; and &xmppim;, many existing Jabber/XMPP instant messaging servers will store messages received while a user is offline and deliver them when the user is next online. Such messages are commonly called "offline messages". The current means of retrieving one's offline messages is simple: one sends available presence to the server and, as a consequence, the server sends a one-time "flood" of all the messages that have been stored while one was offline. This simplification has the following deficiencies:</p>
<ol>
<li><p>It can be overwhelming, which is undesirable for the vacationer or heavy user. Many individuals upon returning to work from a weeklong vacation spend the first few hours wading through the dozens, even hundreds, of emails that they received during their absence. Unlucky, however, is this user who then logs onto their Jabber server and is bombarded by hundreds of instant messages, possibly in scores of popup dialogs, simultaneously. Should their client crash, they have lost all communication that occurred while they were away.</p></li>
<li><p>It can be difficult to integrate with web-based email clients, which is undesirable for some portals. Several large portals are currently trying to blur the distinction between IM and email -- providing both through one web interface. With offline retrieval semantics so vastly different between the two, this is quite difficult.</p></li>

14
xep-0016.xml
View File

@ -138,7 +138,7 @@
<li>&lt;domain&gt; (the domain itself matches, as does any user@domain or domain/resource)</li>
</ol>
<p>If the type is "group", then the 'value' attribute SHOULD contain the name of a group in the user's roster. (If a client attempts to update, create, or delete a list item with a group that is not in the user's roster, the server SHOULD return to the client an &lt;item-not-found/&gt; stanza error.)</p>
<p>If the type is "subscription", then the 'value' attribute MUST be one of "both", "to", "from", or "none" as defined <cite>RFC 3921</cite>, where "none" includes entities that are totally unknown to the user and therefore not in the user's roster at all. These values are exact matches, so that "both" means a bidirectional subscription (not "from" or "to" only).</p>
<p>If the type is "subscription", then the 'value' attribute MUST be one of "both", "to", "from", or "none" as defined <cite>RFC 6121</cite>, where "none" includes entities that are totally unknown to the user and therefore not in the user's roster at all. These values are exact matches, so that "both" means a bidirectional subscription (not "from" or "to" only).</p>
<p>If no 'type' attribute is included, the rule provides the "fall-through" case.</p>
<p>The 'action' attribute MUST be included and its value MUST be either "allow" or "deny". <note>An implementation MUST NOT block communications from one of a user's resources to another, even if the user happens to define a rule that would otherwise result in that behavior.</note></p>
<p>The 'order' attribute MUST be included and its value MUST be a non-negative integer that is unique among all items in the list. (If a client attempts to create or update a list with non-unique order values, the server MUST return to the client a &lt;bad-request/&gt; stanza error.)</p>
@ -157,8 +157,8 @@
<ol>
<li><p>If there is an active list set for a session, it affects only the session(s) for which it is activated, and only for the duration of the session(s); the server MUST apply the active list only and MUST NOT apply the default list (i.e., there is no "layering" of lists).</p></li>
<li><p>The default list applies to the user as a whole, and is processed if there is no active list set for the target session/resource to which a stanza is addressed, or if there are no current sessions for the user.</p></li>
<li><p>If there is no active list set for a session (or there are no current sessions for the user), and there is no default list, then all stanzas SHOULD BE accepted or appropriately processed by the server on behalf of the user in accordance with the server rules for handling XML stanzas defined in <cite>RFC 3921</cite>.</p></li>
<li><p>Privacy lists MUST be the first delivery rule applied by a server, superseding (1) the routing and delivery rules specified in server rules for handling XML stanzas defined in <cite>RFC 3921</cite> and (2) the handling of subscription-related presence stanzas (and corresponding generation of roster pushes) specified in <cite>RFC 3921</cite>.</p></li>
<li><p>If there is no active list set for a session (or there are no current sessions for the user), and there is no default list, then all stanzas SHOULD BE accepted or appropriately processed by the server on behalf of the user in accordance with the server rules for handling XML stanzas defined in <cite>RFC 6121</cite>.</p></li>
<li><p>Privacy lists MUST be the first delivery rule applied by a server, superseding (1) the routing and delivery rules specified in server rules for handling XML stanzas defined in <cite>RFC 6121</cite> and (2) the handling of subscription-related presence stanzas (and corresponding generation of roster pushes) specified in <cite>RFC 6121</cite>.</p></li>
<li><p>The order in which privacy list items are processed by the server is important. List items MUST be processed in ascending order determined by the integer values of the 'order' attribute for each &lt;item/&gt;.</p></li>
<li><p>As soon as a stanza is matched against a privacy list rule, the server MUST appropriately handle the stanza in accordance with the rule and cease processing.</p></li>
<li><p>If no fall-through item is provided in a list, the fall-through action is assumed to be "allow".</p></li>
@ -415,7 +415,7 @@
</query>
</iq>
]]></example>
<p>In accordance with the semantics of IQ stanzas defined in &rfc3920;, each connected resource MUST return an IQ result to the server as well:</p>
<p>In accordance with the semantics of IQ stanzas defined in &xmppcore;, each connected resource MUST return an IQ result to the server as well:</p>
<example caption='Acknowledging receipt of privacy list pushes'><![CDATA[
<iq from='romeo@example.net/orchard'
type='result'
@ -625,7 +625,7 @@
</iq>
]]></example>
<p>As a result of creating and applying the foregoing list, the user will not send presence notifications to any other users.</p>
<p>Note: When a user blocks outbound presence to a contact, the user's server MUST send unavailable presence information to the contact (but only if the contact is allowed to receive presence notifications from the user in accordance with the rules defined in <cite>RFC 3921</cite>).</p>
<p>Note: When a user blocks outbound presence to a contact, the user's server MUST send unavailable presence information to the contact (but only if the contact is allowed to receive presence notifications from the user in accordance with the rules defined in <cite>RFC 6121</cite>).</p>
</section2>
<section2 topic="Blocking IQ Stanzas" anchor="protocol-iq">
<p>Server-side privacy lists enable a user to block incoming IQ stanzas from other entities based on the entity's JID, roster group, or subscription status (or globally). The following examples illustrate the protocol.</p>
@ -743,7 +743,7 @@
<p>If a blocked entity attempts to send a stanza to the user (i.e., an inbound stanza from the user's perspective), the user's server shall handle the stanza according to the following rules:</p>
<ul>
<li>For presence stanzas (including notifications, subscriptions, and probes), the server MUST NOT respond and MUST NOT return an error.</li>
<li>For message stanzas, the server SHOULD return an error, which SHOULD be &unavailable;. <note>Until version 1.5 of this document (therefore also in <cite>RFC 3921</cite>), it was recommended to silently ignore message stanzas, which unfortunately resulted in a delivery "black hole" regarding message stanzas.</note></li>
<li>For message stanzas, the server SHOULD return an error, which SHOULD be &unavailable;. <note>Until version 1.5 of this document (therefore also in <cite>RFC 6121</cite>), it was recommended to silently ignore message stanzas, which unfortunately resulted in a delivery "black hole" regarding message stanzas.</note></li>
<li>For IQ stanzas of type "get" or "set", the server MUST return an error, which SHOULD be &unavailable;. IQ stanzas of other types MUST be silently dropped by the server.</li>
</ul>
<p>If the foregoing suggestions are followed, the user will appear offline to the contact.</p>
@ -807,7 +807,7 @@
<p>A service MAY also filter blocking users out of searches performed on user directories (see, for example, &xep0055;); however, that functionality is out of scope for this specification.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>If properly implemented, this protocol extension does not introduce any new security concerns above and beyond those defined in <cite>RFC 3920</cite> and <cite>RFC 3921</cite>.</p>
<p>If properly implemented, this protocol extension does not introduce any new security concerns above and beyond those defined in <cite>RFC 6120</cite> and <cite>RFC 6121</cite>.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>No interaction with &IANA; is required as a result of this specification.</p>

591
xep-0045.xml
View File

File diff suppressed because it is too large Load Diff

4
xep-0070.xml
View File

@ -97,7 +97,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>HTTP (see &rfc2616;) is a nearly-ubiquitous mechanism for the publication and retrieval of information over the Internet. Sometimes it is appropriate for an HTTP Server to allow access to that information only if the HTTP Client first provides authentication credentials. While there exist several standardized HTTP authentication schemes (see &rfc2617;), it may be useful in some applications to enforce verification of an HTTP request by requiring an XMPP entity (normally an IM user) to confirm that it made the request. This request verification can be combined with native HTTP authentication to provide a stronger association between the request and a particular user, as well as to take advantage of the strong user authentication provided in XMPP (see &rfc3920;).</p>
<p>HTTP (see &rfc2616;) is a nearly-ubiquitous mechanism for the publication and retrieval of information over the Internet. Sometimes it is appropriate for an HTTP Server to allow access to that information only if the HTTP Client first provides authentication credentials. While there exist several standardized HTTP authentication schemes (see &rfc2617;), it may be useful in some applications to enforce verification of an HTTP request by requiring an XMPP entity (normally an IM user) to confirm that it made the request. This request verification can be combined with native HTTP authentication to provide a stronger association between the request and a particular user, as well as to take advantage of the strong user authentication provided in XMPP (see &xmppcore;).</p>
</section1>
<section1 topic='Terminology' anchor='terms'>
<section2 topic='HTTP Terms' anchor='terms-http'>
@ -334,7 +334,7 @@ Content-Length: 3032
<p>To reduce the likelihood of man-in-the-middle attacks, channel encryption SHOULD be used for both the XMPP channel and the HTTP channel. In particular:</p>
<ol>
<li>The channel used for HTTP requests and responses SHOULD be encrypted via SSL (secure HTTP via https: URLs) or TLS (&rfc2817;).</li>
<li>If the standard binding of XMPP to TCP is used, TLS SHOULD be negotiated for the XMPP channel in accordance with <cite>RFC 3920</cite>.</li>
<li>If the standard binding of XMPP to TCP is used, TLS SHOULD be negotiated for the XMPP channel in accordance with <cite>RFC 6120</cite>.</li>
<li>If a binding of XMPP to HTTP is used (e.g., as specified in <cite>XEP-0124</cite>), exchanges between the XMPP Client and XMPP Server (connection manager) SHOULD be sent over a channel that is encrypted using SSL or TLS.</li>
</ol>
</section2>

28
xep-0072.xml
View File

@ -122,14 +122,14 @@
<section1 topic='Introduction' anchor='intro'>
<p>&w3soap; is a lightweight protocol that defines a method for the exchange of messages independently from the programming language and platform. For interoperability, the SOAP specification is also agnostic about possible transport protocols, though almost all existing implementations use mainly HTTP.</p>
<p>The primary limitation of HTTP consists in the fact that HTTP-based message exchanges allow only synchronous request-response semantics. To overcome this limitation, SMTP is often used to carry asynchronous messages, but it is a complex protocol and inefficient for passing short and frequent messages that should be delivered in close to real time.</p>
<p>Thus XMPP (see &rfc3920;) can be the ideal transport protocol for many of the application fields of web services, since it can carry efficiently and reliably both types of messages, synchronous and asynchronous. Moreover, XMPP-based web services will not need complex support protocols, such as <cite>WS-Routing</cite> and <cite>WS-Referral</cite>, in order to deliver messages to entities that cannot be identified by static public IP addresses. Therefore, this document defines a binding of SOAP to XMPP as an alternative to the existing HTTP and SMTP bindings.</p>
<p>Thus XMPP (see &xmppcore;) can be the ideal transport protocol for many of the application fields of web services, since it can carry efficiently and reliably both types of messages, synchronous and asynchronous. Moreover, XMPP-based web services will not need complex support protocols, such as <cite>WS-Routing</cite> and <cite>WS-Referral</cite>, in order to deliver messages to entities that cannot be identified by static public IP addresses. Therefore, this document defines a binding of SOAP to XMPP as an alternative to the existing HTTP and SMTP bindings.</p>
<p>(Note: The main body of this document provides descriptive text suitable for use by XMPP developers. A formal description of the SOAP XMPP Binding itself is provided in the section of this document entitled <link url='#binding'>SOAP XMPP Binding</link>.)</p>
</section1>
<section1 topic="Architectural Assumptions" anchor='arch'>
<p>The usual architecture of XMPP is described in Section 2 of <cite>RFC 3920</cite>. In essence, XMPP is most commonly deployed using a client-server (or logical peer-to-peer) architecture quite similar to that of the email system, except that XMPP does not have multiple hops between servers, enforces domain names to prevent address spoofing, and enables channel encryption (via TLS) and authentication (via SASL) between client and server as well as among servers.</p>
<p>The usual architecture of XMPP is described in <cite>RFC 6120</cite>. In essence, XMPP is most commonly deployed using a client-server (or logical peer-to-peer) architecture quite similar to that of the email system, except that XMPP does not have multiple hops between servers, enforces domain names to prevent address spoofing, and enables channel encryption (via TLS) and authentication (via SASL) between client and server as well as among servers.</p>
<p>The binding of SOAP to XMPP assumes that most SOAP-enabled XMPP entities will be implemented as XMPP clients that communicate with other entities as logical peers. However, in order to deploy more scalable services, such entities could also be implemented as server-side components (see &xep0114;) or even as special-purpose XMPP servers.</p>
<p>The SOAP specification defines the concepts of "SOAP intermediary" and "ultimate SOAP receiver" (see Section 1.5.3 of <cite>SOAP Version 1.2 Part 1</cite>). In general, this specification assumes that XMPP entities that support the SOAP XMPP Binding will be ultimate SOAP receivers, since SOAP intermediaries tend to be artifacts of the existing SOAP bindings (HTTP and SMTP) rather than applicable to all possible bindings. SOAP intermediaries are usually deployed in order to (1) cross trust boundaries in protocols that do not enforce domain names or authenticate end-points, (2) ensure scalability, (3) secure messages sent over unencrypted channels, and (4) provide message tracing. However, these issues are addressed natively in XMPP (e.g., channel encryption is defined in <cite>RFC 3920</cite>), in XMPP extensions (e.g., message tracing is defined in &xep0079;), or in deployment decisions such as business level agreements between XMPP domains. One final justification for SOAP intermediaries is to act as gateways between different transport mechanisms (e.g., between HTTP and SMTP), and XMPP entities may well be SOAP intermediaries for that reason. For further details about gateways between XMPP and other SOAP bindings, refer to the <link url='#impl'>Implementation Notes</link> section of this document.</p>
<p>The SOAP specification defines the concepts of "SOAP intermediary" and "ultimate SOAP receiver" (see Section 1.5.3 of <cite>SOAP Version 1.2 Part 1</cite>). In general, this specification assumes that XMPP entities that support the SOAP XMPP Binding will be ultimate SOAP receivers, since SOAP intermediaries tend to be artifacts of the existing SOAP bindings (HTTP and SMTP) rather than applicable to all possible bindings. SOAP intermediaries are usually deployed in order to (1) cross trust boundaries in protocols that do not enforce domain names or authenticate end-points, (2) ensure scalability, (3) secure messages sent over unencrypted channels, and (4) provide message tracing. However, these issues are addressed natively in XMPP (e.g., channel encryption is defined in <cite>RFC 6120</cite>), in XMPP extensions (e.g., message tracing is defined in &xep0079;), or in deployment decisions such as business level agreements between XMPP domains. One final justification for SOAP intermediaries is to act as gateways between different transport mechanisms (e.g., between HTTP and SMTP), and XMPP entities may well be SOAP intermediaries for that reason. For further details about gateways between XMPP and other SOAP bindings, refer to the <link url='#impl'>Implementation Notes</link> section of this document.</p>
</section1>
<section1 topic="Use Cases" anchor='uc'>
@ -362,7 +362,7 @@
<p>The recommended approaches (file transfer and including a link) are described more fully below.</p>
<section3 topic="File Transfer" anchor='data-ft'>
<p>The recommended method for sending associated data is to use the file transfer protocol described in <cite>XEP-0096</cite>. Because this is the common and standardized method for XMPP entities to transfer large or binary files outside the XMPP band, it SHOULD be used.</p>
<p>In particular, the entity that has the file SHOULD advertise the availability of the associated stream using <cite>XEP-0137</cite> by including the SI-pub data extension along with the XMPP &MESSAGE; stanza with which the data is associated: <note>In accordance with <cite>RFC 3920</cite>, an &IQ; stanza MUST NOT include multiple payload child elements; therefore, a &MESSAGE; stanza must be used when sending associated data.</note></p>
<p>In particular, the entity that has the file SHOULD advertise the availability of the associated stream using <cite>XEP-0137</cite> by including the SI-pub data extension along with the XMPP &MESSAGE; stanza with which the data is associated: <note>In accordance with <cite>RFC 6120</cite>, an &IQ; stanza MUST NOT include multiple payload child elements; therefore, a &MESSAGE; stanza must be used when sending associated data.</note></p>
<example caption="Sender sends message with SI-pub"><![CDATA[
<message from='requester@example.com/soap-client'
id='soap2'
@ -444,7 +444,7 @@
<p>For details regarding file transfer and advertising of file transfer stream initiation requests, refer to <cite>XEP-0096</cite> and <cite>XEP-0137</cite>.</p>
</section3>
<section3 topic="Including Links" anchor='data-link'>
<p>If the file transfer method is not possible (e.g., because file transfer is not implemented or transfer attempts fails), the entity that is sending the associated data MAY as a fallback publish the associated data as a file (e.g., at an HTTP or FTP URL) and include a link to the file as out-of-band content by including the out-of-band data extension along with the XMPP &MESSAGE; stanza with which the data is associated: <note>As above, in accordance with <cite>RFC 3920</cite>, an &IQ; stanza MUST NOT include multiple payload child elements; therefore, a &MESSAGE; stanza must be used when sending associated data.</note></p>
<p>If the file transfer method is not possible (e.g., because file transfer is not implemented or transfer attempts fails), the entity that is sending the associated data MAY as a fallback publish the associated data as a file (e.g., at an HTTP or FTP URL) and include a link to the file as out-of-band content by including the out-of-band data extension along with the XMPP &MESSAGE; stanza with which the data is associated: <note>As above, in accordance with <cite>RFC 6120</cite>, an &IQ; stanza MUST NOT include multiple payload child elements; therefore, a &MESSAGE; stanza must be used when sending associated data.</note></p>
<example caption="Sender sends message with out-of-band data"><![CDATA[
<message from='requester@example.com/soap-client'
id='soap2'
@ -630,7 +630,7 @@
</ul>
</section2>
<section2 topic="Supported Features" anchor='binding-features'>
<p>XMPP is a pure XML streaming protocol used to exchange snippets of structured data called "XML stanzas" (see Section 4.1 of <cite>RFC 3920</cite>) between any two network endpoints.</p>
<p>XMPP is a pure XML streaming protocol used to exchange snippets of structured data called "XML stanzas" (see <cite>RFC 6120</cite>) between any two network endpoints.</p>
<p>Because XMPP is a direct messaging protocol, it does not possess the equivalent of web methods such as the HTTP GET, PUT, POST, and DELETE methods. Therefore, it is NOT RECOMMENDED for a SOAP node that supports only the SOAP XMPP Binding to provide the "SOAP Web Method Feature" described in Section 6.4 of <cite>SOAP Version 1.2 Part 2</cite>. (A SOAP gateway between XMPP and HTTP should support the SOAP Web Method Feature in order to ensure interoperability; however, description of such gateways is outside the scope of this document.)</p>
<p>Because XMPP is a pure XML protocol, it does not use MIME types (&rfc2045;) or XML media types (&rfc3023;), but rather sends XML directly over the wire. Therefore, it is NOT RECOMMENDED for a SOAP node that supports only the SOAP XMPP Binding to provide the "SOAP Action Feature" described in Section 6.5 of <cite>SOAP Version 1.2 Part 2</cite>. (A SOAP gateway between XMPP and HTTP should support the SOAP Action Feature in order to ensure interoperability; however, description of such gateways is outside the scope of this document.)</p>
</section2>
@ -646,7 +646,7 @@
<li>A SOAP node instantiated at an XMPP entity may assume the role (i.e., the <tt>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role</tt> property) of "RequestingSOAPNode".</li>
<li>A SOAP node instantiated at an XMPP entity may assume the role (i.e., the <tt>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role</tt> property) of "RespondingSOAPNode".</li>
</ul>
<p>The remainder of this section describes the message exchange pattern (MEP) state machine and its relation to XMPP as described in <cite>RFC 3920</cite>. For the sake of brevity, relative URIs are used (the base URI being <tt>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role</tt>), the string "fail:" is used as a conventional prefix for the namespace <tt>http://www.example.org/2001/12/soap/mep/FailureReasons/</tt>, and the string "reqresp:" is used as a conventional prefix for the namespace <tt>http://www.example.org/2001/12/soap/mep/request-response/</tt>. In the state tables below, the states are defined as values of the <tt>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State</tt> property (see Section 6.2 of <cite>SOAP Version 1.2 Part 2</cite>) and are of type xs:anyURI.</p>
<p>The remainder of this section describes the message exchange pattern (MEP) state machine and its relation to XMPP as described in <cite>RFC 6120</cite>. For the sake of brevity, relative URIs are used (the base URI being <tt>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role</tt>), the string "fail:" is used as a conventional prefix for the namespace <tt>http://www.example.org/2001/12/soap/mep/FailureReasons/</tt>, and the string "reqresp:" is used as a conventional prefix for the namespace <tt>http://www.example.org/2001/12/soap/mep/request-response/</tt>. In the state tables below, the states are defined as values of the <tt>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State</tt> property (see Section 6.2 of <cite>SOAP Version 1.2 Part 2</cite>) and are of type xs:anyURI.</p>
<section3 topic="Behavior of Requesting SOAP Node" anchor='binding-operation-request'>
<p>The overall flow of the behavior of a Requesting SOAP Node follows the outline state machine description contained in Section 6.2 of <cite>SOAP Version 1.2 Part 2</cite>. The following subsections describe each state in more detail, where "Requesting SOAP Node" is to be understood as a logical entity made up of the binding and the local SOAP node associated with the XMPP entity that generates a SOAP request.</p>
<section4 topic="Init" anchor='binding-operation-request-init'>
@ -777,7 +777,7 @@
<td>fail:ReceptionFailure</td>
</tr>
</table>
<p>For a listing of relevant XMPP error conditions, refer to Sections 9.3.3 and 4.7.3 of <cite>RFC 3920</cite>.</p>
<p>For a listing of relevant XMPP error conditions, refer to <cite>RFC 6120</cite>.</p>
</section4>
<section4 topic="Sending+Receiving" anchor='binding-operation-request-sendingreceiving'>
<p>The following table formally describes the "Sending+Receiving" state of the Requesting SOAP Node in the SOAP XMPP Binding:</p>
@ -834,7 +834,7 @@
<td>fail:BadRequestMessage</td>
</tr>
</table>
<p>For a listing of relevant XMPP error conditions, refer to Sections 9.3.3 and 4.7.3 of <cite>RFC 3920</cite>.</p>
<p>For a listing of relevant XMPP error conditions, refer to <cite>RFC 6120</cite>.</p>
</section4>
<section4 topic="Success and Fail" anchor='binding-operation-request-successfail'>
<p>A given instance of a request-response transport message exchange terminates when the state "Success" or "Fail" is reached; control over the transport message exchange context returns to the Requesting SOAP Node.</p>
@ -897,7 +897,7 @@
<td>fail:BadRequestMessage</td>
</tr>
</table>
<p>For a listing of relevant XMPP error conditions, refer to Section 9.3.3 of <cite>RFC 3920</cite>.</p>
<p>For a listing of relevant XMPP error conditions, refer to <cite>RFC 6120</cite>.</p>
</section4>
<section4 topic="Receiving" anchor='binding-operation-response-receiving'>
<p>The following table formally describes the "Receiving" state of the Responding SOAP Node in the SOAP XMPP Binding:</p>
@ -1039,12 +1039,12 @@
<p>This specification addresses SOAP 1.2 only. This specification may be superseded or supplemented in the future by a XMPP Extension Protocol specification that defines methods for encapsulating content defined by future versions of SOAP as published by the W3C.</p>
</section2>
<section2 topic='XML Versioning' anchor='w3c-xmlversions'>
<p>Per <cite>RFC 3920</cite>, XMPP supports XML 1.0 only. If future versions of XMPP support XML 1.1 or subsequent versions, this specification may be modified to address handling of SOAP messages that are encoded in versions other than XML 1.0.</p>
<p>Per <cite>RFC 6120</cite>, XMPP supports XML 1.0 only. If future versions of XMPP support XML 1.1 or subsequent versions, this specification may be modified to address handling of SOAP messages that are encoded in versions other than XML 1.0.</p>
</section2>
</section1>
<section1 topic="Error Handling" anchor='errors'>
<p>SOAP provides its own encoding scheme for errors due to message processing or application execution, and it uses SOAP envelopes for reporting. In the SOAP HTTP Binding, these errors are mapped to corresponding HTTP status codes. In the SOAP XMPP Binding, they are mapped to the catch-all XMPP error of &undefined; along with application-specific error condition elements qualified by the 'http://jabber.org/protocol/soap#fault' namespace (this is consistent with Section 9.3.3 of <cite>RFC 3920</cite>, see also &xep0086;). The element names of these application-specific error conditions map directly to the SOAP fault codes specified in Section 5.4.6 of <cite>SOAP Version 1.2 Part 1</cite>.</p>
<p>SOAP provides its own encoding scheme for errors due to message processing or application execution, and it uses SOAP envelopes for reporting. In the SOAP HTTP Binding, these errors are mapped to corresponding HTTP status codes. In the SOAP XMPP Binding, they are mapped to the catch-all XMPP error of &undefined; along with application-specific error condition elements qualified by the 'http://jabber.org/protocol/soap#fault' namespace (this is consistent with <cite>RFC 6120</cite>, see also &xep0086;). The element names of these application-specific error conditions map directly to the SOAP fault codes specified in Section 5.4.6 of <cite>SOAP Version 1.2 Part 1</cite>.</p>
<p>The following table provides a mapping between SOAP, HTTP, and application-specific XMPP errors.</p>
<table caption="Mapping of SOAP Faults to HTTP Status Codes and XMPP Error Conditions">
<tr>
@ -1083,7 +1083,7 @@
<section1 topic="Business Rules" anchor='bizrules'>
<section2 topic="Encoding" anchor='bizrules-encoding'>
<p>Because XMPP does not require the parsing of arbitrary and complete XML documents and does not require implementations to support the full XML specification, transported SOAP envelopes MUST comply with the XML restrictions specified in Section 11 ("XML Usage Within XMPP") of <cite>RFC 3920</cite>. In particular, all envelope elements MUST be properly namespaced (SOAP allows elements within the default namespace, but they are deprecated since SOAP 1.2).</p>
<p>Because XMPP does not require the parsing of arbitrary and complete XML documents and does not require implementations to support the full XML specification, transported SOAP envelopes MUST comply with the XML restrictions specified in <cite>RFC 6120</cite>. In particular, all envelope elements MUST be properly namespaced (SOAP allows elements within the default namespace, but they are deprecated since SOAP 1.2).</p>
<p>SOAP envelopes may contain arbitrary data encoded in valid XML as well as byte arrays encoded with SOAP-specific elements. The SOAP specification recommends to encode byte arrays in Base 64 (see &rfc3548;), with the result that envelopes with binary data can be transported within regular XMPP stanzas. All the remaining PCDATA MUST be encoded as UTF-8 in order to match the XML stream encoding.</p>
</section2>
</section1>
@ -1188,7 +1188,7 @@
</S:Body>
</S:Envelope>
]]></example>
<p>Generic XMPP routers that conform to <cite>RFC 3920</cite> may also "store and forward" Jabber messages. This feature is usually called "offline message handling": the router makes a decision as to whether to deliver the message to the local intended recipient based on the recipient's presence, and if the recipient is offline when the router processes the message then it may store the message for delivery when the recipient next comes online (rather than returning an error to the sender). Although it is possible to write an XMPP router that directly supports the SOAP XMPP binding and implements the SOAP processing model, generic XMPP routers do not contain such support. Accordingly, generic XMPP routers will not forward an XMPP message to an alternate SOAP transport such as HTTP or SMTP, or provide other functions of a SOAP intermediary or ultimate receiver. When a generic XMPP router delivers a message to the intended recipient (whether immediately or as delayed in "offline storage") and the intended recipient supports the SOAP XMPP binding, SOAP processing is performed; such an intended recipient MAY act either as a SOAP intermediary or as an ultimate SOAP receiver.</p>
<p>Generic XMPP routers that conform to <cite>RFC 6120</cite> may also "store and forward" Jabber messages. This feature is usually called "offline message handling": the router makes a decision as to whether to deliver the message to the local intended recipient based on the recipient's presence, and if the recipient is offline when the router processes the message then it may store the message for delivery when the recipient next comes online (rather than returning an error to the sender). Although it is possible to write an XMPP router that directly supports the SOAP XMPP binding and implements the SOAP processing model, generic XMPP routers do not contain such support. Accordingly, generic XMPP routers will not forward an XMPP message to an alternate SOAP transport such as HTTP or SMTP, or provide other functions of a SOAP intermediary or ultimate receiver. When a generic XMPP router delivers a message to the intended recipient (whether immediately or as delayed in "offline storage") and the intended recipient supports the SOAP XMPP binding, SOAP processing is performed; such an intended recipient MAY act either as a SOAP intermediary or as an ultimate SOAP receiver.</p>
<p>With regarding to exchange of associated data, an XMPP entity that functions as a gateway to other SOAP bindings it SHOULD use W3C-recommended protocols for transporting SOAP attachments over non-XMPP SOAP bindings (e.g., HTTP and SMTP) when communicating with non-XMPP entities.</p>
</section1>

6
xep-0077.xml
View File

@ -319,7 +319,7 @@
]]></example>
<p>There are two scenarios:</p>
<ol>
<li><p>If the entity cancels its registration with its "home" server (i.e., the server at which it has maintained its XMPP account), then the entity SHOULD NOT include a 'from' or 'to' address in the remove request the server SHOULD then return a &lt;not-authorized/&gt; stream error and terminate all active sessions for the entity. The server SHOULD perform the remove based on the bare JID &LOCALBARE; associated with the current session or connection over which it received the remove request. If the server is an instant messaging and presence server that conforms to &rfc3921;, the server SHOULD also cancel all existing presence subscriptions related to that entity (as stored in the entity's roster).</p></li>
<li><p>If the entity cancels its registration with its "home" server (i.e., the server at which it has maintained its XMPP account), then the entity SHOULD NOT include a 'from' or 'to' address in the remove request the server SHOULD then return a &lt;not-authorized/&gt; stream error and terminate all active sessions for the entity. The server SHOULD perform the remove based on the bare JID &LOCALBARE; associated with the current session or connection over which it received the remove request. If the server is an instant messaging and presence server that conforms to &xmppim;, the server SHOULD also cancel all existing presence subscriptions related to that entity (as stored in the entity's roster).</p></li>
<li><p>If the entity cancels its registration with a service other than its home server, its home server MUST stamp a 'from' address on the remove request, which in accordance with <cite>XMPP Core</cite> will be the entity's full JID &LOCALFULL;. The service MUST perform the remove based on the bare JID &LOCALBARE; portion of the 'from' address.</p></li>
</ol>
<p>As specified below, several error cases are possible.</p>
@ -504,7 +504,7 @@
<p>The fields defined for the 'jabber:iq:register' namespace are strictly limited to those specified in the schema. If a host needs to gather additional information, <cite>XEP-0004: Data Forms</cite> ("x:data") SHOULD be used according to the following rules:</p>
<ol>
<li>A host MUST NOT add new fields to the 'jabber:iq:register' namespace; instead, extensibility SHOULD be pursued via the <cite>Data Forms</cite> protocol as specified herein.</li>
<li>The x:data form shall be contained as a child element of the &lt;query xmlns='jabber:iq:register'/&gt; element (it cannot be a child of the &IQ; stanza and comply with Section 9.2.3 of &rfc3920;).</li>
<li>The x:data form shall be contained as a child element of the &lt;query xmlns='jabber:iq:register'/&gt; element (it cannot be a child of the &IQ; stanza and comply with &rfc6120;).</li>
<li>The x:data form SHOULD contain x:data fields that correspond to all of the iq:register fields (e.g., username and password).</li>
<li>The x:data form SHOULD use a hidden FORM_TYPE field for the purpose of standardizing field names within the form, as defined in &xep0068;.</li>
<li>The x:data form shall take precedence over the iq:register fields; if the submitting entity supports the <cite>Data Forms</cite> protocol, it SHOULD submit the data form rather than the predefined 'jabber:iq:register' fields, and MUST NOT submit both the data form and the predefined fields (see the <link url='#precedence'>Precedence Order</link> section of this document).</li>
@ -593,7 +593,7 @@
<p>The &lt;key/&gt; element was also used during registration removal.</p>
</section1>
<section1 topic='Stream Feature' anchor='streamfeature'>
<p><cite>RFC 3920</cite> defines methods for advertising feature support during stream negotiation. For the sake of efficiency, it may be desirable for a server to advertise support for in-band registration as a stream feature. The namespace for reporting support within &lt;stream:features/&gt; is "http://jabber.org/features/iq-register". Upon receiving a stream header qualified by the 'jabber:client' namespace, a server returns a stream header to the client and MAY announce support for in-band registration by including the relevant stream feature:</p>
<p><cite>RFC 6120</cite> defines methods for advertising feature support during stream negotiation. For the sake of efficiency, it may be desirable for a server to advertise support for in-band registration as a stream feature. The namespace for reporting support within &lt;stream:features/&gt; is "http://jabber.org/features/iq-register". Upon receiving a stream header qualified by the 'jabber:client' namespace, a server returns a stream header to the client and MAY announce support for in-band registration by including the relevant stream feature:</p>
<example caption='Advertising registration as a stream feature'><![CDATA[
<stream:features>
<register xmlns='http://jabber.org/features/iq-register'/>

22
xep-0078.xml
View File

@ -7,7 +7,7 @@
<xep>
<header>
<title>Non-SASL Authentication</title>
<abstract>This document specifies a protocol for authentication with Jabber servers and services using the jabber:iq:auth namespace. Note Well: The protocol specified herein has been superseded in favor of SASL authentication as specified in RFC 3920, and is now obsolete.</abstract>
<abstract>This document specifies a protocol for authentication with Jabber servers and services using the jabber:iq:auth namespace. Note Well: The protocol specified herein has been superseded in favor of SASL authentication as specified in RFC 3920 / RFC 6120, and is now obsolete.</abstract>
&LEGALNOTICE;
<number>0078</number>
<status>Obsolete</status>
@ -19,7 +19,7 @@
</dependencies>
<supersedes/>
<supersededby>
<spec>RFC 3920</spec>
<spec>RFC 6120</spec>
</supersededby>
<shortname>iq-auth</shortname>
<schemaloc>
@ -166,7 +166,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p><em>Note Well: The protocol specified herein has been superseded in favor of SASL authentication as specified in &rfc3920;, and is now obsolete.</em></p>
<p><em>Note Well: The protocol specified herein has been superseded in favor of SASL authentication as specified in &rfc3920; and &rfc6120;, and is now obsolete.</em></p>
<p>Jabber technologies have long included a wire protocol that enables a client to authenticate with a server. <note>Component authentication is out of scope for this document, and is specified separately in &xep0114;.</note> The method originally used in the Jabber community makes use of the 'jabber:iq:auth' namespace and has been documented variously in Internet-Drafts and elsewhere. When the core Jabber protocols were formalized by the IETF, the 'jabber:iq:auth' protocol was replaced by the Simple Authentication and Security Layer (SASL) as specified in &rfc4422;. SASL was incorporated into XMPP because it provides a more flexible approach to authentication by enabling XMPP entities to use a wide variety of authentication methods (e.g., PLAIN, DIGEST-MD5, EXTERNAL, and ANONYMOUS), some of which are more secure than the 'jabber:iq:auth' protocol.</p>
<p>The 'jabber:iq:auth' protocol specified herein is now obsolete. However, because it will take some time for existing implementations and deployments to be upgraded to SASL, client and server software implementations still need to include support for 'jabber:iq:auth' in order to interoperate, and this document provides canonical documentation of the 'jabber:iq:auth' protocol. Nevertheless, implementation and deployment of SASL authentication is strongly recommended, since the 'jabber:iq:auth' protocol will eventually be obsoleted entirely.</p>
</section1>
@ -196,8 +196,8 @@
</query>
</iq>
]]></example>
<p>If the client included a username with the IQ-get but there is no such username, the server SHOULD NOT return an error, but instead SHOULD return the normal authentication fields (this helps to prevent unknown users from discovering which usernames are in use). If the server does not support non-SASL authentication (e.g., because it supports only SASL authentication as defined in <cite>RFC 3920</cite>), it MUST return a &unavailable; error. If the client previously attempted SASL authentication but that attempt failed, the server MUST return a &lt;policy-violation/&gt; stream error (see <cite>RFC 3920</cite> regarding stream error syntax).</p>
<p>Both the username and the resource are REQUIRED for client authentication using the 'jabber:iq:auth' namespace; if more flexible authentication and resource provisioning are desired, a server SHOULD implement SASL authentication and resource binding as defined in <cite>RFC 3920</cite> (e.g., to enable the server to provide the resource). The &lt;username/&gt; and &lt;resource/&gt; elements MUST be included in the IQ result returned by the server in response to the initial IQ get, and also MUST be included in the IQ set sent by the client when providing authentication credentials.</p>
<p>If the client included a username with the IQ-get but there is no such username, the server SHOULD NOT return an error, but instead SHOULD return the normal authentication fields (this helps to prevent unknown users from discovering which usernames are in use). If the server does not support non-SASL authentication (e.g., because it supports only SASL authentication as defined in <cite>RFC 6120</cite>), it MUST return a &unavailable; error. If the client previously attempted SASL authentication but that attempt failed, the server MUST return a &lt;policy-violation/&gt; stream error (see <cite>RFC 6120</cite> regarding stream error syntax).</p>
<p>Both the username and the resource are REQUIRED for client authentication using the 'jabber:iq:auth' namespace; if more flexible authentication and resource provisioning are desired, a server SHOULD implement SASL authentication and resource binding as defined in <cite>RFC 6120</cite> (e.g., to enable the server to provide the resource). The &lt;username/&gt; and &lt;resource/&gt; elements MUST be included in the IQ result returned by the server in response to the initial IQ get, and also MUST be included in the IQ set sent by the client when providing authentication credentials.</p>
<p>The foregoing stanza shows that the server supports both plaintext authentication (via the &lt;password/&gt; element) and digest authentication with SHA1-encrypted passwords (via the &lt;digest/&gt; element).</p>
<p>Therefore, in order to successfully authenticate with the server in this example, a client MUST provide a username, a resource, and one of password or digest.</p>
<example caption='Client Provides Required Information (Plaintext)'><![CDATA[
@ -209,7 +209,7 @@
</query>
</iq>
]]></example>
<p>Plaintext passwords are straightforward (obviously, characters that map to predefined XML entities MUST be escaped according to the rules defined in section 4.6 of the XML specification, and any non-US-ASCII characters MUST be encoded according to the encoding of XML streams as specified in <cite>RFC 3920</cite>, i.e., UTF-8 as defined in &rfc3269;).</p>
<p>Plaintext passwords are straightforward (obviously, characters that map to predefined XML entities MUST be escaped according to the rules defined in section 4.6 of the XML specification, and any non-US-ASCII characters MUST be encoded according to the encoding of XML streams as specified in <cite>RFC 6120</cite>, i.e., UTF-8 as defined in &rfc3269;).</p>
<p>The value of the &lt;digest/&gt; element MUST be computed according to the following algorithm:</p>
<ol>
<li>Concatenate the Stream ID received from the server with the password. <note>In Digest authentication, password characters that map to predefined XML entities SHOULD NOT be escaped as they are for plaintext passwords, but non-US-ASCII characters MUST be encoded as UTF-8 since the SHA-1 hashing algorithm operates on byte arrays.</note></li>
@ -237,7 +237,7 @@
<li>There is a resource conflict (i.e., there is already an active session with that resource identifier associated with the same username). The RECOMMENDED behavior is for the server to terminate the existing session and create the new one; however, the server MAY provide the opposite behavior if desired, leading to a conflict error for the newly requested login.</li>
<li>The user did not provide all of the required information (e.g., did not provide a username or resource).</li>
</ol>
<p>Although <cite>RFC 3920</cite> specifies that error stanzas SHOULD include the original XML sent, error stanzas qualified by the 'jabber:iq:auth' namespace SHOULD NOT do so given the sensitive nature of the information being exchanged.</p>
<p>Although <cite>RFC 6120</cite> specifies that error stanzas SHOULD include the original XML sent, error stanzas qualified by the 'jabber:iq:auth' namespace SHOULD NOT do so given the sensitive nature of the information being exchanged.</p>
<example caption='Server Informs Client of Failed Authentication (Incorrect Credentials)'><![CDATA[
<iq type='error' id='auth2'>
<error code='401' type='auth'>
@ -262,7 +262,7 @@
</section2>
</section1>
<section1 topic='Stream Feature' anchor='streamfeature'>
<p><cite>RFC 3920</cite> defines methods for advertising feature support during stream negotiation. It may be desirable for a server to advertise support for non-SASL authentication as a stream feature. The namespace for reporting support within &lt;stream:features/&gt; is "http://jabber.org/features/iq-auth". Upon receiving a stream header qualified by the 'jabber:client' namespace, a server that returns stream features SHOULD also announce support for non-SASL authentication by including the relevant stream feature. Exactly when a server advertises the iq-auth stream feature is up to the implementation or deployment (e.g., a server MAY advertise this feature only after successful TLS negotiation or if the channel is encrypted via the older SSL method). Obviously, this does not apply to servers that do not support stream features (e.g., older servers that do not comply with XMPP 1.0).</p>
<p><cite>RFC 6120</cite> defines methods for advertising feature support during stream negotiation. It may be desirable for a server to advertise support for non-SASL authentication as a stream feature. The namespace for reporting support within &lt;stream:features/&gt; is "http://jabber.org/features/iq-auth". Upon receiving a stream header qualified by the 'jabber:client' namespace, a server that returns stream features SHOULD also announce support for non-SASL authentication by including the relevant stream feature. Exactly when a server advertises the iq-auth stream feature is up to the implementation or deployment (e.g., a server MAY advertise this feature only after successful TLS negotiation or if the channel is encrypted via the older SSL method). Obviously, this does not apply to servers that do not support stream features (e.g., older servers that do not comply with XMPP 1.0).</p>
<example caption='Advertising non-SASL authentication as a stream feature'><![CDATA[
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
@ -275,7 +275,7 @@
<p>A server SHOULD NOT advertise non-SASL authentication to another server (i.e., if the initial stream header was qualified by the 'jabber:server' namespace).</p>
</section1>
<section1 topic='Error Handling' anchor='errors'>
<p>As defined herein, the 'jabber:iq:auth' namespace supports both the old (HTTP-style) error codes and the extensible error classes and conditions specified in <cite>RFC 3920</cite>. A compliant server or service implementation MUST support both old-style and new-style error handling. A compliant client implementation SHOULD support both.</p>
<p>As defined herein, the 'jabber:iq:auth' namespace supports both the old (HTTP-style) error codes and the extensible error classes and conditions specified in <cite>RFC 6120</cite>. A compliant server or service implementation MUST support both old-style and new-style error handling. A compliant client implementation SHOULD support both.</p>
</section1>
<section1 topic='Expiration Date' anchor='expiration'>
<p>In accordance with Section 8 of &xep0001;, on 2004-10-20 this document was advanced to a status of Final with the understanding that it would expire in six months. On 2006-09-13, the Jabber Council (now XMPP Council) changed the status of this document to Deprecated. The Jabber Council will review this document every six months to determine whether to change its status to Obsolete or to extend the expiration date for an additional six months; this process will continue until the document is obsoleted. For the latest expiration date, refer to the XEP Information block at the beginning of this document.</p>
@ -310,7 +310,7 @@
<xs:documentation>
NOTE WELL: Non-SASL Authentication via the jabber:iq:auth
protocol has been superseded by SASL Authentication as
defined in RFC 3920, and is now obsolete.
defined in RFC 3920 and RFC 6120, and is now obsolete.
For historical purposes, the protocol documented by this
schema is defined in XEP-0078:
@ -349,7 +349,7 @@
<xs:documentation>
NOTE WELL: Non-SASL Authentication via the jabber:iq:auth
protocol has been superseded by SASL Authentication as
defined in RFC 3920, and is now obsolete.
defined in RFC 3920 and RFC 6120, and is now obsolete.
For historical purposes, the protocol documented by this
schema is defined in XEP-0078:

16
xep-0100.xml
View File

@ -119,7 +119,7 @@
</di>
<di>
<dt>Server</dt>
<dd>An instant messaging server as defined in <cite>RFC 3921</cite>.</dd>
<dd>An instant messaging server as defined in <cite>RFC 6121</cite>.</dd>
</di>
</dl>
</section1>
@ -258,7 +258,7 @@
</li>
<li><p>If Gateway logged into Legacy Service in preceding step, Gateway buffers any translatable events (e.g., messages and presence) queued up for Jabber User on Legacy Service.</p></li>
<li>
<p>Optionally, Jabber User sends IQ-set qualified by the 'jabber:iq:roster' namespace to its server (see &rfc3921;), containing a roster item for Gateway.</p>
<p>Optionally, Jabber User sends IQ-set qualified by the 'jabber:iq:roster' namespace to its server (see &xmppcore;), containing a roster item for Gateway.</p>
<example caption="User Creates Roster Entry"><![CDATA[
<iq type='set'
from='romeo@montague.lit/orchard'
@ -289,7 +289,7 @@
from='romeo@montague.lit'
to='aim.shakespeare.lit'/>
]]></example>
<p>Note: As specified in <cite>RFC 3921</cite>, Jabber User's server will generate a "roster push" at this point if client did not previously perform a roster set to add Gateway to user's roster (as mentioned above).</p>
<p>Note: As specified in <cite>RFC 6121</cite>, Jabber User's server will generate a "roster push" at this point if client did not previously perform a roster set to add Gateway to user's roster (as mentioned above).</p>
</li>
<li>
<p>Jabber User sends subscription request to Gateway (i.e., by sending a presence stanza of type "subscribe" to Gateway).</p>
@ -608,7 +608,7 @@
from='romeo@montague.lit'
to='CapuletNurse@aim.shakespeare.lit'/>
]]></example>
<p>Note: As specified in <cite>RFC 3921</cite>, sending this packet will result in a "roster push" from the Server to all of the Jabber User's available resources.</p>
<p>Note: As specified in <cite>RFC 6121</cite>, sending this packet will result in a "roster push" from the Server to all of the Jabber User's available resources.</p>
</li>
<li><p>Gateway transforms subscription request and routes it to Legacy User.</p></li>
<li>
@ -682,7 +682,7 @@
]]></example>
</li>
<li>
<p>Server sends normal "roster push" to Jabber User (see <cite>RFC 3921</cite>) and sends presence stanzas of type "unsubscribe", "unsubscribed", and "unavailable" to Legacy User.</p>
<p>Server sends normal "roster push" to Jabber User (see <cite>RFC 6121</cite>) and sends presence stanzas of type "unsubscribe", "unsubscribed", and "unavailable" to Legacy User.</p>
<example caption="Server Sends Presence Changes to Legacy User"><![CDATA[
<presence type='unsubscribe'
from='romeo@montague.lit'
@ -829,7 +829,7 @@
to='romeo@montague.lit/orchard'/>
]]></example>
</li>
<li><p>Jabber User's server performs defined functionality for handling presence stanzas of type "unsubscribe" and "unsubscribed" (see <cite>RFC 3921</cite>).</p></li>
<li><p>Jabber User's server performs defined functionality for handling presence stanzas of type "unsubscribe" and "unsubscribed" (see <cite>RFC 6121</cite>).</p></li>
<li><p>Use Case Ends.</p></li>
</ol>
</section3>
@ -850,7 +850,7 @@
<body>Art thou not Romeo, and a Montague?</body>
</message>
]]></example>
<p>Note: If the Legacy Service to which the Gateway connects does not support a concept equivalent to that of Jabber "resources" as described in &rfc3920;, the 'from' address of message stanzas generated by a gateway SHOULD NOT include a resource identifier (i.e., they SHOULD be of the form &lt;user@host&gt; rather than &lt;user@host/resource&gt;). However, the 'from' address MAY include a resource if the Gateway determines that this is appropriate in the context of its communications with the Legacy Service.</p>
<p>Note: If the Legacy Service to which the Gateway connects does not support a concept equivalent to that of Jabber "resources" as described in &rfc6120;, the 'from' address of message stanzas generated by a gateway SHOULD NOT include a resource identifier (i.e., they SHOULD be of the form &lt;user@host&gt; rather than &lt;user@host/resource&gt;). However, the 'from' address MAY include a resource if the Gateway determines that this is appropriate in the context of its communications with the Legacy Service.</p>
</li>
<li><p>Jabber User's Server delivers message or (optionally) stores it for later retrieval.</p></li>
<li><p>Use Case Ends.</p></li>
@ -950,7 +950,7 @@
</section2>
</section1>
<section1 topic='Contact Lists' anchor='rosters'>
<p>Some legacy services maintain server-side contact lists, which are sent to the gateway when it logs in to the legacy service on behalf of the user. The gateway MAY initiate adding of the legacy contact list items to the user's Jabber roster. Some existing gateways do this by sending a presence stanza of type "subscribed" from the legacy contact's JID (e.g., &lt;LegacyUser@gateway.jabberserver.com&gt;) to the Jabber user; unfortunately, this behavior violates the presence stanza handling rules specified in <cite>RFC 3921</cite>. Therefore, a gateway SHOULD instead send the legacy contact list items to the Jabber User via the &xep0144; protocol.</p>
<p>Some legacy services maintain server-side contact lists, which are sent to the gateway when it logs in to the legacy service on behalf of the user. The gateway MAY initiate adding of the legacy contact list items to the user's Jabber roster. Some existing gateways do this by sending a presence stanza of type "subscribed" from the legacy contact's JID (e.g., &lt;LegacyUser@gateway.jabberserver.com&gt;) to the Jabber user; unfortunately, this behavior violates the presence stanza handling rules specified in <cite>RFC 6121</cite>. Therefore, a gateway SHOULD instead send the legacy contact list items to the Jabber User via the &xep0144; protocol.</p>
</section1>
<section1 topic='Business Rules' anchor='bizrules'>
<p>The following business rules apply:</p>

6
xep-0111.xml
View File

@ -76,7 +76,7 @@
</header>
<section1 topic="Introduction" anchor='intro'>
<p><em>Note Well: This proposal has been retracted by the authors in favor of &xep0166;.</em></p>
<p>The Session Description Protocol (SDP; see &rfc2327;) provides a mechanism for describing multimedia sessions that are advertised and negotiated over the Internet. The "Transport for Initiating and Negotiating Sessions" (TINS) specified herein describes how to use SDP to build a framework for media stream/session initiation and negotiation between entities that natively support XMPP (see &rfc3920;).
<p>The Session Description Protocol (SDP; see &rfc2327;) provides a mechanism for describing multimedia sessions that are advertised and negotiated over the Internet. The "Transport for Initiating and Negotiating Sessions" (TINS) specified herein describes how to use SDP to build a framework for media stream/session initiation and negotiation between entities that natively support XMPP (see &xmppcore;).
<note>The approach taken herein is to send pure SDP. While earlier versions of this document used &sdpng; (an XML representation of SDP), SDPng is a more experimental technology; by contrast, SDP is a stable protocol and there is broad support for it by existing gateways and devices. The use of SDP rather than SDPng thus enables the Jabber/XMPP community to implement solutions that are deployable on the Internet today.</note>
In particular, TINS provides an XMPP representation of standard session management semantics such as those provided by the Session Initiation Protocol (SIP; see &rfc3261;). As a result, native XMPP clients that support TINS can negotiate out-of-band multimedia sessions (e.g., use of the Real-Time Transport Protocol or RTP; see &rfc3550;) and XMPP services that support TINS can easily interoperate with SIP services through gateways.</p>
</section1>
@ -90,7 +90,7 @@
</section1>
<section1 topic="Protocol" anchor='protocol'>
<p>TINS exchanges are completed by sending &MESSAGE; stanzas containing a child &lt;tins/&gt; element qualified by the 'http://jabber.org/protocol/tins' namespace.
<note>While it may seem that the semantics of &IQ; stanzas are more appropriate, <cite>RFC 3261</cite> allows entities to send multiple results in response to a SIP request, which does not map to the syntax of the &IQ; stanza as defined in <cite>RFC 3920</cite>.</note>
<note>While it may seem that the semantics of &IQ; stanzas are more appropriate, <cite>RFC 3261</cite> allows entities to send multiple results in response to a SIP request, which does not map to the syntax of the &IQ; stanza as defined in <cite>RFC 6120</cite>.</note>
In order to track the structure of the TINS "conversation", the &THREAD; child of &MESSAGE; MAY also be included. The &lt;tins/&gt; element MUST possess a 'method' attribute, whose value SHOULD be either an IANA-registered value for a SIP method or "result", as described below. The following SIP methods will probably be used most frequently in TINS interactions:</p>
<ul>
<li><p>INVITE -- Used to invite the target user to an out-of-band session. The content inside the &lt;tins/&gt; element MAY be SDP descriptions of the connection types offered. If a session is already established for this transaction, the new INVITE serves as a renegotiation of session parameters.</p></li>
@ -273,7 +273,7 @@
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>TINS is subject to the same security considerations as XMPP, particularly with regard to authentication and channel encryption; for details, refer to <cite>RFC 3920</cite>.</p>
<p>TINS is subject to the same security considerations as XMPP, particularly with regard to authentication and channel encryption; for details, refer to <cite>RFC 6120</cite>.</p>
<p>This document does not describe how the media protocols (e.g. RTP) traverse firewalls and NATs.</p>
<p>There is no general-purpose way to ensure that media protocol connections are associated with the in-band TINS conversation.</p>
</section1>

8
xep-0124.xml
View File

@ -159,7 +159,7 @@
<p>The Transmission Control Protocol (TCP; &rfc0793;) is often used to establish a stream-oriented connection between two entities. Such connections can often be long-lived to enable an interactive "session" between the entities. However, sometimes the nature of the device or network can prevent an application from maintaining a long-lived TCP connection to a server or peer. In this case, it is desirable to use an alternative connection method that emulates the behavior of a long-lived TCP connection using a sequenced series of requests and responses that are exchanged over short-lived connections. The appropriate request-response semantics are widely available via the Hypertext Transfer Protocol (HTTP) as specified in &rfc1945; and &rfc2616;.</p>
<p>BOSH, the technology defined in this specification, essentially provides a "drop-in" alternative to a long-lived, bidirectional TCP connection. It is a mature, full-featured technology that has been widely implemented and deployed since 2004. To our knowledge it was the first of many similar technologies, which now include the Comet methodology formalized in the &bayeux; as well as &websocket; and &rhttp;.</p>
<p>BOSH is designed to transport any data efficiently and with minimal latency in both directions. For applications that require both "push" and "pull" semantics, BOSH is significantly more bandwidth-efficient and responsive than most other bidirectional HTTP-based transport protocols and the techniques now commonly known as "Ajax". BOSH achieves this efficiency and low latency by using so-called "long polling" with multiple synchronous HTTP request/response pairs. Furthermore, BOSH can address the needs of constrained clients by employing fully-compliant HTTP 1.0 without the need for "cookies" (see &rfc2965;) <note>Requiring cookies is sub-optimal because several significant computing platforms provide only limited access to underlying HTTP requests/responses; worse, some platforms hide or remove cookie-related headers.</note> or even access to HTTP headers.</p>
<p>BOSH was originally developed in the Jabber/XMPP community as a replacement for an even earlier HTTP-based technology called &xep0025;. Although BOSH assumes that the "payload" of HTTP requests and responses will be XML, the payload formats are not limited to XMPP stanzas (see &rfc3920;) and could contain a mixture of elements qualified by namespaces defined by different protocols (e.g., both XMPP and JSON). This mix is necessary because some connection managers might not support <link url="#multi">Multiple Streams</link> and constrained clients often have no access to HTTP Pipelining (which limits them to one BOSH session at a time). BOSH connection managers are generally not required to understand anything about the XML content that they transport beyond perhaps ensuring that each XML payload is qualified by the correct namespace.</p>
<p>BOSH was originally developed in the Jabber/XMPP community as a replacement for an even earlier HTTP-based technology called &xep0025;. Although BOSH assumes that the "payload" of HTTP requests and responses will be XML, the payload formats are not limited to XMPP stanzas (see &xmppcore;) and could contain a mixture of elements qualified by namespaces defined by different protocols (e.g., both XMPP and JSON). This mix is necessary because some connection managers might not support <link url="#multi">Multiple Streams</link> and constrained clients often have no access to HTTP Pipelining (which limits them to one BOSH session at a time). BOSH connection managers are generally not required to understand anything about the XML content that they transport beyond perhaps ensuring that each XML payload is qualified by the correct namespace.</p>
<p>Note: &xep0206; documents some XMPP-specific extensions of this protocol that were formerly included in this document.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
@ -229,7 +229,7 @@
<li><p>Internal or external DTD subsets</p></li>
<li><p>Internal or external entity references (with the exception of predefined entities)</p></li>
</ul>
<p>The &lt;body/&gt; wrapper MUST NOT contain any XML character data, although its child elements MAY contain character data. The &lt;body/&gt; wrapper MUST contain zero or more complete XML immediate child elements (called "payloads" in this document, e.g., XMPP stanzas as defined in <cite>RFC 3920</cite> or elements containing XML character data that represents objects using the JSON data interchange format as defined in &rfc4627;). Each &lt;body/&gt; wrapper MAY contain payloads qualified under a wide variety of different namespaces.</p>
<p>The &lt;body/&gt; wrapper MUST NOT contain any XML character data, although its child elements MAY contain character data. The &lt;body/&gt; wrapper MUST contain zero or more complete XML immediate child elements (called "payloads" in this document, e.g., XMPP stanzas as defined in <cite>RFC 6120</cite> or elements containing XML character data that represents objects using the JSON data interchange format as defined in &rfc4627;). Each &lt;body/&gt; wrapper MAY contain payloads qualified under a wide variety of different namespaces.</p>
<p>The &lt;body/&gt; element of every client request MUST possess a sequential request ID encapsulated via the 'rid' attribute; for details, refer to the <link url="#rids">Request IDs</link> section of this document.</p>
</section1>
<section1 topic="Initiating a BOSH Session" anchor='session'>
@ -516,7 +516,7 @@ Content-Length: 153
<presence type='unavailable'
xmlns='jabber:client'/>
</body>]]></example>
<p>The connection manager SHOULD return to the client an HTTP 200 OK response with an empty &lt;body/&gt; element.</p>
<p>The connection manager SHOULD respond to this request with an HTTP 200 OK containing an empty &lt;body/&gt; element.</p>
<example caption="Connection manager acknowledges termination">
<![CDATA[HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
@ -828,7 +828,7 @@ Content-Length: 68
</section2>
<section2 topic='Terminal Binding Conditions' anchor='errorstatus-terminal'>
<p>In any response it sends to the client, the connection manager MAY return a fatal error by setting a 'type' attribute of the &lt;body/&gt; element to "terminate". These binding errors imply that the HTTP session is terminated (unless a 'stream' attribute is specified -- see <link url="#multi-error">Multiple Stream Error Conditions</link>).</p>
<p>Note: Although many of these conditions are similar to the XMPP stream error conditions specified in <cite>RFC 3920</cite>, they are not to be confused with XMPP stream errors. In cases where BOSH is being used to transport XMPP, any fatal XMPP stream error conditions experienced between the connection manager and the XMPP server SHOULD only be reported using the "remote-stream-error" condition as described below.</p>
<p>Note: Although many of these conditions are similar to the XMPP stream error conditions specified in <cite>RFC 6120</cite>, they are not to be confused with XMPP stream errors. In cases where BOSH is being used to transport XMPP, any fatal XMPP stream error conditions experienced between the connection manager and the XMPP server SHOULD only be reported using the "remote-stream-error" condition as described below.</p>
<example caption="Remote connection failed error">
<![CDATA[HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8

4
xep-0130.xml
View File

@ -171,7 +171,7 @@
</revision>
</header>
<section1 topic="Introduction" anchor='intro'>
<p>An IM user may want to be informed when a contact creates an IM account. If the user knows some information about the contact (e.g., a phone number or email address), the user's service can use that information to place the contact on a "waiting list", then inform the user when the contact creates an IM account. This document defines an extension to &rfc3920; and &rfc3921; that enables such "waiting list" functionality, including the ability to add contacts on other domains if service providers agree to interoperate (e.g., to add a contact who uses a different mobile telephony service provider).</p>
<p>An IM user may want to be informed when a contact creates an IM account. If the user knows some information about the contact (e.g., a phone number or email address), the user's service can use that information to place the contact on a "waiting list", then inform the user when the contact creates an IM account. This document defines an extension to &xmppcore; and &xmppim; that enables such "waiting list" functionality, including the ability to add contacts on other domains if service providers agree to interoperate (e.g., to add a contact who uses a different mobile telephony service provider).</p>
<p><em>Note: The protocol defined herein is currently in use at several large service providers in Europe. Others are welcome to use the protocol.</em></p>
</section1>
<section1 topic="Glossary" anchor='glossary'>
@ -516,7 +516,7 @@
</query>
</iq>
]]></example>
<p>As described below, various error conditions may occur. (For information about error syntax, refer to <cite>RFC 3920</cite> and &xep0086;.)</p>
<p>As described below, various error conditions may occur. (For information about error syntax, refer to <cite>RFC 6120</cite> and &xep0086;.)</p>
<p>If the IM User provided a URI whose scheme is not supported, WaitingListService MUST return a &badrequest; error to the IM User and MUST NOT add the Contact to the WaitingList.</p>
<example caption='WaitingListService Returns &badrequest; Error to IM User'><![CDATA[
<iq type='error'

10
xep-0133.xml
View File

@ -14,7 +14,7 @@
<type>Informational</type>
<sig>Standards</sig>
<dependencies>
<spec>RFC 3920</spec>
<spec>RFC 6120</spec>
<spec>XEP-0050</spec>
</dependencies>
<supersedes/>
@ -763,7 +763,7 @@
</command>
</iq>
]]></example>
<p>The data form included in the IQ result will include the user's roster, formatted according to the 'jabber:iq:roster' protocol defined in &rfc3921;.</p>
<p>The data form included in the IQ result will include the user's roster, formatted according to the 'jabber:iq:roster' protocol defined in &xmppim;.</p>
<example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit'
id='get-user-roster-2'
@ -987,7 +987,7 @@
]]></example>
</section2>
<section2 topic='Edit Blacklist' anchor='edit-blacklist'>
<p>The service may enable an administrator to define one or more service-wide blacklists (lists of entities that are blocked from communications to or from the service). For example, a multi-user chat service may forbid a certain user from joining any room on the service, or may block entire domains from accessing the service. An entity specified on the blacklist MAY be a JID of any form as specified in &rfc3920;; the order of JID matching SHOULD be that specified for privacy lists in Section 10 of <cite>RFC 3921</cite>.</p>
<p>The service may enable an administrator to define one or more service-wide blacklists (lists of entities that are blocked from communications to or from the service). For example, a multi-user chat service may forbid a certain user from joining any room on the service, or may block entire domains from accessing the service. An entity specified on the blacklist MAY be a JID of any form as specified in &rfc6120;; the order of JID matching SHOULD be that specified for privacy lists in &xep0016;.</p>
<p>A blacklist may prevent inbound communications, outbound communications, or both; whether to offer only bidirectional blocking or a more granular choice of inbound or outbound blocking is a matter of implementation or deployment policy. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#edit-blacklist" if blocking is bidirectional as shown below; "http://jabber.org/protocol/admin#add-to-blacklist-in" for inbound blocking only; and "http://jabber.org/protocol/admin#add-to-blacklist-out" for outbound blocking only.</p>
<p>A sample protocol flow for this use case is shown below.</p>
<example caption='Admin Requests Editing of Blacklist'><![CDATA[
@ -1065,7 +1065,7 @@
]]></example>
</section2>
<section2 topic='Edit Whitelist' anchor='edit-whitelist'>
<p>The service may enable an administrator to define one or more service-wide whitelists (lists of entities that are allowed to communicate the service). For example, a publish-subscribe may allow only a select list of users to publish or subscribe to nodes hosted on the service. An entity added to a whitelist MAY be a JID of any form as specified in <cite>RFC 3920</cite>; the order of JID matching SHOULD be that specified for privacy lists in Section 10 of <cite>RFC 3921</cite>.</p>
<p>The service may enable an administrator to define one or more service-wide whitelists (lists of entities that are allowed to communicate the service). For example, a publish-subscribe may allow only a select list of users to publish or subscribe to nodes hosted on the service. An entity added to a whitelist MAY be a JID of any form as specified in <cite>RFC 6120</cite>; the order of JID matching SHOULD be that specified for privacy lists in &xep0016;.</p>
<p>As with blacklists, a whitelist may prevent inbound communications, outbound communications, or both; whether to offer only bidirectional blocking or a more granular choice of inbound or outbound blocking is a matter of implementation or deployment policy. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#add-to-whitelist" if blocking is bidirectional; "http://jabber.org/protocol/admin#add-to-whitelist-in" for inbound blocking only; and "http://jabber.org/protocol/admin#add-to-whitelist-out" for outbound blocking only.</p>
<p>A sample protocol flow for this use case is shown below.</p>
<example caption='Admin Requests Editing of Whitelist'><![CDATA[
@ -1223,7 +1223,7 @@
]]></example>
</section2>
<section2 topic='Get Number of Online Users' anchor='get-online-users-num'>
<p>It may be helpful to enable an administrator to retrieve the number of registered users who are online at any one moment. By "online user" is meant any user or account that currently has at least one connected or available resource as specified in <cite>RFC 3920</cite> and <cite>RFC 3921</cite>, whether that user is actively sending XML stanzas or is idle. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-online-users-num".</p>
<p>It may be helpful to enable an administrator to retrieve the number of registered users who are online at any one moment. By "online user" is meant any user or account that currently has at least one connected or available resource as specified in <cite>RFC 6120</cite> and <cite>RFC 6121</cite>, whether that user is actively sending XML stanzas or is idle. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-online-users-num".</p>
<p>A sample protocol flow for this use case is shown below.</p>
<example caption='Admin Requests Number of Online Users'><![CDATA[
<iq from='bard@shakespeare.lit/globe'

4
xep-0150.xml
View File

@ -109,13 +109,13 @@
</error>
</iq>
]]></example>
<p>Note: The &lt;not-modified/&gt; error condition is not specified as a stanza error condition in &rfc3920; and an error code of 304 was not included in the older Jabber error codes (see &xep0086;). However, the &lt;not-modified/&gt; error condition is included in &rfc6120;.</p>
<p>Note: The &lt;not-modified/&gt; error condition is not specified as a stanza error condition in &rfc3920; and an error code of 304 was not included in the older Jabber error codes (see &xep0086;). However, the &lt;not-modified/&gt; error condition is included in &xmppcore;.</p>
<p>Note: In HTTP, an Entity Tag may be either "strong" or "weak" (see Section 13.3.3 of <cite>RFC 2616</cite>); Entity Tags as used in XMPP extensions MUST be considered strong rather than weak.</p>
<p>Note: The ETag and If-None-Match headers SHOULD be used only in &IQ; stanzas, although they MAY be used in &MESSAGE; stanza interactions if IQ request-response semantics are not appropriate, for example in &xep0072; and in certain applications that use &xep0004;.</p>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='Caching and Retrieving Rosters' anchor='roster'>
<p>As specified in &rfc3921;, an XMPP instant messaging client will typically store its "roster" (contact list) on the server so that any connecting client for that account can retrieve the roster at will. Since <cite>RFC 3921</cite> defines no upper limit on the number of items allowed in the roster, it is possible for a roster to become quite large (e.g., there are known cases of rosters with more than 1,000 items). Therefore a server may support Entity Tag functionality with regard to roster management. The process is as follows.</p>
<p>As specified in &xmppim;, an XMPP instant messaging client will typically store its "roster" (contact list) on the server so that any connecting client for that account can retrieve the roster at will. Since <cite>RFC 6121</cite> defines no upper limit on the number of items allowed in the roster, it is possible for a roster to become quite large (e.g., there are known cases of rosters with more than 1,000 items). Therefore a server may support Entity Tag functionality with regard to roster management. The process is as follows.</p>
<p>First, the client requests its roster:</p>
<example caption='Client Requests Roster'><![CDATA[
<iq type='get'

6
xep-0152.xml
View File

@ -60,7 +60,7 @@
<p>Sometimes it is desirable or necessary to switch from instant messaging (IM) to another real-time communications medium, such as a telephone conversation conducted over the traditional public switched telephone network (PSTN) or more recent Voice over Internet Protocol (VoIP) applications. In order to facilitate switching from IM to telephony or some other medium, a user needs to advertise the address(es) at which they can be reached. There are several possible ways to do this:</p>
<ul>
<li><p>Publish the reachability address(es) in the user's vCard (see &xep0054;); this is convenient, but is not very dynamic (e.g., reachability addresses might change when the user moves to a new conference room in an office building).</p></li>
<li><p>Send the reachability address(es) within a &PRESENCE; stanza; this option is described in the <link url='#transport-presence'>Presence Broadcast</link> section of this document and is consistent with Section 5.1.2 of &rfc3921; since reachability is one aspect of a user's availability for communication.</p></li>
<li><p>Send the reachability address(es) within a &PRESENCE; stanza; this option is described in the <link url='#transport-presence'>Presence Broadcast</link> section of this document and is consistent with &rfc6121; since reachability is one aspect of a user's availability for communication.</p></li>
<li><p>Send reachability address(es) to the appropriate &xep0163; node; this option is described in the <link url='#transport-pep'>PEP Transport</link> section of this document but may not be available at all service providers.</p></li>
</ul>
</section1>
@ -82,7 +82,7 @@
</reach>
]]></example>
<p>When publishing reachability addresses, the &lt;reach/&gt; element MUST contain at least one &lt;addr/&gt; element. Each &lt;addr/&gt; element MUST possess a 'uri' attribute, whose value MUST be the Uniform Resource Identifier (&rfc3986;) or Internationalized Resource Identifier (&rfc3987;) of an alternate communications method for reaching the user.</p>
<p>The &lt;addr/&gt; element MAY contain one or more &lt;desc/&gt; children whose XML character data is a natural-language description of the address; this element SHOULD possess an 'xml:lang' attribute whose value is a language tag that conforms to &rfc4646; (although the default language MAY be specified at the stanza level; see Section 9.1.5 of &rfc3920;). In order to preserve bandwidth, the &lt;desc/&gt; element SHOULD NOT be included when sending reachbility data via presence broadcast, but MAY be included when using the personal eventing protocol.</p>
<p>The &lt;addr/&gt; element MAY contain one or more &lt;desc/&gt; children whose XML character data is a natural-language description of the address; this element SHOULD possess an 'xml:lang' attribute whose value is a language tag that conforms to &rfc4646; (although the default language MAY be specified at the stanza level; see &rfc6120;). In order to preserve bandwidth, the &lt;desc/&gt; element SHOULD NOT be included when sending reachbility data via presence broadcast, but MAY be included when using the personal eventing protocol.</p>
<example caption="Reachability Addresses With Descriptions"><![CDATA[
<reach xmlns='urn:xmpp:reach:0'>
<addr uri='tel:+1-303-555-1212'>
@ -201,7 +201,7 @@
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>This document introduces no security considerations above and beyond those described in RFC 3920, RFC 3921, and (for the personal eventing transport) XEP-0163.</p>
<p>This document introduces no security considerations above and beyond those described in RFC 6120, RFC 6121, and (for the personal eventing transport) XEP-0163.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>

2
xep-0153.xml
View File

@ -240,7 +240,7 @@
<p>If the image data exceeds the 8 KB restriction, the processing application SHOULD process the data.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>This document introduces no security considerations above and beyond those described in &rfc3920;, &rfc3921;, and &xep0054;.</p>
<p>This document introduces no security considerations above and beyond those described in &xmppcore;, &xmppim;, and &xep0054;.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>

8
xep-0156.xml
View File

@ -92,9 +92,9 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Although &rfc3920; specifies the use of TCP as the method of connecting to an XMPP server, alternative connection methods exist, including the &xep0124; method for which &xep0206; is the XMPP profile, the &xep0025; method (now deprecated), and less common methods such as &wap;. For some of these methods, it is necessary to discover further parameters before connecting, such as the HTTP URL of an alternative connection manager. Currently, if a client application needs to discover alternative connection methods before connecting to an XMPP service, the relevant information needs to be provided manually by a human user, which is cumbersome and error-prone. Thankfully, there are several potential ways to complete this pre-connection service discovery in an automated fashion:</p>
<p>Although &xmppcore; specifies the use of TCP as the method of connecting to an XMPP server, alternative connection methods exist, including the &xep0124; method for which &xep0206; is the XMPP profile, the &xep0025; method (now deprecated), and less common methods such as &wap;. For some of these methods, it is necessary to discover further parameters before connecting, such as the HTTP URL of an alternative connection manager. Currently, if a client application needs to discover alternative connection methods before connecting to an XMPP service, the relevant information needs to be provided manually by a human user, which is cumbersome and error-prone. Thankfully, there are several potential ways to complete this pre-connection service discovery in an automated fashion:</p>
<ol>
<li><p>Define a &w3wsdl; definition (or other XML file format) and a canonical URL for that definition at a domain that offers XMPP services. Unfortunately, this approach requires access to the HTTP server for the domain (and quite possibly to the root directory thereof), which can be difficult for XMPP server administrators to arrange. In addition, it requires a client to retrieve the relevant file via HTTP before performing DNS lookups and XMPP connection; it would be more efficient to use recognized DNS methods since DNS lookups are already required by <cite>RFC 3920</cite>.</p></li>
<li><p>Define a &w3wsdl; definition (or other XML file format) and a canonical URL for that definition at a domain that offers XMPP services. Unfortunately, this approach requires access to the HTTP server for the domain (and quite possibly to the root directory thereof), which can be difficult for XMPP server administrators to arrange. In addition, it requires a client to retrieve the relevant file via HTTP before performing DNS lookups and XMPP connection; it would be more efficient to use recognized DNS methods since DNS lookups are already required by <cite>RFC 6120</cite>.</p></li>
<li><p>Define a way to specify alternative connection methods as part of the existing DNS SRV records (see &rfc2782;) for a domain that offers XMPP services. While this approach sounds promising, it is not feasible since the DNS SRV Target field can be used only to specify domain names and cannot be used to specify full URIs (such as the URL for an HTTP connection manager).</p></li>
<li><p>Define a way to specify alternative connection methods using the "straightforward NAPTR" (S-NAPTR) profile of the Dynamic Delegation Discovery System (see &rfc3958; and &rfc3401;). Unfortunately, S-NAPTR also does not allow inclusion of full URIs, and thus does not meet the requirements for discovery of alternative connection methods.</p></li>
<li><p>Define a way to specify alternative connection methods using the "URI-enabled NAPTR" (U-NAPTR) profile of the Dynamic Delegation Discovery System (see &rfc4848;). While this is a valid approach that is worth pursuing, the authors are concerned about the deployability of such an approach given the rarity of support for DDDS and U-NAPTR, especially in client-side applications (the main focus of this specification).</p></li>
@ -120,8 +120,8 @@
<section1 topic='Business Rules' anchor='bizrules'>
<p>The following business rules apply:</p>
<ol start='1'>
<li>TXT lookups MUST be used only as a fallback after the methods specified in <cite>RFC 3920</cite> have been exhausted. <note>The point of this rule is to prevent someone from defining a new XEP-0156 connection method like "_xmpp-client-tcp" to override the SRV records defined in the core XMPP specification.</note></li>
<li>A domain SHOULD NOT present information in DNS TXT records that is available via the DNS SRV records defined in <cite>RFC 3920</cite>.</li>
<li>TXT lookups MUST be used only as a fallback after the methods specified in <cite>RFC 6120</cite> have been exhausted. <note>The point of this rule is to prevent someone from defining a new XEP-0156 connection method like "_xmpp-client-tcp" to override the SRV records defined in the core XMPP specification.</note></li>
<li>A domain SHOULD NOT present information in DNS TXT records that is available via the DNS SRV records defined in <cite>RFC 6120</cite>.</li>
<li>The order of DNS TXT records SHOULD NOT be interpreted as significant by the presenting domain or the receiving entity.</li>
</ol>
</section1>

2
xep-0157.xml
View File

@ -83,7 +83,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&rfc2142; specifies conventional electronic mailbox names for common services, roles, and functions related to SMTP, NNTP, and HTTP (such as hostmaster@domain.tld, usenet@domain.tld, and abuse@domain.tld). However, no such conventional email address or XMPP address has been specified for XMPP services (e.g., in &rfc3920;). This document remedies that oversight.</p>
<p>&rfc2142; specifies conventional electronic mailbox names for common services, roles, and functions related to SMTP, NNTP, and HTTP (such as hostmaster@domain.tld, usenet@domain.tld, and abuse@domain.tld). However, no such conventional email address or XMPP address has been specified for XMPP services (e.g., in &rfc3920;). This document remedies that oversight, and the email recommendation specified here has been incorporated into &rfc6120;.</p>
</section1>
<section1 topic='Email Address' anchor='email'>
<p>Consistent with <cite>RFC 2142</cite>, a domain that offers a Jabber/XMPP service SHOULD provide an Internet mailbox of "XMPP" for inquiries related to that service.</p>

2
xep-0158.xml
View File

@ -109,7 +109,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The appearance of large public IM services based on &rfc3920; and &rfc3921; makes it desirable to implement protocols that <em>discourage</em> the sending of large quantities of instant messaging spam (a.k.a. "spim") or, in general, abusive traffic. Abusive stanzas could be generated by XMPP clients connected to legitimate servers or by XMPP servers with virtual clients, where the malicious entities are hosted on networks of "zombie" machines. Such abusive stanas could take many forms; a full taxonomy is outside the scope of this document.</p>
<p>The appearance of large public IM services based on &xmppcore; and &xmppim; makes it desirable to implement protocols that <em>discourage</em> the sending of large quantities of instant messaging spam (a.k.a. "spim") or, in general, abusive traffic. Abusive stanzas could be generated by XMPP clients connected to legitimate servers or by XMPP servers with virtual clients, where the malicious entities are hosted on networks of "zombie" machines. Such abusive stanas could take many forms; a full taxonomy is outside the scope of this document.</p>
<p>One technique developed to combat abusive messages and behavior via non-XMPP technologies requires humans to be differentiated from bots using a "Completely Automated Public Turing Test to Tell Computers and Humans Apart" or CAPTCHA (see &lt;<link url='http://www.captcha.net/'>http://www.captcha.net/</link>&gt;). These challenge techniques are easily adapted to discourage XMPP abuse. The very occasional inconvenience of responding to a CAPTCHA (e.g., when creating an IM account or sending a message to a new correspondent) is small and perfectly acceptable -- especially when compared to the countless robot-generated interruptions people might otherwise have to filter every day.</p>
<p>An alternative technique to CAPTCHAs requires Desktop PC clients to undertake a <span class='ref'>Hashcash</span> <note>Hashcash &lt;<link url='http://hashcash.org/'>http://hashcash.org/</link>&gt;.</note> challenge. These are completely transparent to PC users. They require clients to perform specified CPU-intensive work, making it difficult to send large amounts of abusive traffic.</p>
<p>Both CAPTCHAs and hashcash have been criticized regarding their effectiveness (or lack thereof). Therefore, the challenge protocol specified herein provides a great deal of flexibility, so that challenges can include CAPTCHAs, hashcash, word puzzles, so-called kitten authentication, and any other mechanism that may be developed in the future.</p>

2
xep-0159.xml
View File

@ -52,7 +52,7 @@
<section1 topic='Introduction' anchor='intro'>
<section2 topic='Motivation' anchor='intro-motive'>
<p>The appearance of large public IM services based on &rfc3920; and &rfc3921; makes it desirable to implement protocols that <em>discourage</em> the sending of large quantities of instant messaging spam (a.k.a. "spim"). Spim could be generated by XMPP clients connected to legitimate servers or by XMPP servers with virtual clients, where the malicious entities are hosted on networks of "zombie" machines. Spim is defined here as any type of unsolicited XMPP stanza sent by a "robot" and delivered to a human, including messages and subscription requests. Spim has the potential to disrupt people even more than spam, because each message interrupts the receiver (humans typically filter SPAM in batch mode).</p>
<p>The appearance of large public IM services based on &xmppcore; and &xmppim; makes it desirable to implement protocols that <em>discourage</em> the sending of large quantities of instant messaging spam (a.k.a. "spim"). Spim could be generated by XMPP clients connected to legitimate servers or by XMPP servers with virtual clients, where the malicious entities are hosted on networks of "zombie" machines. Spim is defined here as any type of unsolicited XMPP stanza sent by a "robot" and delivered to a human, including messages and subscription requests. Spim has the potential to disrupt people even more than spam, because each message interrupts the receiver (humans typically filter SPAM in batch mode).</p>
<p>Spim blocking is more efficiently performed on the receiving server for several reasons:</p>
<ul>
<li>The sending server may be controlled by the spimmer.</li>

8
xep-0160.xml
View File

@ -49,13 +49,13 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&rfc3920; and &rfc3921; specify general rules for handling XML stanzas, but explicitly do not address how to handle message stanzas sent to recipients (e.g., IM users or other nodes) that are offline, except to say that a server MUST return a &unavailable; error if offline message storage or message forwarding is not enabled (see Section 11.1 of <cite>RFC 3921</cite>). This document fills the gap by specifying best practices for storage and delivery of so-called "offline messages".</p>
<p>&xmppcore; and &xmppim; specify general rules for handling XML stanzas, but explicitly do not address how to handle message stanzas sent to recipients (e.g., IM users or other nodes) that are offline, except to say that a server MUST return a &unavailable; error if offline message storage or message forwarding is not enabled (see <cite>RFC 6121</cite>). This document fills the gap by specifying best practices for storage and delivery of so-called "offline messages".</p>
</section1>
<section1 topic='Process Flow' anchor='flow'>
<p>The RECOMMENDED process flow is as follows:</p>
<ol>
<li>Sender generates XMPP message stanza <note>This document does not discuss IQ or presence stanzas, handling of which is described in <cite>RFC 3920</cite> and <cite>RFC 3921</cite>.</note> for delivery to a recipient such as an IM user or other node, where the 'to' address is of the form &lt;node@domain&gt; or &lt;node@domain/resource&gt; (see <cite>RFC 3921</cite> for rules regarding server handling of such XMPP message stanzas).</li>
<li>Recipient's server determines that the intended recipient has no available resources that have specified non-negative presence priority. <note>As specified in <cite>RFC 3920</cite>, available resources that have specified a negative presence priority shall never receive message stanzas addressed to &lt;node@domain&gt;.</note></li>
<li>Sender generates XMPP message stanza <note>This document does not discuss IQ or presence stanzas, handling of which is described in <cite>RFC 6120</cite> and <cite>RFC 6121</cite>.</note> for delivery to a recipient such as an IM user or other node, where the 'to' address is of the form &lt;node@domain&gt; or &lt;node@domain/resource&gt; (see <cite>RFC 6121</cite> for rules regarding server handling of such XMPP message stanzas).</li>
<li>Recipient's server determines that the intended recipient has no available resources that have specified non-negative presence priority. <note>As specified in <cite>RFC 6120</cite>, available resources that have specified a negative presence priority shall never receive message stanzas addressed to &lt;node@domain&gt;.</note></li>
<li>Recipient's server determines that if the server can store offline messages on behalf of the intended recipient; if not (e.g., because the recipient's offline message queue is full), the server returns a &unavailable; error to the sender.</li>
<li>Recipient's server does not return a &unavailable; error but instead stores the message stanza for later delivery.</li>
<li>When the recipient next sends non-negative available presence to the server, the server delivers the message to the resource that has sent that presence. (Alternatively, the server may support &xep0013;, although that functionality is not described herein.)</li>
@ -94,7 +94,7 @@
]]></example>
</section1>
<section1 topic='Handling of Message Types' anchor='types'>
<p>Message stanzas SHOULD be handled by a server as follows (based on the values of the 'type' attribute specified in <cite>RFC 3921</cite>):</p>
<p>Message stanzas SHOULD be handled by a server as follows (based on the values of the 'type' attribute specified in <cite>RFC 6121</cite>):</p>
<ul>
<li><p><strong>normal</strong> -- Messages with a 'type' attribute whose value is "normal" (or messages with no 'type' attribute) SHOULD be stored offline.</p></li>
<li><p><strong>chat</strong> -- Messages with a 'type' attribute whose value is "chat" SHOULD be stored offline, with the exception of messages that contain only &xep0085; content (such messages SHOULD NOT be stored offline).</p></li>

4
xep-0165.xml
View File

@ -75,7 +75,7 @@
<section1 topic='Introduction' anchor='intro'>
<p>There are two forms of address spoofing: forging and mimicking.</p>
<p>In the context of Jabber/XMPP technologies, an address is <em>forged</em> when an entity is able to generate an XML stanza whose 'from' address does not correspond to the account credentials with which the entity authenticated onto the network -- for example, if an entity that authenticated as "stpeter@jabber.org" is able to send XML stanzas from "MaineBoy@jabber.org" or "peter@saint-andre.com".</p>
<p>Address forging is difficult in Jabber/XMPP systems given the requirement for sending servers to stamp 'from' addresses and for receiving servers to verify sending domains via server dialback or server-to-server authentication (see &rfc3920;). Difficult, but not impossible: a rogue server could forge JIDs at the sending domain by ignoring the stamping requirement and could even forge JIDs at other domains by means of a DNS poisoning attack. However, discussion of ways to deal with such rogue servers is out of scope for this document.</p>
<p>Address forging is difficult in Jabber/XMPP systems given the requirement for sending servers to stamp 'from' addresses and for receiving servers to verify sending domains via server dialback or server-to-server authentication (see &xmppcore;). Difficult, but not impossible: a rogue server could forge JIDs at the sending domain by ignoring the stamping requirement and could even forge JIDs at other domains by means of a DNS poisoning attack. However, discussion of ways to deal with such rogue servers is out of scope for this document.</p>
<p>An address is <em>mimicked</em> when an entity provides legitimate authentication credentials for and sends XML stanzas from an account whose Jabber ID (JID) appears to a human user to be the same as another JID -- for example, in some clients "paypa1@jabber.org" (spelled with the number one as the final character of the node identifier) may appear to be the same as "paypal@jabber.org (spelled with the lower-case version of the letter "L"). <note>This phenomenon is sometimes called "typejacking".</note> A more sophisticated example of address mimicking (which may not render correctly in all browsers) is the following:</p>
<code>
&#5082;&#5026;&#5045;&#5036;&#5026;&#5036;&#5074;@&#5035;&#5034;&#5108;&#5108;&#5036;&#5074;.org</code>
@ -96,7 +96,7 @@
<ol>
<li><p>The JID "stpeter@jabber.org" is globally unique on the Jabber/XMPP network, but it is not necessarily memorable.</p></li>
<li><p>The nickname "psa" (asserted by the user associated with the address "stpeter@jabber.org") is globally memorable but not necessarily unique; see &xep0172; for more information about user-asserted nicknames.</p></li>
<li><p>The handle or petname "that protocol dude" (assigned by a contact who adds "stpeter@jabber.org" to her contact list) is privately memorable and unique <note>If not shared or leaked, it may even be securely unique.</note> but is by no means global since it has meaning only to the person who assigns it; for consistency with <cite>XEP-0172</cite> and &rfc6121; we refer to this as a "handle". <note>In <cite>RFC 3921</cite> this was referred to as an "alias".</note></p></li>
<li><p>The handle or petname "that protocol dude" (assigned by a contact who adds "stpeter@jabber.org" to her contact list) is privately memorable and unique <note>If not shared or leaked, it may even be securely unique.</note> but is by no means global since it has meaning only to the person who assigns it; for consistency with <cite>XEP-0172</cite> and &xmppim; we refer to this as a "handle". <note>In <cite>RFC 6121</cite> this was referred to as an "alias".</note></p></li>
</ol>
<p>A client SHOULD require an end user to assign a handle for every contact added to the person's roster, which SHOULD be stored in the roster as the value of the &lt;item/&gt; element's 'name' attribute (see the <link url='#security'>Security Considerations</link> section of this document for further discussion). A client SHOULD then present that handle instead of or in addition to the contact's JID or nickname (e.g., in the user's roster and in chat interfaces). This will help to discourage mimicked addresses from being presented as equivalent to the address that is being mimicked.</p>
</section2>

2
xep-0168.xml
View File

@ -117,7 +117,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Within the Extensible Messaging and Presence Protocol (XMPP; see &rfc3920;), presence indicates availability for communication. Specifically, in systems that bundle presence and instant messaging (see &rfc3921;), the &lt;priority/&gt; child of the XMPP &PRESENCE; stanza indicates availability for communications qualified by the "jabber:client" namespace, especially instant messaging. However, a wide variety of entities might provide XMPP presence, including entities that are not primarily focused on IM (e.g., phones) or even entities that do not support XMPP messaging at all.</p>
<p>Within the Extensible Messaging and Presence Protocol (&xmppcore;), presence indicates availability for communication. Specifically, in systems that bundle presence and instant messaging (see &xmppim;), the &lt;priority/&gt; child of the XMPP &PRESENCE; stanza indicates availability for communications qualified by the "jabber:client" namespace, especially instant messaging. However, a wide variety of entities might provide XMPP presence, including entities that are not primarily focused on IM (e.g., phones) or even entities that do not support XMPP messaging at all.</p>
<p>Consider a scenario in which a contact wants to initiate a voice chat (see &xep0167;) with a user who has the following three XMPP resources:</p>
<table caption='Application Presence'>
<tr>

4
xep-0171.xml
View File

@ -107,7 +107,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>There currently exists no standard for describing language translations over a text chat protocol. While numerous products and services exist to provide translation of text, there exists no standardized protocol extension for requesting a translation and expressing the details of the translation over XMPP (see &rfc3920;). This document describes how to express a translation and its components in an XMPP message as well as a method to request translation.</p>
<p>There currently exists no standard for describing language translations over a text chat protocol. While numerous products and services exist to provide translation of text, there exists no standardized protocol extension for requesting a translation and expressing the details of the translation over XMPP (see &xmppcore;). This document describes how to express a translation and its components in an XMPP message as well as a method to request translation.</p>
<p>Direct translation can be realized by either client-side translation before sending or transparent components translating messages on the fly. Discovering XMPP entities capable of translation allows for clients to request translation from them based on their capabilities. The remote XMPP entity could be either an automated translation service or a human providing translation.</p>
</section1>
<section1 topic='Glossary' anchor='glossary'>
@ -380,7 +380,7 @@
<p>Note: The 'reviewed' and 'pivotable' attributes are of type "boolean" and MUST be handled accordingly. &BOOLEANNOTE;</p>
</section1>
<section1 topic='Internationalization Considerations' anchor='i18n'>
<p>In order to properly process multi-language messages, clients MUST implement support for multiple message bodies differentiated by the 'xml:lang' attribute as described in <cite>RFC 3920</cite>.</p>
<p>In order to properly process multi-language messages, clients MUST implement support for multiple message bodies differentiated by the 'xml:lang' attribute as described in <cite>RFC 6120</cite>.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>Potential attacks may be easier against services that implement translation because of the potential disclosure of information regarding language pairings, engines, and dictionaries used however no specific vulnerabilities are introduced.</p>

2
xep-0198.xml
View File

@ -161,7 +161,7 @@
<li>Stream Resumption -- the ability to quickly resume a stream that has been terminated.</li>
</ul>
<p>Stream management implements these features using short XML elements at the root stream level. These elements are not "stanzas" in the XMPP sense (i.e., not &IQ;, &MESSAGE;, or &PRESENCE; stanzas as defined in &xmppcore;) and are not counted or acked in stream management, since they exist for the purpose of managing stanzas themselves.</p>
<p>Stream management is used at the level of an XML stream. To check TCP connectivity underneath a given stream, it is RECOMMENDED to use whitespace keepalives (see Section 4.6.1 of &rfc6120;), &xep0199;, or TCP keepalives. By constrast with stream management, &xep0079; and &xep0184; define acks that are sent end-to-end over multiple streams; these facilities are useful in special scenarios but are unnecessary for checking of a direct stream between two XMPP entities.</p>
<p>Stream management is used at the level of an XML stream. To check TCP connectivity underneath a given stream, it is RECOMMENDED to use whitespace keepalives (see &xmppcore;), &xep0199;, or TCP keepalives. By constrast with stream management, &xep0079; and &xep0184; define acks that are sent end-to-end over multiple streams; these facilities are useful in special scenarios but are unnecessary for checking of a direct stream between two XMPP entities.</p>
<p>(Examples prepended by "C:" are sent by a client and examples prepended by "S:" are sent by a server. Stream management can be used server-to-server but most of the examples in this specification show its use between a client and a server.)</p>
</section1>

16
xep-0199.xml
View File

@ -70,7 +70,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>As specified in &rfc3920;, the XML streams used in XMPP are bound to TCP. Unfortunately, TCP connections can go down without the application (XMPP) layer knowing about it. The traditional approach to solving this issue has been to periodically send so-called "whitespace pings" over the XML stream. This document recommends a more XML-friendly approach, which can be used over more than one hop in the communication path (e.g., from one client to another) and can also be used with other bindings such as the &xep0124; method for which &xep0206; is the XMPP profile.</p>
<p>As specified in &xmppcore;, the XML streams used in XMPP are bound to TCP. Unfortunately, TCP connections can go down without the application (XMPP) layer knowing about it. The traditional approach to solving this issue has been to periodically send so-called "whitespace pings" over the XML stream. This document recommends a more XML-friendly approach, which can be used over more than one hop in the communication path (e.g., from one client to another) and can also be used with other bindings such as the &xep0124; method for which &xep0206; is the XMPP profile.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
@ -110,7 +110,7 @@
</error>
</iq>
]]></example>
<p>The other error conditions defined in <cite>RFC 3920</cite> could also be returned if appropriate.</p>
<p>The other error conditions defined in <cite>RFC 6120</cite> could also be returned if appropriate.</p>
</section2>
<section2 topic='Client-To-Server Pings' anchor='c2s'>
<p>A client may also ping its server by sending an IQ-get over the stream between the two entities.</p>
@ -133,7 +133,7 @@
</error>
</iq>
]]></example>
<p>The other error conditions defined in <cite>RFC 3920</cite> could also be returned if appropriate.</p>
<p>The other error conditions defined in <cite>RFC 6120</cite> could also be returned if appropriate.</p>
</section2>
<section2 topic='Server-To-Server Pings' anchor='s2s'>
<p>Pings can also be used to test a server-to-server connection. This is done by sending an IQ-get over the stream from one server to another.</p>
@ -155,7 +155,7 @@
</error>
</iq>
]]></example>
<p>The other error conditions defined in <cite>RFC 3920</cite> could also be returned if appropriate.</p>
<p>The other error conditions defined in <cite>RFC 6120</cite> could also be returned if appropriate.</p>
</section2>
<section2 topic='Client-to-Client Pings' anchor='e2e'>
<p>Pings can also be used for client-to-client (i.e., end-to-end) pings.</p>
@ -187,7 +187,7 @@
</error>
</iq>
]]></example>
<p>The other error conditions defined in <cite>RFC 3920</cite> could also be returned if appropriate.</p>
<p>The other error conditions defined in <cite>RFC 6120</cite> could also be returned if appropriate.</p>
</section2>
<section2 topic='Component-to-Client Pings' anchor='other'>
<p>Pings can also be used for component-to-client pings, for example from a &xep0045; component to a client.</p>
@ -207,7 +207,7 @@
id='comp1'
type='result'/>
]]></example>
<p>If the pinged entity does not support the ping namespace, <cite>RFC 3920</cite> requires it to return a &unavailable; error:</p>
<p>If the pinged entity does not support the ping namespace, <cite>RFC 6120</cite> requires it to return a &unavailable; error:</p>
<example caption="Ping Not Supported"><![CDATA[
<iq from='juliet@capulet.lit/chamber'
to='chat.shakespeare.lit'
@ -219,7 +219,7 @@
</error>
</iq>
]]></example>
<p>The other error conditions defined in <cite>RFC 3920</cite> could also be returned if appropriate.</p>
<p>The other error conditions defined in <cite>RFC 6120</cite> could also be returned if appropriate.</p>
</section2>
</section1>
@ -253,7 +253,7 @@
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>If a server receives a ping request directed to a full JID &LOCALFULL; associated with a registered account but there is no connected resource matching the 'to' address, <cite>RFC 3920</cite> requires it to reply with a &unavailable; error and set the 'from' address of the IQ-error to the full JID provided in the 'to' address of the ping request. If a connected resource receives a ping request but it does not want to reveal its network availability to the sender for any reason (e.g., because the sender is not authorized to know the connected resource's availability), then it too MUST reply with a &unavailable; error. This consistency between the server response and the client response helps to prevent presence leaks.</p>
<p>If a server receives a ping request directed to a full JID &LOCALFULL; associated with a registered account but there is no connected resource matching the 'to' address, <cite>RFC 6120</cite> requires it to reply with a &unavailable; error and set the 'from' address of the IQ-error to the full JID provided in the 'to' address of the ping request. If a connected resource receives a ping request but it does not want to reveal its network availability to the sender for any reason (e.g., because the sender is not authorized to know the connected resource's availability), then it too MUST reply with a &unavailable; error. This consistency between the server response and the client response helps to prevent presence leaks.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>

4
xep-0200.xml
View File

@ -129,8 +129,8 @@
<p>Alice MAY use this protocol to encrypt only that part of the <em>content</em> of one-to-one &MESSAGE;, &PRESENCE; and &IQ; stanzas that would normally be ignored by the intermediate servers. She MUST NOT encrypt:</p>
<ul>
<li><p>Stanza wrapper element tags (only stanza content)</p></li>
<li><p>&lt;error/&gt; elements <note>RFC 3920 requires that stanzas of type 'error' contain an &lt;error/&gt; child element.</note></p></li>
<li><p>&lt;defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/&gt; child elements of &lt;error/&gt; elements. <note>RFC 3920 requires that &lt;error/&gt; elements contain a &lt;defined-condition/&gt; child element.</note></p></li>
<li><p>&lt;error/&gt; elements <note>RFC 6120 requires that stanzas of type 'error' contain an &lt;error/&gt; child element.</note></p></li>
<li><p>&lt;defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/&gt; child elements of &lt;error/&gt; elements. <note>RFC 6120 requires that &lt;error/&gt; elements contain a &lt;defined-condition/&gt; child element.</note></p></li>
<li><p>&THREAD; elements <note>Applications typically use &THREAD; elements internally to route stanzas to the process handling a session. The content of thread elements MUST be opaque with no semantic meaning and only exact comparisons MAY be made against it.</note></p></li>
<li><p>&lt;amp/&gt; elements (see &xep0079;)</p></li>
</ul>

8
xep-0205.xml
View File

@ -59,7 +59,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>A key factor in the reliability and security of network infrastructure is its resilience in the face of denial of service attacks (see &rfc4732;). Although the existing network of servers and clients that communicate via the Extensible Messaging and Presence Protocol (XMPP; see &rfc3920;) has not yet been subject to such attacks, that is no cause for complacency. Therefore this document specifies a set of best practices that server implementations and deployments can follow in order to reduce the likelihood of denial of service attacks on the Jabber network.</p>
<p>A key factor in the reliability and security of network infrastructure is its resilience in the face of denial of service attacks (see &rfc4732;). Although the existing network of servers and clients that communicate via the Extensible Messaging and Presence Protocol (&xmppcore;) has not yet been subject to such attacks, that is no cause for complacency. Therefore this document specifies a set of best practices that server implementations and deployments can follow in order to reduce the likelihood of denial of service attacks on the Jabber network.</p>
</section1>
<section1 topic='Potential Attacks' anchor='attacks'>
<p><cite>RFC 4732</cite> defines denial of service as follows:</p>
@ -79,9 +79,9 @@
<p>Numerous potential solutions have been suggested to deal with the threat of denial of service attacks against XMPP servers, including the following:</p>
<ol start='1'>
<li><p>Limiting the number of connections that a server will accept from a given IP address at any one time. Such a limit may help to prevent automated processes from exhausting the server's resources (such as available ports or XML parser processing resources).</p></li>
<li><p>Limiting the number of connection attempts (via the TCP binding specified in <cite>RFC 3920</cite> or via the &xep0124;) that a server will accept from a given IP address in a given time period. Such a limit may help to prevent automated processes from exhausting the server's resources (such as available ports or XML parser processing capacity).</p></li>
<li><p>Limiting the number of connection attempts (via the TCP binding specified in <cite>RFC 6120</cite> or via the &xep0124;) that a server will accept from a given IP address in a given time period. Such a limit may help to prevent automated processes from exhausting the server's resources (such as available ports or XML parser processing capacity).</p></li>
<li><p>Limiting the number of authentication attempts for a given Jabber ID in a given time period. While such a limit may seem beneficial, in fact it might result in locking out the legitimate owner of a Jabber ID if a malicious entity attempts a large number of illegitimate authentication attempts for the Jabber ID; therefore such a limit is not recommended except as described in Section 6.4.5 of &rfc6120;, and it is instead recommended to limit the number of connections and connection attempts on a per-IP basis.</p></li>
<li><p>Disallowing unauthenticated connections from clients and from peer servers; as mentioned below, this is required by <cite>RFC 3920</cite>.</p></li>
<li><p>Disallowing unauthenticated connections from clients and from peer servers; as mentioned below, this is required by <cite>RFC 6120</cite>.</p></li>
<li><p>Limiting the number of XMPP resource identifiers allowed to an account at any one time. This may help to prevent a rogue account from creating an unlimited number of sessions and therefore exhausting the resources of the server's session manager.</p></li>
<li><p>Limiting the absolute size in bytes of XML stanzas accepted by the server, or of particular aspects of an XML stanza (e.g., attribute values, element names, XML character data). Limits on particular aspects of an XML stanza are probably not needed, as long as it is possible to limit the absolute size of each XML stanza, since such a limit may help to prevent exhaustion of server resources (e.g., XML parser processing capacity).</p></li>
<li><p>Limiting the number of bytes or XML stanzas that a server will accept over a given TCP connection or for a given JabberID in a given time period. Such a limit, which helps to prevent rogue accounts or hijacked clients from flooding the server, is common in existing XMPP server implementations and often goes by the name "karma".</p></li>
@ -102,7 +102,7 @@
<p>If an entity attempts to connect but the maximum number of connection attempts has been reached, the receiving server MUST NOT allow the new connection to proceed. There are no XMPP errors associated with this behavior, since it occurs at the binding (TCP or HTTP) level before an XML stream is initiated.</p>
</section2>
<section2 topic='Unauthenticated Connections' anchor='rec-auth'>
<p>In accordance with <cite>RFC 3920</cite>, a server MUST NOT process XML stanzas (i.e., &MESSAGE;, &PRESENCE;, or &IQ;) from clients that have not yet provided appropriate authentication credentials, and MUST NOT process XML stanzas from peer servers whose identity it has not either authenticated via SASL (see &rfc4422;) or verified via server dialback.</p>
<p>In accordance with <cite>RFC 6120</cite>, a server MUST NOT process XML stanzas (i.e., &MESSAGE;, &PRESENCE;, or &IQ;) from clients that have not yet provided appropriate authentication credentials, and MUST NOT process XML stanzas from peer servers whose identity it has not either authenticated via SASL (see &rfc4422;) or verified via server dialback.</p>
</section2>
<section2 topic='Simultaneous Resources' anchor='rec-resources'>
<p>A server implementation SHOULD enable a server administrator to limit the number of resources it will allow an account to bind at any one time.</p>

9
xep-0211.xml
View File

@ -87,12 +87,12 @@
<th>Requirement Level</th>
</tr>
<tr>
<td><strong>&rfc3920;</strong></td>
<td>REQUIRED *</td>
<td><strong>&rfc6120;</strong></td>
<td>REQUIRED</td>
</tr>
<tr>
<td><strong>&rfc3921;</strong></td>
<td>REQUIRED *</td>
<td><strong>&rfc6121;</strong></td>
<td>REQUIRED</td>
</tr>
<tr>
<td><strong>&xep0030;</strong></td>
@ -111,7 +111,6 @@
<td>RECOMMENDED</td>
</tr>
</table>
<p>* Note: RFC 3920 and RFC 3921 are currently being revised to correct errors, clarify matters that were underspecified, and incorporate feedback based on implementation and deployment experience gained since RFC 3920 and RFC 3921 were published in 2004. Although the compliance level specified herein refers to RFC 3920 and RFC 3921, developers are also advised to consult &rfc3920bis; and &rfc3921bis;, which provide the most up-to-date and accurate description the core XMPP protocols.</p>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>Some of the protocol specifications referenced herein have their own dependencies; developers must refer to the relevant specifications for further information.</p>

15
xep-0212.xml
View File

@ -81,12 +81,12 @@
<th>Requirement Level</th>
</tr>
<tr>
<td><strong>&rfc3920;</strong></td>
<td>REQUIRED *</td>
<td><strong>&rfc6120;</strong></td>
<td>REQUIRED</td>
</tr>
<tr>
<td><strong>&rfc3921;</strong></td>
<td>REQUIRED *</td>
<td><strong>&rfc6121;</strong></td>
<td>REQUIRED</td>
</tr>
<tr>
<td><strong>&xep0030;</strong></td>
@ -94,19 +94,18 @@
</tr>
<tr>
<td><strong>&xep0078;</strong></td>
<td>RECOMMENDED **</td>
<td>RECOMMENDED *</td>
</tr>
<tr>
<td><strong>&xep0086;</strong></td>
<td>RECOMMENDED **</td>
<td>RECOMMENDED *</td>
</tr>
<tr>
<td><strong>&xep0138;</strong></td>
<td>RECOMMENDED</td>
</tr>
</table>
<p>* Note: RFC 3920 and RFC 3921 are currently being revised to correct errors, clarify matters that were underspecified, and incorporate feedback based on implementation and deployment experience gained since RFC 3920 and RFC 3921 were published in 2004. Although the compliance level specified herein refers to RFC 3920 and RFC 3921, developers are also advised to consult &rfc3920bis; and &rfc3921bis;, which provide the most up-to-date and accurate description the core XMPP protocols.</p>
<p>** Note: Support for XEP-0078 and XEP-0086 is recommended for backward compatibility only. It is likely that compliance definitions for future years will remove these recommendations.</p>
<p>* Note: Support for XEP-0078 and XEP-0086 is recommended for backward compatibility only. It is likely that compliance definitions for future years will remove these recommendations.</p>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>Some of the protocol specifications referenced herein have their own dependencies; developers must refer to the relevant specifications for further information.</p>

8
xep-0219.xml
View File

@ -67,7 +67,7 @@
<section1 topic='Introduction' anchor='intro'>
<p><em>Note: This specification has been retracted by the author because the problem is not compelling and a real solution would be too complicated.</em></p>
<section2 topic='Motivation' anchor='motivation'>
<p>When two XMPP users communicate, one or both of them may want to know the status of the XMPP communications path (i.e., of all the hops) between them. While the primary motivation is to determine if all the hops are secured via Transport Layer Security (see &rfc5246;) as specified for XMPP in &rfc3920;, more general information about the communications path may also be of interest.</p>
<p>When two XMPP users communicate, one or both of them may want to know the status of the XMPP communications path (i.e., of all the hops) between them. While the primary motivation is to determine if all the hops are secured via Transport Layer Security (see &rfc5246;) as specified for XMPP in &xmppcore;, more general information about the communications path may also be of interest.</p>
<p>This document describes a protocol for discovering such information, similar in spirit to the traceroute protocol specified in &rfc1393; but specific to XMPP.</p>
</section2>
<section2 topic='Approach' anchor='approach'>
@ -183,9 +183,9 @@
<li>If the respondent does not support the hopcheck namespace, it MUST return a &unavailable; error.</li>
<li>If the &lt;hopcheck/&gt; element does not include a 'to' attribute, the respondent MUST return a &badrequest; error.</li>
<li>If the 'to' or 'for' attribute of the &lt;hopcheck/&gt; element contains a JID that is malformed, the respondent MUST return a &badjid; error.</li>
<li>If the respondent is a server and the sender is a full JID &LOCALFULL;, the server MUST verify that the JID is a connected resource of the server (per <cite>RFC 3920</cite>); if it is not, then the respondent MUST return a &forbidden; error.</li>
<li>If the respondent is a server and the sender is a full JID &LOCALFULL;, the server MUST verify that the JID is a connected resource of the server (per <cite>RFC 6120</cite>); if it is not, then the respondent MUST return a &forbidden; error.</li>
<li>If both the sender and the respondent are servers and the domain identifier of the &lt;hopcheck/&gt; element's 'to' attribute does not match a validated domain of the respondent, the respondent MUST return a &notfound; error.</li>
<li>If both the sender and the respondent are servers, the JID of the &lt;hopcheck/&gt; element's 'to' is a connected resource of the respondent server, and the JID of the &lt;hopcheck/&gt; element's 'for' is not authorized to know the presence of the target (either via presence subscription or temporary presence sharing via directed presence as defined in &rfc3921;), then the respondent MUST return a &forbidden; error.</li>
<li>If both the sender and the respondent are servers, the JID of the &lt;hopcheck/&gt; element's 'to' is a connected resource of the respondent server, and the JID of the &lt;hopcheck/&gt; element's 'for' is not authorized to know the presence of the target (either via presence subscription or temporary presence sharing via directed presence as defined in &xmppim;), then the respondent MUST return a &forbidden; error.</li>
</ul>
</section2>
<section2 topic='Response' anchor='protocol-response'>
@ -214,7 +214,7 @@
<ul>
<li>A Simple Authentication and Security Layer mechanism (see &rfc4422; for the specification and &ianasasl; for a list of registered SASL mechanisms; the names for standardized, non-obsolete mechanisms are used as values of the 'auth' attribute).</li>
<li>The obsolete &xep0078; protocol using the "plaintext" or "digest" method.</li>
<li>The server dialback protocol ("dialback") as specified in <cite>RFC 3920</cite>.</li>
<li>The server dialback protocol ("dialback") as specified in &xep0220;.</li>
</ul>
</section2>
</section1>

4
xep-0233.xml
View File

@ -54,7 +54,7 @@
<section1 topic='Introduction' anchor='intro'>
<p>In certain kinds of XMPP deployments, multiple connection managers associated with the XMPP server can be used to handle requests from connecting clients. In such an architecture, the connection manager might need to communicate the hostname to which the client has connected, or information about alternative connection manager.</p>
<p>This is especially true in environments that make use of Kerberos V and negotiation of Simple Authentication and Security Layer (SASL) over XMPP, because the client might need additional information about the Kerberos principal so that it can obtain a proper ticket for authentication.</p>
<p>This scenario was not addressed in &rfc3920;. However, the problem can now be solved using the concept of domain-based service names as described in &rfc5178;. In particular, because XMPP servers typically use the Kerberos V5 ("GSSAPI") SASL mechanism as described in &rfc4752;, they can communicate domain-based names as Kerberos V service principal names as described in &rfc5179;.</p>
<p>This scenario was not addressed in &rfc3920; or &rfc6120;. However, the problem can now be solved using the concept of domain-based service names as described in &rfc5178;. In particular, because XMPP servers typically use the Kerberos V5 ("GSSAPI") SASL mechanism as described in &rfc4752;, they can communicate domain-based names as Kerberos V service principal names as described in &rfc5179;.</p>
<p>Therefore this document defines a method for communication of authentication hostnames (especially Kerberos V domain-based service names) in the context of SASL negotiation by XMPP entities.</p>
</section1>
@ -94,7 +94,7 @@
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>The communication of hostnames during SASL negotiation is not known to introduce new security vulnerabilities. Communication of hostnames SHOULD NOT occur until after the underlying channel has been secured using Transport Layer Security (TLS; &rfc5246;) as described for XMPP in <cite>RFC 3920</cite> and <cite>RFC 6120</cite>. For additional security considerations, refer to <cite>RFC5178</cite> and <cite>RFC 5179</cite>.</p>
<p>The communication of hostnames during SASL negotiation is not known to introduce new security vulnerabilities. Communication of hostnames SHOULD NOT occur until after the underlying channel has been secured using Transport Layer Security (TLS; &rfc5246;) as described for XMPP in <cite>RFC 6120</cite> and <cite>RFC 6120</cite>. For additional security considerations, refer to <cite>RFC5178</cite> and <cite>RFC 5179</cite>.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>

4
xep-0238.xml
View File

@ -41,7 +41,7 @@
<ol start='1'>
<li><p>Permissive Federation -- a server accepts a connection from any other peer on the network, even without verifiying the identity of the peer based on DNS lookups. The lack of peer verification or authentication means that domains can be spoofed. Permissive federation was effectively outlawed on the Jabber network in October 2000 with the release of the jabberd 1.2 server, which included support for the newly-developed &xep0220; protocol.</p></li>
<li><p>Verified Federation -- a server accepts a connection from a peer only after the identity of the peer has been weakly verified via Server Dialback, based on information obtained via the Domain Name System (DNS) and verification keys exchanged in-band over XMPP. However, the connection is not encrypted. The use of identity verification effectively prevents domain spoofing, but federation requires proper DNS setup and is still subject to DNS poisoning attacks. Verified federation has been the default service policy followed by servers on the open XMPP network from October 2000 until now.</p></li>
<li><p>Encrypted Federation -- a server accepts a connection from a peer only if the peer supports Transport Layer Security (TLS) as defined for XMPP in &rfc3920; and the peer presents a digital certificate. However, the certificate may be self-signed, in which case mutual authentication is typically not possible. Therefore, after STARTTLS negotiation the parties proceed to weakly verify identity using Server Dialback. This combination results in an encrypted connection with weak identity verification.</p></li>
<li><p>Encrypted Federation -- a server accepts a connection from a peer only if the peer supports Transport Layer Security (TLS) as defined for XMPP in &xmppcore; and the peer presents a digital certificate. However, the certificate may be self-signed, in which case mutual authentication is typically not possible. Therefore, after STARTTLS negotiation the parties proceed to weakly verify identity using Server Dialback. This combination results in an encrypted connection with weak identity verification.</p></li>
<li><p>Trusted Federation -- a server accepts a connection from a peer only if the peer supports Transport Layer Security (TLS) and the peer presents a digital certificate issued by a trusted root certification authority (CA). The list of trusted root CAs is determined by local service policy, as is the level of trust accorded to various types of certificates (i.e., Class 1, Class 2, or Class 3). The use of trusted domain certificates effectively prevents DNS poisoning attacks but makes federation more difficult since typically such certificates are not easy to obtain.</p></li>
</ol>
<p>The remainder of this document describes in more detail the protocol flows that make it possible to deploy verified federation, encrypted federation, and trusted federation. Protocol flows are shown for federation attempts between various combinations to illustrate the interaction between different federation policies.</p>
@ -62,7 +62,7 @@
<td>Type 1</td>
<td>Verified Only</td>
<td>None</td>
<td>XMPP 0.9 <note>"XMPP 0.9" is the core XML streaming protocol used in the Jabber community before the formalization of XMPP 1.0 by the IETF in <cite>RFC 3920</cite>, including STARTTLS and SASL.</note> and Server Dialback</td>
<td>XMPP 0.9 <note>"XMPP 0.9" is the core XML streaming protocol used in the Jabber community before the formalization of XMPP 1.0 by the IETF in &rfc3920;, including STARTTLS and SASL.</note> and Server Dialback</td>
<td>type1.lit</td>
<td>citizen@type1.lit</td>
</tr>

5
xep-0242.xml
View File

@ -59,12 +59,11 @@
<section1 topic='XMPP Core Client 2009' anchor='core'>
<p>The XMPP Core Client 2009 certification level is defined as follows:</p>
<ul>
<li>&rfc3920; *</li>
<li>&rfc3921; *</li>
<li>&rfc6120;</li>
<li>&rfc6121;</li>
<li>&xep0030;</li>
<li>&xep0115;</li>
</ul>
<p>* Note: RFC 3920 and RFC 3921 are currently being revised to correct errors, clarify matters that were underspecified, and incorporate feedback based on implementation and deployment experience gained since RFC 3920 and RFC 3921 were published in 2004. Although the compliance level specified herein refers to RFC 3920 and RFC 3921, developers are also advised to consult &rfc3920bis; and &rfc3921bis;, which provide the most up-to-date and accurate description the core XMPP protocols.</p>
</section1>
<section1 topic='XMPP Advanced Client 2009' anchor='advanced'>
<p>The XMPP Advanced Client 2009 certification level is defined as follows:</p>

5
xep-0243.xml
View File

@ -67,11 +67,10 @@
<section1 topic='XMPP Core Server 2009' anchor='core'>
<p>The XMPP Core Server 2009 certification level is defined below. Support for these specifications is REQUIRED for compliance purposes.</p>
<ul>
<li>&rfc3920; *</li>
<li>&rfc3921; *</li>
<li>&rfc6120;</li>
<li>&rfc6121;</li>
<li>&xep0030;</li>
</ul>
<p>* Note: RFC 3920 and RFC 3921 are currently being revised to correct errors, clarify matters that were underspecified, and incorporate feedback based on implementation and deployment experience gained since RFC 3920 and RFC 3921 were published in 2004. Although the compliance level specified herein refers to RFC 3920 and RFC 3921, developers are also advised to consult &rfc3920bis; and &rfc3921bis;, which provide the most up-to-date and accurate description the core XMPP protocols.</p>
</section1>
<section1 topic='XMPP Advanced Server 2009' anchor='advanced'>
<p>The XMPP Advanced Server 2009 certification level is defined as follows:</p>

10
xep-0246.xml
View File

@ -36,7 +36,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>XMPP as defined in &rfc3920; does not support direct interaction between endpoints, since it requires a client to authenticate an XML stream with a "home" server and send of all of its outbound XML stanzas through that server (which potentially can route those stanzas through a peer server for delivery to the intended recipient). However, in some scenarios it is desirable to establish end-to-end XML streams between two endpoints instead of relying on the standard client-server architecture. These scenarios include:</p>
<p>XMPP as defined in &xmppcore; does not support direct interaction between endpoints, since it requires a client to authenticate an XML stream with a "home" server and send of all of its outbound XML stanzas through that server (which potentially can route those stanzas through a peer server for delivery to the intended recipient). However, in some scenarios it is desirable to establish end-to-end XML streams between two endpoints instead of relying on the standard client-server architecture. These scenarios include:</p>
<ul>
<li>Two endpoints cannot access an XMPP server</li>
<li>Two endpoints want to enforce end-to-end encryption</li>
@ -47,7 +47,7 @@
</section1>
<section1 topic='Initiating an e2e Stream' anchor='initiate'>
<p>The initiator and recipient essentially follow the process defined in <cite>RFC 3920</cite> to establish XML streams between themselves.</p>
<p>The initiator and recipient essentially follow the process defined in <cite>RFC 6120</cite> to establish XML streams between themselves.</p>
<p>First, the initiator opens an XML stream to the recipient over the negotiated transport.</p>
<example caption="Opening a Stream"><![CDATA[
<stream:stream
@ -57,8 +57,8 @@
to='juliet@pronto'
version='1.0'>
]]></example>
<p>In accordance with &rfc3921bis;, the initial stream header SHOULD include the 'to' and 'from' attributes. In the case of <cite>XEP-0174</cite>, these SHOULD be the username@machine-name advertised in the PTR record. In the case of <cite>Jingle XML Streams</cite>, these SHOULD be the bare JIDs &BAREJID; of the entities as communicated via XMPP.</p>
<p>If the initiator supports stream features and the other stream-related aspects of XMPP 1.0 as specified in <cite>RFC 3920</cite>, then it SHOULD include the version='1.0' flag as shown in the previous example.</p>
<p>In accordance with <cite>RFC 6120</cite>, the initial stream header SHOULD include the 'to' and 'from' attributes. In the case of <cite>XEP-0174</cite>, these SHOULD be the username@machine-name advertised in the PTR record. In the case of <cite>Jingle XML Streams</cite>, these SHOULD be the bare JIDs &BAREJID; of the entities as communicated via XMPP.</p>
<p>If the initiator supports stream features and the other stream-related aspects of XMPP 1.0 as specified in <cite>RFC 6120</cite>, then it SHOULD include the version='1.0' flag as shown in the previous example.</p>
<p>The recipient then responds with a stream header as well:</p>
<example caption="Stream Header Response"><![CDATA[
<stream:stream
@ -68,7 +68,7 @@
to='romeo@forza'
version='1.0'>
]]></example>
<p>If both the initiator and recipient included the version='1.0' flag, the recipient SHOULD also send stream features as specified in <cite>RFC 3920</cite>:</p>
<p>If both the initiator and recipient included the version='1.0' flag, the recipient SHOULD also send stream features as specified in <cite>RFC 6120</cite>:</p>
<example caption="Recipient Sends Stream Features"><![CDATA[
<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

2
xep-0261.xml
View File

@ -186,7 +186,7 @@ Initiator Responder
</section2>
<section2 topic='Exchanging Data' anchor='protocol-data'>
<p>Now the initiator can begin sending IBB packets using an IQ-set for each chunk as described in <cite>XEP-0047</cite>, where the responder will acknowledge each IQ-set in accordance with &rfc3920;.</p>
<p>Now the initiator can begin sending IBB packets using an IQ-set for each chunk as described in <cite>XEP-0047</cite>, where the responder will acknowledge each IQ-set in accordance with &xmppcore;.</p>
<example caption='An IBB packet'><![CDATA[
<iq from='romeo@montague.net/orchard'
id='ls72b58f'

15
xep-0270.xml
View File

@ -59,14 +59,14 @@
<th>Advanced Client</th>
</tr>
<tr>
<td>&rfc3920; *</td>
<td>&rfc6120;</td>
<td align='center'>&#10003;</td>
<td align='center'>&#10003;</td>
<td align='center'>&#10003;</td>
<td align='center'>&#10003;</td>
</tr>
<tr>
<td>&rfc3921; *</td>
<td>&rfc6121;</td>
<td align='center'>&#10003;</td>
<td align='center'>&#10003;</td>
<td align='center'>&#10003;</td>
@ -111,14 +111,14 @@
<td>&xep0124;</td>
<td align='center'>&#10005;</td>
<td align='center'>&#10005;</td>
<td align='center'>&#10003; **</td>
<td align='center'>&#10003; *</td>
<td align='center'>&#10005;</td>
</tr>
<tr>
<td>&xep0206;</td>
<td align='center'>&#10005;</td>
<td align='center'>&#10005;</td>
<td align='center'>&#10003; **</td>
<td align='center'>&#10003; *</td>
<td align='center'>&#10005;</td>
</tr>
<tr>
@ -139,8 +139,8 @@
<td>&xep0045;</td>
<td align='center'>&#10005;</td>
<td align='center'>&#10005;</td>
<td align='center'>&#10003; *</td>
<td align='center'>&#10003; **</td>
<td align='center'>&#10003; ***</td>
</tr>
<tr>
<td>&xep0085;</td>
@ -150,9 +150,8 @@
<td align='center'>&#10003;</td>
</tr>
</table>
<p>* RFC 3920 and RFC 3921 are currently being revised to correct errors, clarify matters that were underspecified, and incorporate feedback based on implementation and deployment experience gained since RFC 3920 and RFC 3921 were published in 2004. Although the compliance level specified herein refers to RFC 3920 and RFC 3921, developers are also advised to consult &rfc3920bis; and &rfc3921bis;, which provide the most up-to-date and accurate description the core XMPP protocols.</p>
<p>** Support can be enabled via an external component or an internal server module/plugin.</p>
<p>*** Support for the Entity Use Cases and Occupant Use Cases is REQUIRED; support for the remaining use cases is RECOMMENDED.</p>
<p>* Support can be enabled via an external component or an internal server module/plugin.</p>
<p>** Support for the Entity Use Cases and Occupant Use Cases is REQUIRED; support for the remaining use cases is RECOMMENDED.</p>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>Some of the protocol specifications referenced herein have their own dependencies; developers need to consult the relevant specifications for further information.</p>

4
xep-0271.xml
View File

@ -44,7 +44,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Both &xep0030; and &xep0060; refer to "nodes" in relation to XMPP entities. However, the concept of an XMPP node has never been clearly specified (e.g., in &rfc3920;). This document attempts to remedy that oversight.</p>
<p>Both &xep0030; and &xep0060; refer to "nodes" in relation to XMPP entities. However, the concept of an XMPP node has never been clearly specified (e.g., in &rfc3920; or &rfc6120;). This document attempts to remedy that oversight.</p>
</section1>
<section1 topic='Definition' anchor='def'>
<p>To clarify the nature of a node, it is first helpful to describe the architecture of XMPP systems.</p>
@ -114,7 +114,7 @@ xmpp:romeo@example.org?;node=foo
<p>An XMPP node can include any UTF-8 character.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>This specification introduces no security considerations above and beyond those discussed in <cite>RFC 3920</cite>, <cite>XEP-0030</cite>, <cite>XEP-0060</cite>.</p>
<p>This specification introduces no security considerations above and beyond those discussed in <cite>RFC 6120</cite>, <cite>XEP-0030</cite>, <cite>XEP-0060</cite>.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>

2
xep-0274.xml
View File

@ -437,7 +437,7 @@
</Signature>
</message>
]]></example>
<p>The example.com server is required, per &rfc3920;, to add a 'from' attribute to the
<p>The example.com server is required, per &xmppcore;, to add a 'from' attribute to the
&MESSAGE; element before forwarding it to the example.net server. The example.net server is
required to replace the 'to' attribute with the full JID of the romeo@example.net client it
intends to forward the message to. These alternatations will "break" the signature.</p>

2
xep-0279.xml
View File

@ -97,7 +97,7 @@
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>&rfc3920; specifies that client IP addresses shall not be made public. If a client requests its own IP address, that policy is not violated. However, a server MUST NOT return the IP address of another client (e.g., if a connected client sends a SIC request to the bare JID of another user); instead, it MUST return a &forbidden; error.</p>
<p>&xmppcore; specifies that client IP addresses shall not be made public. If a client requests its own IP address, that policy is not violated. However, a server MUST NOT return the IP address of another client (e.g., if a connected client sends a SIC request to the bare JID of another user); instead, it MUST return a &forbidden; error.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>

5
xep-0283.xml
View File

@ -97,15 +97,14 @@
<p>This XEP defines an approach for communicating that your JID has
moved to a new JID, extending the existing subscription protocol documented
in &rfc3921;. The steps outlined here may be done either through a client
in &xmppim;. The steps outlined here may be done either through a client
or automated by a server.
</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<ul>
<li>The methods described here maintain compatibility with &rfc3920; and
&rfc3921;</li>
<li>The methods described here maintain compatibility with &xmppcore; and <cite>RFC 6121</cite>.</li>
</ul>
</section1>

2
xep-0288.xml
View File

@ -56,7 +56,7 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>&rfc3920; restricts server-to-server communication in such a way that a server has to use on TCP connection for XML stanzas sent from the server to the peer and another TCP connection (initiated by the peer) for stanzas from the peer to the server, for a total of two TCP connections. &rfc6120; allows two servers to send stanzas in a bidirectional way, but does not define methods for explicitly signalling the usage thereof. This is accomplished in this specification.</p>
<p>&xmppcore; restricts server-to-server communication in such a way that a server has to use on TCP connection for XML stanzas sent from the server to the peer and another TCP connection (initiated by the peer) for stanzas from the peer to the server, for a total of two TCP connections. &rfc6120; allows two servers to send stanzas in a bidirectional way, but does not define methods for explicitly signalling the usage thereof. This is accomplished in this specification.</p>
</section1>
<!--
http://www.ietf.org/mail-archive/web/xmpp/current/msg00658.html

3
xep.ent
View File

@ -643,9 +643,6 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates</link></span> <note>
<!-- IETF XMPP Specs -->
<!ENTITY rfc3920bis "<span class='ref'><link url='http://tools.ietf.org/html/draft-ietf-xmpp-3920bis'>rfc3920bis</link></span> <note>rfc3920bis: proposed revisions to Extensible Messaging and Presence Protocol (XMPP): Core &lt;<link url='http://tools.ietf.org/html/draft-ietf-xmpp-3920bis'>http://tools.ietf.org/html/draft-ietf-xmpp-3920bis</link>&gt;. (work in progress)</note>" >
<!ENTITY rfc3921bis "<span class='ref'><link url='http://tools.ietf.org/html/draft-ietf-xmpp-3921bis'>rfc3921bis</link></span> <note>rfc3921bis: proposed revisions to Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence &lt;<link url='http://tools.ietf.org/html/draft-ietf-xmpp-3921bis'>http://tools.ietf.org/html/draft-ietf-xmpp-3921bis</link>&gt;. (work in progress)</note>" >
<!ENTITY xmpp "<span class='ref'><link url='http://xmpp.org/'>XMPP</link></span> <note>Extensible Messaging and Presence Protocol (XMPP) &lt;<link url='http://xmpp.org/'>http://xmpp.org/</link>&gt;.</note>" >
<!ENTITY xmppcore "<span class='ref'><link url='http://tools.ietf.org/html/rfc6120'>XMPP Core</link></span> <note>RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core &lt;<link url='http://tools.ietf.org/html/rfc6120'>http://tools.ietf.org/html/rfc6120</link>&gt;.</note>" >
<!ENTITY xmppim "<span class='ref'><link url='http://tools.ietf.org/html/rfc6121'>XMPP IM</link></span> <note>RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence &lt;<link url='http://tools.ietf.org/html/rfc6121'>http://tools.ietf.org/html/rfc6121</link>&gt;.</note>" >