Re: Etag-on-write, 2nd attempt (== IETF draft 01)

This draft has discussion of how subsequent rewrites might affect a  
decision on how to return ETags in PUT responses when the content  
might have been rewritten.  That's great, but there's another kind of  
consideration entirely, and that's how a client that maintains an  
offline synchronized store, or cache of resources, will be affected.

A likely real-world example is a CalDAV server that can augment the  
information in a VEVENT: filling in attendee status, adding alternate  
attendee addresses, or filling in location information, or adding a  
URL where the VEVENT can be seen as a HTML Web page (think of  
calendar sites like meetup and upcoming.org).  While a subsequent  
edit of the same event might or might not result in the same outcome  
whether or not the client downloaded the intermediate version,  
there's still a problem if the cached/offline copy isn't as rich as  
the server copy.  A user who sees the discrepancy will assume bugginess.

It would sure be great if existing clients that already do offline  
synch, and might already encounter this case, would work  
appropriately with a new mechanism improving the functionality of  
ETags on PUTs.

Lisa

On Aug 25, 2006, at 2:03 PM, Julian Reschke wrote:

>
> Hi,
>
> this new draft attempts to resolve issues raised over here two  
> weeks ago, mainly in the extensibility model (removed for now to  
> avoid bikeshed-type discussions), and with respect to backwards  
> compatibility with components that treat newly introduced headers  
> as entity headers (I'm trying to get away by making the header an  
> entity header, eagerly awaiting new feedback).
>
> I hope that this addresses the feedback I received so far (thanks a  
> lot!).
>
> Best regards, Julian
>
>
> Internet-Drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts  
>> directories.
>> 	Title		: The Hypertext Transfer Protocol (HTTP) Entity Tag  
>> ("ETag") Response Header in Write Operations
>> 	Author(s)	: J. Reschke
>> 	Filename	: draft-reschke-http-etag-on-write-01.txt
>> 	Pages		: 20
>> 	Date		: 2006-8-25
>> 	
>> The Hypertext Transfer Protocol (HTTP) specifies a state identifier,
>>    called "Entity Tag", to be returned in the "ETag" response header.
>>    However, the description of this header for write operations  
>> such as
>>    PUT is incomplete, and has caused confusion among developers and
>>    protocol designers, and potentially interoperability problems.
>>    This document explains the problem in detail and suggests both a
>>    clarification for a revision to the HTTP/1.1 specification  
>> (RFC2616)
>>    and a new header for use in responses, making HTTP entity tags  
>> more
>>    useful for user agents that want to avoid round-trips to the  
>> server
>>    after modifying a resource.
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-reschke-http-etag-on- 
>> write-01.txt
>> To remove yourself from the I-D Announcement list, send a message  
>> to i-d-announce-request@ietf.org with the word unsubscribe in the  
>> body of the message. You can also visit https://www1.ietf.org/ 
>> mailman/listinfo/I-D-announce to change your subscription settings.
>> Internet-Drafts are also available by anonymous FTP. Login with  
>> the username "anonymous" and a password of your e-mail address.  
>> After logging in, type "cd internet-drafts" and then "get draft- 
>> reschke-http-etag-on-write-01.txt".
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow- 
>> sites.txt
>> Internet-Drafts can also be obtained by e-mail.
>> Send a message to:
>> 	mailserv@ietf.org.
>> In the body type:
>> 	"FILE /internet-drafts/draft-reschke-http-etag-on-write-01.txt".
>> 	
>> NOTE:	The mail server at ietf.org can return the document in
>> 	MIME-encoded form by using the "mpack" utility.  To use this
>> 	feature, insert the command "ENCODING mime" before the "FILE"
>> 	command.  To decode the response(s), you will need "munpack" or
>> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>> 	exhibit different behavior, especially when dealing with
>> 	"multipart" MIME messages (i.e. documents which have been split
>> 	up into multiple messages), so check your local documentation on
>> 	how to manipulate these messages.
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> --------------------------------------------------------------------- 
>> ---
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>
>

Received on Wednesday, 6 September 2006 21:22:29 UTC