On Fri, 2007-08-17 at 09:30 -0600, Peter Saint-Andre wrote: > 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.
Not sure. The point that I was trying to make is there is a semantic difference between using just one id (current?) or having the service pick one for you. We should maybe decide which of the two we intend as I was assuming the former. > > 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? I know item identifiers must be unique, but I was saying here is that the XEP doesn't specify that a server needs to generate unique ids if the publisher doesn't provide one. -- Groetjes, ralphm
