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

cleanup for RFC 6120 and RC 6121

Browse Source
This commit is contained in:
stpeter 2011-04-11 16:33:53 -06:00
parent e5e1a3b991
commit e5e5e4a862
25 changed files with 63 additions and 66 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
xep-0012.xml
View File

@ -230,7 +230,7 @@
<p>The information contained in an IQ reply for this namespace is inherently ambiguous. Specifically, for a bare JID &LOCALBARE; the information is the time since the JID was last connected to its server; for a full JID &LOCALFULL; the information is the time since the resource was last active in the context of an existing session; and for a bare domain the information is the uptime for the server or component. An application MUST take these differences into account when presenting the information to a human user (if any).</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>A server MUST NOT allow an unauthorized entity to learn a user's network availability by sending a Last Activity request to a JID of the form &LOCALBARE; or &LOCALFULL;, since doing so would constitute a "presence leak" as described in &rfc3920bis;. That is, Last Activity information MAY be divulged only to those entities that have permission to view the user's presence via a presence subscription (potentially as restricted by &xep0016; or &xep0191;).</p>
<p>A server MUST NOT allow an unauthorized entity to learn a user's network availability by sending a Last Activity request to a JID of the form &LOCALBARE; or &LOCALFULL;, since doing so would constitute a "presence leak" as described in <cite>RFC 6120</cite>. That is, Last Activity information MAY be divulged only to those entities that have permission to view the user's presence via a presence subscription (potentially as restricted by &xep0016; or &xep0191;).</p>
<p>A client MUST provide a way for a human user to disable sending of Last Activity responses from the client's full JID &LOCALFULL;.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>

6
xep-0060.xml
View File

@ -65,7 +65,7 @@
<li>Defined "room" value for itemreply config option.</li>
<li>Added optional 'publisher' attribute to &lt;item/&gt; element.</li>
<li>Added optional &lt;redirect/&gt; child to &lt;delete/&gt; element.</li>
<li>Based redirects on URIs for consistency with rfc3920bis gone and redirect errors.</li>
<li>Based redirects on URIs for consistency with RFC 6120 gone and redirect errors.</li>
<li>Clarified meaning of filtered notifications (they are based on NodeIDs, not payload namespaces).</li>
<li>Added pubsub-on-a-jid service discovery feature for explicit discovery that an IM and presence account also functions as a virtual pubsub service.</li>
<li>Added purge_offline node configuration option for purging the node when the relevant publisher goes offline, for use in certain extended presence applications.</li>
@ -2681,7 +2681,7 @@ And by opposing end them?
]]></example>
</section4>
<section4 topic='Item Publisher' anchor='publisher-publish-success-publisher'>
<p>If configured to do so, the service can include the pubisher of the item when it generates event notifications.</p>
<p>If configured to do so, the service can include the publisher of the item when it generates event notifications.</p>
<example caption='Service Notifies Subscribers'><![CDATA[
<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
@ -4644,7 +4644,7 @@ And by opposing end them?
</query>
</iq>
]]></example>
<p>Note: Because the account owner's bare JID is the default destination address for any stanzas a client generates, clients often omit the "to" attribute on such stanzas; on this point, see &rfc3920bis; and (with regard to rosters) &rfc3921bis;.</p>
<p>Note: Because the account owner's bare JID is the default destination address for any stanzas a client generates, clients often omit the "to" attribute on such stanzas; on this point, see <cite>RFC 6120</cite> and (with regard to rosters) <cite>RFC 6121</cite>.</p>
<section2 topic='Auto-Subscribe' anchor='auto-subscribe'>
<p>When a contact is affiliated with the account owner through sharing of XMPP presence, the "auto-subscribe" feature greatly simplifies the subscription process. In particular, support for the "auto-subscribe" has the following implications:</p>
<section3 topic='Account Owner' anchor='auto-subscribe-owner'>

2
xep-0115.xml
View File

@ -498,7 +498,7 @@
ver='ItBTI0XLDFvVxZ72NQElAzKS9sU='/>
</stream:features>
]]></example>
<p>When a connected client or peer server sends a service discovery information request to determine the entity capabilities of a server that advertises capabilities via the stream feature, the requesting entity MUST send the disco#info request to the server's JID as provided in the 'from' attribute of the response stream header (the 'from' attribute was recommended by &rfc3920; and is required by &rfc3920bis;). To enable this functionality, a server that advertises support for entity capabilities MUST provide a 'from' address in its response stream headers, in accordance with <cite>rfc3920bis</cite>.</p>
<p>When a connected client or peer server sends a service discovery information request to determine the entity capabilities of a server that advertises capabilities via the stream feature, the requesting entity MUST send the disco#info request to the server's JID as provided in the 'from' attribute of the response stream header (the 'from' attribute was recommended by &rfc3920; and is required by &rfc6120;). To enable this functionality, a server that advertises support for entity capabilities MUST provide a 'from' address in its response stream headers, in accordance with <cite>RFC 6120</cite>.</p>
</section2>
</section1>

2
xep-0150.xml
View File

@ -109,7 +109,7 @@
</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 &rfc3920bis;.</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 &rfc6120;.</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>

4
xep-0165.xml
View File

@ -96,12 +96,12 @@
<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 &rfc3921bis; 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 &rfc6121; we refer to this as a "handle". <note>In <cite>RFC 3921</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>
<section2 topic='Associating Security Credentials with Roster Items' anchor='rec-secure'>
<p>Although a Jabber ID can be considered globally unique, the petname system in which it is embedded can be strengthened by associating that JID with a key that can be used for signing and encryption (such as an OpenPGP key, X.509 certificate, or RSA key), preferably a key that encapsulates the associated XMPP address (e.g., as described in Section 6.4 of <cite>rfc3920bis</cite>). A client SHOULD associate a key with the user of that client, and SHOULD generate such a key if the user does not have one.</p>
<p>Although a Jabber ID can be considered globally unique, the petname system in which it is embedded can be strengthened by associating that JID with a key that can be used for signing and encryption (such as an OpenPGP key, X.509 certificate, or RSA key), preferably a key that encapsulates the associated XMPP address. A client SHOULD associate a key with the user of that client, and SHOULD generate such a key if the user does not have one.</p>
<p>Unfortunately, cryptographic identities such as keys, certificates, and fingerprints are even less memorable than JIDs, which makes assigning a handle even more important. Therefore, if a contact provides such a cryptographic identity, a client MUST reliably associate it with the contact in a user's roster (including, as mentioned, a handle for each contact) in order to further strengthen the petname system.</p>
</section2>
<section2 topic='Referrals' anchor='rec-referrals'>

