Subject: [Simple] PUBLISH: versioning of published information

From: [email-masked]
Date: Thu, 5 Jun 2003 18:13:33 +0300

Hi All,

In the SIMPLE interim we discussed the issue of versioning of published information (among other things - other issues will be posted on separate emails). There were proposals at the meeting, and we've also had a suggestion on the list since then. I'll try to summarize the issue and the proposals made this far.

The current PUBLISH draft uses information contained in the body of a publication, namely timestamps in individual tuples to version the published tuples. This doesn't work without global clock sync between the EPAs, and so we need something else.

Proposal 1:
Have the server return a timestamp in the response of a PUBLISH, and have the client use that timestamp with the HTTP/1.1 style preconditions "If-Unmodified-Since" to detect if someone else has modified the published tuple(s). Attempt to PUBLISH a "stale" tuple would result in a 412 Preconditions Failed error response. An automata refreshing a publication would never override in such a case, but some type of human intervention would be required to do a fresh PUBLISH, i.e., a publication without the preconditions.

Proposal 2:
Since there is theoretically a 1 second time window for two publications to collide due to the resolution of the Date header time, it was suggested that we should instead use a counter. Each fresh publication of the tuple would return an incremented value, which the client would use in each refresh publication.  

Proposal 3:
Basically identical to the previous proposal except that instead of a counter value, the server would return an opaque token, much like the Set-Cookie, Cookie headers in HTTP.

Proposal 4:
It was suggested that HTTP/1.1 style entity-tags would be used to identify a specific instance or version of a tuple. The value received from a server in an "ETag" header would be used by the client with an HTTP/1.1 style request precondition of "If-Match". Failure to match the entity tag would fail the request with a 412 response like in Proposal 1.

Personally, I like Proposal 4, because it accomplishes exactly what we want without the (theoretical) problem with the 1 second resolution in Date values.

Comments?

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

---

From: [email-masked]
Date: Fri, 6 Jun 2003 10:18:28 +0300

I share some of Sean's concern, mainly for the reason I mentioned in the interim that we can't assume that all presentities will publish using PUBLISH. Putting something like this in the body will increase the chances of it being used.

Regards,
Hisham

> -----Original Message-----
> From: ext Sean Olson [mailto:[email-masked]]
> Sent: Thursday, June 05, 2003 7:55 PM
> To: Niemi Aki (NMP/Helsinki); [email-masked]
> Subject: Re: [Simple] PUBLISH: versioning of published information
> 
> 
> The rationale behind using the timestamp element was
> that is was pre-existing and more importantly, it was
> in the body itself. The goal was to make the actual
> PUBLISH request headers as simple as possible without
> introducing new headers if at all possible. 
> 
> I like option 4, but it still has a sync. issue
> between EPAs. Namely, how does an EPA who is watching
> the published state detect collisions? I would like to
> see some feedback mechanism in the published state
> itself. Can we include the ETag as an optional
> component of the published tuple?
> 
> 
> --- [email-masked] wrote:
> > Hi All,
> > 
> > In the SIMPLE interim we discussed the issue of
> > versioning of published information (among other
> > things - other issues will be posted on separate
> > emails). There were proposals at the meeting, and
> > we've also had a suggestion on the list since then.
> > I'll try to summarize the issue and the proposals
> > made this far.
> > 
> > The current PUBLISH draft uses information contained
> > in the body of a publication, namely timestamps in
> > individual tuples to version the published tuples.
> > This doesn't work without global clock sync between
> > the EPAs, and so we need something else.
> > 
> > Proposal 1:
> > Have the server return a timestamp in the response
> > of a PUBLISH, and have the client use that timestamp
> > with the HTTP/1.1 style preconditions
> > "If-Unmodified-Since" to detect if someone else has
> > modified the published tuple(s). Attempt to PUBLISH
> > a "stale" tuple would result in a 412 Preconditions
> > Failed error response. An automata refreshing a
> > publication would never override in such a case, but
> > some type of human intervention would be required to
> > do a fresh PUBLISH, i.e., a publication without the
> > preconditions.
> > 
> > Proposal 2:
> > Since there is theoretically a 1 second time window
> > for two publications to collide due to the
> > resolution of the Date header time, it was suggested
> > that we should instead use a counter. Each fresh
> > publication of the tuple would return an incremented
> > value, which the client would use in each refresh
> > publication.  
> > 
> > Proposal 3:
> > Basically identical to the previous proposal except
> > that instead of a counter value, the server would
> > return an opaque token, much like the Set-Cookie,
> > Cookie headers in HTTP.
> > 
> > Proposal 4:
> > It was suggested that HTTP/1.1 style entity-tags
> > would be used to identify a specific instance or
> > version of a tuple. The value received from a server
> > in an "ETag" header would be used by the client with
> > an HTTP/1.1 style request precondition of
> > "If-Match". Failure to match the entity tag would
> > fail the request with a 412 response like in
> > Proposal 1.
> > 
> > Personally, I like Proposal 4, because it
> > accomplishes exactly what we want without the
> > (theoretical) problem with the 1 second resolution
> > in Date values.
> > 
> > Comments?
> > 
> > Cheers,
> > Aki  
> >   
> __________________________________
> Do you Yahoo!?
> Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
> http://calendar.yahoo.com

