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

0.13

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@316 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-01-09 04:29:49 +00:00
parent 879fdf0316
commit 486cf73e70
1 changed files with 47 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

93
xep-0136.xml
View File

@ -39,9 +39,9 @@
&infiniti;
<revision>
<version>0.13</version>
<date>2006-12-13</date>
<date>2007-01-08</date>
<initials>psa/ip</initials>
<remark><p>Clarified chat session negotiation of OTR settings; defined stream feature.</p></remark>
<remark><p>Harmonized chat session negotiation of message logging settings with XEP-0155; defined stream feature.</p></remark>
</revision>
<revision>
<version>0.12</version>
@ -174,7 +174,8 @@
<p>Note: Support for the 'message' value is optional and, to conserve bandwidth and storage space, it is RECOMMENDED that client implementations do not specify the 'message' value. <note>Stream compression typically does not mitigate bandwidth and storage issues since collections SHOULD be encrypted, and since clients running in constrained runtime environments typically cannot take advantage of stream compression (no binary data, only XML, may be transfered).</note></p>
<p>Note: When archiving <em>locally</em> a client MAY save the full XML content of each &MESSAGE; element even if the Save Mode is 'body'.</p>
<p>Each &lt;default/&gt; or &lt;item/&gt; element in the response whose 'save' attribute is not set to 'false' is RECOMMENDED to also include an 'expire' attribute which indicates how many seconds after messages are archived that the server SHOULD delete them.</p>
<p>Each &lt;default/&gt; or &lt;item/&gt; element in the response MUST include an 'otr' attribute, whose value MAY be 'require', 'prefer', 'approve', 'concede', 'oppose' or 'forbid'. The client MUST be guided by the specified 'otr' attribute value when negotiating (see &xep0155;) whether or not all messages exchanged with a contact will be <link url='#otr'>Off The Record</link>. Note: If the OTR Mode is 'require' then the Save Mode MUST be 'false'.</p>
<p>Each &lt;default/&gt; or &lt;item/&gt; element in the response MUST include an 'otr' attribute, whose value MAY be 'require', 'prefer', 'approve', 'concede', 'oppose', or 'forbid'. The client MUST be guided by the specified 'logging' attribute value when negotiating (see &xep0155;) whether or not all messages exchanged with a contact will be <link url='#otr'>Off The Record</link>. (Note: An 'otr' attribute value of "require" in Message Archiving is equivalent to a 'logging' attribute value of "mustnot" in Chat Session Negotiation; for details, see the <link url='#otr-nego'>OTR Negotiation</link> section of this document.)</p>
<p>Note: If the OTR Mode is 'require' then the Save Mode MUST be 'false'.</p>
<p>The server MUST also include &lt;method/&gt; elements that reflect the user's preferences for each of the possible archiving methods. There MUST be at least three such elements for local file archiving (type 'local'), automatic archiving by the user's server (type 'auto'), and manual archiving to a server (type 'manual'). The 'use' attribute of each &lt;method/&gt; element MUST be set to 'prefer', 'concede' or 'forbid' - indicating which archiving methods the user's clients SHOULD, MAY (if it does not support any preferred method) or MUST NOT use.</p>
<p>The server MUST also include an &lt;auto/&gt; element reflecting the current <link url='#auto'>Automated Archiving</link> settings for <em>this stream</em>.</p>
<example caption='Server Returns Preferences'><![CDATA[
@ -299,104 +300,104 @@
<section1 topic='Off The Record' anchor='otr'>
<p>A user will sometimes exchange messages with contacts who prefer that their conversations are not archived by either party.</p>
<section2 topic='OTR Negotiation' anchor='otr-nego'>
<p>Any client that archives messages SHOULD support <cite>Chat Session Negotiation</cite> and its 'otr' field both to give other contacts the opportunity to indicate this preference, and to negotiate an "Off The Record" (OTR) policy that complies with its user's own <link url='#pref'>Archiving Preferences</link>.</p>
<p>Any client that archives messages SHOULD support <cite>Chat Session Negotiation</cite> and its 'logging' field both to give other contacts the opportunity to indicate this preference, and to negotiate an "Off The Record" (OTR) policy that complies with its user's own <link url='#pref'>Archiving Preferences</link>.</p>
<p>Note: A client MUST NOT propose or agree to enable OTR (i.e., disallow message logging) unless it has confirmed that its server will allow it to switch off <link url='#auto'>Automated Archiving</link>.</p>
<p>Both parties to a chat session negotiation may have OTR preferences (i.e, the initiating party or "user" and the responding party or "contact"). These preferences will interact in the ways specified below, resulting either in a successful negotiation or an unsuccessful negotiation (naturally, an unsuccessful negotiation can lead to a subsequent negotiation attempt by the user or the contact).</p>
<p>The following table shows what chat session negotiation values the initating party (i.e., the "user") should send for the 'otr' field in the initial data form for a chat session negotiation (note: 'may' means that the receiving party MAY enable message logging and 'mustnot' means that the receiving party MUST NOT enable logging).</p>
<table caption='OTR options offered by initiating party (user)'>
<p>The following table shows what chat session negotiation values the initating party (i.e., the "user") should send for the 'logging' field in the initial data form for a chat session negotiation (note: 'may' means that the receiving party MAY enable message logging and 'mustnot' means that the receiving party MUST NOT enable logging).</p>
<table caption='Chat Session Negotiation logging options offered by initiating party (user)'>
<tr>
<th>User's OTR Preference</th>
<th>Offering 'otr' Negotiation Option(s)*</th>
<th>Offering 'logging' Negotiation Option(s)*</th>
</tr>
<tr>
<td>require</td>
<td>may**</td>
<td>mustnot**</td>
</tr>
<tr>
<td>prefer</td>
<td>may,mustnot</td>
<td>mustnot,may</td>
</tr>
<tr>
<td>approve</td>
<td>may,mustnot</td>
<td>mustnot,may</td>
</tr>
<tr>
<td>concede</td>
<td>mustnot,may***</td>
<td>may,mustnot***</td>
</tr>
<tr>
<td>oppose</td>
<td>mustnot,may***</td>
<td>may,mustnot***</td>
</tr>
<tr>
<td>forbid</td>
<td>mustnot***</td>
<td>may***</td>
</tr>
</table>
<p>* In order of preference, the first value is the default</p>
<p>* In order of preference, the first value is the default.</p>
<p>** If the user receives no response it MUST NOT send any messages to the contact.</p>
<p>*** Alternatively, the user MAY decide not to <em>initiate</em> an OTR negotiation and to save messages (until the contact initiates a negotiation).</p>
<p>Note: When negotiating a chat session, the user MUST include the &lt;required/&gt; element inside the 'otr' &lt;field/&gt; element. If the user does not receive a successful response to its chat negotiation request (and if the OTR Mode is not 'require'), then it SHOULD proceed as if the contact had responded with the value of the 'otr' &lt;field/&gt; element set to 'false'.</p>
<p>The following table shows what chat session negotiation values the responding party (i.e., "contact") should send for the 'otr' field in its response to a chat session negotiation request from the user.</p>
<table caption='OTR value selected by responding party (contact)'>
<p>Note: When negotiating a chat session, the user MUST include the &lt;required/&gt; element inside the 'logging' &lt;field/&gt; element. If the user does not receive a successful response to its chat negotiation request (and if the OTR Mode is not 'require'), then it SHOULD proceed as if the contact had responded with the value of the 'logging' &lt;field/&gt; element set to 'may'.</p>
<p>The following table shows what chat session negotiation values the responding party (i.e., "contact") should send for the 'logging' field in its response to a chat session negotiation request from the user.</p>
<table caption='Chat Session Negotiation logging value selected by responding party (contact)'>
<tr>
<th>Contact's OTR Preference</th>
<th colspan='4'>Responding 'otr' Negotiation Values*</th>
<th colspan='4'>Responding 'logging' Negotiation Values*</th>
</tr>
<tr>
<th>Initiator Options --&gt;</th>
<th>may</th>
<th>may,mustnot*</th>
<th>mustnot,may*</th>
<th>mustnot</th>
<th>mustnot,may*</th>
<th>may,mustnot*</th>
<th>may</th>
</tr>
<tr>
<td>require</td>
<td>may</td>
<td>may</td>
<td>may</td>
<td>require OTR mode</td>
<td>mustnot</td>
<td>mustnot</td>
<td>mustnot</td>
<td>fail**</td>
</tr>
<tr>
<td>prefer</td>
<td>may</td>
<td>may</td>
<td>may</td>
<td>prefer OTR mode</td>
<td>mustnot</td>
<td>mustnot</td>
<td>mustnot</td>
<td>may</td>
</tr>
<tr>
<td>approve</td>
<td>may</td>
<td>may</td>
<td>approve OTR mode</td>
<td>mustnot</td>
<td>mustnot</td>
<td>may</td>
<td>may</td>
</tr>
<tr>
<td>concede</td>
<td>may</td>
<td>may</td>
<td>concede OTR mode</td>
<td>mustnot</td>
<td>mustnot</td>
<td>may</td>
<td>may</td>
</tr>
<tr>
<td>oppose</td>
<td>oppose OTR mode</td>
<td>mustnot</td>
<td>may</td>
<td>may</td>
<td>may</td>
<td>mustnot</td>
<td>mustnot</td>
<td>mustnot</td>
</tr>
<tr>
<td>forbid</td>
<td>forbid OTR mode</td>
<td>fail**</td>
<td>mustnot</td>
<td>mustnot</td>
<td>mustnot</td>
<td>may</td>
<td>may</td>
<td>may</td>
</tr>
</table>
<p>* The first value is the default.</p>
<p>** The negotiation fails and the parties MUST NOT exchange any messages; however, the recipient MAY attempt to initiate a chat session negotiation with the other party.</p>
<p>Note: If a contact does not include an 'otr' field in its initial Chat Session Negotiation request, and a user's Archiving Preferences indicate that OTR is <em>required</em>, then the client MUST refuse the request. It MAY then send its own Chat Session Negotiation request with an 'otr' field.</p>
<p>If a user's OTR preference for a contact changes during a Chat Session that has been negotiated with the contact, and if the new preference would affect the value of the 'otr' field that was previously negotiated, then the client MUST immediately renegotiate the 'otr' field according to the user's new OTR preference (or terminate the Chat Session).</p>
<p>Note: If a contact does not include a 'logging' field in its initial Chat Session Negotiation request, and a user's Archiving Preferences indicate that OTR is <em>required</em>, then the client MUST refuse the request. It MAY then send its own Chat Session Negotiation request with a 'logging' field.</p>
<p>If a user's OTR preference for a contact changes during a Chat Session that has been negotiated with the contact, and if the new preference would affect the value of the 'logging' field that was previously negotiated, then the client MUST immediately renegotiate the 'logging' field according to the user's new OTR preference (or terminate the Chat Session).</p>
</section2>
<section2 topic='Notes' anchor='otr-notes'>
<p>If a Chat Session Negotiation agreed to enable OTR then the clients MUST NOT allow messages sent in <em>either</em> direction to be archived in any way (including <link url='#manual'>Manual Archiving</link> and <link url='#auto'>Automated Archiving</link>). <note>If a client (or user) acts in bad faith then its contacts cannot prevent it archiving conversations.</note></p>
@ -1200,7 +1201,7 @@
</section1>
<section1 topic='Security Considerations' anchor='security'>
<section2 topic='Automatic Archiving Defaulting to On' anchor='security-autoon'>
<p>If automatic archiving defaults to enabled then that creates serious privacy issues for users of legacy clients that do not support this protocol, and (more seriously) for those contacts who they unwittingly mislead by agreeing to disable logging (via the 'otr' field defined in XEP-0155).</p>
<p>If automatic archiving defaults to enabled then that creates serious privacy issues for users of legacy clients that do not support this protocol, and (more seriously) for those contacts who they unwittingly mislead by agreeing to disable logging (via the 'logging' field defined in XEP-0155).</p>
<p>If a server deployment enables automatic archiving by default, then it MUST return a stream feature containing an empty &lt;default/&gt; element (see the <link url='#streamfeature'>Stream Feature</link> section of this document).</p>
</section2>
<section2 topic='Plain Text Subject' anchor='security-encrypt'>