32
xep-0178.xml
View File

@ -24,10 +24,10 @@
&stpeter;
&pgmillard;
<revision>
<version>1.1rc1</version>
<date>in progress, last updated 2010-09-24</date>
<version>1.1rc3</version>
<date>in progress, last updated 2011-04-11</date>
<initials>psa</initials>
<remark><p>Updated to reflect draft-ietf-xmpp-3920bis and draft-saintandre-tls-server-id-check.</p></remark>
<remark><p>Updated to reflect RFC 6120 and RFC 6125.</p></remark>
</revision>
<revision>
<version>1.0</version>
@ -57,13 +57,13 @@
<version>0.4</version>
<date>2006-11-27</date>
<initials>psa</initials>
<remark><p>Modified XMPP address encapsulation methods per rfc3920bis; clarified conditions for certificates to be considered acceptable.</p></remark>
<remark><p>Modified XMPP address encapsulation methods per revisions to RFC 3920; clarified conditions for certificates to be considered acceptable.</p></remark>
</revision>
<revision>
<version>0.3</version>
<date>2006-09-21</date>
<initials>psa</initials>
<remark><p>Added TLS and SASL required child elements per rfc3920bis.</p></remark>
<remark><p>Added TLS and SASL required child elements per revisions to RFC 3920.</p></remark>
</revision>
<revision>
<version>0.2</version>
@ -97,10 +97,10 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>XMPP as specified in &rfc3920; and provisionally clarified in &rfc3920bis; allows the use of any SASL (&rfc4422;) mechanism in the authentication of XMPP entities. This document specifies a recommended protocol flow for use of the SASL EXTERNAL mechanism with PKIX (&rfc5280;) certificates <note>This specification focuses on the use of the SASL EXTERNAL mechanism with X.509 certificates. Future specifications may document best practices for use of SASL EXTERNAL outside the context of the X.509 infrastructure, for example via Internet Protocol Security (IPSec) as specified in &rfc4301;.</note>, expecially when an XMPP service indicates that TLS is mandatory-to-negotiate. <note>The protocol flows when TLS is not required are more complicated (e.g., alternate flows involving server dialback) and may be described in a future version of this document.</note></p>
<p>XMPP as specified in &rfc3920; and updated in &rfc6120; allows the use of any SASL (&rfc4422;) mechanism in the authentication of XMPP entities. This document specifies a recommended protocol flow for use of the SASL EXTERNAL mechanism with PKIX (&rfc5280;) certificates <note>This specification focuses on the use of the SASL EXTERNAL mechanism with X.509 certificates. Future specifications may document best practices for use of SASL EXTERNAL outside the context of the X.509 infrastructure, for example via Internet Protocol Security (IPSec) as specified in &rfc4301;.</note>, expecially when an XMPP service indicates that TLS is mandatory-to-negotiate. <note>The protocol flows when TLS is not required are more complicated (e.g., alternate flows involving server dialback) and may be described in a future version of this document.</note></p>
</section1>
<section1 topic='Client-to-Server Recommendation' anchor='c2s'>
<p>As specified in <cite>RFC 3920</cite> and provisionally clarified in <cite>rfc3920bis</cite>, during the stream negotiation process an XMPP client can present a certificate (here called an "end-user certificate"). If a JabberID is included in an end-user certificate, it is encapsulated as an id-on-xmppAddr Object Identifier ("xmppAddr"), i.e., a subjectAltName entry of type otherName with an ASN.1 Object Identifier of "id-on-xmppAddr" as specified in Section 5.1.1. of <cite>RFC 3920</cite> and Section 13.7.1.4 of <cite>rfc3920bis</cite>.</p>
<p>As specified in <cite>RFC 3920</cite> and updated in <cite>RFC 6120</cite>, during the stream negotiation process an XMPP client can present a certificate (here called an "end-user certificate"). If a JabberID is included in an end-user certificate, it is encapsulated as an id-on-xmppAddr Object Identifier ("xmppAddr"), i.e., a subjectAltName entry of type otherName with an ASN.1 Object Identifier of "id-on-xmppAddr" as specified in Section 5.1.1. of <cite>RFC 3920</cite> and Section 13.7.1.4 of <cite>RFC 6120</cite>.</p>
<p>There are three possible cases:</p>
<ol>
<li>The certificate includes one xmppAddr.</li>
@ -182,7 +182,7 @@
]]></code>
</li>
<li>
<p>Server advertises SASL mechanisms. Here the server offers and prefers the SASL EXTERNAL mechanism (see Section 6.2.4 of <cite>rfc3920bis</cite> for recommendations regarding the conditions under which to offer the SASL EXTERNAL mechanism).</p>
<p>Server advertises SASL mechanisms. Here the server offers and prefers the SASL EXTERNAL mechanism (see Section 6.3.4 of <cite>RFC 6120</cite> for recommendations regarding the conditions under which to offer the SASL EXTERNAL mechanism).</p>
<code><![CDATA[
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
@ -195,7 +195,7 @@
]]></code>
</li>
<li>
<p>Client considers EXTERNAL to be its preferred SASL mechanism. Here the client does not include an authorization identity and therefore sets the XML character data of the &lt;auth/&gt; element to "=", indicating an empty response (see Section 6.2.8 of <cite>rfc3920bis</cite> for recommendations regarding the conditions under which to include an authorization identity).</p>
<p>Client considers EXTERNAL to be its preferred SASL mechanism. Here the client does not include an authorization identity and therefore sets the XML character data of the &lt;auth/&gt; element to "=", indicating an empty response (see Section 6.3.8 of <cite>RFC 6120</cite> for recommendations regarding the conditions under which to include an authorization identity).</p>
<code><![CDATA[
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='EXTERNAL'>=</auth>
@ -215,7 +215,7 @@
<code><![CDATA[
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
]]></code>
<p>If no authorization identity is included, then the server MUST return a SASL failure case of &lt;invalid-authzid/&gt; and close the stream.</p>
<p>If no authorization identity is included, then the server SHOULD return a SASL failure case of &lt;invalid-authzid/&gt; and close the stream.</p>
<code><![CDATA[
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<invalid-authzid/>
@ -246,12 +246,12 @@
</ol>
</li>
<li>
<p>If SASL authentication succeeded, the client opens new stream, then client and server proceed with resource binding as described in <cite>RFC 3920</cite> and <cite>rfc3920bis</cite>.</p>
<p>If SASL authentication succeeded, the client opens new stream, then client and server proceed with resource binding as described in <cite>RFC 3920</cite> and <cite>RFC 6120</cite>.</p>
</li>
</ol>
</section1>
<section1 topic='Server-to-Server Recommendation' anchor='s2s'>
<p><cite>RFC 3920</cite> specified that if a JabberID is included in a certificate intended for use by an XMPP server (here called a "domain certificate"), it shall be encapsulated as an xmppAddr. That recommendation is udpated in <cite>rfc3920bis</cite> through a reference to &certid;, which prefers use of a dNSName and/or SRVName entry in the Subject Alternative Name. The DNS domain name contained in the certificate can be a fully-qualified domain name ("FQDN") or a so-called "wildcard" with the '*' character as the complete left-most label.</p>
<p><cite>RFC 3920</cite> specified that if a JabberID is included in a certificate intended for use by an XMPP server (here called a "domain certificate"), it shall be encapsulated as an xmppAddr. That recommendation is updated in <cite>RFC 6120</cite> through a reference to &certid;, which prefers use of a dNSName and/or SRVName entry in the Subject Alternative Name. The DNS domain name contained in the certificate can be a fully-qualified domain name ("FQDN") or a so-called "wildcard" with the '*' character as the complete left-most label.</p>
<p>The RECOMMENDED protocol flow for server-to-server use of SASL EXTERNAL with server (domain) certificates is as follows:</p>
<ol>
<li>
@ -303,10 +303,10 @@
<p>Server1 presents its certificate during TLS negotiation.</p>
</li>
<li>
<p>Server2 validates certificate in accordance with the rules from <cite>rfc3920bis</cite> and <cite>draft-saintandre-tls-server-id-check</cite>.</p>
<p>Server2 validates certificate in accordance with the rules from <cite>RFC 6120</cite> and <cite>RFC 6125</cite>.</p>
<ol>
<li>
<p>If certificate is unacceptable for the reasons explained in <cite>rfc3920bis</cite> and <cite>draft-saintandre-tls-server-id-check</cite>, Server2 closes Server1's TCP connection.</p>
<p>If certificate is unacceptable for the reasons explained in <cite>RFC 6120</cite> and <cite>RFC 6125</cite>, Server2 closes Server1's TCP connection.</p>
</li>
<li>
<p>Else Server2 completes successful TLS negotiation and Server1 sends a new initial stream header to Server2 over the encrypted TCP connection.</p>
@ -345,7 +345,7 @@
]]></code>
</li>
<li>
<p>Server2 considers EXTERNAL to be its preferred SASL mechanism. Here it includes a base-64-encoded authorization identity as the XML character data of the &lt;auth/&gt; element, setting it to the same value as the 'from' address on the stream header it sent to Server2.</p>
<p>Server1 considers EXTERNAL to be its preferred SASL mechanism. Here it includes a base-64-encoded authorization identity as the XML character data of the &lt;auth/&gt; element, setting it to the same value as the 'from' address on the stream header it sent to Server2.</p>
<code><![CDATA[
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='EXTERNAL'>Y29uZmVyZW5jZS5leGFtcGxlLm9yZwo=</auth>
]]></code>
@ -355,7 +355,7 @@
<p>Server2 determines if hostname is valid.</p>
<ol>
<li>
<p>If the authorization identity provided by Server1 can be matched against one of the identifiers provided in the certificate following the matching rules from <cite>draft-saintandre-tls-server-id-check</cite>, Server2 returns success.</p>
<p>If the authorization identity provided by Server1 can be matched against one of the identifiers provided in the certificate following the matching rules from <cite>RFC 6125</cite>, Server2 returns success.</p>
<code><![CDATA[
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
]]></code>

8
xep-0185.xml
View File

@ -44,7 +44,7 @@
<version>0.3</version>
<initials>ph</initials>
<date>2006-11-01</date>
<remark><p>Recommended hashing the secret to satisfy length requirement; hostnames and Stream ID should be separated by spaces to avoid ambiguity; updated example to match rfc3920bis.</p>
<remark><p>Recommended hashing the secret to satisfy length requirement; hostnames and Stream ID should be separated by spaces to avoid ambiguity; updated example to match revisions to RFC 3920.</p>
</remark>
</revision>
<revision>
@ -69,7 +69,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&rfc3920; does not specify in detail a recommended algorithm for generating the keys used in the server dialback protocol. This document provides such a recommendation as an aid to implementors of XMPP servers. This document is not meant to supersede any text in <cite>RFC 3920</cite>; however, the recommendations in this document have been incorporated into &rfc3920bis;.</p>
<p>&rfc3920; does not specify in detail a recommended algorithm for generating the keys used in the server dialback protocol. This document provides such a recommendation as an aid to implementors of XMPP servers. This document is not meant to supersede any text in <cite>RFC 3920</cite>; however, the recommendations in this document have been incorporated into &xep0220;.</p>
</section1>
<section1 topic='Recommended Algorithm' anchor='algorithm'>
<p>The process for generating and validating a dialback key SHOULD take into account the following four inputs:</p>
@ -101,7 +101,7 @@ key = HMAC-SHA256
</ol>
</section1>
<section1 topic='Example' anchor='example'>
<p>This document closely follows the description of the dialback protocol in <cite>RFC 3920</cite> and <cite>rfc3920bis</cite>, but omits steps that are not important for the generation and validation of the dialback keys. For ease of comparison the numbering of the steps is the same as in section 8.3 of <cite>RFC 3920</cite> and Appendix C.3 of <cite>rfc3920bis</cite>. Any line breaks in the examples are included for the purpose of readability only.</p>
<p>This document closely follows the description of the dialback protocol in <cite>RFC 3920</cite> and <cite>XEP-0220</cite>, but omits steps that are not important for the generation and validation of the dialback keys. For ease of comparison the numbering of the steps is the same as in section 8.3 of <cite>RFC 3920</cite> and Appendix C.3 of <cite>XEP-0220</cite>. Any line breaks in the examples are included for the purpose of readability only.</p>
<p>The following data values are used in the examples:</p>
<table caption='Data Used in Examples'>
<tr>
@ -194,7 +194,7 @@ key = HMAC-SHA256(
]]></code>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>This document introduces no security considerations or concerns above and beyond those discussed in <cite>RFC 3920</cite> and <cite>rfc3920bis</cite>.</p>
<p>This document introduces no security considerations or concerns above and beyond those discussed in <cite>RFC 3920</cite> and <cite>XEP-0220</cite>.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>

3
xep-0190.xml
View File

@ -52,9 +52,8 @@
</header>
<section1 topic='Introduction' anchor='intro'>
&RFC3920BISNOTE;
<p><cite>RFC 3920</cite> describes several ways to terminate an XML stream, but does not always make a clear statement about which to use. This can lead to faulty implementations. In particular, closing a stream that has not been in use for a while is very often achieved using a connection-timeout error, then closing the socket. This can lead to loss of data. Therefore this document proposes a practice that will avoid such data loss.</p>
<p>Note: The recommendation described herein has been incorporated into <cite>rfc3920bis</cite>.</p>
<p>Note: The recommendation described herein has been incorporated into &rfc6120;.</p>
</section1>
<section1 topic='How to Close an Idle Stream' anchor='do'>

5
xep-0192.xml
View File

@ -46,13 +46,12 @@
</revision>
</header>
<section1 topic='Introduction' anchor='proto'>
&RFC3920BISNOTE;
<p><cite>RFC 3920</cite> introduced the concept of stream features. Implementation experience has revealed several shortcomings in the current definition and usage of stream features:</p>
<ul>
<li>Because not all stream features include a mechanism for specifying that negotiation of the feature is required, servers and clients cannot know with certainty when the stream negotiation has been completed and therefore when it is acceptable to begin sending XML stanzas over the stream.</li>
<li>The server dialback protocol does not have a stream feature associated with it.</li>
</ul>
<p>Those shortcomings are addressed in this document, and the recommendations described herein have been incorporated into <cite>rfc3920bis</cite>.</p>
<p>Those shortcomings are addressed in this document, and the recommendations described herein have been incorporated into &rfc6120;.</p>
</section1>
<section1 topic='Required Flag' anchor='required'>
<p>The XMPP stream feature for Transport Layer Security (TLS) includes a &lt;required/&gt; child element that can be used to indicate that negotiation of TLS must be completed before proceeding with the rest of the stream negotiation. However, as defined in <cite>RFC 3920</cite> the remaining stream features do not include the ability to flag that negotiation of the feature is required in order to (1) proceed with the negotiation or (2) begin sending XML stanzas. Because the non-TLS features lack a required flag, it is not possible for the initiating entity to know definitively how to proceed at any given stage in the stream negotiation, and the only way for the initiating entity to know whether it may begin sending XML stanzas is to attempt to send them (the receiving entity will return a &notauthorized; stream error if not all required features have been negotiated). This state of affairs is suboptimal. Therefore, every stream feature must include the ability to flag the feature as required or not required. When the initiating entity receives a stream features element with no features containing a &lt;required/&gt; element, it knows thatt the receiving party will accept XML stanzas over the stream.</p>
@ -272,7 +271,7 @@ S2: <stream:features>
<name>dialback</name>
<element>dialback</element>
<desc>Support for Server Dialback</desc>
<doc>XEP-0192 (rfc3920bis when published)</doc>
<doc>XEP-0220</doc>
</feature>
]]></code>
</section2>

