[Bug 50] Property teminology inconsistent with RFC3253

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

julian.reschke <at> greenbytes.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

------- Additional Comments From julian.reschke <at> greenbytes.de  2006-01-01 04:18 -------
The changes look good to me, except that I would prefer to use some other
property than DAV:getcontentlength as example for "protected" (because that one
is even computed). Such as:

Section 14., para. 2:
OLD:

    A protected property is one which cannot be changed with a PROPPATCH
    request.  There may be other requests which would result in a change
    to a protected property (as when a PUT request to an existing
    resource causes DAV:contentlength to change to a new value).  Note
    that a given property could be protected on one type of resource, but
    not protected on another type of resource.

NEW:

    A protected property is one which cannot be changed with a PROPPATCH
    request.  There may be other requests which would result in a change
    to a protected property (as when a LOCK request affects the value of

Cacheability; MKCOL idempotent?

Hi.

While looking into BugZilla issue 80 ("Specify idempotence and safeness 
for all new methods", 
<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=80>), I noticed 
that RFC2518 says that MKCOL's results aren't cacheable because it's not 
idempotent (see

<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.change.bz080.3>). 

I think that's incorrect, because similar to PUT, repeating the same 
MKCOL request multiple times will cause the server to have the same 
state afterwards (just like PUT, but unlike POST).

So I fixed that, but wonder: should this affect what we say about the 
cacheability of MKCOL results? Are we still saying "MUST NOT be cached"?

As a matter of fact, should we rethink that for all methods? We 
currently say that PROPFIND results SHOULD NOT be cached

(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.section.8.2>). 
Is there any good reason for it? Should the fact that real-world WebDAV 
clients *do* cache PROPFIND results tell us something? 

Feedback appreciated,

Julian

I-D ACTION:draft-ietf-webdav-rfc2518bis-10.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF.

	Title		: HTTP Extensions for Distributed Authoring - WebDAV
	Author(s)	: L. Dusseault
	Filename	: draft-ietf-webdav-rfc2518bis-10.txt
	Pages		: 131
	Date		: 2006-1-3
	
WebDAV consists of a set of methods, headers, and content-types
   ancillary to HTTP/1.1 for the management of resource properties,
   creation and management of resource collections, URL namespace
   manipulation, and resource locking (collision avoidance).

   RFC2518 was published in February 1999, and this specification makes
   minor revisions mostly due to interoperability experience.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-webdav-rfc2518bis-10.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-webdav-rfc2518bis-10.txt".

Re: Cacheability; MKCOL idempotent?

Julian wrote on 01/03/2006 02:41:38 PM:
>
> While looking into BugZilla issue 80 ("Specify idempotence and safeness
> for all new methods",
> <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=80>), I noticed
> that RFC2518 says that MKCOL's results aren't cacheable because it's not
> idempotent (see
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-
> latest.html#rfc.change.bz080.3>).
> I think that's incorrect, because similar to PUT, repeating the same
> MKCOL request multiple times will cause the server to have the same
> state afterwards (just like PUT, but unlike POST).

I agree.  MKCOL is idempotent.

> So I fixed that, but wonder: should this affect what we say about the
> cacheability of MKCOL results? Are we still saying "MUST NOT be cached"?

Yes (just as PUT must not be cached).

> As a matter of fact, should we rethink that for all methods? We
> currently say that PROPFIND results SHOULD NOT be cached
> (<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-
> latest.html#rfc.section.8.2>).

PROPFIND isn't cacheable because we don't provide any
cache-validity mechanisms for properties (such as etag or last-modified).

> Is there any good reason for it? Should the fact that real-world WebDAV
> clients *do* cache PROPFIND results tell us something?

Just tells us that there are buggy clients out there (.

Cheers,
Geoff

[Bug 10] Round-tripping various information in properties

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

elias <at> cse.ucsc.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

------- Additional Comments From elias <at> cse.ucsc.edu  2006-01-04 09:49 -------
Assigned to Lisa for above changes.

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

[Bug 80] Specify idempotence and safeness for all new methods

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

elias <at> cse.ucsc.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

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

[Bug 80] Specify idempotence and safeness for all new methods

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

elias <at> cse.ucsc.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|elias <at> cse.ucsc.edu          |julian.reschke <at> greenbytes.de

------- Additional Comments From elias <at> cse.ucsc.edu  2006-01-04 09:52 -------
MKCOL is indeed idempotent, contrary to what 2518 says. Julian to review spec
language on cacheability.

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

[Bug 146] PROP_ROUNDTRIP

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

Bug 146 depends on bug 10, which changed state.

Bug 10 Summary: Round-tripping various information in properties
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

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

[Bug 10] Round-tripping various information in properties

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

lisa <at> osafoundation.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

------- Additional Comments From lisa <at> osafoundation.org  2006-01-04 09:53 -------
I didn't make the exact changes in the diff, but rather the changes we discussed
in the call.  This will be in a revision to -10.

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

[Bug 22] attributes on properties

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

Bug 22 depends on bug 10, which changed state.

Bug 10 Summary: Round-tripping various information in properties
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.