From b7605a47af3f94ffc2498c11a28beb12e4f224db Mon Sep 17 00:00:00 2001 From: Ian Paterson Date: Wed, 14 Mar 2007 23:21:26 +0000 Subject: [PATCH] 1.1 RC2 renamed to stanza session negotiation git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@654 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0155.xml | 58 ++++++++++++++++++++++++++-------------------------- 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/xep-0155.xml b/xep-0155.xml index a65e42fb..6ddc504e 100644 --- a/xep-0155.xml +++ b/xep-0155.xml @@ -6,8 +6,8 @@
- Session Negotiation - This document specifies a feature negotiation profile for initiating a one-to-one XMPP communication session. + Stanza Session Negotiation + This document specifies a feature negotiation profile for initiating a one-to-one XMPP stanza communication session. &LEGALNOTICE; 0155 Draft @@ -29,7 +29,7 @@ 1.1 2007-03-12 ip -

Renamed to Session Negotiation

 +

Renamed to Stanza Session Negotiation

 1.0 @@ -113,7 +113,7 @@ 0.2 2005-07-15 psa -

Further described contexts in which session negotiation could be useful; added more examples; added reference to SIP RFC and explained basic mapping to SIP INVITE method; added XMPP Registrar considerations.

 +

Further described contexts in which stanza session negotiation could be useful; added more examples; added reference to SIP RFC and explained basic mapping to SIP INVITE method; added XMPP Registrar considerations.

 0.1 @@ -129,11 +129,11 @@
-

The traditional model for one-to-one chat "sessions" in Jabber/XMPP is for a user to simply send a message to a contact without any formal negotiation of session parameters (e.g., see &xmppim;). This informal approach to initiation of a session is perfectly acceptable in many contexts, environments, and cultures. However, it may be desirable to formally request a chat session (or any other type of session) and negotiate its parameters before beginning the session in some circumstances, such as:

+

The traditional model for one-to-one chat "sessions" in Jabber/XMPP is for a user to simply send a message to a contact without any formal negotiation of session parameters (e.g., see &xmppim;). This informal approach to initiation of a session is perfectly acceptable in many contexts, environments, and cultures. However, it may be desirable to formally request a chat session (or any other type of XMPP stanza session) and negotiate its parameters before beginning the session in some circumstances, such as:

    -
  • Whenever parameters specific to a session must be agreed. e.g., security and privacy parameters (see &xep0116; and &xep0136;).
    • +
  • Whenever parameters specific to a stanza session must be agreed. e.g., security and privacy parameters (see &xep0116; and &xep0136;).
  • The parties are unknown to each other, have not exchanged presence, or have not discovered their respective capabilities via &xep0030; or &xep0115;.
    • -
  • When an XMPP-based system interfaces with a SIP-based system built on top of &rfc3261;. In essence, a session negotiation request as specified herein is functionally equivalent to a SIP INVITE request, and acceptance of such a request is functionally equivalent to sending a SIP 200 OK response; see Section 17 of RFC 3261.
    • +
  • When an XMPP-based system interfaces with a SIP-based system built on top of &rfc3261;. In essence, a stanza session negotiation request as specified herein is functionally equivalent to a SIP INVITE request, and acceptance of such a request is functionally equivalent to sending a SIP 200 OK response; see Section 17 of RFC 3261.
  • Within an organization or culture in which one would not simply begin interacting with another person (e.g., a superior) without first receiving permission to do so.

This proposal defines best practices for such a negotiation, re-using the protocol defined in &xep0020;.

@@ -141,10 +141,10 @@

The specification addresses the following use cases:

    -
  • Negotiating a new session
    • -
  • Moving an existing session from one resource to another
    • -
  • Renegotiating an existing session
    • -
  • Terminating an existing session
    • +
  • Negotiating a new stanza session
    • +
  • Moving an existing stanza session from one resource to another
    • +
  • Renegotiating an existing stanza session
    • +
  • Terminating an existing stanza session
 @@ -177,11 +177,11 @@ PENDING o---------------+ | o ENDED -

