mirror of https://github.com/moparisthebest/xeps
0.10 RC6 triple handshake, removed id attributes, etc
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@135 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Ian Paterson
parent
6754343f23
commit
4d512163d2
110
xep-0155.xml
110
xep-0155.xml
|
|
@ -27,9 +27,9 @@
|
|||
&ianpaterson;
|
||||
<revision>
|
||||
<version>0.10</version>
|
||||
<date>2006-10-23</date>
|
||||
<date>2006-10-31</date>
|
||||
<initials>ip</initials>
|
||||
<remark><p>Defined handling of offline requests; specified localization of the title element and all labels; changed syntax of list of unacceptable fields; removed reason field from some examples; minor clarifications.</p></remark>
|
||||
<remark><p>Defined handling of offline requests; specified localization of the title element and all labels; changed syntax of list of unacceptable fields; removed reason field from some examples; added confirmation message to initial negotiation; clarified the initial participating resources; removed id attributes.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.9</version>
|
||||
|
|
@ -104,14 +104,13 @@
|
|||
</section1>
|
||||
<section1 topic='Use Cases' anchor='usecases'>
|
||||
<section2 topic='Initiating a Chat' anchor='initiate'>
|
||||
<p>In order to initiate a negotiated chat session, the initiating party ("user") sends a &MESSAGE; <note>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).</note> 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.</p>
|
||||
<p>In order to initiate a negotiated chat session, the initiating party ("user") sends a &MESSAGE; <note>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).</note> 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 "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.</p>
|
||||
<p>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 <em>immediate</em> chat session then the user SHOULD instruct the contact's server not to store the message for later delivery using the &xep0079; protocol.</p>
|
||||
<p>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;) <note>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 <cite>Message Archiving</cite>).</note> 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 <link url='#registrar'>XMPP Registrar Considerations</link> section of this document.)</p>
|
||||
<example caption="User requests chat session"><![CDATA[
|
||||
<message type='normal'
|
||||
from='romeo@montague.net/orchard'
|
||||
to='juliet@capulet.com'
|
||||
id='init1'>
|
||||
to='juliet@capulet.com'>
|
||||
<thread>ffd7076498744578d10edabfe7f4a866</thread>
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
|
|
@ -168,16 +167,15 @@
|
|||
</amp>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>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 <cite>Advanced Message Processing</cite> 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 <em>immediate</em> 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.</p>
|
||||
<p>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.</p>
|
||||
<p>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 <cite>Advanced Message Processing</cite> 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 <em>immediate</em> 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.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>If the contact's client is configured to show the form to the client instead of responding automatically it SHOULD replace the content of the <title/> element and of all label attributes of the <field/> and <option/> elements with it's own localised versions before showing the form to the client - even if the form already appears to be in the correct language. Note: If a client fails to localise the form then an malicious contact might, for examples, either switch the labels on the 'security' and 'otr' fields, or use the <title/> to mislead the user regarding the identity of the contact.</p>
|
||||
<p>In the example below we assume that Juliet accepts the chat and specifies that she prefers to speak Italian with Romeo:</p>
|
||||
<example caption="Contact accepts offer and specifies parameters"><![CDATA[
|
||||
<example caption="Contact accepts chat and specifies parameters"><![CDATA[
|
||||
<message type='normal'
|
||||
from='juliet@capulet.com/balcony'
|
||||
to='romeo@montague.net/orchard'
|
||||
id='init1'>
|
||||
to='romeo@montague.net/orchard'>
|
||||
<thread>ffd7076498744578d10edabfe7f4a866</thread>
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
|
|
@ -198,13 +196,13 @@
|
|||
</feature>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>Note: Both entities MUST assume the session has been established with the resource of the contact that sends the reply, even if the user sent its request to a different resource of the contact.</p>
|
||||
<p>If the contact does not want to reveal presence to the user for whatever reason then the contact's client SHOULD return no response or error (see <link url='#security'>Security Considerations</link>). Also, if the contact is using a legacy client then it MAY not support returning any response or error. In both these cases the user MAY, proceed to send stanzas to the contact outside the context of a negotiated chat session.</p>
|
||||
<p>However, if the contact simply prefers not to chat then the client SHOULD decline the invitation:</p>
|
||||
<example caption="Contact declines offer and specifies reason"><![CDATA[
|
||||
<message type='normal'
|
||||
from='juliet@capulet.com/balcony'
|
||||
to='romeo@montague.net/orchard'
|
||||
id='init1'>
|
||||
to='romeo@montague.net/orchard'>
|
||||
<thread>ffd7076498744578d10edabfe7f4a866</thread>
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
|
|
@ -223,8 +221,7 @@
|
|||
<example caption="Contact returns service unavailable error"><![CDATA[
|
||||
<message type='error'
|
||||
from='juliet@capulet.com/balcony'
|
||||
to='romeo@montague.net/orchard'
|
||||
id='init1'>
|
||||
to='romeo@montague.net/orchard'>
|
||||
<thread>ffd7076498744578d10edabfe7f4a866</thread>
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
|
|
@ -243,8 +240,7 @@
|
|||
<example caption="Contact returns feature not implemented error"><![CDATA[
|
||||
<message type='error'
|
||||
from='juliet@capulet.com/balcony'
|
||||
to='romeo@montague.net/orchard'
|
||||
id='init1'>
|
||||
to='romeo@montague.net/orchard'>
|
||||
<thread>ffd7076498744578d10edabfe7f4a866</thread>
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
|
|
@ -266,8 +262,7 @@
|
|||
<example caption="Contact returns options not acceptable error"><![CDATA[
|
||||
<message type='error'
|
||||
from='juliet@capulet.com/balcony'
|
||||
to='romeo@montague.net/orchard'
|
||||
id='init1'>
|
||||
to='romeo@montague.net/orchard'>
|
||||
<thread>ffd7076498744578d10edabfe7f4a866</thread>
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
|
|
@ -283,6 +278,23 @@
|
|||
<field var='security'/>
|
||||
</feature>
|
||||
</error>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>Finally, if the contact accepted the chat then the user SHOULD reply with a result form containing an 'accept' field set to 'true' (or '1') to confirm to the contact that the combination of values it submitted was acceptable, and that the chat session is open. <note>See <cite>Encrypted Sessions</cite> for examples where the user might find the values submitted by the contact unacceptable.</note> The user MAY include other content (e.g., a &BODY; element) in the confirmation stanza:</p>
|
||||
<example caption="User confirms session is open"><![CDATA[
|
||||
<message type='normal'
|
||||
from='romeo@montague.net/orchard'
|
||||
to='juliet@capulet.com/balcony'>
|
||||
<thread>ffd7076498744578d10edabfe7f4a866</thread>
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='result'>
|
||||
<field var='FORM_TYPE'>
|
||||
<value>http://jabber.org/protocol/chatneg</value>
|
||||
</field>
|
||||
<field var='accept'><value>1</value></field>
|
||||
</x>
|
||||
</feature>
|
||||
<body>I forgot what I wanted to say!</body>
|
||||
</message>
|
||||
]]></example>
|
||||
</section2>
|
||||
|
|
@ -292,8 +304,7 @@
|
|||
<example caption="One party requests renegotiation"><![CDATA[
|
||||
<message type='normal'
|
||||
from='juliet@capulet.com/balcony'
|
||||
to='romeo@montague.net/orchard'
|
||||
id='reneg1'>
|
||||
to='romeo@montague.net/orchard'>
|
||||
<thread>ffd7076498744578d10edabfe7f4a866</thread>
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
|
|
@ -316,8 +327,7 @@
|
|||
<example caption="Other party accepts offer and specifies parameters"><![CDATA[
|
||||
<message type='normal'
|
||||
from='romeo@montague.net/orchard'
|
||||
to='juliet@capulet.com/balcony'
|
||||
id='reneg1'>
|
||||
to='juliet@capulet.com/balcony'>
|
||||
<thread>ffd7076498744578d10edabfe7f4a866</thread>
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
|
|
@ -332,32 +342,11 @@
|
|||
<p>If the other party's client does not support one or more of the <em>required</em> features, it SHOULD return a &feature; error instead, while if it supports <em>none</em> of the options for one or more fields, it SHOULD return a ¬acceptable; error instead (see <link url='#initiate'>Initiating a Chat</link>). In either of these cases the existing negotiated chat session parameters are maintained. Either party MAY then terminate the chat session as specified in the section <link url='#terminate'>Terminating a Chat</link>.</p>
|
||||
</section2>
|
||||
<section2 topic='Switching Resources' anchor='switch'>
|
||||
<p>Either party MAY use chat renegotiation to attempt to continue the session using another of its resources. The requesting party does this by sending a feature renegotiation form with a "continue" field containing the value of the new resource:</p>
|
||||
<p>Either party MAY ask to continue the session using another of its resources. The requesting party does this by submitting a form with a "continue" field containing the value of the new resource:</p>
|
||||
<example caption="One party asks to switch session to another of its resources"><![CDATA[
|
||||
<message type='normal'
|
||||
from='juliet@capulet.com/balcony'
|
||||
to='romeo@montague.net/orchard'
|
||||
id='reneg2'>
|
||||
<thread>ffd7076498744578d10edabfe7f4a866</thread>
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>http://jabber.org/protocol/chatneg</value>
|
||||
</field>
|
||||
<field label='New client name' type='text-single' var='continue'>
|
||||
<value>PDA</value>
|
||||
</field>
|
||||
</x>
|
||||
</feature>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>The requesting party SHOULD NOT send stanzas within the session from either resource until the other party has accepted or rejected (with a &feature; error) the switch to the new resource.</p>
|
||||
<p>The other party SHOULD accept the switch since the requesting party might otherwise be unable to continue the session:</p>
|
||||
<example caption="Other party accepts switch"><![CDATA[
|
||||
<message type='normal'
|
||||
from='romeo@montague.net/orchard'
|
||||
to='juliet@capulet.com/balcony'
|
||||
id='reneg2'>
|
||||
to='romeo@montague.net/orchard'>
|
||||
<thread>ffd7076498744578d10edabfe7f4a866</thread>
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
|
|
@ -367,17 +356,33 @@
|
|||
<field var='continue'><value>PDA</value></field>
|
||||
</x>
|
||||
</feature>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>The requesting party SHOULD NOT send stanzas within the session from either resource until the other party has accepted or rejected (with a &feature; error) the switch to the new resource.</p>
|
||||
<p>The other party SHOULD accept the switch since the requesting party might otherwise be unable to continue the session:</p>
|
||||
<example caption="Other party accepts switch"><![CDATA[
|
||||
<message type='normal'
|
||||
from='romeo@montague.net/orchard'
|
||||
to='juliet@capulet.com/balcony'>
|
||||
<thread>ffd7076498744578d10edabfe7f4a866</thread>
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='result'>
|
||||
<field var='FORM_TYPE'>
|
||||
<value>http://jabber.org/protocol/chatneg</value>
|
||||
</field>
|
||||
<field var='continue'><value>PDA</value></field>
|
||||
</x>
|
||||
</feature>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>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.</p>
|
||||
</section2>
|
||||
<section2 topic='Terminating a Chat' anchor='terminate'>
|
||||
<p>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 SHOULD possess an 'id' attribute and 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" and MAY also contain a "reason" field.</p>
|
||||
<p>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" and MAY also contain a "reason" field.</p>
|
||||
<example caption="One party terminates chat and specifies reason"><![CDATA[
|
||||
<message type='normal'
|
||||
from='juliet@capulet.com/balcony'
|
||||
to='romeo@montague.net/orchard'
|
||||
id='term1'>
|
||||
to='romeo@montague.net/orchard'>
|
||||
<thread>ffd7076498744578d10edabfe7f4a866</thread>
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
|
|
@ -391,12 +396,11 @@
|
|||
</message>
|
||||
]]></example>
|
||||
<p>Both parties MUST then consider the chat session to be ended.</p>
|
||||
<p>The other party's client MAY explicitly acknowledge the termination of the chat by sending a &MESSAGE; containing a data form of type "result", with no "reason" field and the value of the "terminate" field set to "1" or "true". The client MUST mirror the 'id' attribute and &THREAD; value it received.</p>
|
||||
<p>The other party's client MAY explicitly acknowledge the termination of the chat by sending a &MESSAGE; containing a data form of type "result", with no "reason" field and the value of the "terminate" field set to "1" or "true". The client MUST mirror the &THREAD; value it received.</p>
|
||||
<example caption="Other party acknowledges chat termination"><![CDATA[
|
||||
<message type='normal'
|
||||
from='romeo@montague.net/orchard'
|
||||
to='juliet@capulet.com/balcony'
|
||||
id='term1'>
|
||||
to='juliet@capulet.com/balcony'>
|
||||
<thread>ffd7076498744578d10edabfe7f4a866</thread>
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='result'>
|
||||
|
|
@ -425,8 +429,8 @@
|
|||
<p>A client MAY require a human user to approve each chat session negotiation request or MAY auto-accept and auto-reject requests based on some user-configurable policy (see <link url='#security'>Security Considerations</link>).</p>
|
||||
</section2>
|
||||
<section2 topic='Unavailable Presence' anchor='impl-unavail'>
|
||||
<p>If a party receives XMPP presence of type "unavailable" from the full JID (&FULLJID;) of the other party (i.e., the resource with which it has had an active session) during a chat session, the receiving party MAY assume that the other client will still be able to continue the session (perhaps it simply became "invisible", or it is persisting the state of the negotiated chat until it reconnects and receives "offline" messages).</p>
|
||||
<p>However, if the receiving party assumes that the other client will <em>not</em> be able to continue the session, then it MUST explicitly terminate the session (see <link url='#terminate'>Terminating a Chat</link>) - since its assumption could be incorrect. If after terminating the session the receiving party later receives presence of type "available" from that same resource or another resource associated with the other party and the receiving party desires to restart the chat session, then it MUST initiate a new chat session (including a newly-generated ThreadID) with the other party. It MUST NOT renegotiate parameters for the terminated session. (Note: This is consistent with the handling of chat states as specified in <cite>XEP-0085</cite>.)</p>
|
||||
<p>If a party receives an XMPP presence stanza of type "unavailable" from the full JID (&FULLJID;) of the other party (i.e., the resource with which it has had an active session) during a chat session, the receiving party SHOULD assume that the other client will still be able to continue the session (perhaps it simply became "invisible", or it is persisting the state of the negotiated chat until it reconnects and receives "offline" messages).</p>
|
||||
<p>However, the receiving party MAY assume that the other client will <em>not</em> be able to continue the session. <note>In general, if a party is not subscribing to the other party's presence then it will never assume the other party is is unable to continue a session.</note> In that case it MUST explicitly terminate the session (see <link url='#terminate'>Terminating a Chat</link>) - since its assumption could be incorrect. If after terminating the session the receiving party later receives presence of type "available" from that same resource or another resource associated with the other party and the receiving party desires to restart the chat session, then it MUST initiate a new chat session (including a newly-generated ThreadID) with the other party. It MUST NOT renegotiate parameters for the terminated session. (Note: This is consistent with the handling of chat states as specified in <cite>XEP-0085</cite>.)</p>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
|
|
|
|||
Loading…
Reference in New Issue