moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 10:12:19 -05:00
Code Issues Releases Wiki Activity

changed to Obsolete because of RFC publication

Browse Source
This commit is contained in:
stpeter 2012-02-07 06:10:05 -07:00
parent f35e05df01
commit e6bf04edc7
4 changed files with 42 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
xep-0190.xml
View File

@ -10,14 +10,16 @@
<abstract>This document specifies a best practice for closing an XML stream that is perceived to be idle.</abstract>
&LEGALNOTICE;
<number>0190</number>
<status>Active</status>
<status>Obsolete</status>
<type>Informational</type>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>
<supersedes/>
<supersededby/>
<supersededby>
<spec>RFC 6120</spec>
</supersededby>
<shortname>N/A</shortname>
<author>
<firstname>Carlo</firstname>
@ -25,6 +27,12 @@
<email>lynX@jabber.getting.psyced.org</email>
<jid>lynX@ve.symlynX.com</jid>
</author>
<revision>
<version>1.1rc1</version>
<date>2012-02-07</date>
<initials>psa</initials>
<remark><p>Changed status to Obsolete because it is superseded by RFC 6120.</p></remark>
</revision>
<revision>
<version>1.0</version>
<date>2007-01-04</date>

17
xep-0192.xml
View File

@ -10,16 +10,24 @@
<abstract>This document proposes improvements to the XML stream features definition for inclusion in the specification that supersedes RFC 3920.</abstract>
&LEGALNOTICE;
<number>0192</number>
<status>Deprecated</status>
<status>Obsolete</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
<supersedes/>
<supersededby>
<spec>RFC 6120</spec>
</supersededby>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>1.2rc1</version>
<date>2012-02-07</date>
<initials>psa</initials>
<remark><p>Changed status from Deprecated to Obsolete.</p></remark>
</revision>
<revision>
<version>1.1</version>
<date>2011-05-11</date>
@ -57,7 +65,8 @@
<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 &rfc6120;.</p>
<p>Those shortcomings are addressed in this document.</p>
<p class='box'>Note: The recommendations from this document were NOT incorporated into &rfc6120; and this document is Obsolete.</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>

10
xep-0193.xml
View File

@ -10,7 +10,7 @@
<abstract>This document proposes improvements to the definition of resource binding for inclusion in the specification that supersedes RFC 3920.</abstract>
&LEGALNOTICE;
<number>0193</number>
<status>Deprecated</status>
<status>Obsolete</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
@ -20,6 +20,12 @@
<supersededby>None</supersededby>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>1.2rc1</version>
<date>2012-02-07</date>
<initials>psa</initials>
<remark><p>Changed status from Deprecated to Obsolete.</p></remark>
</revision>
<revision>
<version>1.1</version>
<date>2011-05-11</date>
@ -65,7 +71,7 @@
</header>
<section1 topic='Introduction' anchor='proto'>
<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 from this document were NOT incorporated into &rfc6120;.</p>
<p class='box'>Note: The recommendations from this document were NOT incorporated into &rfc6120; and this document is Obsolete.</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>

14
xep-0237.xml
View File

@ -10,7 +10,7 @@
<abstract>This specification defines a proposed modification to the XMPP roster protocol that enables versioning of rosters such that the server will not send the roster to the client if the roster has not been modified, thus saving bandwidth during session establishment.</abstract>
&LEGALNOTICE;
<number>0237</number>
<status>Draft</status>
<status>Obsolete</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@ -19,7 +19,9 @@
<spec>XMPP IM</spec>
</dependencies>
<supersedes/>
<supersededby/>
<supersededby>
<spec>RFC 6121</spec>
</supersededby>
<shortname>N/A</shortname>
<schemaloc>
<ns>feature</ns>
@ -27,6 +29,12 @@
</schemaloc>
&stpeter;
&dcridland;
<revision>
<version>1.3rc1</version>
<date>2012-02-07</date>
<initials>psa</initials>
<remark><p>Changed status to Obsolete because it is superseded by RFC 6121.</p></remark>
</revision>
<revision>
<version>1.2</version>
<date>2011-03-16</date>
@ -331,7 +339,7 @@ S: <iq from='romeo@montague.lit' id='dh361f35' to='romeo@montague.lit/home' type
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
XEP-0237: http://www.xmpp.org/extensions/xep-0237.html
RFC 6121: http://tools.ietf.org/html/rfc6121
</xs:documentation>
</xs:annotation>