- From: Cullen Jennings <fluffy@cisco.com>
- Date: Mon, 19 Dec 2005 21:41:46 -0800
- To: Jim Whitehead <ejw@soe.ucsc.edu>, Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
- CC: Julian Reschke <julian.reschke@gmx.de>, WebDav <w3c-dist-auth@w3.org>, <w3c-dist-auth-request@w3.org>
- Message-ID: <BFCCD99A.661DA%fluffy@cisco.com>
My recollection was that BIND did NOT pass WGLC with no open issues. (There
may have been no new issues but that is quite a different thing). I'm could
certainly be wrong on this and would be happy to be shown I was wrong. It
may be that all the open issues are resolved in bis.
If the WG does not come to agreement on BIND, I would certainly view an
individual submission of this work as an end run around the WG. We have had
this discussion before on the topic of bis and Ted and I have both commented
on our feelings about the idea that if the WG can't agree we will just
submit some draft anyways.
I do believe that bis and BIND can both be completed.
On 12/19/05 9:28 AM, "Jim Whitehead" <ejw@soe.ucsc.edu> wrote:
> 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 05:41:58 UTC