Re: Comments on draft-dusseault-http-patch-06

Lisa Dusseault wrote:
>> On Oct 17, 2004, at 3:52 PM, Lisa Dusseault wrote:
> ...
> I do realize that RFC2616 is ambiguous, and I don't mean to justify one 
> theory based on legalistic readings of the spec.  On the one hand, 
> RFC2616 says "Content-Type specifies the media type of the underlying 
> data.".  On the other hand, RFC2616 says "Any HTTP/1.1 message 
> containing an entity-body SHOULD include a Content-Type header field 
> defining the media type of that body."  Both these sentences are in 
> section 7.2.1! The first sentence seems to support RFC3229's model; the 
> second sentence seems to support your (Roy's) preferred model.  
> Standards are rarely perfect; ambiguous language like this leaves lots 
> of room for interpretation of how the model can be refined and how HTTP 
> can be extended.  So I tend to devalue arguments based only on selected 
> text from the standard; I'd like to hear more arguments based on harmful 
> intermediary interactions or implementation concerns.

Quoting the section fully 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.7.2.1>):

 >> 7.2.1 Type

When an entity-body is included with a message, the data type of that 
body is determined via the header fields Content-Type and 
Content-Encoding. These define a two-layer, ordered encoding model:

        entity-body := Content-Encoding( Content-Type( data ) )

Content-Type specifies the media type of the underlying data. 
Content-Encoding may be used to indicate any additional content codings 
applied to the data, usually for the purpose of data compression, that 
are a property of the requested resource. There is no default encoding.

Any HTTP/1.1 message containing an entity-body SHOULD include a 
Content-Type header field defining the media type of that body. If and 
only if the media type is not given by a Content-Type field, the 
recipient MAY attempt to guess the media type via inspection of its 
content and/or the name extension(s) of the URI used to identify the 
resource. If the media type remains unknown, the recipient SHOULD treat 
it as type "application/octet-stream".  <<

I think that's clear enough, specifically the first sentence.

 > ...
> I did realize one advantage of the PATCH with IM approach, and that is 
> to create a new resource of a specified type.  For example:
> 
>        PATCH /file.ics HTTP/1.1
>        Host: www.example.com
>        Content-Type: text/calendar;component=VEVENT
>        IM: vcdiff
>        If-Match: "e0023aa4e"
>        Content-Length: 100
> 
>        [vcdiff-bytes]
> 
>  >>Response:
> 
>        HTTP/1.1 201 Created
>        ...
> 
> This would create a new file of type text/calendar.  With the PATCH -05 
> proposal, there wasn't a way to use PATCH to create a new resource and 
> assign the correct MIME type to begin with.

If this is a required feature, it could be implemented using a new 
request header.

Anyway, if the change between 05 and 06 just was based on the problems 
registering a MIME tyoe, then I think that was the wrong approach to 
solving it.

Proposal: as both GDIFF (unclear IPR and no MIME type) and VCDIFF 
(unclear source license and complexity?) seem to be problematic as 
REQUIRED delta format, we may want to sit down and come up with a really 
simple delta format and use *that* in the PATCH spec (either in-line or 
in a separate document).


Best regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Monday, 18 October 2004 17:43:34 UTC