[1] A session negotiation is initiated when the user sends a message containing a data form of type "form" with an "accept" field.

-

[2] A session negotiation is accepted when the contact sends a message containing a data form of type "submit" with an "accept" field whose value is "1" or "true".

-

[3] A session negotiation is rejected when the contact sends a message containing a data form of type "submit" with an "accept" field whose value is "0" or "false".

-

[4] A session negotiation is confirmed when the user sends a message containing a data form of type "result" with an "accept" field whose value is "1" or "true".

-

[5] A session negotiation is confirmed when the user sends a message containing a data form of type "result" with an "accept" field whose value is "0" or "false".

+

[1] A stanza session negotiation is initiated when the user sends a message containing a data form of type "form" with an "accept" field.

+

[2] A stanza session negotiation is accepted when the contact sends a message containing a data form of type "submit" with an "accept" field whose value is "1" or "true".

+

[3] A stanza session negotiation is rejected when the contact sends a message containing a data form of type "submit" with an "accept" field whose value is "0" or "false".

+

[4] A stanza session negotiation is confirmed when the user sends a message containing a data form of type "result" with an "accept" field whose value is "1" or "true".

+

[5] A stanza session negotiation is confirmed when the user sends a message containing a data form of type "result" with an "accept" field whose value is "0" or "false".

[6] An existing session is re-negotiated when either party sends a message containing a data form of type "form" with a "renegotiate" field whose value is "1" or "true".

[7] A session re-negotiation is accepted when the other party sends a message containing a data form of type "submit" with a "renegotiate" field whose value is "1" or "true".

[8] A session re-negotiation is rejected when the other party sends a message containing a data form of type "submit" with a "renegotiate" field whose value is "0" or "false"; however, the session remains in the active state with the previously-negotiated parameters in force.

@@ -191,7 +191,7 @@ PENDING o---------------+

In order to initiate a negotiated session, the initiating party ("user") sends a &MESSAGE; The &MESSAGE; stanza is used because the user does not necessarily know which of the contact's resources is most available (or indeed if the contact is online). stanza to the receiving party ("contact") containing a <feature/> child qualified by the 'http://jabber.org/protocol/feature-neg' namespace. The &MESSAGE; stanza MUST NOT contain a &BODY; child element (as specified in &rfc3921;). The &MESSAGE; stanza type SHOULD be "normal" (either explicitly or by non-inclusion of the 'type' attribute). The stanza MUST contain a &THREAD; element for tracking purposes (where the newly-generated ThreadID is unique to the proposed session). The data form MUST contain a hidden FORM_TYPE field whose value is "urn:xmpp:chatneg" and MUST contain a boolean field named "accept". &BOOLEANNOTE; The inclusion of "logging", "disclosure" and "security" fields is also RECOMMENDED. Note: The options within any 'list-single' fields SHOULD appear in order of preference.

Note: Sessions may be conducted between entities who are never online at the same time. However, if the user is interested only in an immediate session then the user SHOULD instruct the contact's server not to store the message for later delivery (see &xep0160;) using the &xep0079; protocol.

-

In the following example of a negotiation request, Romeo requests a chat with Juliet and also queries her regarding whether she is able to disallow all message logging (see &xep0136;) A client MUST NOT set the 'logging' field to 'mustnot' unless it has confirmed that its server will allow it to switch off Automated Archiving (see Message Archiving)., whether she wants to temporarily share presence for this session (see the Sharing Presence section of this document), and whether she wants to support the &xep0071; and &xep0085; extensions during this session. He asks Juliet's client if it is prepared to make a (legally binding) guarantee that it does not intentionally implement any feature (not even a disabled feature) that might disclose the content of the session, any associated (decryption) keys, or his identity to any third-party (see Encrypted Session Negotiation). He also requires that they are both connected securely to their servers, and asks which language she prefers amongst those he can write. (Note: These fields are examples only; a full set of session negotiation parameters will be registered as described in the XMPP Registrar Considerations section of this document.)

+

