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 [email protected] 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.2.4.2.
>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
<feature-not-implemented/>?
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.
Regards,
Alexey
