moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

1.2pre2

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1450 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-12-06 18:09:53 +00:00
parent 1683feaa92
commit eb36e9ffa0
1 changed files with 77 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

81
xep-0155.xml
View File

@ -26,10 +26,10 @@
&ianpaterson;
&stpeter;
<revision>
<version>1.2pre1</version>
<date>in progress, last updated 2007-11-13</date>
<version>1.2pre2</version>
<date>in progress, last updated 2007-12-06</date>
<initials>psa</initials>
<remark><p>Specified that IM message bodies must not be included.</p></remark>
<remark><p>Specified that IM message bodies must not be included; added boolean multisession field to explicitly determine whether multiple simultaneous sessions are allowed between the full JIDs of the parties.</p></remark>
</revision>
<revision>
<version>1.1</version>
@ -197,7 +197,8 @@ PENDING o---------------+
<section2 topic='Initiating a Session' anchor='new-initiate'>
<p>In order to initiate a negotiated 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 "urn:xmpp:ssn" 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: 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> 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 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 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 session, 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 stanza 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 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 session, 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.</p>
<p>Note: These fields are examples only. For definitions of these fields, refer to the <link url='#parameters'>Defined Parameters</link> section of this document.</p>
<example caption="User requests session"><![CDATA[
<message type='normal'
from='romeo@montague.net/orchard'
@ -236,6 +237,9 @@ PENDING o---------------+
</option>
<required/>
</field>
<field label='Allow multiple sessions?' type='boolean' var='multisession'>
<value>false</value>
</field>
<field label='XHTML formatting'
type='list-single'
var='http://jabber.org/protocol/xhtml-im'>
@ -575,6 +579,71 @@ PENDING o---------------+
</message>
]]></example>
</section1>
<section1 topic='Defined Parameters' anchor='parameters'>
<p>This section defines the parameters for stanza session negotiation parameters and whether they must, should, or may be included in the initial negotiation form. Additional parameters may be registered as described in the <link url='#registrar'>XMPP Registrar Considerations</link> section of this document.</p>
<table caption='Form Fields'>
<tr>
<th>Name</th>
<th>Definition</th>
<th>Inclusion</th>
</tr>
<tr>
<td>accept</td>
<td>Whether the receiving party wishes to accept the invitation</td>
<td>MUST</td>
</tr>
<tr>
<td>continue</td>
<td>Another resource with which to continue the session</td>
<td>N/A (used to move a session)</td>
</tr>
<tr>
<td>disclosure</td>
<td>Whether and to what extent the content, keys, and identities can be disclosed to third parties; the options are "never" (disclosure must never occur), "disabled" (only disclosure required by law shall occur), and "enabled" (disclosure may occur)</td>
<td>SHOULD</td>
</tr>
<tr>
<td>http://jabber.org/protocol/chatstates</td>
<td>Whether the parties may exchange Chat State Notifications per XEP-0085; the options are "may" and "mustnot"</td>
<td>OPTIONAL</td>
</tr>
<tr>
<td>http://jabber.org/protocol/xhtml-im</td>
<td>Whether the parties may exchange XHTML formatting per XEP-0071; the options are "may" and "must not"</td>
<td>OPTIONAL</td>
</tr>
<tr>
<td>language</td>
<td>The preferred natural language(s) for information exchange, using language codes defined in accordance with &rfc4646;</td>
<td>SHOULD</td>
</tr>
<tr>
<td>logging</td>
<td>Whether the parties may log messages; the options are "may" and "mustnot"</td>
<td>SHOULD</td>
</tr>
<tr>
<td>multisession</td>
<td>Whether to allow multiple simultaneous sessions between the full JIDs of the parties; this is a boolean variable that defaults to false</td>
<td>SHOULD</td>
</tr>
<tr>
<td>renegotiate</td>
<td>Whether the receiving party wishes to renegotiate the session</td>
<td>N/A (used to renegotiate a session)</td>
</tr>
<tr>
<td>security</td>
<td>The minimum security level for secure connections between the parties; the options are "none" (a secure connection is not required), "c2s" (both parties must be securely connected to their servers), and "e2e" (both parties must be securely connected to each other, for example via Encrypted Sessions)</td>
<td>SHOULD</td>
</tr>
<tr>
<td>terminate</td>
<td>Whether the receiving party wishes to terminate the session</td>
<td>N/A (used to terminate a session)</td>
</tr>
</table>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<section2 topic='Auto Accept or Reject' anchor='impl-auto'>
<p>A client MAY require a human user to approve each stanza session negotiation request, however it is RECOMMENDED that it accepts or rejects automatically as many requests as possible, based on a set of user-configurable policies (see <link url='#secure-leak'>Presence Leaks</link>).</p>
@ -710,6 +779,10 @@ PENDING o---------------+
<value>mustnot</value>
</option>
</field>
<field
var='multisession'
type='boolean'
label='Whether to allow multiple simultaneous sessions between the parties'/>
<field
var='renegotiate'
type='boolean'