W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

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

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:12 GMT