git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@296 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-12-22 02:33:41 +00:00
parent 4845600b59
commit 93ac525e51
1 changed files with 25 additions and 24 deletions

View File

@ -22,14 +22,14 @@
</dependencies>
<supersedes/>
<supersededby/>
<shortname>TBD</shortname>
<shortname>TO BE ASSIGNED</shortname>
&ianpaterson;
&stpeter;
<revision>
<version>0.14</version>
<date>2006-12-12</date>
<date>2006-12-21</date>
<initials>psa/ip</initials>
<remark><p>Specified state chart; added optional presence sharing; harmonized treatment of renegotiation; per XEP-0053, specified use of provisional namespace until spec advances to Draft.</p></remark>
<remark><p>Specified state chart; added optional presence sharing; renamed otr field to logging; harmonized treatment of renegotiation; per XEP-0053, specified use of provisional namespace until spec advances to Draft.</p></remark>
</revision>
<revision>
<version>0.13</version>
@ -168,17 +168,18 @@ PENDING o---------------+
<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>[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 "1" or "true".</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>
<p>[8] A chat 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.</p>
<p>[9] 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 Session' 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 &lt;feature/&gt; 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>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 &lt;feature/&gt; 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 "logging", "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>
<p>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;) <note>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 <cite>Message Archiving</cite>).</note>, whether she wants to temporarily share presence for this session (see the <link url='#impl-presence'>Sharing Presence</link> section of this document), and whether she wants to 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 amongst 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'
@ -194,7 +195,7 @@ PENDING o---------------+
<value>true</value>
<required/>
</field>
<field label='Message logging' type='list-single' var='otr'>
<field label='Message logging' type='list-single' var='logging'>
<value>mustnot</value>
<option label='Allow message logging'>
<value>may</value>
@ -279,13 +280,13 @@ PENDING o---------------+
<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>
<field var='disclosure'><value>never</value></field>
<field var='logging'><value>mustnot</value></field>
<field var='disclosure'><value>mustnot</value></field>
<field var='http://jabber.org/protocol/xhtml-im'>
<value>0</value>
<value>may</value>
</field>
<field var='http://jabber.org/protocol/chatstates'>
<value>0</value>
<value>may</value>
</field>
<field var='security'><value>c2s</value></field>
<field var='language'><value>it</value></field>
@ -350,7 +351,7 @@ PENDING o---------------+
<error code='501' type='cancel'>
<feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<field var='otr'/>
<field var='logging'/>
</feature>
</error>
</message>
@ -466,10 +467,10 @@ PENDING o---------------+
<value>1</value>
<required/>
</field>
<field label='Message logging' type='list-single' var='otr'>
<field label='Message logging' type='list-single' var='logging'>
<value>mustnot</value>
<option label='Disallow all message logging'>
<value>mustnot</value>
<value>may</value>
</option>
<required/>
</field>
@ -490,7 +491,7 @@ PENDING o---------------+
<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>
<field var='logging'><value>may</value></field>
</x>
</feature>
</message>
@ -510,7 +511,7 @@ PENDING o---------------+
<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>
<field var='logging'><value>may</value></field>
</x>
</feature>
</message>
@ -590,13 +591,16 @@ PENDING o---------------+
</section2>
<section2 topic='Localization' anchor='secure-local'>
<p>If a client is configured to show a request &lt;form/&gt; to a human user instead of responding automatically, it SHOULD replace the content of the &lt;title/&gt; element and of all label attributes of the known and registered &lt;field/&gt; and &lt;option/&gt; 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 &lt;title/&gt; to mislead the user regarding the identity of the contact.</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 'logging' fields, or use the &lt;title/&gt; to mislead the user regarding the identity of the contact.</p>
</section2>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='ns'>
<p>Until this specification advances to a status of Draft, its associated namespace (as used in the negotiation FORM_TYPE) 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>
</section2>
<section2 topic='Service Discovery Features' anchor='registrar-features'>
<p>The &REGISTRAR; shall include 'http://www.xmpp.org/extensions/xep-0155.html#ns' in its registry of Service Discovery features.</p>
<code caption='Registry Submission'><![CDATA[
@ -670,14 +674,14 @@ PENDING o---------------+
value appears in order of preference and
conforms to RFC 4646 and the IANA registry)'/>
<field
var='otr'
var='logging'
type='list-single'
label='Whether allowed to log messages (i.e.,
whether Off-The-Record mode is required)'>
<option label='May Log Messages'>
<option label='Allow Message Logging'>
<value>may</value>
</option>
<option label='Must Not Log Messages (i.e., must
<option label='Disallow All Message Logging (i.e., must
disable absolutely all message
logging including automatic archiving
-- see XEP-0136'>
@ -716,7 +720,4 @@ PENDING o---------------+
<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>