Re: I-D ACTION:draft-reschke-http-etag-on-write-00.txt

Hi,

we've been discussing the interpretation of ETags returned upon an HTTP 
PUT request for some time now. Jim Whitehead started work on an Internet 
Draft discussing this topic in February (see 
<http://greenbytes.de/tech/webdav/draft-whitehead-http-etag-00.html>), 
but unfortunately we didn't make any progress since.

Personally, I think that we really need a very minor clarification, plus 
a simple new feature to help clients that want to avoid a re-fetch after 
sending the content. I therefore decided to write up my own draft. It 
summarizes the situation (as RFC2616 is concerned), proposes one 
clarification to RFC2616 (as mentioned in 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2006JanMar/0003.html>), 
and also proposes that minor new feature (a new response header).

Feedback appreciated. I mean it. We really should resolve this, as two 
drafts in front of the IESG already make contradicting requirements.

HTML at 
<http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-00.html>.

Best regards, Julian




Internet-Drafts@ietf.org schrieb:
> 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-00.txt
> 	Pages		: 19
> 	Date		: 2006-8-9
> 	
>    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 response header, 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-00.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-00.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-00.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, 9 August 2006 20:32:28 UTC