5
xep-0193.xml
View File

@ -58,9 +58,8 @@
</revision>
</header>
<section1 topic='Introduction' anchor='proto'>
&RFC3920BISNOTE;
<p><cite>RFC 3920</cite> introduced the concept of binding a resource to an XML stream (this concept superseded part of the obsolete jabber:iq:auth protocol described in &xep0078;). As defined in <cite>RFC 3920</cite>, resource binding enables a client to bind one resource to a stream but does not enable a client to unbind a resource and leaves underspecified what a server and client should do if a client binds more than one resource to a stream. Because the ability to bind multiple resources to a stream is desirable in certain environments (e.g., for devices that are unable to open more than one TCP connection or when a machine runs a daemon process that is used by multiple applications), this document proposes improvements to resource binding in order to address these shortcomings.</p>
<p>Note: The recommendations described herein have been incorporated into <cite>rfc3920bis</cite>.</p>
<p>Note: The recommendations from this document were NOT incorporated into &rfc6120;.</p>
</section1>
<section1 topic='Unbinding a Resource' anchor='unbind'>
<p>In order to properly manage the resources associated with an XML stream, a client must be able to unbind resources. This shall be completed by sending an IQ-set with a child element of &lt;unbind/&gt; qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace, which in turn has a child element of &lt;resource/&gt; whose XML character data specifies the resource to be unbound:</p>
@ -84,7 +83,7 @@
</section1>
<section1 topic='Business Rules' anchor='bizrules'>
<section2 topic='From Addresses' anchor='from'>
<p>When a client binds multiple resources to the same stream, proper management of 'from' addresses is imperative. In particular, a client MUST specify a 'from' address on every stanza it sends over a stream to which it has bound multiple resources, where the 'from' address is the full JID &LOCALFULL; associated with the relevant resource. If a client does not specify a 'from' address on a stanza it sends over a stream to which it has bound multiple resources (or if it specifies as the 'from' address a full JID other than one of the bound resources), the server MUST return the stanza to the client with an &lt;unknown-sender/&gt; stanza error. <note>Currently there is no &lt;unknown-sender/&gt; stanza defined in <cite>RFC 3920</cite>. The author will work to add such an error condition (with a type of "modify") to <cite>rfc3920bis</cite>.</note></p>
<p>When a client binds multiple resources to the same stream, proper management of 'from' addresses is imperative. In particular, a client MUST specify a 'from' address on every stanza it sends over a stream to which it has bound multiple resources, where the 'from' address is the full JID &LOCALFULL; associated with the relevant resource. If a client does not specify a 'from' address on a stanza it sends over a stream to which it has bound multiple resources (or if it specifies as the 'from' address a full JID other than one of the bound resources), the server MUST return the stanza to the client with an &lt;unknown-sender/&gt; stanza error. <note>Currently there is no &lt;unknown-sender/&gt; stanza defined in <cite>RFC 3920</cite>. The author will work to add such an error condition (with a type of "modify") to the document that revises <cite>RFC 3920</cite>.</note></p>
<p>Naturally, the existing rules from <cite>RFC 3920</cite> regarding validation of asserted 'from' addresses still apply.</p>
</section2>
<section2 topic='Server Sessions' anchor='sessions'>

