Ralph Meijer wrote: > On Thu, 2007-08-16 at 09:05 -0600, Peter Saint-Andre wrote: >> Ralph Meijer wrote: >>> [..] >>> >>> We used to have an explicit 'current' item identifier for the different >>> extended presence specs, but these seem to have been removed. I always >>> assumed extended presence to have a more transient notion than one which >>> may persist a history of changes (as each publish gets a unique id if >>> you don't provide one). Peter, could you comment on this? >> I don't think the "current" ItemID was ever meant to have special >> meaning, it was just what pgmillard put into the examples. We removed >> that so that people would no longer get confused. > > I don't think pgm put them in for no reason.
I can't remember. IIRC it was just a kind of "placeholder" ID. > Assuming notifications with > payload and persistent nodes (even for one item), the semantics of > providing an item identifier or not are different. > > If you don't provide an item identifier, the service MUST generate one > and, although this is not explicitly specified, a unique one at that. The definition of ItemID is: "A unique identifier for an item in the context of a specific node." Shall we specify a preferred algorithm for ensuring uniqueness? > Whether or not you provide this unique identifier with the publish > request, this means that every published item has a different item > identifier (see also the examples in the various extended presence specs > where the notifications show a uuid). This implies all items continue to > have significance and together form a history of events. > > Providing a node identifier like 'current' for all items, on the other > hand, means that every published item overrides the previously published > one. There is no sense of history here. That's all correct. >>> In general I think you should simply provide an identifier if you want >>> to be able to retract them at a later point in time. I don't think we >>> ever discussed how retraction works in the context of PEP. >> Any use case not discussed in PEP is to be handled as defined in >> XEP-0060. That applies to item retraction as well. > > Sure, but not providing an item identifier, as all examples show, makes > it hard(er) to revoke items, since you need to figure out what the > identifier was that the service assigned on your behalf. Right -- you'd have to listen for the event coming through and correlate it with what you published. As you say, it's easier if you provide the ItemID for tracking purposes (similar to IDs on IQ stanzas). > We could have > specified protocol where this item identifier is returned as part of the > result of the publish request, but I'm not sure if that is needed as > this point. I don't think so. > Also, should PEP clients process retraction and node deletion event > notifications? I think we need to get a bit of experience with all this before we come up with a recommendation. In general I'd say "why not?" but it does make implementation more complex. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
