From 6d2593a4e43d4aa7d1099e4910ab3aae5ba550e9 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 30 Jan 2008 21:32:25 +0000 Subject: [PATCH] typo git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1628 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0220.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xep-0220.xml b/xep-0220.xml index 4703fcde..69314c55 100644 --- a/xep-0220.xml +++ b/xep-0220.xml @@ -336,7 +336,7 @@ that is,
  • By inclusion of the server dialback feature in a given set of stream features.
  • By inclusion of the dialback namespace declaration in the stream header.
    • -

    The former method is preferred, but the latter method is also specified herein for the purpose of backward-compatibility with older "XMPP 0.9" deployments.

    +

    The former method is preferred, but the latter method is also specified herein for the purpose of backwards-compatibility with older "XMPP 0.9" deployments.

    The server dialback stream feature is advertised by including in any given set of stream features a <dialback/> element qualified by the 'urn:xmpp:features:dialback' namespace; the <dialback/> element MAY also include an empty <required/> element, indicating that the entity sending the stream features requires dialback to be negotiated for the stream.

    @@ -354,7 +354,7 @@ that is, from='example.com' to='example.net'> ]]> -

    No matter which method is used, a service SHOULD advertise support for server dialback only at a point in the stream negotiation when it will accept negotiation of server dialback for that stream. For example, if a service wishes to be backward-compatible with older "XMPP 0.9" deployments, it SHOULD include the server dialback namespace declaration in the initial stream header it sends to other servers (so that "XMPP 0.9" servers can proceed with dialback in the absence of TLS and SASL authentication). However, in the midst of stream negotiation with an XMPP 1.0 or higher server, a service SHOULD advertise the dialback stream feature only at a point when negotiation of server dialback is allowed in accordance with local service policies (e.g., after TLS negotiation in the case when a self-signed certificate was presented by the Originating Server and local service policies stipulate that it is preferable to weakly identify the Originating Server via server dialback rather than depend on the self-signed certificate for identity verification).

    +

    No matter which method is used, a service SHOULD advertise support for server dialback only at a point in the stream negotiation when it will accept negotiation of server dialback for that stream. For example, if a service wishes to be backwards-compatible with older "XMPP 0.9" deployments, it SHOULD include the server dialback namespace declaration in the initial stream header it sends to other servers (so that "XMPP 0.9" servers can proceed with dialback in the absence of TLS and SASL authentication). However, in the midst of stream negotiation with an XMPP 1.0 or higher server, a service SHOULD advertise the dialback stream feature only at a point when negotiation of server dialback is allowed in accordance with local service policies (e.g., after TLS negotiation in the case when a self-signed certificate was presented by the Originating Server and local service policies stipulate that it is preferable to weakly identify the Originating Server via server dialback rather than depend on the self-signed certificate for identity verification).