mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-21 23:28:51 -05:00
0.14
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@296 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
4845600b59
commit
93ac525e51
49
xep-0155.xml
49
xep-0155.xml
@ -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 <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>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 "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 <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>
|
||||
<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 <title/> 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 ®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[
|
||||
@ -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>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user