4
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 &rfc3920bis;), &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 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>(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>
@ -203,7 +203,7 @@ S: <enabled xmlns='urn:xmpp:sm:3'/>
S: <enabled xmlns='urn:xmpp:sm:3' id='some-long-sm-id' resume='true'/>
]]></example>
<p>The &lt;enabled/&gt; element MAY include a 'max' attribute to specify the receiving entity's preferred maximum resumption time.</p>
<p>The &lt;enabled/&gt; element MAY include a 'location' attribute to specify the receiving entity's preferred IP address or hostname (optionally with a port) for reconnection, in the form specified in Section 4.9.3.19 of &rfc3920bis; (i.e., "domainpart:port", where IPv6 addresses are enclosed in square brackets "[...]" as described in &rfc5952;); if reconnection to that location fails, the standard XMPP connection algorithm specified in &xmppcore; applies.</p>
<p>The &lt;enabled/&gt; element MAY include a 'location' attribute to specify the receiving entity's preferred IP address or hostname (optionally with a port) for reconnection, in the form specified in Section 4.9.3.19 of <cite>RFC 6120</cite> (i.e., "domainpart:port", where IPv6 addresses are enclosed in square brackets "[...]" as described in &rfc5952;); if reconnection to that location fails, the standard XMPP connection algorithm specified in &xmppcore; applies.</p>
<p>The initiating entity MUST NOT attempt to negotiate stream management until it is authenticated; i.e., it MUST NOT send an &lt;enable/&gt; element until after authentication (such as SASL, &xep0078; or &xep0220;) has been completed successfully.</p>
<p>For client-to-server connections, the client MUST NOT attempt to enable stream management until after it has completed Resource Binding <em>unless it is resuming a previous session</em> (see <link url='#resumption'>Resumption</link>).</p>
<p>The server SHALL enforce this order and return a &lt;failed/&gt; element in response if the order is violated (see <link url='#errors'>Error Handling</link>).</p>

