Re: BIND, was: [Bug 85] clarification of live property behaviour vs namespace ops needed

Let's hold hands.

Am 19.12.2005 um 18:28 schrieb Jim Whitehead:

> I agree with this as well.
>
> - Jim
> On Dec 17, 2005, at 7:43 AM, Geoffrey M Clemm wrote:
>
>>
>> Sounds good to me.
>>
>> Cheers,
>> Geoff
>>
>> Julian wrote on 12/17/2005 06:40:38 AM:
>>
>>  >
>>  > Hi.
>>  >
>>  > With the inclusion of the proposed text below in RFC2518bius, we'd 
>> be
>>  > closing an issue that was raised in spring while discussing BIND. 
>> In the
>>  > subsequent discussion (summarized in
>>  > 
>> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-namespace-vs-
>>  > properties-latest.html>)
>>  > we found that it's not a problem specific to BIND at all, because 
>> it
>>  > applies to any operation that creates new resources or moves them.
>>  >
>>  > Since then BIND has passed (a third!) working group last call, 
>> with no
>>  > new issues raised. So here's my current understanding of where we 
>> stand
>>  > with BIND. Feedback appreciated.
>>  >
>>  > 1) BIND is finished, however it's currently on hold because we're 
>> busy
>>  > with RFC2518bis.
>>  >
>>  > 2) Should the working group manage to complete RFC2518bis as 
>> planned, we
>>  > can slightly revise the current BIND draft, taking out stuff 
>> that's not
>>  > needed anymore, namely
>>  > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12.
>>  > html#rfc.section.1.3>
>>  > ("preconditions and postconditions"), parts of
>>  > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12.
>>  > html#rfc.section.2.4>
>>  > (discussion of broken DELETE semantics of RFC2518bis), and parts of
>>  > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12.
>>  > html#rfc.section.8.2>
>>  > (introduction of "DAV" request header). As these changes would be 
>> purely
>>  > editorial, I'll assume we wouldn't want to do another WGLC.
>>  >
>>  > 3) On the other hand, should the working group fail to finish
>>  > RFC2518bis, we'll submit BIND as is.
>>  >
>>  >
>>  > Best regards, Julian
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  > bugzilla@soe.ucsc.edu wrote:
>>  > > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=85
>>  > >
>>  > >
>>  > >
>>  > >
>>  > >
>>  > > ------- Additional Comments From julian.reschke@greenbytes.de
>>  > 2005-12-17 03:25 -------
>>  > > OK, I believe I have completed my changes. As usual, see them in 
>> context at
>>  > > 
>> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-
>>  > latest.html#rfc.issue.bz085>
>>  > >
>>  > >
>>  > > In Section 8, NEW:
>>  > >
>>  > > 8.1.6 Impacts of Namespace Operations on Cacheability
>>  > >
>>  > > Note that the HTTP response headers "Etag" and "Last-Modified" 
>> (see
>>  > > [RFC2616], Sections 14.19 and 14.29) are defined per URL (not per
>>  > > resource), and are used by clients for caching. Therefore servers
>>  > > must ensure that executing any operation that affects the URL
>>  > > namespace (such as COPY, MOVE, DELETE, PUT or MKCOL) does 
>> preserve
>>  > > their semantics, in particular:
>>  > >
>>  > > o For any given URL, the "Last-Modified" value must increment 
>> every
>>  > > time the representation returned upon GET changes (within the
>>  > > limits of timestamp resolution).
>>  > >
>>  > > o For any given URL, no "ETag" value must ever be re-used for
>>  > > different representations returned by GET.
>>  > >
>>  > > In practice this means that servers
>>  > >
>>  > > o may have to increment "Last-Modified" timestamps for every
>>  > > resource inside the destination namespace of a namespace
>>  > > operation, and
>>  > >
>>  > > o similarily, may have to re-assign "ETag" values for these
>>  > > resources (unless the server allocates entity tags in a way so
>>  > > that they are unique across the whole URL namespace managed by 
>> the
>>  > > server).
>>  > >
>>  > > Note that these considerations also apply to specific use cases, 
>> such
>>  > > as using PUT creating a new resource at a URL that has been 
>> mapped
>>  > > before, but has been deleted since then.
>>  > >
>>  > > Finally, WebDAV properties (such as DAV:getetag and DAV:
>>  > > getlastmodified) that inherit their semantics from HTTP headers 
>> must
>>  > > behave accordingly.
>>  > >
>>  > > In the description for DAV:getetag:
>>  > >
>>  > > OLD:
>>  > >
>>  > > COPY/MOVE behaviour: This property value is dependent on the 
>> final
>>  > > state of the destination resource, not the value of the property
>>  > > on the source resource.
>>  > >
>>  > > NEW:
>>  > >
>>  > > COPY/MOVE behaviour: This property value is dependent on the 
>> final
>>  > > state of the destination resource, not the value of the property
>>  > > on the source resource. Also note the cacheability considerations
>>  > > in Section 8.1.6.
>>  > >
>>  > > In the description for DAV:getlastmodified:
>>  > >
>>  > > Section 14., para. 56:
>>  > > OLD:
>>  > >
>>  > > COPY/MOVE behaviour: This property value is dependent on the last
>>  > > modified date of the destination resource, not the value of the
>>  > > property on the source resource. Note that some server
>>  > > implementations use the file system date modified value for the
>>  > > DAV:getlastmodified value, and this is preserved in a MOVE even
>>  > > when the HTTP Last-Modified value SHOULD change. Thus, clients
>>  > > cannot rely on this value for caching and SHOULD use ETags.
>>  > >
>>  > > NEW:
>>  > >
>>  > > COPY/MOVE behaviour: This property value is dependent on the last
>>  > > modified date of the destination resource, not the value of the
>>  > > property on the source resource. Also note the cacheability
>>  > > considerations in Section 8.1.6.
>>  > >
>>  > > Note that tis particular change removes language that contradicts
>>  > RFC2616 (we
>>  > > can't simply tell people that RFC2616 doesn't count anymore, at 
>> least not
>>  > > without strong WG consensus).
>>  >

Received on Tuesday, 20 December 2005 09:21:51 UTC