---

From: [email-masked]
Date: Fri, 6 Jun 2003 10:18:28 +0300

Regards,
Hisham

---

From: [email-masked]
Date: Fri, 6 Jun 2003 12:56:30 +0300

> Sent: 05 June, 2003 19:55

An EPA would detect a collision once it tried to refresh its state, and got a 412 response. Between the refreshes, doesn't the tuple ID basically enable this? If a watcher detects presence notification that matches its own, but has different state then it can figure out that a collision occurred?

Cheers,
Aki

---

From: [email-masked]
Date: Fri, 6 Jun 2003 12:56:30 +0300

Cheers,
Aki

---

From: [email-masked]
Date: Fri, 6 Jun 2003 13:10:24 +0300

Having versioning in the body would be the optimal solution, but I think we quite clearly demonstrated that it won't work without clock (or counter, etc.) sync between the publishers.

I think this problem maps quite nicely to the model used in HTTP where a resource (data object or service) has many representations, defined as entities - an entity tag uniquely identifying each one of them.

We can think of an event segment being the resource, and each publication of that event segment carrying a representation of that resource. There needs to be a central body assigning entity tags for those representations (the server) - otherwise we end up with the sync problem.

I don't think it matters whether a more recent publication for the same event segment arrived via PUBLISH or some other mechanism. I think it's up to the other mechaisms to define their own way of  detecting collisions. We only need to define that for PUBLISH.

Cheers,
Aki

 > From: ext [email-masked] 
 > [mailto:[email-masked]]
 > Sent: 06 June, 2003 10:18
 > To: [email-masked]; Niemi Aki (NMP/Helsinki); [email-masked]
 > Subject: RE: [Simple] PUBLISH: versioning of published information
 > 
 > 
 > I share some of Sean's concern, mainly for the reason I 
 > mentioned in the interim that we can't assume that all 
 > presentities will publish using PUBLISH. Putting something 
 > like this in the body will increase the chances of it being used.
 > 
 > Regards,
 > Hisham
 >

---

From: [email-masked]
Date: Fri, 6 Jun 2003 13:10:24 +0300

Cheers,
Aki

---

From: Adam Roach <[email-masked]>
Date: Sun, 8 Jun 2003 11:52:35 -0500

> From: [email-masked] [mailto:[email-masked]]
> 

Keep in mind that, long term, we want PUBLISH to work
for events in general, not just presence. The bodies for
other event packages have demonstrated a tendency to
be radically different than those of presence.

/a

---

From: Adam Roach <[email-masked]>
Date: Sun, 8 Jun 2003 11:52:35 -0500

/a