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

Alexey Melnikov alexey.melnikov at isode.com
Sat Apr 12 18:12:28 UTC 2008


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




More information about the Standards mailing list