Subject: [Bug 85] clarification of live property behaviour vs namespace ops needed

From: [email-masked]
Date: Sat, 17 Dec 2005 03:25:46 -0800

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=85

------- Additional Comments From [email-masked]  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).

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 17 Dec 2005 12:40:38 +0100

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sat, 17 Dec 2005 10:42:52 -0500

Sounds good to me.

Cheers,
Geoff

---

From: Jim Whitehead <[email-masked]>
Date: Mon, 19 Dec 2005 09:28:57 -0800

I agree with this as well.

- Jim

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 19 Dec 2005 21:41:46 -0800

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" <[email-masked]> wrote:

>>>>  > >     COPY/MOVE behaviour:  This property value is dependent on the >>>>
final
>>>>  > >     COPY/MOVE behaviour:  This property value is dependent on the >>>>
final

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 20 Dec 2005 10:21:32 +0100

Let's hold hands.

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 20 Dec 2005 08:49:31 -0500

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. 
> 

>  > > can't simply tell people that RFC2616 doesn't count anymore, 
atleast not