From efdf66a041239a793c80cc8e1daa6d9e9ce73896 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 1 Nov 2006 16:26:51 +0000 Subject: [PATCH] bisnote fixes git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@154 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0157.xml | 2 +- xep-0175.xml | 4 ++-- xep-0178.xml | 2 +- xep-0190.xml | 5 +++-- xep-0192.xml | 5 ++--- xep-0193.xml | 4 ++-- xep.ent | 6 +++++- 7 files changed, 16 insertions(+), 12 deletions(-) diff --git a/xep-0157.xml b/xep-0157.xml index 50c1a915..c36d8302 100644 --- a/xep-0157.xml +++ b/xep-0157.xml @@ -59,7 +59,7 @@ - &BISNOTE; + &RFC3920BISNOTE;

&rfc2142; specifies conventional electronic mailbox names for common services, roles, and functions related to SMTP, NNTP, and HTTP (such as postmaster@domain.tld, usenet@domain.tld, and webmaster@domain.tld). However, no such conventional email address or Jabber ID (JID) has been specified for XMPP services. This document remedies that oversight.

 diff --git a/xep-0175.xml b/xep-0175.xml index b4f4ebe5..17ed6a47 100644 --- a/xep-0175.xml +++ b/xep-0175.xml @@ -41,9 +41,9 @@ - &BISNOTE; + &RFC3920BISNOTE;

RFC 3920 allows the use of any SASL mechanism (see &rfc4422;) in XMPP authentication, including the SASL ANONYMOUS mechanism (see &rfc4505;). This document specifies a recommended protocol flow for such use.

-

Note: This document is provided for discussion purposes in order to clarify the usage of SASL ANONYMOUS in XMPP systems. It is not meant to supersede the text in RFC 3920, RFC 4422, or RFC 4505. However, the recommendations in this document may be folded into rfc3920bis when that document is written.

+

Note: This document is provided for discussion purposes in order to clarify the usage of SASL ANONYMOUS in XMPP systems. It is not meant to supersede the text in RFC 3920, RFC 4422, or RFC 4505. However, the recommendations in this document may be folded into rfc3920bis.

RFC 3920 specifies that after an XMPP client authenticates with an XMPP server, it must bind a resource to the XML stream so that XML stanzas can be routed to the client. In essence there are three resource binding scenarios:

diff --git a/xep-0178.xml b/xep-0178.xml index 84344e93..52d23353 100644 --- a/xep-0178.xml +++ b/xep-0178.xml @@ -60,7 +60,7 @@ - &BISNOTE; + &RFC3920BISNOTE;

RFC 3920 allows the use of any SASL mechanism (see &rfc4422;) in XMPP authentication, including the SASL EXTERNAL mechanism. This document specifies a recommended protocol flow for such use, specifically when use of TLS is required by a deployment. The protocol flows when TLS is not required are more complicated (e.g., alternate flows involving server dialback) and may be documented in a future version of this document.

 diff --git a/xep-0190.xml b/xep-0190.xml index 8def536a..0b4aab7a 100644 --- a/xep-0190.xml +++ b/xep-0190.xml @@ -46,13 +46,14 @@ - &BISNOTE; + &RFC3920BISNOTE;

RFC 3920 offers several ways on how to terminate an XMPP stream, but doesn't always make a clear statement which one to take. This can lead to faulty implementations. In particular, closing a stream that hasn't 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.

+ this document proposes a practice that will avoid such data loss. Note: The + recommendation described herein has been incorporated into rfc3920bis.

 -

Those shortcomings are addressed in this document.

+

Those shortcomings are addressed in this document, and the recommendations described herein have been incorporated into rfc3920bis.

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 either to proceed with the negotiation or to 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, we recommend that every stream feature must include the ability to flag the feature as required or not required.

diff --git a/xep-0193.xml b/xep-0193.xml index 326febbe..0e0f270c 100644 --- a/xep-0193.xml +++ b/xep-0193.xml @@ -40,8 +40,8 @@ - &BISNOTE; -

RFC 3920 introduced the concept of binding a resource to an XML stream (this concept superseded part of the older 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 client daemon that is used by multiple applications), this document proposes improvements to resource binding in order to address these shortcomings.

+ &RFC3920BISNOTE; +

RFC 3920 introduced the concept of binding a resource to an XML stream (this concept superseded part of the older 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 client daemon that is used by multiple applications), this document proposes improvements to resource binding in order to address these shortcomings. Note: The recommendations described herein have been incorporated into rfc3920bis.

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.ent b/xep.ent index 3c22d51c..40c5beb7 100644 --- a/xep.ent +++ b/xep.ent @@ -126,7 +126,8 @@ -Note: This document describes a protocol or best practice that is intended for addition to the specification that will supersede either &rfc3920; or &rfc3921; within the Internet Standards Process. This document is provided only for the purpose of open community discussion of the potential modification and will be obsoleted as soon as the relevant RFC is published.

" > +Note: This document describes a protocol or best practice that is intended for incorporation into the specification that will supersede &rfc3920; within the Internet Standards Process, i.e., &rfc3920bis;. This document is provided only for the purpose of open community discussion of the potential modification and will be obsoleted as soon as the relevant RFC is published.

" > +Note: This document describes a protocol or best practice that is intended for incorporation into the specification that will supersede &rfc3921; within the Internet Standards Process, i.e., &rfc3921bis;. This document is provided only for the purpose of open community discussion of the potential modification and will be obsoleted as soon as the relevant RFC is published.

" > In accordance with Section 3.2.2.1 of XML Schema Part 2: Datatypes, the allowable lexical representations for the xs:boolean datatype are the strings "0" and "false" for the concept 'false' and the strings "1" and "true" for the concept 'true'; implementations MUST support both styles of lexical representation." > @@ -423,6 +424,9 @@ +rfc3920bis rfc3921bis: proposed revisions to Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/internet-drafts/draft-saintandre-rfc3920bis-00.txt>. (work in progress)" > +rfc3921bis rfc3921bis: proposed revisions to Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/internet-drafts/draft-saintandre-rfc3921bis-00.txt>. (work in progress)" > + XMPP Extensible Messaging and Presence Protocol (XMPP) <http://www.xmpp.org/>." > XMPP Core RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>." > XMPP IM RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>." >