Etag-on-write, 3rd attempt (== IETF draft 01), was: Etag-on-write, 2nd attempt (== IETF draft 01)

Hi.

Thanks for the comments so far. In the meantime, I have submitted draft 
02, addressing some of the comments made so far (see 
<http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-02.html>, 
in particular 
<http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-02.html#rfc.section.B.2> 
for changes).

Looking at the feedback I haven't addressed so far, it seems to fall 
into one of the categories below:

1) "Yes, RFC2616 allows servers to rewrite the content upon PUT and 
still return an ETag, but that's just stupid; don't do it", and

2) "We like the new header, but could it be made extensible so that the 
kind of transformation can be specified?"

What I *haven't* heard is that the analysis of what RFC2616 says is 
incorrect (see 
<http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-02.html#rfc.section.1.3>). 
If people feel I got this one wrong, or that the explanation can be 
enhanced, please speak up.

Regarding the two other points:

re 1) First of all, I don't think it's stupid. There are use cases where 
it seems to make sense, see for instance 
<http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-02.html#rfc.section.A.1>. 
Furthermore, if we really believe it's stupid or incorrect to return an 
ETag in that case, we should put that into an RFC2616 
clarification/erratum instead, right?

re 2) I'd really like to avoid that. The proposal as in draft 02 is 
simple, and does exactly what it was designed to do. Adding 
extensibility into *this* header seems to buy little, and introduces the 
issue of how to disambiguate extensions (IANA registry? URI?). Anyway, 
if people feel strong about this, please submit a concrete proposal for 
how that extension should look like; and a description of how a client 
would benefit from that.


That being said, I'm continuing edits at 
<http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-latest.html>, 
and plan to do an informal last call over here before the IETF Internet 
Draft cut off date (Oct 23). Then (after the San Diego IETF), I plan to 
submit the draft to the RFC Editor for publication as Experimental RFC. 
    Independently of that, I'll try to get one of the Applications Area 
Directors of the IESG to shepherd it for publication as Proposed Standard.


Best regards, Julian

Received on Thursday, 5 October 2006 20:15:56 UTC