- From: <bugzilla@soe.ucsc.edu>
- Date: Tue, 17 Jan 2006 10:54:59 -0800
- To: w3c-dist-auth@w3.org
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=152
julian.reschke@greenbytes.de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
------- Additional Comments From julian.reschke@greenbytes.de 2006-01-17 10:54 -------
I think there's more to do; below are the missing changes + rational.
Section 7., para. 31:
OLD:
A successful lock request to an unmapped URL MUST result in the
creation of an locked resource with empty content. Subsequently, a
successful PUT request (with the correct lock token) provides the
content for the resource, and the server MUST also use the content-
type and content-language information from this request.
NEW:
A successful lock request to an unmapped URL MUST result in the
creation of an locked resource with empty content. Subsequently, a
successful PUT request (with the correct lock token) provides the
content for the resource.
If we know that servers won't accept the content type header, there's no point
claiming it's a MUST requirement, in particular not in the section about locks.
Section 7., para. 44:
OLD:
o SHOULD default to having no content type.
o MAY NOT have values for properties like DAV:getcontentlanguage
which haven't been specified yet by the client.
NEW:
o MAY NOT have values for properties like DAV:getcontentlanguage
which haven't been specified yet by the client.
Again: we can't force servers to do this. If a server computes the mime type
based on the extension, this is what the mime type will be.
Section 7., para. 49:
OLD:
The client is expected to update the locked empty resource shortly
after locking it, using PUT and possibly PROPPATCH. When the client
uses PUT to overwrite a locked empty resource the client MUST supply
a Content-Type if any is known.
NEW:
The client is expected to update the locked empty resource shortly
after locking it, using PUT and possibly PROPPATCH.
Why do we require this, and why is it a MUST?
Section 14., para. 42:
OLD:
Protected: SHOULD NOT be protected, so clients may fix this value.
Note that servers implementing RFC2518 might have made this a
protected property as this is a new requirement.
NEW:
Protected: Potentially protected if the server prefers to assign
content types on it's own (see also discussion in Section 8.8.1).
DAV:getcontenttype is defined in terms of HTTP, and if we don't require servers
to accept the content-type upon PUT, then there's also no requirement to make
DAV:getcontenttype settable (same reasoning).
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Tuesday, 17 January 2006 18:55:04 UTC