moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-28 04:02:20 -05:00
Code Issues Releases Wiki Activity

0.11 RC1 removed reason field and clarified handling of required fields

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@159 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Ian Paterson 2006-11-02 00:27:11 +00:00
parent ce9daa3e60
commit 31a6a45594
1 changed files with 18 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
xep-0155.xml
View File

@ -7,7 +7,7 @@
<xep>
<header>
<title>Chat Session Negotiation</title>
<abstract>This document specifies a feature negotiation profile for initiating a one-to-one XMPP chat session.</abstract>
<abstract>This document specifies a feature negotiation profile for initiating a one-to-one chat session.</abstract>
&LEGALNOTICE;
<number>0155</number>
<status>Experimental</status>
@ -25,6 +25,12 @@
<shortname>chatneg</shortname>
&stpeter;
&ianpaterson;
<revision>
<version>0.11</version>
<date>2006-11-02</date>
<initials>ip</initials>
<remark><p>Removed reason field; clarified handling of required fields</p></remark>
</revision>
<revision>
<version>0.10</version>
<date>2006-10-31</date>
@ -130,6 +136,7 @@
<option label='Disable all message logging'>
<value>true</value>
</option>
<required/>
</field>
<field label='XHTML Formatting?'
type='list-single'
@ -152,6 +159,7 @@
<option label='Both parties must be securely connected to their servers'>
<value>c2s</value>
</option>
<required/>
</field>
<field label='Primary written language of the chat'
type='list-single'
@ -169,8 +177,8 @@
]]></example>
<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 &lt;title/&gt; element and of all label attributes of the &lt;field/&gt; and &lt;option/&gt; 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 &lt;title/&gt; to mislead the user regarding the identity of the contact.</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>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'
@ -198,7 +206,7 @@
]]></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>
<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'
from='juliet@capulet.com/balcony'
@ -210,11 +218,9 @@
<value>http://jabber.org/protocol/chatneg</value>
</field>
<field var='accept'><value>0</value></field>
<field var='reason'>
<value>Sorry, can't chat now! How about tonight?</value>
</field>
</x>
</feature>
<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 "http://jabber.org/protocol/chatneg" FORM_TYPE, it SHOULD return a &unavailable; error:</p>
@ -316,9 +322,7 @@
<option label='Disable all message logging'>
<value>true</value>
</option>
</field>
<field label='Reason' type='text-single' var='reason'>
<value>Lets keep this private!</value>
<required/>
</field>
</x>
</feature>
@ -378,8 +382,8 @@
<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 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[
<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>
<example caption="One party terminates chat"><![CDATA[
<message type='normal'
from='juliet@capulet.com/balcony'
to='romeo@montague.net/orchard'>
@ -390,13 +394,12 @@
<value>http://jabber.org/protocol/chatneg</value>
</field>
<field var='terminate'><value>1</value></field>
<field var='reason'><value>Gotta go!</value></field>
</x>
</feature>
</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 &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", 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'
@ -493,9 +496,7 @@
<field
var='language'
type='list-single'
label='Primary written language of the chat (each
value appears in order of preference and
conforms to RFC 4646 and the IANA registry)'/>
label='Primary written language of the chat (each value appears in order of preference and conforms to RFC 4646 and the IANA registry)'/>
<field
var='otr'
type='list-single'
@ -503,16 +504,10 @@
<option label='Allow message logging'>
<value>false</value>
</option>
<option label='Disable absolutely all message logging
including automatic archiving - see
XEP-0136'>
<option label='Disable absolutely all message logging including automatic archiving - see XEP-0136'>
<value>true</value>
</option>
</field>
<field
var='reason'
type='text-single'
label='A reason for chatting (or not)'/>
<field
var='security'
type='list-single'