moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

bisnote fixes

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@154 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-11-01 16:26:51 +00:00
parent a4231045f0
commit efdf66a041
7 changed files with 16 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
xep-0157.xml
View File

@ -59,7 +59,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
&BISNOTE;
&RFC3920BISNOTE;
<p>&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.</p>
</section1>
<section1 topic='XMPP Address' anchor='xmpp'>

4
xep-0175.xml
View File

@ -41,9 +41,9 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
&BISNOTE;
&RFC3920BISNOTE;
<p><cite>RFC 3920</cite> 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.</p>
<p>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 <cite>RFC 3920</cite>, <cite>RFC 4422</cite>, or <cite>RFC 4505</cite>. However, the recommendations in this document may be folded into <cite>rfc3920bis</cite> when that document is written.</p>
<p>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 <cite>RFC 3920</cite>, <cite>RFC 4422</cite>, or <cite>RFC 4505</cite>. However, the recommendations in this document may be folded into <cite>rfc3920bis</cite>.</p>
</section1>
<section1 topic='Recommendation' anchor='rec'>
<p><cite>RFC 3920</cite> 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:</p>

2
xep-0178.xml
View File

@ -60,7 +60,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
&BISNOTE;
&RFC3920BISNOTE;
<p><cite>RFC 3920</cite> 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. <note>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.</note></p>
</section1>
<section1 topic='Client-to-Server Recommendation' anchor='c2s'>

5
xep-0190.xml
View File

@ -46,13 +46,14 @@
</header>
<section1 topic='Introduction' anchor='intro'>
&BISNOTE;
&RFC3920BISNOTE;
<p><cite>RFC 3920</cite> 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.</p>
this document proposes a practice that will avoid such data loss. Note: The
recommendation described herein has been incorporated into <cite>rfc3920bis</cite>.</p>
</section1>
<!-- section1 topic='How Not to Close an Idle Stream' anchor='dont'>

5
xep-0192.xml
View File

@ -34,14 +34,13 @@
</revision>
</header>
<section1 topic='Introduction' anchor='proto'>
&BISNOTE;
&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>
<!--<li>It is not possible to discover which SASL mechanisms a server supports after SASL negotiation has been completed.</li>-->
</ul>
<p>Those shortcomings are addressed in this document.</p>
<p>Those shortcomings are addressed in this document, and the recommendations described herein have been incorporated into <cite>rfc3920bis</cite>.</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 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 &notauthorized; 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.</p>

4
xep-0193.xml
View File

@ -40,8 +40,8 @@
</revision>
</header>
<section1 topic='Introduction' anchor='proto'>
&BISNOTE;
<p><cite>RFC 3920</cite> 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 <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 client daemon that is used by multiple applications), this document proposes improvements to resource binding in order to address these shortcomings.</p>
&RFC3920BISNOTE;
<p><cite>RFC 3920</cite> 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 <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 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 <cite>rfc3920bis</cite>.</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>

6
xep.ent
View File

@ -126,7 +126,8 @@
<!-- other JSF-related text shortcuts -->
<!ENTITY BISNOTE "<p><em>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.</em></p>" >
<!ENTITY RFC3920BISNOTE "<p><em>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.</em></p>" >
<!ENTITY RFC3921BISNOTE "<p><em>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.</em></p>" >
<!ENTITY BOOLEANNOTE "<note>In accordance with Section 3.2.2.1 of <cite>XML Schema Part 2: Datatypes</cite>, the allowable lexical representations for the xs:boolean datatype are the strings &quot;0&quot; and &quot;false&quot; for the concept 'false' and the strings &quot;1&quot; and &quot;true&quot; for the concept 'true'; implementations MUST support both styles of lexical representation.</note>" >
@ -423,6 +424,9 @@
<!-- IETF XMPP Specs -->
<!ENTITY rfc3920bis "<span class='ref'>rfc3920bis</span> <note>rfc3921bis: proposed revisions to Extensible Messaging and Presence Protocol (XMPP): Core &lt;<link url='http://www.ietf.org/internet-drafts/draft-saintandre-rfc3920bis-00.txt'>http://www.ietf.org/internet-drafts/draft-saintandre-rfc3920bis-00.txt</link>&gt;. (work in progress)</note>" >
<!ENTITY rfc3921bis "<span class='ref'>rfc3921bis</span> <note>rfc3921bis: proposed revisions to Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence &lt;<link url='http://www.ietf.org/internet-drafts/draft-saintandre-rfc3921bis-00.txt'>http://www.ietf.org/internet-drafts/draft-saintandre-rfc3921bis-00.txt</link>&gt;. (work in progress)</note>" >
<!ENTITY xmpp "<span class='ref'>XMPP</span> <note>Extensible Messaging and Presence Protocol (XMPP) &lt;<link url='http://www.xmpp.org/'>http://www.xmpp.org/</link>&gt;.</note>" >
<!ENTITY xmppcore "<span class='ref'>XMPP Core</span> <note>RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core &lt;<link url='http://www.ietf.org/rfc/rfc3920.txt'>http://www.ietf.org/rfc/rfc3920.txt</link>&gt;.</note>" >
<!ENTITY xmppim "<span class='ref'>XMPP IM</span> <note>RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence &lt;<link url='http://www.ietf.org/rfc/rfc3921.txt'>http://www.ietf.org/rfc/rfc3921.txt</link>&gt;.</note>" >