- From: <bugzilla@soe.ucsc.edu>
- Date: Sat, 4 Feb 2006 05:23:00 -0800
- To: w3c-dist-auth@w3.org
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=152
------- Additional Comments From julian.reschke@greenbytes.de 2006-02-04 05:23 -------
First, let me note that this discussion really doesn't belong under this issue.
There are problems directly related to this bug, which I'll cover first (as
usual, see also
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz152>).
Section 9.7.1., para. 3:
OLD:
A PUT request is the only way a client has to indicate to the server
what Content-Type a resource should have, and whether it should
change if the resource is overwritten. Thus, a client MUST provide a
Content-Type for a new resource if any is known, and a server SHOULD
use the Content-Type header value on any PUT request as the
resource's type (unless security concerns or policy dictates
otherwise). If the client does not provide a Content-Type for a new
resource, the server MAY create a resource with no Content-Type
assigned, or it MAY attempt to assign a reasonable and legal Content-
Type.
NEW:
A PUT request is the only way a client has to indicate to the server
what Content-Type a resource should have, and whether it should
change if the resource is overwritten. Thus, a client SHOULD provide
a Content-Type if any is known, and a server SHOULD use the Content-Type
header value on any PUT request as the resource's type (unless
security concerns or policy dictates otherwise).
1) I have a hard time believing a "MUST" level statement if it is immediately
relaxed by something untestable such as "if any is known". I could live with a
SHOULD, though. Also, the last sentence (two MAYs) doesn't seem to say anything
new; it only states things that are stated again in the subsequent paragraph.
That being said, I find the definition of ELRs (empty locked resources) lame; it
makes a thing complicated that was meant to become simple. Taking out the word
"essentially" is one step, replacing the normative language here is another. I'd
also like to point out that all the points listed here are entirely useless for
people who do not know or care about the previous LNR (lock null resource)
model, and *is* going to cause confusion. So, this really belongs into the
Changes section.
Section 7.3., para. 12:
OLD:
In the "locked empty resource" model, which is now the recommended
implementation, a resource created with a LOCK is empty but otherwise
behaves in every way as a normal resource. It is essentially the
same resource that would result from a PUT request with an empty body
where a Content-Type was not specified, followed by a LOCK request to
the same resource. A locked empty resource:
NEW:
In the "locked empty resource" model, which is now the recommended
implementation, a resource created with a LOCK is empty but otherwise
behaves in every way as a normal resource. It is the same resource
that would result from a PUT request with an empty body where a
Content-Type was not specified, followed by a LOCK request to the
same resource. A locked empty resource:
Section 7.3., para. 15:
OLD:
o SHOULD NOT disappear when its lock goes away (clients must
therefore be responsible for cleaning up their own mess, as with
any other operation or any non-empty resource)
NEW:
o Will not disappear when its lock goes away (clients must therefore
be responsible for cleaning up their own mess, as with any other
operation or any non-empty resource).
Section 7.3., para. 16:
OLD:
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.
(note: "MAY NOT" is not defined by any IETF spec :-)
Section 7.3., para. 18:
OLD:
o MUST NOT be converted into a collection. The server MUST fail a
MKCOL request (as it would with a MKCOL request to any existing
non-collection resource).
NEW:
o Can not be converted into a collection. The server will fail a
MKCOL request (as it would with a MKCOL request to any existing
non-collection resource).
Section 7.3., para. 19:
OLD:
o MUST have defined values for DAV:lockdiscovery and DAV:
supportedlock properties.
NEW:
o Will have defined values for DAV:lockdiscovery and DAV:
supportedlock properties.
Section 7.3., para. 20:
OLD:
o The response MUST indicate that a resource was created, by use of
the "201 Created" response code (a LOCK request to an existing
resource instead will result in 200 OK). The body must still
include the DAV:lockdiscovery property, as with a LOCK request to
an existing resource.
NEW:
o The response will indicate that a resource was created, by use of
the "201 Created" response code (a LOCK request to an existing
resource instead will result in 200 OK). The body must still
include the DAV:lockdiscovery property, as with a LOCK request to
an existing resource.
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Saturday, 4 February 2006 13:23:05 UTC