[Standards] LAST CALL: XEP-0136 (Message Archiving)
stpeter at stpeter.im
Mon Apr 14 23:25:28 UTC 2008
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards