From eb36e9ffa0bc06838880d9add9d18a5413072759 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Thu, 6 Dec 2007 18:09:53 +0000 Subject: [PATCH] 1.2pre2 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1450 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0155.xml | 81 +++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 77 insertions(+), 4 deletions(-) diff --git a/xep-0155.xml b/xep-0155.xml index 853fc342..e9d83f0e 100644 --- a/xep-0155.xml +++ b/xep-0155.xml @@ -26,10 +26,10 @@ &ianpaterson; &stpeter; - 1.2pre1 - in progress, last updated 2007-11-13 + 1.2pre2 + in progress, last updated 2007-12-06 psa -

Specified that IM message bodies must not be included.

 +

Specified that IM message bodies must not be included; added boolean multisession field to explicitly determine whether multiple simultaneous sessions are allowed between the full JIDs of the parties.

 1.1 @@ -197,7 +197,8 @@ 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:ssn" 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 stanza 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. For definitions of these fields, refer to the Defined Parameters section of this document.

+ + false + @@ -575,6 +579,71 @@ PENDING o---------------+ ]]> + +

This section defines the parameters for stanza session negotiation parameters and whether they must, should, or may be included in the initial negotiation form. Additional parameters may be registered as described in the XMPP Registrar Considerations section of this document.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameDefinitionInclusion
acceptWhether the receiving party wishes to accept the invitationMUST
continueAnother resource with which to continue the sessionN/A (used to move a session)
disclosureWhether and to what extent the content, keys, and identities can be disclosed to third parties; the options are "never" (disclosure must never occur), "disabled" (only disclosure required by law shall occur), and "enabled" (disclosure may occur)SHOULD
http://jabber.org/protocol/chatstatesWhether the parties may exchange Chat State Notifications per XEP-0085; the options are "may" and "mustnot"OPTIONAL
http://jabber.org/protocol/xhtml-imWhether the parties may exchange XHTML formatting per XEP-0071; the options are "may" and "must not"OPTIONAL
languageThe preferred natural language(s) for information exchange, using language codes defined in accordance with &rfc4646;SHOULD
loggingWhether the parties may log messages; the options are "may" and "mustnot"SHOULD
multisessionWhether to allow multiple simultaneous sessions between the full JIDs of the parties; this is a boolean variable that defaults to falseSHOULD
renegotiateWhether the receiving party wishes to renegotiate the sessionN/A (used to renegotiate a session)
securityThe minimum security level for secure connections between the parties; the options are "none" (a secure connection is not required), "c2s" (both parties must be securely connected to their servers), and "e2e" (both parties must be securely connected to each other, for example via Encrypted Sessions)SHOULD
terminateWhether the receiving party wishes to terminate the sessionN/A (used to terminate a session)
+

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

@@ -710,6 +779,10 @@ PENDING o---------------+ mustnot +