8
xep-0201.xml
View File

@ -40,13 +40,13 @@
<version>0.7</version>
<date>2010-07-12</date>
<initials>psa</initials>
<remark><p>Removed definition of ThreadID syntax, semantics, and uniqueness because rfc3921bis covers those topics.</p></remark>
<remark><p>Removed definition of ThreadID syntax, semantics, and uniqueness because the revisions to RFC 3921 covers those topics.</p></remark>
</revision>
<revision>
<version>0.6</version>
<date>2010-05-21</date>
<initials>psa</initials>
<remark><p>Simplified several handling rules; removed ThreadID SHIM header for IQ stanzas; removed implementation note about In-Reply-To SHIM header; removed references to XEP-0155; corrected some errors; harmonized text with rfc3921bis in coordination with editor's review.</p></remark>
<remark><p>Simplified several handling rules; removed ThreadID SHIM header for IQ stanzas; removed implementation note about In-Reply-To SHIM header; removed references to XEP-0155; corrected some errors; harmonized text with the revisions to RFC 3921 in coordination with editor's review.</p></remark>
</revision>
<revision>
<version>0.5</version>
@ -92,7 +92,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Although message threads are re-used in XMPP extension protocols such as &xep0085;, best practices for generating and handling message threads have never been well specified (e.g., in &rfc3921; or &rfc3921bis;). This document attempts to clearly specify those matters for implementation by XMPP clients.</p>
<p>Although message threads are re-used in XMPP extension protocols such as &xep0085;, best practices for generating and handling message threads have never been well specified (e.g., in &rfc3921; or &rfc6121;). This document attempts to clearly specify those matters for implementation by XMPP clients.</p>
</section1>
<section1 topic='Motivation' anchor='motivation'>
<p>Threads matter because they enable XMPP clients to:</p>
@ -174,7 +174,7 @@
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>Several security considerations related to XMPP threads are described in &rfc3921bis;.</p>
<p>Several security considerations related to XMPP threads are described in <cite>RFC 6121</cite>.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>

4
xep-0205.xml
View File

@ -31,7 +31,7 @@
<version>0.3</version>
<date>2008-12-19</date>
<initials>psa</initials>
<remark><p>Incorporated Last Call comments: removed paragraph about compression, added paragraph about rate limiting in message or presence amplifiers, corrected simultaneous connections error per rfc3920bis.</p></remark>
<remark><p>Incorporated Last Call comments: removed paragraph about compression, added paragraph about rate limiting in message or presence amplifiers, corrected simultaneous connections error per revisions to RFC 3920.</p></remark>
</revision>
<revision>
<version>0.2</version>
@ -80,7 +80,7 @@
<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 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 7.3.5 of &rfc3920bis;, and it is instead recommended to limit the number of connections and connection attempts on a per-IP basis.</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>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>

6
xep-0206.xml
View File

