From e35d13b4de3a2dd256bae48767a4d9ecc2aa460f Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 20 Dec 2006 17:47:14 +0000 Subject: [PATCH] 0.2 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@281 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0192.xml | 65 +++++++++++----------------------------------------- 1 file changed, 13 insertions(+), 52 deletions(-) diff --git a/xep-0192.xml b/xep-0192.xml index 0a756978..1851fbda 100644 --- a/xep-0192.xml +++ b/xep-0192.xml @@ -20,6 +20,12 @@ None N/A &stpeter; + + 0.2 + 2006-12-20 + psa +

Removed session establishment examples and text; specified that namespace for dialback stream feature shall be issued by the XMPP Registrar.

 + 0.1 2006-08-16 @@ -43,8 +49,8 @@

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.

-

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.)

+

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

+

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.)

- - - - C: @@ -178,30 +180,20 @@ S: somenode@example.com/someresource - -C: - - - -S: - ]]>

As specified in RFC 3920, suupport for the server dialback protocol is currently adverised through inclusion of a dialback namespace prefix in the stream header:

- ]]> -

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.

+

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.

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.

[Dialback negotiation] - ]]> @@ -260,11 +251,11 @@ S2: -

The ®ISTRAR; shall include 'http://jabber.org/features/dialback' in its registry of stream features.

+

The ®ISTRAR; shall issue an XMPP URN for the dialback stream feature and include the feature in its stream feature registry (see &STREAMFEATURES;).

The submission is as follows:

- http://jabber.org/features/dialback + TO BE ISSUED dialback dialback Support for Server Dialback @@ -380,36 +371,6 @@ S2: - - ]]> - - -

Note: The following provisional schema is intended to replace the existing schema for the Session Establishment stream feature.

- - - - - - - - - - - - - - - - - ]]> @@ -420,8 +381,8 @@ S2: