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

0.2

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@281 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-12-20 17:47:14 +00:00
parent 3c8497e559
commit e35d13b4de
1 changed files with 13 additions and 52 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

65
xep-0192.xml
View File

@ -20,6 +20,12 @@
<supersededby>None</supersededby>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>0.2</version>
<date>2006-12-20</date>
<initials>psa</initials>
<remark><p>Removed session establishment examples and text; specified that namespace for dialback stream feature shall be issued by the XMPP Registrar.</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2006-08-16</date>
@ -43,8 +49,8 @@
<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>
<p>The following examples show a possible flow of stream negotiation between a client and a server, using the required flag for all but one of the features. (This example is more verbose than a typical stream negotiation flow, but is provided here for the sake of completeness.)</p>
<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, we recommend that every stream feature must include the ability to flag the feature as required or not required.</p>
<p>The following examples show a possible flow of stream negotiation between a client and a server, using the required flag for all but one of the features and following the order specified in &xep0170;. (This example is more verbose than a typical stream negotiation flow, but is provided here for the sake of completeness.)</p>
<example caption='A stream negotiation'><![CDATA[
C: <stream:stream
@ -161,10 +167,6 @@ S: <stream:features>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<required/>
</bind>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'>
<required/>
</session>
<amp xmlns='http://jabber.org/features/amp'/>
</stream:features>
C: <iq type='set' id='bind_1'>
@ -178,30 +180,20 @@ S: <iq type='result' id='bind_1'>
<jid>somenode@example.com/someresource</jid>
</bind>
</iq>
C: <iq to='example.com' type='set' id='sess_1'>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
</iq>
S: <iq from='example.com' type='result' id='sess_1'/>
]]></example>
</section1>
<section1 topic='Dialback Stream Feature' anchor='dialback'>
<p>As specified in <cite>RFC 3920</cite>, suupport for the server dialback protocol is currently adverised through inclusion of a dialback namespace prefix in the stream header:</p>
<example caption='Stream header with dialback namespace advertisement'><![CDATA[
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'
id='s2s_123'>
]]></example>
<p>However, it is not clear if inclusion of the dialback namespace indicates that a server supports the server dialback protocol or it if requires negotiation of server dialback. To make this clear, we define a stream feature for server dialback.</p>
<p>However, it is not clear if inclusion of the dialback namespace indicates that a server supports the server dialback protocol or that it requires negotiation of server dialback. To make this clear, we define a stream feature for server dialback.</p>
<p>Consider the following scenario, in which Server1 provides a self-signed certificate. According to Server2's local service policy, it does not consider self-signed certificates to be trustworthy and therefore requires negotiation of server dialback in this case.</p>
<example caption='A stream negotiation with server dialback'><![CDATA[
S1: <stream:stream
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'
@ -249,7 +241,6 @@ S2: <stream:features>
</stream:features>
[Dialback negotiation]
]]></example>
</section1>
<section1 topic='Security Considerations' anchor='security'>
@ -260,11 +251,11 @@ S2: <stream:features>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Stream Features' anchor='registrar-stream'>
<p>The &REGISTRAR; shall include 'http://jabber.org/features/dialback' in its registry of stream features.</p>
<p>The &REGISTRAR; shall issue an XMPP URN for the dialback stream feature and include the feature in its stream feature registry (see &STREAMFEATURES;).</p>
<p>The submission is as follows:</p>
<code><![CDATA[
<feature>
<ns>http://jabber.org/features/dialback</ns>
<ns>TO BE ISSUED</ns>
<name>dialback</name>
<element>dialback</element>
<desc>Support for Server Dialback</desc>
@ -380,36 +371,6 @@ S2: <stream:features>
</xs:restriction>
</xs:simpleType>
</xs:schema>
]]></code>
</section2>
<section2 topic='Session Establishment Stream Feature' anchor='schema-session'>
<p>Note: The following provisional schema is intended to replace the existing schema for the Session Establishment stream feature.</p>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-session'
xmlns='urn:ietf:params:xml:ns:xmpp-session'
elementFormDefault='qualified'>
<xs:element name='session'>
<xs:complexType>
<xs:sequence>
<xs:element name='required'
minOccurs='0'
maxOccurs='1'
type='empty'/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
]]></code>
</section2>
@ -420,8 +381,8 @@ S2: <stream:features>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/features/dialback'
xmlns='http://jabber.org/features/dialback'
targetNamespace='TO BE ISSUED'
xmlns='TO BE ISSUED'
elementFormDefault='qualified'>
<xs:element name='dialback'>