Subject: [Bug 152] SHOULD_A_SERVER_DETERMINE_MIMETYPE_OF_CONTENT

From: [email-masked]
Date: Tue, 17 Jan 2006 10:54:59 -0800

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

[email-masked] changed:

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

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