mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-21 23:28:51 -05:00
0.14pre1
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@265 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
b947f2c31c
commit
6a71aae1ed
180
xep-0155.xml
180
xep-0155.xml
@ -22,9 +22,15 @@
|
||||
</dependencies>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>chatneg</shortname>
|
||||
<shortname>TBD</shortname>
|
||||
&ianpaterson;
|
||||
&stpeter;
|
||||
<revision>
|
||||
<version>0.14</version>
|
||||
<date>2006-12-11</date>
|
||||
<initials>psa/ip</initials>
|
||||
<remark><p>Specified state chart; added optional presence sharing; harmonized treatment of renegotiation; changed otr, xhtml-im, and chatstates fields back to boolean; per XEP-0053, specified use of provisional namespace until spec advances to Draft.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.13</version>
|
||||
<date>2006-11-27</date>
|
||||
@ -120,10 +126,49 @@
|
||||
</ul>
|
||||
<p>This proposal defines best practices for such a negotiation, re-using the protocol defined in &xep0020;.</p>
|
||||
</section1>
|
||||
<section1 topic='State Chart' anchor='statechart'>
|
||||
<p>The following figure attempts to capture the state transitions in visual form.</p>
|
||||
<code>
|
||||
o
|
||||
|
|
||||
[1]
|
||||
|
|
||||
PENDING o---------------+
|
||||
| |
|
||||
| [3]
|
||||
| |
|
||||
[2]-----[5]------|
|
||||
| |
|
||||
[4] |
|
||||
| |
|
||||
| |
|
||||
ACTIVE o |
|
||||
| |
|
||||
+------+ |
|
||||
| | |
|
||||
| [6] |
|
||||
| | |
|
||||
| [7] or [8] |
|
||||
| | |
|
||||
+------+ |
|
||||
| |
|
||||
+-----[9]-------+
|
||||
|
|
||||
o ENDED
|
||||
</code>
|
||||
<p>[1] A chat session negotiation is initiated when the user sends a message containing a data form of type "form" with an "accept" field.</p>
|
||||
<p>[2] A chat 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".</p>
|
||||
<p>[3] A chat 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".</p>
|
||||
<p>[4] A chat 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".</p>
|
||||
<p>[5] A chat 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".</p>
|
||||
<p>[6] An existing chat 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".</p>
|
||||
<p>[7] A chat 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".</p>
|
||||
<p>[8] A chat session is terminated when either party sends a message containing a data form of type "submit" with a "terminate" field whose value is "1" or "true".</p>
|
||||
</section1>
|
||||
<section1 topic='Negotiating a New Chat Session' anchor='new'>
|
||||
<section2 topic='Initiating a Chat' anchor='new-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 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 "otr", "disclosure" 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 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://www.xmpp.org/extensions/xep-0155.html#ns" and MUST contain a boolean field named "accept". &BOOLEANNOTE; The inclusion of "otr", "disclosure" 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 (see &xep0160;) 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 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 chat, any associated (decryption) keys or his identity to any third-party (see <cite>Encrypted Session Negotiation</cite>). 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'
|
||||
@ -134,13 +179,13 @@
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
<title>Open chat with Romeo?</title>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:chatneg</value>
|
||||
<value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
|
||||
</field>
|
||||
<field label='Accept this chat?' type='boolean' var='accept'>
|
||||
<value>true</value>
|
||||
<required/>
|
||||
</field>
|
||||
<field label='Off-The-Record?' type='list-single' var='otr'>
|
||||
<field label='Off-The-Record?' type='boolean' var='otr'>
|
||||
<value>0</value>
|
||||
<option label='Allow message logging'>
|
||||
<value>0</value>
|
||||
@ -163,15 +208,22 @@
|
||||
</option>
|
||||
<required/>
|
||||
</field>
|
||||
<field label='XHTML Formatting?'
|
||||
type='list-single'
|
||||
<field label='XHTML formatting?'
|
||||
type='boolean'
|
||||
var='http://jabber.org/protocol/xhtml-im'>
|
||||
<value>1</value>
|
||||
<option label='Disable'><value>0</value></option>
|
||||
<option label='Enable'><value>1</value></option>
|
||||
</field>
|
||||
<field label='Temporarily share presence?'
|
||||
type='boolean'
|
||||
var='presence'
|
||||
<value>1</value>
|
||||
<option label='Disable'><value>0</value></option>
|
||||
<option label='Enable'><value>1</value></option>
|
||||
</field>
|
||||
<field label='Chat State Notifications?'
|
||||
type='list-single'
|
||||
type='boolean'
|
||||
var='http://jabber.org/protocol/chatstates'>
|
||||
<value>1</value>
|
||||
<option label='Disable'><value>0</value></option>
|
||||
@ -205,7 +257,7 @@
|
||||
<section2 topic='Accepting a Chat' anchor='new-accept'>
|
||||
<p>If, upon reception of a user's chat session request, a contact finds that the request had been stored for later delivery, and if the contact is interested only in an <em>immediate</em> chat session, then 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 request is accepted then the 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.</p>
|
||||
<p>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.</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 chat and specifies parameters"><![CDATA[
|
||||
<message type='normal'
|
||||
@ -215,7 +267,7 @@
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE'>
|
||||
<value>urn:xmpp:chatneg</value>
|
||||
<value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
|
||||
</field>
|
||||
<field var='accept'><value>true</value></field>
|
||||
<field var='otr'><value>0</value></field>
|
||||
@ -235,7 +287,7 @@
|
||||
<p>Note: Both entities MUST assume the session is being 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>
|
||||
</section2>
|
||||
<section2 topic='Rejecting a Chat' anchor='new-reject'>
|
||||
<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='#secure-leak'>Presence Leaks</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>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='#secure-leak'>Presence Leaks</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. The data form MUST contain the FORM_TYPE field and the "accept" field set to "0" or "false". It is RECOMMENDED that the form does not contain any other fields even if the request indicated they are required. The client MAY include a reason in the &BODY; child of the &MESSAGE; stanza:</p>
|
||||
<example caption="Contact declines offer and specifies reason"><![CDATA[
|
||||
<message type='normal'
|
||||
@ -245,7 +297,7 @@
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE'>
|
||||
<value>urn:xmpp:chatneg</value>
|
||||
<value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
|
||||
</field>
|
||||
<field var='accept'><value>0</value></field>
|
||||
</x>
|
||||
@ -253,7 +305,7 @@
|
||||
<body>Sorry, can't chat now! How about tonight?</body>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>If the contact's client does not support feature negotiation or does not support the "urn:xmpp:chatneg" FORM_TYPE, it SHOULD return a &unavailable; error:</p>
|
||||
<p>If the contact's client does not support feature negotiation or does not support the "http://www.xmpp.org/extensions/xep-0155.html#ns" FORM_TYPE, it SHOULD return a &unavailable; error:</p>
|
||||
<example caption="Contact returns service unavailable error"><![CDATA[
|
||||
<message type='error'
|
||||
from='juliet@capulet.com/balcony'
|
||||
@ -262,7 +314,7 @@
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:chatneg</value>
|
||||
<value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
|
||||
</field>
|
||||
...
|
||||
</x>
|
||||
@ -281,7 +333,7 @@
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:chatneg</value>
|
||||
<value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
|
||||
</field>
|
||||
...
|
||||
</x>
|
||||
@ -303,7 +355,7 @@
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:chatneg</value>
|
||||
<value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
|
||||
</field>
|
||||
...
|
||||
</x>
|
||||
@ -317,9 +369,9 @@
|
||||
</message>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Completing or Canceling the Negotitation' anchor='new-complete'>
|
||||
<p>If the contact accepted the chat (see <link url='#new-accept'>Accepting a Chat</link>) then the user MUST either complete or cancel the session negotitation. 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. <note>See <cite>Encrypted Session Negotiation</cite> for examples of other instances where the user might find the values submitted by the contact unacceptable.</note> In any case the user's client SHOULD verify that the selected values are acceptable before completing the session negotitation - and confirming that the chat 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:</p>
|
||||
<example caption="User completes negotitation and confirms session is open"><![CDATA[
|
||||
<section2 topic='Completing or Canceling the Negotiation' anchor='new-complete'>
|
||||
<p>If the contact accepted the chat (see <link url='#new-accept'>Accepting a Chat</link>) 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. <note>See <cite>Encrypted Session Negotiation</cite> for example of other instances where the user might find the values submitted by the contact unacceptable.</note> In any case the user's client SHOULD verify that the selected values are acceptable before completing the session negotiation -- and confirming that the chat 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:</p>
|
||||
<example caption="User completes negotiation and confirms session is open"><![CDATA[
|
||||
<message type='normal'
|
||||
from='romeo@montague.net/orchard'
|
||||
to='juliet@capulet.com/balcony'>
|
||||
@ -327,7 +379,7 @@
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='result'>
|
||||
<field var='FORM_TYPE'>
|
||||
<value>urn:xmpp:chatneg</value>
|
||||
<value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
|
||||
</field>
|
||||
<field var='accept'><value>true</value></field>
|
||||
</x>
|
||||
@ -335,8 +387,8 @@
|
||||
<body>I forgot what I wanted to say!</body>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>Alternatively, if the user decides to cancel the session negotitation then the client MUST reply with a data form containing the FORM_TYPE field and the "accept" field set to "0" or "false":</p>
|
||||
<example caption="User cancels session negotitation"><![CDATA[
|
||||
<p>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":</p>
|
||||
<example caption="User cancels session negotiation"><![CDATA[
|
||||
<message type='normal'
|
||||
from='romeo@montague.net/orchard'
|
||||
to='juliet@capulet.com/balcony'>
|
||||
@ -344,7 +396,7 @@
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='result'>
|
||||
<field var='FORM_TYPE'>
|
||||
<value>urn:xmpp:chatneg</value>
|
||||
<value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
|
||||
</field>
|
||||
<field var='accept'><value>0</value></field>
|
||||
</x>
|
||||
@ -364,7 +416,7 @@
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE'>
|
||||
<value>urn:xmpp:chatneg</value>
|
||||
<value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
|
||||
</field>
|
||||
<field var='continue'><value>PDA</value></field>
|
||||
</x>
|
||||
@ -381,7 +433,7 @@
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='result'>
|
||||
<field var='FORM_TYPE'>
|
||||
<value>urn:xmpp:chatneg</value>
|
||||
<value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
|
||||
</field>
|
||||
<field var='continue'><value>PDA</value></field>
|
||||
</x>
|
||||
@ -391,7 +443,7 @@
|
||||
<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='Renegotiating a Chat' anchor='renegotiate'>
|
||||
<p>At any time during an existing chat session, either party MAY attempt to renegotiate the parameters of the session using the protocol described in <link url='#new'>Negotiating a New Chat Session</link>. The requesting party does this by sending a new &MESSAGE; stanza containing a feature negotiation form and a &THREAD; element with the <em>same</em> 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.</p>
|
||||
<p>At any time during an existing chat session, either party MAY attempt to renegotiate the parameters of the session using the protocol described in <link url='#new'>Negotiating a New Chat Session</link>. The requesting party does this by sending a new &MESSAGE; stanza containing a feature negotiation form and a &THREAD; element with the <em>same</em> 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 negotiation form.</p>
|
||||
<example caption="One party requests renegotiation"><![CDATA[
|
||||
<message type='normal'
|
||||
from='juliet@capulet.com/balcony'
|
||||
@ -400,9 +452,13 @@
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:chatneg</value>
|
||||
<value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
|
||||
</field>
|
||||
<field label='Off-The-Record?' type='list-single' var='otr'>
|
||||
<field label='Renegotiate?' type='boolean' var='renegotiate'>
|
||||
<value>1</value>
|
||||
<required/>
|
||||
</field>
|
||||
<field label='Off-The-Record?' type='boolean' var='otr'>
|
||||
<value>1</value>
|
||||
<option label='Disable all message logging'>
|
||||
<value>1</value>
|
||||
@ -414,6 +470,7 @@
|
||||
</message>
|
||||
]]></example>
|
||||
<p>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.</p>
|
||||
<p>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 "1" or "true".</p>
|
||||
<example caption="Other party accepts renegotiation and specifies parameters"><![CDATA[
|
||||
<message type='normal'
|
||||
from='romeo@montague.net/orchard'
|
||||
@ -422,16 +479,35 @@
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE'>
|
||||
<value>urn:xmpp:chatneg</value>
|
||||
<value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
|
||||
</field>
|
||||
<field var='renegotiate'><value>1</value></field>
|
||||
<field var='otr'><value>1</value></field>
|
||||
</x>
|
||||
</feature>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>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 <link url='#new-complete'>Completing or Canceling the Negotitation</link>).</p>
|
||||
<p>Note: Both parties MUST consider the renegotiation to be complete as soon as the parameter acceptance message has been sent (or received).</p>
|
||||
<p>Note: The requesting party SHOULD NOT send a renegotiation completion or cancelation message (see <link url='#new-complete'>Completing or Canceling the Negotiation</link>).</p>
|
||||
<p>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.</p>
|
||||
<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 <em>required</em> fields, it SHOULD return a ¬acceptable; error instead (see <link url='#new-reject'>Rejecting a Chat</link>). 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 <link url='#terminate'>Terminating a Chat</link>.</p>
|
||||
<p>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".</p>
|
||||
<example caption="Other party rejects renegotiation"><![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='submit'>
|
||||
<field var='FORM_TYPE'>
|
||||
<value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
|
||||
</field>
|
||||
<field var='renegotiate'><value>0</value></field>
|
||||
<field var='otr'><value>1</value></field>
|
||||
</x>
|
||||
</feature>
|
||||
</message>
|
||||
]]></example>
|
||||
<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. If the other party's client supports <em>none</em> of the options for one or more <em>required</em> fields, it SHOULD return a ¬acceptable; error (see <link url='#new-reject'>Rejecting a Chat</link>). 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 <link url='#terminate'>Terminating a Chat</link>.</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 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".</p>
|
||||
@ -443,7 +519,7 @@
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE'>
|
||||
<value>urn:xmpp:chatneg</value>
|
||||
<value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
|
||||
</field>
|
||||
<field var='terminate'><value>1</value></field>
|
||||
</x>
|
||||
@ -460,7 +536,7 @@
|
||||
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||||
<x xmlns='jabber:x:data' type='result'>
|
||||
<field var='FORM_TYPE'>
|
||||
<value>urn:xmpp:chatneg</value>
|
||||
<value>http://www.xmpp.org/extensions/xep-0155.html#ns</value>
|
||||
</field>
|
||||
<field var='terminate'><value>1</value></field>
|
||||
</x>
|
||||
@ -476,9 +552,19 @@
|
||||
<section2 topic='Persisting Sessions' anchor='impl-close'>
|
||||
<p>Chat 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 chat sessions whenever possible. For example, a client SHOULD NOT terminate chat sessions unless the user is going offline, even if its user closes a chat window.</p>
|
||||
</section2>
|
||||
<section2 topic='Sharing Presence' anchor='impl-presence'>
|
||||
<p>If so negotiated via the 'presence' field, two parties who do not have subscriptions to each other's presence (as specified in <cite>XMPP-IM</cite>) may share presence by sending directed presence after the session is negotiated.</p>
|
||||
<example caption="User sends directed presence to contact"><![CDATA[
|
||||
<presence from='romeo@montague.net/orchard' to='juliet@capulet.com/balcony'/>
|
||||
]]></example>
|
||||
<example caption="Contact sends directed presence to user"><![CDATA[
|
||||
<presence from='juliet@capulet.com/balcony' to='romeo@montague.net/orchard'/>
|
||||
]]></example>
|
||||
<p>In accordance with the rules specified in <cite>XMPP-IM</cite>, sharing presence enables one party's server to send unavailable presence to the other party if the sending party goes offline for any reason.</p>
|
||||
</section2>
|
||||
<section2 topic='Unavailable Presence' anchor='impl-unavail'>
|
||||
<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>
|
||||
<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>
|
||||
<section2 topic='Mapping to SIP' anchor='impl-sip'>
|
||||
<p>When mapping instant messaging flows to SIP, implementations SHOULD adhere to &xmppsimple;.</p>
|
||||
@ -496,7 +582,8 @@
|
||||
<p>If a contact accepts a user's chat session negotiation request or returns an error to the user, the user will effectively discover the presence of the contact's resource. Due care must therefore be exercised in determining whether to accept the request or return an error. For examples, the contact's client SHOULD NOT <em>automatically</em> (i.e. without first asking the contact) either accept the user's request or return an error to the user unless the user is subscribing to the contact's presence (and the contact's presence is not currently "invisible" to the user). Note: There should be no need for the contact's client to consult the contact's block list, since if the user is on the list then the contact would not receive any request messages from the user anyway.</p>
|
||||
</section2>
|
||||
<section2 topic='Localization' anchor='secure-local'>
|
||||
<p>If a client is configured to show a request <form/> to a human user instead of responding automatically, the client 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 localize the form then a 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>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.</p>
|
||||
<p>Note: If a client fails to localize the form, a malicious contact might, for example, 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>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
@ -504,10 +591,10 @@
|
||||
</section1>
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<section2 topic='Service Discovery Features' anchor='registrar-features'>
|
||||
<p>The ®ISTRAR; shall include 'urn:xmpp:chatneg' in its registry of Service Discovery features.</p>
|
||||
<p>The ®ISTRAR; shall include 'http://www.xmpp.org/extensions/xep-0155.html#ns' in its registry of Service Discovery features.</p>
|
||||
<code caption='Registry Submission'><![CDATA[
|
||||
<var>
|
||||
<name>urn:xmpp:chatneg</name>
|
||||
<name>http://www.xmpp.org/extensions/xep-0155.html#ns</name>
|
||||
<desc>Support for Chat Session Negotiation and its FORM_TYPE</desc>
|
||||
<doc>XEP-0155</doc>
|
||||
</var>
|
||||
@ -517,7 +604,7 @@
|
||||
<p>&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. The following fields shall be registered for use in Chat Session Negotiation:</p>
|
||||
<code caption='Registry Submission'><![CDATA[
|
||||
<form_type>
|
||||
<name>urn:xmpp:chatneg</name>
|
||||
<name>http://www.xmpp.org/extensions/xep-0155.html#ns</name>
|
||||
<doc>XEP-0155</doc>
|
||||
<desc>
|
||||
Forms enabling negotation of a one-to-one
|
||||
@ -549,18 +636,18 @@
|
||||
</field>
|
||||
<field
|
||||
var='http://jabber.org/protocol/chatstates'
|
||||
type='list-single'
|
||||
label='Whether must send Chat State Notifications per XEP-0085'>
|
||||
<option label='May Send'>
|
||||
type='boolean'
|
||||
label='Whether may send Chat State Notifications per XEP-0085'>
|
||||
<option label='Must Not Send'>
|
||||
<value>0</value>
|
||||
</option>
|
||||
<option label='Must Send'>
|
||||
<option label='May Send'>
|
||||
<value>1</value>
|
||||
</option>
|
||||
</field>
|
||||
<field
|
||||
var='http://jabber.org/protocol/xhtml-im'
|
||||
type='list-single'
|
||||
type='boolean'
|
||||
label='Whether allowed to use XHTML-IM formatting per XEP-0071'>
|
||||
<option label='Must Not Send'>
|
||||
<value>0</value>
|
||||
@ -577,14 +664,14 @@
|
||||
conforms to RFC 4646 and the IANA registry)'/>
|
||||
<field
|
||||
var='otr'
|
||||
type='list-single'
|
||||
type='boolean'
|
||||
label='Off-The-Record'>
|
||||
<option label='May log messages'>
|
||||
<value>0</value>
|
||||
</option>
|
||||
<option label='Must disable absolutely all message
|
||||
logging including automatic archiving
|
||||
- see XEP-0136'>
|
||||
-- see XEP-0136'>
|
||||
<value>1</value>
|
||||
</option>
|
||||
</field>
|
||||
@ -616,4 +703,7 @@
|
||||
<section1 topic='Acknowledgements' anchor='ack'>
|
||||
<p>Thanks to Thomas Charron and Jean-Louis Seguineau for their feedback.</p>
|
||||
</section1>
|
||||
<section1 topic='Namespace' anchor='ns'>
|
||||
<p>Until this specification advances to a status of Draft, its associated namespace shall be "http://www.xmpp.org/extensions/xep-0155.html#ns"; upon advancement of this specification, the XMPP Registrar shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.</p>
|
||||
</section1>
|
||||
</xep>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user