diff --git a/xep-0155.xml b/xep-0155.xml index 9d4d439f..5b967ef4 100644 --- a/xep-0155.xml +++ b/xep-0155.xml @@ -29,7 +29,7 @@ 0.10 2006-10-20 ip -

Specified handling of offline requests.

 +

Specified handling of offline requests; minor clarifications.

 0.9 @@ -105,7 +105,7 @@

In order to initiate a negotiated chat 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 MAY include an 'id' attribute and 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 "http://jabber.org/protocol/chatneg" and MUST contain a boolean field named "accept". &BOOLEANNOTE; The inclusion of "otr" and "security" fields is also RECOMMENDED. Note: The options within any 'list-single' fields SHOULD appear in order of preference.

-

Note: If the user is interested only in an immediate chat session then the user SHOULD instruct the contact's server not to store the message for later delivery using the &xep0079; protocol.

+

Note: Chat sessions may be conducted between entities who are never online at the same time. However, if the user is interested only in an immediate chat session then the user SHOULD instruct the contact's server not to store the message for later delivery 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 wants to enable all message logging (see &xep0136;) A client MUST NOT set the 'otr' field to 'true' unless it has confirmed that its server will allow it to switch off Automated Archiving (see Message Archiving). and support the &xep0071; and &xep0085; extensions during this chat session. He also requires that they are both connected securely to their servers, and asks which language she prefers amoungst those he can write. (Note: These fields are examples only; a full set of chat session negotiation parameters will be registered as described in the XMPP Registrar Considerations section of this document.)

]]> -

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. In this case, if the contact is interested only in an immediate chat session when it eventually receives the request, it SHOULD initiate a new chat 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.

+

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. In this case, if the contact is interested only in an immediate chat session when it eventually receives the request, it SHOULD initiate a new chat 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 any 'id' attribute and &THREAD; value so that the user's client can correctly track the response.

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 chat and specifies that she prefers to speak Italian with Romeo:

@@ -230,6 +230,17 @@ to='romeo@montague.net/orchard' id='init1'> ffd7076498744578d10edabfe7f4a866 + + + + http://jabber.org/protocol/chatneg + + ... + + + + + @@ -242,6 +253,17 @@ to='romeo@montague.net/orchard' id='init1'> ffd7076498744578d10edabfe7f4a866 + + + + http://jabber.org/protocol/chatneg + + ... + + + + + otr @@ -255,7 +277,18 @@ to='romeo@montague.net/orchard' id='init1'> ffd7076498744578d10edabfe7f4a866 - + + + + http://jabber.org/protocol/chatneg + + ... + + + + + + security