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
