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: Sean Olson <[email-masked]>
Date: Thu, 5 Jun 2003 09:55:23 -0700 (PDT)

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
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Sean Olson <[email-masked]>
Date: Thu, 5 Jun 2003 09:55:23 -0700 (PDT)