From 486cf73e70f0fcd53f3b7d477dc86b736852ecaf Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Tue, 9 Jan 2007 04:29:49 +0000 Subject: [PATCH] 0.13 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@316 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0136.xml | 93 ++++++++++++++++++++++++++-------------------------- 1 file changed, 47 insertions(+), 46 deletions(-) diff --git a/xep-0136.xml b/xep-0136.xml index 79497aa3c..bd6e648c6 100644 --- a/xep-0136.xml +++ b/xep-0136.xml @@ -39,9 +39,9 @@ &infiniti; 0.13 - 2006-12-13 + 2007-01-08 psa/ip -

Clarified chat session negotiation of OTR settings; defined stream feature.

 +

Harmonized chat session negotiation of message logging settings with XEP-0155; defined stream feature.

 0.12 @@ -174,7 +174,8 @@

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. 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: When archiving locally a client MAY save the full XML content of each &MESSAGE; element even if the Save Mode is 'body'.

Each <default/> or <item/> 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.

-

Each <default/> or <item/> 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 Off The Record. Note: If the OTR Mode is 'require' then the Save Mode MUST be 'false'.

+

Each <default/> or <item/> 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 Off The Record. (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 OTR Negotiation section of this document.)

+

Note: If the OTR Mode is 'require' then the Save Mode MUST be 'false'.

The server MUST also include <method/> 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 <method/> 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.

The server MUST also include an <auto/> element reflecting the current Automated Archiving settings for this stream.

A user will sometimes exchange messages with contacts who prefer that their conversations are not archived by either party.

-

Any client that archives messages SHOULD support Chat Session Negotiation 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 Archiving Preferences.

+

Any client that archives messages SHOULD support Chat Session Negotiation 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 Archiving Preferences.

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 Automated Archiving.

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).

-

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).

- +

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).

+
- + - + - + - + - + - + - +
User's OTR PreferenceOffering 'otr' Negotiation Option(s)*Offering 'logging' Negotiation Option(s)*
requiremay**mustnot**
prefermay,mustnotmustnot,may
approvemay,mustnotmustnot,may
concedemustnot,may***may,mustnot***
opposemustnot,may***may,mustnot***
forbidmustnot***may***
-

* In order of preference, the first value is the default

+

* In order of preference, the first value is the default.

** If the user receives no response it MUST NOT send any messages to the contact.

*** Alternatively, the user MAY decide not to initiate an OTR negotiation and to save messages (until the contact initiates a negotiation).

-

Note: When negotiating a chat session, the user MUST include the <required/> element inside the 'otr' <field/> 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' <field/> element set to 'false'.

-

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.

- +

Note: When negotiating a chat session, the user MUST include the <required/> element inside the 'logging' <field/> 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' <field/> element set to 'may'.

+

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.

+
- + - - - + + + - - - - + + + + - - - - + - - - - - + - - - + + + - - + + + + + + + + + - + - - - + + +
Contact's OTR PreferenceResponding 'otr' Negotiation Values*Responding 'logging' Negotiation Values*
Initiator Options -->maymay,mustnot*mustnot,may* mustnotmustnot,may*may,mustnot*may
requiremaymaymayrequire OTR modemustnotmustnotmustnot fail**
prefermaymaymayprefer OTR mode mustnot
approvemaymay mustnot mustnotmay
concedemaymayapprove OTR mode mustnot mustnotmaymay
opposemayconcede OTR mode mustnot mustnotmaymay
oppose OTR mode mustnotmaymaymay
forbidforbid OTR mode fail**mustnotmustnotmustnotmaymaymay

* The first value is the default.

** 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.

-

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 required, then the client MUST refuse the request. It MAY then send its own Chat Session Negotiation request with an 'otr' field.

-

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).

+

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 required, then the client MUST refuse the request. It MAY then send its own Chat Session Negotiation request with a 'logging' field.

+

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).

If a Chat Session Negotiation agreed to enable OTR then the clients MUST NOT allow messages sent in either direction to be archived in any way (including Manual Archiving and Automated Archiving). If a client (or user) acts in bad faith then its contacts cannot prevent it archiving conversations.

@@ -1200,7 +1201,7 @@ -

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).

+

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).

If a server deployment enables automatic archiving by default, then it MUST return a stream feature containing an empty <default/> element (see the Stream Feature section of this document).