Hi Peter,
Most of your changes look good to me, so I didn't include them in my
reply. Some additional comments below.
Peter Saint-Andre wrote:
Alexey Melnikov wrote:
[...]
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
In fact that section doesn't include any text whatsoever!
I think that (1) it's fine for the client to set only one or two method
preferences, (2) the server must not modify any unset preferences, and
(3) the push must include all the prefs, not just those set by the
client.
This looks reasonable to me.
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.
Hmm. AFAICT, the client needs to figure this out based on the rules in
Section 5.1. So if you log in and don't receive a warning message, you
can assume that automatic archiving is not on by default (yes, I hear
the objections already: but message delivery is not reliable so you
might not receive the warning message!). If you do receive a warning
message because automatic archiving is on by default, the only way to
determine if it can be turned off is to try. If you receive an error as
described in SEction 5.2 then you know that automatic archiving cannot
be turned off.
That seems rather messy.
Yes. But if you want to keep current behavior, I think you should give
an example.
See also below.
[...]
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?
I think it is a client requirement.
Then don't use passive voice, e.g.
Note: The client SHOULD archive the content of message/ elements that have
different thread
IDs in separate collections.
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.
I suppose a server could try to enforce this rule to save the client
from its own stupidity, but I don't see that it's necessary.
If you want to allow a server to validate this, you should list an
appropriate error response.
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?
I think we don't need the third bullet.
Good :-).
5.2 Not-Implemented Responses
The server MUST return a feature-not-implemented/ error in the
following cases:
I think these should be distinct error cases. I would suggest the
following...
• 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.
feature-not-implemented/
• If administrator policies require that every message is logged
automatically, and the client is trying to disable automatic archiving.
not-acceptable/
• If the client is trying to enable encryption, but the server does
not support encryption
also feature-not-implemented/
or the user did not specify a public key and is
not publishing any keys using XEP-0189.
not-allowed/
I like that.
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.
Thus:
**
5. Automatic Archiving
[...]
If service policies require that every message is logged automatically,
the server MUST return a not-acceptable/ error.
Your example below uses not-allowed/. I think not-acceptable/ is a
cut and paste error.
Example 35. Automatic Archiving is Compulsory
iq type='error' id='auto3'
error type='cancel'
not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/
/error
/iq