@ -30,13 +30,13 @@
<version>1.3</version>
<date>2010-07-02</date>
<initials>psa</initials>
<remark><p>Added 'restartlogic' attribute per XSF ticket SPEC-8; added note about use of the 'from' and 'to' attributes from XEP-0124 in relation to XML stream headers as specified in rfc3920bis.</p></remark>
<remark><p>Added 'restartlogic' attribute per XSF ticket SPEC-8; added note about use of the 'from' and 'to' attributes from XEP-0124 in relation to XML stream headers as specified in RFC 6120.</p></remark>
</revision>
<revision>
<version>1.2</version>
<date>2008-10-29</date>
<initials>psa</initials>
<remark><p>Clarified handling of xbosh restart -- client MUST send the restart and the body MUST be empty; removed IM session establishment examples because that protocol is deprecated in rfc3921bis; corrected XML schema.</p></remark>
<remark><p>Clarified handling of xbosh restart -- client MUST send the restart and the body MUST be empty; removed IM session establishment examples because that protocol is deprecated in RFC 6121; corrected XML schema.</p></remark>
</revision>
<revision>
<version>1.1</version>
@ -69,7 +69,7 @@
</section1>
<section1 topic="Session Creation Request" anchor='initiate'>
<p>The client SHOULD include a 'version' attribute qualified by the 'urn:xmpp:xbosh' namespace in its session creation request. This attribute corresponds to the 'version' attribute of the XMPP &lt;stream:stream/&gt; element as defined in <cite>RFC 3920</cite> and &rfc3920bis;. The connection manager SHOULD forward the value to the XMPP server accordingly.</p>
<p>The client SHOULD include a 'version' attribute qualified by the 'urn:xmpp:xbosh' namespace in its session creation request. This attribute corresponds to the 'version' attribute of the XMPP &lt;stream:stream/&gt; element as defined in <cite>RFC 3920</cite> and &rfc6120;. The connection manager SHOULD forward the value to the XMPP server accordingly.</p>
<example caption="Requesting a session with a version attribute">
<![CDATA[POST /webclient HTTP/1.1
Host: httpcm.jabber.org

6
xep-0220.xml
View File

@ -70,7 +70,7 @@
<li>Added explanatory text about scenarios in which Server Dialback is used and not used.</li>
<li>Clarified basic description of how dialback works.</li>
<li>Clarified discovery of dialback support.</li>
<li>Separated sections into subsections, as has been done for rfc3920bis and rfc3921bis.</li>
<li>Separated sections into subsections, as has been done for the revisions to RFC 3920 and RFC 3921.</li>
<li>Described the protocol flows in much greater detail.</li>
<li>Explained and illustrated failure cases more completely.</li>
<li>Clarified reuse of negotiated connections, a.k.a. piggybacking.</li>
@ -87,7 +87,7 @@
<version>0.0.1</version>
<date>2007-06-22</date>
<initials>psa</initials>
<remark><p>Content moved from rfc3920bis.</p></remark>
<remark><p>Content moved from the revisions to RFC 3920.</p></remark>
</revision>
</header>
@ -95,7 +95,7 @@
<section2 topic="Why Dialback?" anchor="intro-why">
<p>When Jabber technologies were first developed in 1998, they were conceived of as a client-server system similar to email, wherein a client would connect to a server in order to communicate with other clients. Similarly, servers would connect with peer servers to provide inter-domain communication (often called "federation"). In a system that allows federation, it is important for a server to be able to determine the identity of a peer server; accepting a connection from any peer without determining its identity would result in the use of merely asserted identities and a completely uncontrolled approach to federation, which on the open Internet would rapidly devolve into chaos. Clearly such a state of affairs would be unsustainable for a network protocol aiming for widespread deployment.</p>
<p>Such potential chaos was the state of affairs on the Jabber network during the earliest releases of the original &jabberd; server codebase (up through the 1.0 release in May 2000). Therefore the Jabber developer community designed a protocol ("Server Dialback") for weak identity verification based on the Domain Name System (DNS), built support for that protocol into the jabberd 1.2 server (released in October 2000), and mandated support for that protocol on the emerging Jabber server network.</p>
<p>When the early Jabber protocols were formalized by the XMPP Working Group of the &IETF; in 2002-2004, support for strong identity verification was added. That support takes the form of Transport Layer Security (TLS) for encryption of server-to-server XML streams and the Simple Authentication and Security Layer (SASL) for authentication of such streams, using digital certificates issued by trusted root certificate authorities (CAs). However, the Server Dialback protocol is still in wide use, and probably will be for the foreseeable future given the perceived difficulty of obtaining digital certificates issued by common CAs (although this problem is mitigated by the &XMPPICA; run by the &XSF;). Therefore it is important to maintain accurate documentation of the Server Dialback protocol. Such documentation was originally provided in &rfc3920;. Although that documentation was removed from &rfc3920bis;, it is still provided in this specification for the sake of interoperability.</p>
<p>When the early Jabber protocols were formalized by the XMPP Working Group of the &IETF; in 2002-2004, support for strong identity verification was added. That support takes the form of Transport Layer Security (TLS) for encryption of server-to-server XML streams and the Simple Authentication and Security Layer (SASL) for authentication of such streams, using digital certificates issued by trusted root certificate authorities (CAs). However, the Server Dialback protocol is still in wide use, and probably will be for the foreseeable future given the perceived difficulty of obtaining digital certificates issued by common CAs (although this problem is mitigated by the &XMPPICA; run by the &XSF;). Therefore it is important to maintain accurate documentation of the Server Dialback protocol. Such documentation was originally provided in &rfc3920;. Although that documentation was removed from &rfc6120;, it is still provided in this specification for the sake of interoperability.</p>
</section2>
<section2 topic="What Dialback Accomplishes" anchor="intro-what">

2
xep-0225.xml
View File

@ -127,7 +127,7 @@ S: <iq id='unbind_1' type='result'/>
]]></example>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>This protocol improves upon the earlier component protocol defined in <cite>XEP-0114</cite> by specifying the use of Transport Layer Security (TLS) for channel encryption and the Simple Authentication and Security Layer (SASL) for authentication. Because this protocol re-uses the XML stream establishment processes defined in XMPP Core, the security considerations from RFC 3920 and rfc3920bis apply to this protocol as well.</p>
<p>This protocol improves upon the earlier component protocol defined in <cite>XEP-0114</cite> by specifying the use of Transport Layer Security (TLS) for channel encryption and the Simple Authentication and Security Layer (SASL) for authentication. Because this protocol re-uses the XML stream establishment processes defined in XMPP Core, the security considerations from RFC 3920 and RFC 6120 apply to this protocol as well.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>

4
xep-0233.xml
View File

@ -59,7 +59,7 @@
</section1>
<section1 topic='Use with Kerberos' anchor='kerberos'>
<p>When a connection manager associated with an XMPP server needs to communicate additional information about its service principal name to a connecting client, it can do so by including a child element of the &lt;mechanisms/&gt; element during SASL negotation, as specified in &rfc3920bis;. In the case of the Kerberos V SASL mechanism, the child element is a &lt;hostname/&gt; element qualified by the 'urn:xmpp:domain-based-name:0' namespace &NSNOTE;. In the context of Kerberos, the &lt;hostname/&gt; element MUST include a 'mechanism' attribute, where the value MUST be "GSSAPI". The XML character data of the &lt;hostname/&gt; element shall specify the fully-qualified name of the connection manager (known as the hostname). The client then generates a domain-based service name from the provided hostname, following the format specified in <cite>RFC 5179</cite> (i.e., "protocol/hostname/domainname@REALM"):</p>
<p>When a connection manager associated with an XMPP server needs to communicate additional information about its service principal name to a connecting client, it can do so by including a child element of the &lt;mechanisms/&gt; element during SASL negotation, as specified in &rfc6120;. In the case of the Kerberos V SASL mechanism, the child element is a &lt;hostname/&gt; element qualified by the 'urn:xmpp:domain-based-name:0' namespace &NSNOTE;. In the context of Kerberos, the &lt;hostname/&gt; element MUST include a 'mechanism' attribute, where the value MUST be "GSSAPI". The XML character data of the &lt;hostname/&gt; element shall specify the fully-qualified name of the connection manager (known as the hostname). The client then generates a domain-based service name from the provided hostname, following the format specified in <cite>RFC 5179</cite> (i.e., "protocol/hostname/domainname@REALM"):</p>
<ul>
<li>The <strong>protocol</strong> string MUST be "xmpp"</li>
<li>The <strong>hostname</strong> string MUST be the XML character data of the &lt;hostname/&gt; element</li>
@ -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>rfc3920bis</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 3920</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-0237.xml
View File

