[Standards] LAST CALL: XEP-0136 (Message Archiving)

Alexey Melnikov alexey.melnikov at isode.com
Fri Apr 11 16:17:44 UTC 2008

XMPP Extensions Editor wrote:

> This message constitutes notice of a Last Call for comments on 
> XEP-0136 (Message Archiving). Abstract: This document defines 
> mechanisms and preferences for the archiving and retrieval of XMPP 
> messages. URL: http://www.xmpp.org/extensions/xep-0136.html This Last 
> Call begins today and shall end at the close of business on 
> 2008-04-18. Please consider the following questions during this Last 
> Call and send your feedback to the standards at xmpp.org discussion list: 
> 1. Is this specification needed to fill gaps in the XMPP protocol 
> stack or to clarify an existing protocol? 2. Does the specification 
> solve the problem stated in the introduction and requirements? 3. Do 
> you plan to implement this specification in your code? If not, why 
> not? 4. Do you have any security concerns related to this 
> specification? 5. Is the specification accurate and clearly written? 
> Your feedback is appreciated!

In general I think the document is in a good shape. It contains some 
useful suggestions for implementors, which I like.

Below are my detailed comments from reviewing the document:

 >2.2.4 Method Element
 >Each <method/> element specifies the the user's preferences for one
 >available archiving method. The <method/> element MUST be empty
 >and MUST include both the 'type' and 'use' attributes. The <pref/>
 >element MUST include at least three <method/> elements,
 >differentiated by the value of the 'type' attribute.

It took me several passes to figure out what this text is trying to say. 
Maybe it would be better to say that <pref/> element MUST include 
<method/> element for each type defined in section

 >2.4 Setting Default Modes
 >The server MAY be configured to return a <feature-not-implemented/> 
error in the following cases:
 >• If it does not allow the saving of full message stanza content, and 
the client set the value of the 'save'
 >attribute to 'message' or 'stream', and any of the user's connected 
resources have Automated Archiving enabled.
 >• If administrator policies require that at least the <body/> elements 
(or the full content) of every message
 >are logged automatically, and the client sets the value of the 'save' 
attribute to 'false' (or 'body').

Should the second case return something other than 
Examples show that changes to settings by a resource are pushed out to 
the resource that caused the change. Should this be optimized out?

> 2.6 Setting Archiving Method Preferences
> Example 12. Client Sets Method Preferences
> <iq type='set' id='pref4'>
> <pref xmlns='urn:xmpp:tmp:archive'>
> <method type='auto' use='concede'/>
> <method type='local' use='forbid'/>
> <method type='manual' use='prefer'/>
> </pref>
> </iq> 

This section doesn't describe if it is Ok for the client to only modify 
one archiving type at a time (.e.g. if <pref> contains just one 
<method>) and if not, what should be the error response

> 3.1 OTR Negotiation


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

An example of how this can be done (or a reference to a section 
describing how this can be done) would be helpful here.

 >The following table shows what stanza session negotiation values
 > the initating party (i.e., the "user")

typo: initiating

 >should send for the 'logging' field in the initial data form for
 >a stanza session negotiation (note: 'may' means that the receiving
 >party MAY enable message logging and 'mustnot' means that
 >the receiving party MUST NOT enable logging).

While I think this sentence is correct, is it possible to simplify/split 
it into multiple, as it is hard to understand?

In section 4.2:

> Note: The content of <message/> elements that have different thread 
> IDs SHOULD be archived in separate collections.

Is this a requirement on the client or on the server? If this is a 
requirement on the server, than an example demonstrating what the server 
should do if it finds a <message/> with non matching tread ID.

> 4.6 Groupchat Messages
> A client MAY archive messages that it receives from Multi-User Chat 
> [8] rooms. The 'with' attribute MUST be the bare JID of the room. The 
> client MUST include a 'name' attribute for each <from/> element to 
> specify the room nickname (and, if available, bare JID) of the message 
> sender:

Before I saw the example, I misread this as "the name attribute can 
contain either nickname and/or bare JID". Please clarify that any JID is 
recorded in the 'jid' attribute.

> 5.1 Toggling Auto-Archiving
> If server administration policies require that every message is logged 
> automatically (see Security Considerations) then:
> • The server MUST enable automatic archiving when each stream is opened.
> • Clients MUST NOT be allowed to disable automatic archiving.
> • Automatic archiving MUST NOT be subject to users' Archiving 
> Preferences.

I don't think the last requirement is entirely clear. How is this 
different from the previous requirement?

> 5.2 Not-Implemented Responses
> The server MUST return a <feature-not-implemented/> error in the 
> following cases:
> • If the client is trying to enable automatic archiving, but the 
> server does not allow the saving of full message stanza content, and 
> the user has specified the 'message' Save Mode in one of its Archiving 
> Preferences.
> • If administrator policies require that every message is logged 
> automatically, and the client is trying to disable automatic archiving.
> • If the client is trying to enable encryption, but the server does 
> not support encryption or the user did not specify a public key and is 
> not publishing any keys using XEP-0189.

The last listed case (user didn't specify a public key) is not 
"not-implemented". This is a distinct error condition and another error 
code should be used, if possible.

> 6.1 Retrieving a List of Collections
> To request a list of collections the client sends a <list/> element. 
> The 'start' and 'end' attributes MAY be specified to indicate a date 
> range (the values of these attributes MUST be UTC and adhere to the 
> DateTime format specified in XEP-0082). The 'with' attribute MAY be 
> specified to limit the list to a single participating full JID, bare 
> JID or domain. 

So if the client specifies a domain, does it mean that the server should 
return all collections with any JID in that domain?

I think <changed> and <removed> are only mentioned in passing before 
section 9.4 (Replication), so some explanation early on (where they 
referenced for the first time) would be helpful.


More information about the Standards mailing list