W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2006

[Bug 152] SHOULD_A_SERVER_DETERMINE_MIMETYPE_OF_CONTENT

From: <bugzilla@soe.ucsc.edu>
Date: Sat, 4 Feb 2006 05:23:00 -0800
Message-Id: <200602041323.k14DN0Wt007377@ietf.cse.ucsc.edu>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:13 GMT