@ -92,7 +92,7 @@
<version>0.5</version>
<date>2009-02-19</date>
<initials>psa</initials>
<remark><p>Reverted to a roster-specific method and modified presentation to enable incorporation into rfc3921bis.</p></remark>
<remark><p>Reverted to a roster-specific method and modified presentation to enable incorporation into the revisions to RFC 3921.</p></remark>
</revision>
<revision>
<version>0.4</version>
@ -141,7 +141,7 @@
<section1 topic='Introduction' anchor='intro'>
<p>Although XMPP rosters can become quite large, they tend to change infrequently. Therefore it can be inefficient for the server to send the roster to the client during session establishment if the roster has not been modified. This document defines a small modification to the XMPP roster protocol specified in &xmppim; that enables "versioning" of roster information.</p>
<p>The basic model is that if the client specifies a version ID when it requests the roster, the server returns an empty IQ-result. If the roster has been modified, the server sends versioned roster pushes for each roster item that has been touched in any way since the version specified by the client. The client processes each roster push as it normally would, modifying its local version ID with each roster push it receives. This enables the client to receive only the items that have been modified, not the entire roster.</p>
&RFC3921BISNOTE;
<p>Note: The protocol described herein has been incorporated into &rfc6121;.</p>
</section1>
<section1 topic='Protocol' anchor='proto'>

2
xep-0246.xml
View File

@ -78,7 +78,7 @@
<section1 topic='Stream Encryption' anchor='encryption'>
<p>The mere exchange of stream headers results in an unencrypted and unauthenticated channel between the two entities. The entities SHOULD upgrade the channel to an encrypted stream using the XMPP STARTTLS command defined in &xmppcore; using &rfc4346;, optionally followed by SASL negotiation for mutual authentication (see &rfc4422;).</p>
<p>End-to-end XML streams can be negotiated between two XMPP clients, between an XMPP client and a remote XMPP service (i.e., a service with which a client does not have a direct XML stream, such as a remote &xep0045; room), or between two remote XMPP services. Therefore, if standard X.509 certificates are used then a party to an e2e XML stream will present either a client certificate or a server certificate as appropriate. If X.509 certificates are used, they MUST at a minimum be generated and validated in accordance with the certificate guidelines guidelines provided in &rfc3920bis;; however, applications of end-to-end XML streams MAY define supplemental guidelines for certificate validation in the context of particular architectures, such as <cite>XEP-0174</cite> for link-local streams and <cite>XEP-0247</cite> for direct or mediated streams negotiated through XMPP servers.</p>
<p>End-to-end XML streams can be negotiated between two XMPP clients, between an XMPP client and a remote XMPP service (i.e., a service with which a client does not have a direct XML stream, such as a remote &xep0045; room), or between two remote XMPP services. Therefore, if standard X.509 certificates are used then a party to an e2e XML stream will present either a client certificate or a server certificate as appropriate. If X.509 certificates are used, they MUST at a minimum be generated and validated in accordance with the certificate guidelines guidelines provided in &rfc6120;; however, applications of end-to-end XML streams MAY define supplemental guidelines for certificate validation in the context of particular architectures, such as <cite>XEP-0174</cite> for link-local streams and <cite>XEP-0247</cite> for direct or mediated streams negotiated through XMPP servers.</p>
<p>To ease the transition from the PGP-based object encryption method specified in &xep0027;, clients using TLS for e2e streams MAY use the OpenPGP TLS extension defined in &rfc5081; (if available).</p>
<p>Use of other TLS extensions MAY be appropriate as well, including those defined in &rfc4346; and &rfc5054;.</p>
</section1>

4
xep-0257.xml
View File

@ -59,7 +59,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>An XMPP client typically needs a user name and a password to log into an account. Many clients provide a mechanism to store these credentials to automatically log in into an account. While this practice is very user friendly, it is a security risk for some devices. Mobile devices like a phone or a laptop may get stolen, providing the thief with the required password. Mobile phones are particularly insecure: providing the password on the keypad for each log in is too complicated and the risk of losing the phone is high.</p>
<p>A solution to this problem is to allow a client to log in without knowing the password. XMPP as specified in &rfc3920; and provisionally clarified in &rfc3920bis; allows the use of any SASL mechanism (see &rfc4422;) in the authentication of XMPP entities, including the SASL EXTERNAL mechanism. &xep0178; defines the usage of X.509 certificates used in the TLS handshake.</p>
<p>A solution to this problem is to allow a client to log in without knowing the password. XMPP as specified in &rfc3920; and updated in &rfc6120; allows the use of any SASL mechanism (see &rfc4422;) in the authentication of XMPP entities, including the SASL EXTERNAL mechanism. &xep0178; defines the usage of X.509 certificates used in the TLS handshake.</p>
<p>XEP-0178 assumes that the certificates used for SASL EXTERNAL are signed by a trusted CA. This could be a problem for the average user: signing a certificate is both an expensive and a complicated procedure. If the device gets stolen, the user also needs to provide the required information to the CA to revoke the certificate, and the server needs to keep its list of revoked certificates up-to-date. The end-to-end security mechanism described in &xep0250; relies on self-signed certificates (although CA-issued certificates are allowed). A client capable of secure end-to-end communicate already has a self-signed X.509 certificate for that purpose. The same client certificate should be used for a client to log in. Since the certificates are not signed by a trusted CA, the server must be aware of the list of certificates that are used by the users' clients. This document describes how to manage the list of client certificates.</p>
</section1>
@ -177,7 +177,7 @@
<section1 topic='SASL EXTERNAL' anchor='sasl'>
<p>The protocol flow is similar to the one described in XEP-0178. Only step 9 is different: the certificate does not need to be signed by a trusted entity if the certificate was uploaded by the user. The server still MUST reject the certificate if it is expired. In a company environment the server MAY only accept signed certificates; the behavior depends on the company's security policy. A free public XMPP server MUST allow self-signed certificates and certificates signed by a CA unknown to the server.</p>
<p>The client certificate SHOULD include a JID as defined in sections 15.2.1.2. and 15.2.1.3. in rfc3920bis: a JID MUST be represented as an XmppAddr, i.e., as a UTF8String within an otherName entity inside the subjectAltName.</p>
<p>The client certificate SHOULD include a JID as defined in sections 17.2.1.2. and 17.2.1.3. in RFC 6120: a JID MUST be represented as an XmppAddr, i.e., as a UTF8String within an otherName entity inside the subjectAltName.</p>
<example caption='subjectAltName using the "id-on-xmppAddr" format'><![CDATA[
subjectAltName=otherName:id-on-xmppAddr;UTF8:hamlet@shakespeare.lit
]]></example>

