[Standards] UPDATED: XEP-0136 (Message Archiving)
Version 0.16 of XEP-0136 (Message Archiving) has been released. Abstract: This document defines mechanisms and preferences for the archiving and retrieval of XMPP messages. Changelog: Addressed last call comments; clarified syntax of the pref and chat elements; deferred definition of data forms for attribute association to future specifications; removed registration of field standardization fields. (psa) Diff: currently unavailable URL: http://www.xmpp.org/extensions/xep-0136.html
Re: [Standards] Query Regarding MUC XEP-0045
Matthew Wild wrote: > On Fri, Apr 11, 2008 at 10:23 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > > Registered with the room or with the service? Do we need to > > differentiate between the two? If you are registered with the room then > > you are a member, whereas nick registration has meaning across the > > service. Compare Section 7.10 of XEP-0045, where you register with the > > room, to registration with the service. > > > > Good question... the problem I see is that all this is very > implementation dependent. ejabberd at least doesn't allow you to > register a nick in a room, and it isn't explicitly specified in the > XEP (which says the server can send a data form). > > If you are a room member, this is visible already anyway, so I am > edging towards registration with the whole service (unless we > implemented both). Yes I think that makes sense. > > > The reason I believe this is needed is because the lack of it makes nick > > > registration fairly useless in anonymous rooms. If someone can see > > > that a user's nick is registered, they have a certain level of > > > assurance that the next time they see this nick, it is the same > > > person. Without this knowledge it may as well be someone completely > > > different. > > > > > > Currently I don't believe there is any way to tell, which means that > > > even if you register your nick on a service, it provides little > > > benefit (unlike it would on IRC/NickServ). > > > > The only way to tell is by trying to register the nick yourself. And > > that seems rather silly. :) > > > > Ah yes, there is that (a method I have used before, and even > considered adding to HAL as a hacky workaround). HAL knows all... > > I see two approaches: > > > > 1. If someone is registered, the service includes a flag in their > > presence broadcast -- something like the following: > > > >> from='[EMAIL PROTECTED]/thirdwitch' > > to='[EMAIL PROTECTED]/desktop'> > > > > > > > > > > > > > > Seems ok... > > > 2. The service enables you to check if someone is registered: > > > >> id='check-nick-1' > > to='macbeth.shakespeare.lit' > > type='get'> > > > > thirdwitch > > > > > > > > If the nick is registered, the service returns an IQ-result, otherwise > > it returns an error ( if the nick is not registered, > > if the protocol is not supported): > > > >> id='check-nick-1' > > to='[EMAIL PROTECTED]/desktop' > > type='result'/> > > > > OR > > > >> id='check-nick-1' > > to='[EMAIL PROTECTED]/desktop' > > type='error'> > > > > > > > > > > > > > > Also ok... > > I'm wondering which would be more convenient from a client UI perspective. > > A new element in presence is a new overhead, but if you want to know > up-front who is registered, we don't want clients to have to query > each user in every MUC they join. > > In my use case I don't mind querying (I only want to know about people > I interact with) and the same for HAL's use case (checking that the > user is the same person, when he isn't in a position to know their > JID). If we don't include it in presence, clients will query everyone. I think I'd prefer the presence flag. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Query Regarding MUC XEP-0045
On Fri, Apr 11, 2008 at 10:23 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Registered with the room or with the service? Do we need to > differentiate between the two? If you are registered with the room then > you are a member, whereas nick registration has meaning across the > service. Compare Section 7.10 of XEP-0045, where you register with the > room, to registration with the service. > Good question... the problem I see is that all this is very implementation dependent. ejabberd at least doesn't allow you to register a nick in a room, and it isn't explicitly specified in the XEP (which says the server can send a data form). If you are a room member, this is visible already anyway, so I am edging towards registration with the whole service (unless we implemented both). > > > The reason I believe this is needed is because the lack of it makes nick > > registration fairly useless in anonymous rooms. If someone can see > > that a user's nick is registered, they have a certain level of > > assurance that the next time they see this nick, it is the same > > person. Without this knowledge it may as well be someone completely > > different. > > > > Currently I don't believe there is any way to tell, which means that > > even if you register your nick on a service, it provides little > > benefit (unlike it would on IRC/NickServ). > > The only way to tell is by trying to register the nick yourself. And > that seems rather silly. :) > Ah yes, there is that (a method I have used before, and even considered adding to HAL as a hacky workaround). > I see two approaches: > > 1. If someone is registered, the service includes a flag in their > presence broadcast -- something like the following: > > from='[EMAIL PROTECTED]/thirdwitch' > to='[EMAIL PROTECTED]/desktop'> > > > > > > Seems ok... > 2. The service enables you to check if someone is registered: > > id='check-nick-1' > to='macbeth.shakespeare.lit' > type='get'> > > thirdwitch > > > > If the nick is registered, the service returns an IQ-result, otherwise > it returns an error ( if the nick is not registered, > if the protocol is not supported): > > id='check-nick-1' > to='[EMAIL PROTECTED]/desktop' > type='result'/> > > OR > > id='check-nick-1' > to='[EMAIL PROTECTED]/desktop' > type='error'> > > > > > > Also ok... I'm wondering which would be more convenient from a client UI perspective. A new element in presence is a new overhead, but if you want to know up-front who is registered, we don't want clients to have to query each user in every MUC they join. In my use case I don't mind querying (I only want to know about people I interact with) and the same for HAL's use case (checking that the user is the same person, when he isn't in a position to know their JID). Matthew.
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 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 elements that > have different thread > IDs in separate collections. I have this: The content of elements that have different thread IDs SHOULD be archived in separate collections and the content of 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 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 error. > Your example below uses . I think 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)
Alexander Tsvyashchenko wrote: > > Hello All, > > Quoting Alexey Melnikov <[EMAIL PROTECTED]>: > In section 4.2: > Note: The content of 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 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 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
