Re: [Standards] LAST CALL: XEP-0136 (Message Archiving)
Alexander Tsvyashchenko wrote: Hello All, Quoting Alexey Melnikov [EMAIL PROTECTED]: 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. As 4.2 is general description of collections requirements and behavior I would say this requirement is both for client and server depending on archiving scenario, no? If the auto-archiving is activated - this is certainly server-side behavior, it is covered by the previous discussion we had on this list related to thread treatment. If manual archiving is used - then it's indeed client's task to handle that correctly. That seems sensible to me. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] LAST CALL: XEP-0136 (Message Archiving)
Alexey Melnikov wrote: Peter Saint-Andre wrote: Alexey Melnikov wrote: 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. OK I'll work that in. 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. I have this: The content of message/ elements that have different thread IDs SHOULD be archived in separate collections and the content of message/ elements that have the same thread IDs SHOULD be archived in the same collection; this is the responsibility of the client if manual archiving is used and the responsibility of the server if automatic archiving is used. 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. I don't want to allow a server to validate this. :) 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. Right. I've fixed that. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] LAST CALL: XEP-0136 (Message Archiving)
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
Re: [Standards] LAST CALL: XEP-0136 (Message Archiving)
Hello All, Quoting Alexey Melnikov [EMAIL PROTECTED]: 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. As 4.2 is general description of collections requirements and behavior I would say this requirement is both for client and server depending on archiving scenario, no? If the auto-archiving is activated - this is certainly server-side behavior, it is covered by the previous discussion we had on this list related to thread treatment. If manual archiving is used - then it's indeed client's task to handle that correctly. Good luck! Alexander This message was sent using IMP, the Internet Messaging Program.
Re: [Standards] LAST CALL: XEP-0136 (Message Archiving)
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@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.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?
Re: [Standards] LAST CALL: XEP-0136 (Message Archiving)
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 Per XMPP Council consensus, I will split this into two specifications during the Last Call period -- we will move the encryption aspects to a separate document. Feedback is welcome regarding that decision and the spec in general. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] LAST CALL: XEP-0136 (Message Archiving)
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@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!
