Subject: [Simple] Publish from different source of same tuple ID

From: Avshalom Houri <[email-masked]>
Date: Wed, 14 Mar 2007 12:56:18 +0200

Assuming a publish of tuples IDs: 1,2,3 and then another
initial publish of tuples IDs: 1,7,8.

Assuming that the first publish have not expired yet.

What should happen in the ESC?

* Possibility 1 - Forget the first publish and regard only the
  last publish.

* Possibility 2 - The second publish masks the first publish and is
  the relevant one. If the latter expires and the previous one has
  not expired yet, the ESC returns to the previous one.

* Possibility 3 - The aggregated document will contain:
  1 (new), 2, 3,, 7, 8

Other possibilities?

Thanks
--Avshalom

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Aki Niemi <[email-masked]>
Date: Mon, 19 Mar 2007 13:56:00 +0100

> * Possibility 3 - The aggregated document will contain:

One clarifying question first. Is the collision intentional or
accidental here?

If it's intentional, I would go with approach #3. But I would also be
interested to hear how real-life systems are intending to handle the
situation. Currently, all the standard (PUBLISH method) says is how you
publish the documents, and the rest is left to the compositor, which at
this point is a black box.

Cheers,
Aki

---

From: Robert Sparks <[email-masked]>
Date: Mon, 19 Mar 2007 14:05:27 +0100

Let me state what I think Aki's pointing to more strongly:

There are many many possibilities here. You're talking about  
composition policies,
and those are arbitrary.

For what you propose with (3). It's been awhile since I looked
hard at this, but this is what my memory is telling me:

The uniqueness of tuple-ids is scoped to the source of the information.
It is not global uniqueness. In the scope of an entity tag, the  
publisher
must keep the tuple-ids consistent  (3390 section 10.4). Outside of the
scope of that tag (the new initial publish from that source or somewhere
else), an entirely different set of ids can be used. There is some  
pressure
on a new initial publish coming from the same source to be consistent
with its tuple ids that you can derive from 3863, but IIRC you can only
state this as a "good idea".

Further, the tuple ids coming out of a compositor do not have to  
relate in any
way to the tuple ids going into the compositor. The compositor just has
to be consistent with the ids it generates within the scope of the etag.

So, for 3 below, in particular, if the second publish didn't come  
from the same
source, you don't want to be interpreting the 1's from each document  
to mean
the same thing.

RjS

---

From: Avshalom Houri <[email-masked]>
Date: Wed, 21 Mar 2007 10:21:45 +0200

> state this as a "good idea".
RFC 3903 say that but RFC 3863 4.1.2 says:

   The <tuple> element MUST contain an 'id' attribute which is used to
   distinguish this tuple from other tuples in the same PRESENTITY.  The
   value of an 'id' attribute MUST be unique within 'id' attribute
   values of other tuples for the same PRESENTITY.  An 'id' value is
   used by applications processing the presence document to identify the
   corresponding tuple in the previously acquired PRESENCE INFORMATION
   of the same PRESENTITY.  The value of the 'id' attribute is an
   arbitrary string, and has no significance beyond providing a means to
   distinguish <tuple> values, as noted above.

Seems as though there is a contradiction between 3903 and 3863.

> source, you don't want to be interpreting the 1's from each document 

The problem is that the compositor does not know weather the new publish 
is
coming from the same source (device crashed) or from a different source.
Remapping the IDs can be a way to solve the presumed contradiction between 

3903 and 3863.

> > this point is a black box.
It is not possible to know if the second publish is coming from
a different device or from the same device that has crashed and has lost
the entity tag.
Seems as though the fact that composition is open may create a lot of 
interop issues.
With one compositor certain presence doc will be created, with a different 
compositor
another presence doc may be created. Not sure that it is an acute problem 
but in
deployments people may not like this situation.