8
xep-0260.xml
View File

@ -194,7 +194,7 @@ Initiator Responder
jid='juliet@capulet.lit/balcony'
port='16453'
priority='7929856'
type='direct'/>
type='assisted'/>
<candidate cid='grt654q2'
host='2001:638:708:30c9:219:d1ff:fea4:a17d'
jid='juliet@capulet.lit/balcony'
@ -248,7 +248,7 @@ priority = (2^16)*(type preference) + (local preference)
<p>The local preference is used to rate different candidates of the same type, e.g. a DSL link might be preferred over a VPN connection. The value of the local preference SHOULD be between 0 and 65535. The proposed values are only guidelines. If a client wants to increase or decrease the value of a specific candidate it is free to do so. For instance, a client might have an expensive UMTS link as a last resort and might rate this link lower than all SOCKS5 relays.</p>
</section2>
<section2 topic='Connecting to Candidates' anchor='connect'>
<p>After receiving its peer's candidates, a client start to connect to them in order of the priority. The protocol is described in <cite>XEP-0065</cite> in detail. Once one client has successfully created a connection, it sends the &lt;candidate-used/&gt; element to the peer inside a transport-info Jingle message. If a client receives a candidate-used notification it SHOULD continue trying to connect to candidates of its peer if it has not tried all candidates with a higher priority than the one successfully used by the peer.</p>
<p>After receiving its peer's candidates, a client start to connect to them in order of the priority. The protocol is described in <cite>XEP-0065</cite> in detail. Once one client has successfully created a connection, it sends the &lt;candidate-used/&gt; element to the peer inside a Jingle transport-info message. If a client receives a candidate-used notification it SHOULD continue trying to connect to candidates of its peer if it has not tried all candidates with a higher priority than the one successfully used by the peer.</p>
<example caption="Initiator sends candidate-used in Jingle transport-info"><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='hjdi8'
@ -347,7 +347,7 @@ priority = (2^16)*(type preference) + (local preference)
</jingle>
</iq>
]]></example>
<p>The parties shall then consider the bytestream unsuccessful and fallback to IBB as described in <link url='#fallback'>Fallback to IBB</link>.</p>
<p>The parties shall then consider the bytestream unsuccessful and fall back to IBB as described in <link url='#fallback'>Fallback to IBB</link>.</p>
</section2>
<section2 topic='Exchanging Data' anchor='data'>
<p>Once the parties have chosen (and if necessary activated) a streamhost, they can exchange data as defined in <cite>XEP-0065</cite>.</p>
@ -404,7 +404,7 @@ Romeo Juliet
|--------------------------------->|
| |
]]></code>
<p>First the initiator sends a Jingle session-initiate, in this case with a transport of SOCKS5 Bytestreams. The protocol flow is exactly the same as described above. If both clients are unable to connect to a candidate provided by the peer, both send candidate-error messages and SOCKS5 as failed. The initiator MUST either terminate the Jingle session with a Jingle reason of &lt;connectivity-error/&gt; or replace the transport with something else using the transport-replace action. Typically the fallback option is IBB (see, for example, &xep0234;). Therefore the initiator sends a transport-replace action including a transport of IBB.</p>
<p>First the initiator sends a Jingle session-initiate, in this case with a transport of SOCKS5 Bytestreams. The protocol flow is exactly the same as described above. If both clients are unable to connect to a candidate provided by the peer, both send candidate-error messages and SOCKS5 has failed. The initiator MUST either terminate the Jingle session with a Jingle reason of &lt;connectivity-error/&gt; or replace the transport with something else using the transport-replace action. Typically the fallback option is IBB (see, for example, &xep0234;). Therefore the initiator sends a transport-replace action including a transport of IBB.</p>
<example caption="Initiator replaces transport with IBB"><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='hs92n57'

2
xep-0283.xml
View File

@ -217,7 +217,7 @@
<section2 topic='Contacts Offline at the Time the Rename Occurs'
anchor='offline'>
<p>&rfc3920bis; clarifies that an incoming subscribe &PRESENCE; stanza
<p>&rfc6120; clarifies that an incoming subscribe &PRESENCE; stanza
MUST be preserved by the server and &PRESENCE; stanzas of type
unsubscribe and unsubscribed are not preserved on the server.
Therefore, for a contact who is offline, their servers MAY have

2
xep-0285.xml
View File

@ -216,7 +216,7 @@
<p>In Case #1, the receiving application MUST do one and only one of the following: (1) ignore
the &lt;signed/&gt; extension, (2) ignore the entire stanza, or (3), except where precluded by
the protocol (&rfc3920bis;), return a &lt;service-unavailable/&gt; error to the sender.</p>
the protocol (&rfc6120;), return a &lt;service-unavailable/&gt; error to the sender.</p>
<p>In Case #2, the receiving application MUST NOT return a stanza error to the sender, since
this is the success case.</p>
<p>In Case #3, the receiving application MAY, except where precluded by the protocol, return a

2
xep-0286.xml
View File

@ -46,7 +46,7 @@
<section1 topic='Overview' anchor='overview'>
<p>Mobile handsets typically have two constraints - power and bandwidth. The advent of 3G technology and beyond has tended to mean that bandwidth is radically higher, and comparable to broadband speeds - however many operators still charge based on transferred data, hence bandwidth remains an important issue for cost purposes.</p>
<p>The major cost of power in the handset for our purposes is the radio - here, too, bandwidth plays a part, but as this document will show, the time the radio is forced to be available to receive also costs substantially.</p>
<p>Whilst this document refers to &xmppcore;, implementors are advised to take note of &rfc3920bis;.</p>
<p>Whilst this document refers to &rfc3920;, implementors are advised to take note of &rfc6120;.</p>
</section1>
<section1 topic='Compression'>
<p>XMPP is known to compress well. Both TLS, part of &xmppcore;, and &xep0138; can provide access to the DEFLATE codec (<span class='ref'><link url='http://tools.ietf.org/html/rfc1951'>RFC 1951</link></span> <note>RFC 1951 DEFLATE Compressed Data Format Specification version 1.3

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. &rfc3920bis; 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>&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>
</section1>
<!--
http://www.ietf.org/mail-archive/web/xmpp/current/msg00658.html