Changed status to Obsolete because it is superseded by RFC 6120.
Changed status from Deprecated to Obsolete.
Those shortcomings are addressed in this document, and the recommendations described herein have been incorporated into &rfc6120;.
+Those shortcomings are addressed in this document.
+Note: The recommendations from this document were NOT incorporated into &rfc6120; and this document is Obsolete.
The XMPP stream feature for Transport Layer Security (TLS) includes a <required/> 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 RFC 3920 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 ¬authorized; 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 <required/> element, it knows thatt the receiving party will accept XML stanzas over the stream.
diff --git a/xep-0193.xml b/xep-0193.xml index 765cde48..d4d0cab4 100644 --- a/xep-0193.xml +++ b/xep-0193.xml @@ -10,7 +10,7 @@Changed status from Deprecated to Obsolete.
RFC 3920 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 RFC 3920, 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.
-Note: The recommendations from this document were NOT incorporated into &rfc6120;.
+Note: The recommendations from this document were NOT incorporated into &rfc6120; and this document is Obsolete.
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 <unbind/> qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace, which in turn has a child element of <resource/> whose XML character data specifies the resource to be unbound:
diff --git a/xep-0237.xml b/xep-0237.xml index 8a4e62d8..f080089e 100644 --- a/xep-0237.xml +++ b/xep-0237.xml @@ -10,7 +10,7 @@Changed status to Obsolete because it is superseded by RFC 6121.