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

Peter Saint-Andre 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.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080414/102c68e7/attachment.bin>


More information about the Standards mailing list