- From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
- Date: Tue, 20 Dec 2005 08:49:31 -0500
- To: " webdav" <w3c-dist-auth@w3.org>
- Message-ID: <OFBF8D9422.9F872FD0-ON852570DD.004B4186-852570DD.004BF22E@us.ibm.com>
It is my understanding that issues that were open against the BIND
specification were actually 2518bis issues, and therefore have been
moved to the 2518bis open issue list (and are being currently addressed).
So if there is an open issue remaining against the BIND specification,
could someone identify it?
Also, what in Julian's statement that suggested that an individual
submission of the BIND work be made?? He was just stating that his
understanding was that the working group had come to an agreement on
BIND, and that the only reason we haven't submitted BIND is that we
are focusing on 2518bis (which is the statement Jim and I were
agreeing with).
Cheers,
Geoff
Cullen wrote on 12/20/2005 12:41:46 AM:
>
> 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,
atleast not
> > > without strong WG consensus).
> >
>
>
Received on Tuesday, 20 December 2005 13:49:44 UTC