From d9a4f539258127a84280e5b5e7b1231510dc166c Mon Sep 17 00:00:00 2001 From: Ian Paterson Date: Fri, 10 Nov 2006 16:21:15 +0000 Subject: [PATCH] 0.12 RC1 removed accept field from renegotiation forms git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@181 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0155.xml | 38 ++++++++++++-------------------------- 1 file changed, 12 insertions(+), 26 deletions(-) diff --git a/xep-0155.xml b/xep-0155.xml index e56f1882..c7ae325a 100644 --- a/xep-0155.xml +++ b/xep-0155.xml @@ -25,6 +25,12 @@ chatneg &ianpaterson; &stpeter; + + 0.12 + 2006-11-10 + ip +

Removed accept field from renegotiation forms

 + 0.11 2006-11-03 @@ -268,7 +274,7 @@ ]]> -

If the contact's client supports none of the options for one or more fields, it SHOULD return a ¬acceptable; error, specifying the field(s) with unsupported options using the 'var' attribute of one or more <field/> child elements of a <feature/> child element of the <error/> scoped by the 'http://jabber.org/protocol/feature-neg' namespace:

+

If the contact's client supports none of the options for one or more required fields, it SHOULD return a ¬acceptable; error, specifying the field(s) with unsupported options using the 'var' attribute of one or more <field/> child elements of a <feature/> child element of the <error/> scoped by the 'http://jabber.org/protocol/feature-neg' namespace:

Once the other party has accepted the switch then all stanzas sent within the chat session MUST be to or from the new resource. Note: Both parties MUST ensure that they comply with all the other chat session negotiation parameters that were previously agreed for this session.

-

At any time during an existing chat session, either party MAY attempt to renegotiate the parameters of the session using the protocol described in Negotiating a New Chat Session. The requesting party does this by sending a new &MESSAGE; stanza containing a feature negotiation form and a &THREAD; element with the same value as that of the existing chat session. Note: Although the "accept" field MUST be included in a renegotiation form, the other fields MAY be different from the set of fields included in the initial session negotitation form.

+

At any time during an existing chat session, either party MAY attempt to renegotiate the parameters of the session using the protocol described in Negotiating a New Chat Session. The requesting party does this by sending a new &MESSAGE; stanza containing a feature negotiation form and a &THREAD; element with the same value as that of the existing chat session. Note: The "accept" field MUST NOT be included in a renegotiation form. The other fields MAY be different from the set of fields included in the initial session negotitation form.

http://jabber.org/protocol/chatneg - - true - - 1 -

The requesting party MAY continue to send stanzas within the session while it is waiting for the other party to either accept or reject the renegotiation.

+

The requesting party MAY continue to send stanzas within the session while it is waiting for the other party to either accept the parameters or report an error.

http://jabber.org/protocol/chatneg - 1 1 ]]> -

Note: Both parties MUST consider the renegotiation to be complete as soon as the acceptance message has been sent (or received). The requesting party SHOULD NOT send a renegotiation completion or cancelation message (see Completing or Canceling the Negotitation).

-

Note: Both parties MUST ensure that they comply with all the chat session negotiation parameters that were not renegotiated but had previously been agreed for this session.

-

If the other party's client does not support one or more of the required features, it SHOULD return a &feature; error instead, while if it supports none of the options for one or more fields, it SHOULD return a ¬acceptable; error instead (see Rejecting a Chat). However, if the other party simply prefers to maintain the existing negotiated parameters then it SHOULD decline the renegotiation as in the example below. Note: In any of these cases the existing negotiated chat session parameters are maintained. Either party MAY choose to terminate the chat session only as specified in the section Terminating a Chat.

- - ffd7076498744578d10edabfe7f4a866 - - - - http://jabber.org/protocol/chatneg - - 0 - - - - ]]> +

Note: Both parties MUST consider the renegotiation to be complete as soon as the parameter acceptance message has been sent (or received). Note: The requesting party SHOULD NOT send a renegotiation completion or cancelation message (see Completing or Canceling the Negotitation).

+

Note: Both parties MUST ensure that they continue to comply with all the chat session negotiation parameters that were not renegotiated but had previously been agreed for this session.

+

If the other party's client does not support one or more of the required features, it SHOULD return a &feature; error instead, while if it supports none of the options for one or more required fields, it SHOULD return a ¬acceptable; error instead (see Rejecting a Chat). Note: In any of these cases the existing negotiated chat session parameters are maintained. Either party MAY choose to terminate the chat session only as specified in the section Terminating a Chat.

In order to explicitly terminate a negotiated chat, the party that wishes to end the chat MUST do so by sending a &MESSAGE; containing a data form of type "submit". The &MESSAGE; stanza MUST contain a &THREAD; element with the same XML character data as the original initiation request. The data form containing a boolean field named "terminate" set to a value of "1" or "true".