In the following example of a negotiation request, Romeo requests a chat with Juliet and also queries her regarding whether she is able to disallow all message logging (see &xep0136;) A client MUST NOT set the 'logging' field to 'mustnot' unless it has confirmed that its server will allow it to switch off Automated Archiving (see Message Archiving)., whether she wants to temporarily share presence for this session (see the Sharing Presence section of this document), and whether she wants to support the &xep0071; and &xep0085; extensions during this session. He asks Juliet's client if it is prepared to make a (legally binding) guarantee that it does not intentionally implement any feature (not even a disabled feature) that might disclose the content of the session, any associated (decryption) keys, or his identity to any third-party (see Encrypted Session Negotiation). He also requires that they are both connected securely to their servers, and asks which language she prefers amongst those he can write. (Note: These fields are examples only; a full set of stanza session negotiation parameters will be registered as described in the XMPP Registrar Considerations section of this document.)

The user MAY request a session with a specific resource of the contact. However, if the user specifies no resource (or if the specified resource is not available), then the contact's server delivers the request to the contact's most available resource (which in the examples below happens to be "balcony"). If no resource is available (and no Advanced Message Processing rule included in the request specifies otherwise) then the server MAY store the request for later delivery.

 -

If, upon reception of a user's session request, a contact finds that the request had been stored for later delivery, and if the contact is interested only in an immediate session, then it SHOULD initiate a new session negotiation (including a newly-generated ThreadID) instead of responding to the user's request. Note: Sending any response to the user's original request would leak presence information since it would divulge the fact that the contact had been offline rather than just ignoring the user.

+

If, upon reception of a user's session request, a contact finds that the request had been stored for later delivery, and if the contact is interested only in an immediate session, then it SHOULD initiate a new stanza session negotiation (including a newly-generated ThreadID) instead of responding to the user's request. Note: Sending any response to the user's original request would leak presence information since it would divulge the fact that the contact had been offline rather than just ignoring the user.

In any response to the user's request, the contact's client MUST mirror the &THREAD; value so that the user's client can correctly track the response.

If the request is accepted then the contact's client MUST include in its response values for all the fields that the request indicated are required. If the contact's client does not support one of the default values or if the contact has disabled its support (as for Chat State Notifications and XHTML formatting in the example below), and the client can still accept the request, then it MUST set that field to a value that it can support.

In the example below we assume that Juliet accepts the session and specifies that she prefers to speak Italian with Romeo:

@@ -392,7 +392,7 @@ PENDING o---------------+ ]]> -

If the contact accepted the session (see Accepting a Session) then the user MUST either complete or cancel the session negotiation. If the contact chose an option other than the default (prefered) value for one or more of the fields, then instead of having the client accept the session automatically the user may prefer to review the values that the contact selected before confirming that the session is open. See Encrypted Session Negotiation for example of other instances where the user might find the values submitted by the contact unacceptable. In any case the user's client SHOULD verify that the selected values are acceptable before completing the session negotiation -- and confirming that the session is open -- by replying with a form with the form 'type' attribute set to 'result'. The form MUST contain the FORM_TYPE field and the "accept" field set to "1" or "true". The user MAY include other content (e.g., a &BODY; element) in the confirmation stanza:

+

If the contact accepted the session (see Accepting a Session) then the user MUST either complete or cancel the stanza session negotiation. If the contact chose an option other than the default (prefered) value for one or more of the fields, then instead of having the client accept the session automatically the user may prefer to review the values that the contact selected before confirming that the session is open. See Encrypted Session Negotiation for example of other instances where the user might find the values submitted by the contact unacceptable. In any case the user's client SHOULD verify that the selected values are acceptable before completing the stanza session negotiation -- and confirming that the session is open -- by replying with a form with the form 'type' attribute set to 'result'. The form MUST contain the FORM_TYPE field and the "accept" field set to "1" or "true". The user MAY include other content (e.g., a &BODY; element) in the confirmation stanza:

I forgot what I wanted to say! ]]> -

Alternatively, if the user decides to cancel the session negotiation then the client MUST reply with a data form containing the FORM_TYPE field and the "accept" field set to "0" or "false":

- Alternatively, if the user decides to cancel the stanza session negotiation then the client MUST reply with a data form containing the FORM_TYPE field and the "accept" field set to "0" or "false":

+ @@ -461,10 +461,10 @@ PENDING o---------------+ ]]> -

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

+

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

 -

At any time during an existing session, either party MAY attempt to renegotiate the parameters of the session using the protocol described in Negotiating a New 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 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 negotiation form.

+

At any time during an existing session, either party MAY attempt to renegotiate the parameters of the session using the protocol described in Negotiating a New 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 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 stanza session negotiation form.

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

-

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

+

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

In order to reject the renegotiation, the other party shall send a message containing a data form of type "submit" with the 'renegotiate' field set to a value of "0" or "false".

-

A client MAY require a human user to approve each session negotiation request, however it is RECOMMENDED that it accepts or rejects automatically as many requests as possible, based on a set of user-configurable policies (see Presence Leaks).

+

A client MAY require a human user to approve each stanza session negotiation request, however it is RECOMMENDED that it accepts or rejects automatically as many requests as possible, based on a set of user-configurable policies (see Presence Leaks).

 -

Session negotiation sometimes requires the involvement of either or both human users, and if human input is required but the user is away then session establishment may be delayed indefinitely. So, in order to minimise the number of user interruptions and delays, clients SHOULD reuse existing sessions whenever possible. For example, a client SHOULD NOT terminate sessions unless the user is going offline, even if its user closes a window associated with the session.

+

Stanza session negotiation sometimes requires the involvement of either or both human users, and if human input is required but the user is away then session establishment may be delayed indefinitely. So, in order to minimise the number of user interruptions and delays, clients SHOULD reuse existing sessions whenever possible. For example, a client SHOULD NOT terminate sessions unless the user is going offline, even if its user closes a window associated with the session.

If so negotiated via the 'presence' field, two parties who do not have subscriptions to each other's presence (as specified in XMPP-IM) may share presence by sending directed presence after the session is negotiated.

@@ -599,7 +599,7 @@ PENDING o---------------+ -

If a contact does not share its presence information with a user through a presence subscription (see RFC 3921) or if it blocks outbound presence notifications to the user (see &xep0016;), then it will effectively expose its presence if it accepts the user's session negotiation request or returns an error to the user. Therefore, due care must be exercised in determining whether to accept the request or return an error. The contact's client SHOULD NOT automatically (i.e. without first asking the contact) either accept the user's request or return an error to the user unless the user is subscribed to the contact's presence and the contact is not blocking outbound presence notifications to the user. Note: There should be no need for the contact's client to consult the contact's block list (see &xep0191;), since if the user is on the block list then the contact would not receive the request from the user in the first place.

+

If a contact does not share its presence information with a user through a presence subscription (see RFC 3921) or if it blocks outbound presence notifications to the user (see &xep0016;), then it will effectively expose its presence if it accepts the user's stanza session negotiation request or returns an error to the user. Therefore, due care must be exercised in determining whether to accept the request or return an error. The contact's client SHOULD NOT automatically (i.e. without first asking the contact) either accept the user's request or return an error to the user unless the user is subscribed to the contact's presence and the contact is not blocking outbound presence notifications to the user. Note: There should be no need for the contact's client to consult the contact's block list (see &xep0191;), since if the user is on the block list then the contact would not receive the request from the user in the first place.

If a client is configured to show a request <form/> to a human user instead of responding automatically, it SHOULD replace the content of the <title/> element and of all label attributes of the known and registered <field/> and <option/> elements with its own localised versions before showing the form to the user -- even if the form already appears to be in the correct language.

@@ -618,13 +618,13 @@ PENDING o---------------+ urn:xmpp:chatneg - Support for Session Negotiation and its FORM_TYPE + Support for Stanza Session Negotiation and its FORM_TYPE XEP-0155 ]]> -

&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. The following fields are registered for use in Session Negotiation (see &FORMTYPES;):

+

&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. The following fields are registered for use in Stanza Session Negotiation (see &FORMTYPES;):

urn:xmpp:chatneg