Re: I-D for WebDAV methods - APPEND and PATCH

Jim Whitehead schrieb:

>>> patch-type is mapped to a set of content-types that it would work on.
>>> Using the content-type header to indicate the patch-type that would map
>>> against a set of content-types seemed confusing. But as I was reading 
>>> the
>>> earlier discussion, there were some convincing objections against 
>>> using a
>>> new header field. If the Content-Type header is the preferred way to
>>> define the patch format, we could proceed with that.
>>
>> You simply have to do that. RFC2616 *mandates* that when you send an 
>> HTTP message, the Content-Type header defines the type of the content. 
>> That's what it's for.
>>
> 
> There can potentially be multiple diff formats that use the same MIME 
> type for transport. For example, I can imagine multiple diff formats 
> that would use text/plain (i.e., most of the human-readable diffs in use 
> by version control systems today).

OK, there are two ways to approach that:

1) either make sure that each of the patch formats indeed has it's own 
MIME type,

2) use generic types, and have an additional request header specify the 
type of operation.

 From a spec writing point of view, 1) seems to be preferable to me. If 
you choose 2), you will essentially have to invent a new registry for 
types (IANA??), and have to maintain specifications for these types 
(which can be just pointers to existing specs). It's not entirely clear 
to me how this is better than registering MIME types for these formats.

>> The single issue with this spec (that eventually brought the previous 
>> attempt to a halt) is that there seems to be agreement that the spec 
>> should require at least one simple (!) patch format, and that needs to 
>> have a MIME type (either already defined or defined by this spec), and 
>> that needs to satisfy the IPR requirements of the IETF.
>>
> 
> Can you summarize the IPR issues that affected the previous specification?

As far as I can recall, there was no single patch algorithm where the 
format description could be easily be used in a standards-track 
document. But maybe back then we haven't looked hard enough.

Of course the alternative is to define the format in the spec itself, 
but if that format is identical/similar to another one, you still risk 
IPR problems, and you have the additional problem that your own 
description may be incomplete or buggy (thus duplicating the 
specification of the patch format maybe a bad idea).

>> Just use:
>>
>>         PATCH /~suma/index.txt HTTP/1.1
>>         Host: dav.cse.ucsc.edu
>>         Content-type: text/entity-append
>>
>>         Testing Append
>>         Hello World Again!!!
>>
>> And then let the spec define the MIME types for "text/entity-append" 
>> (appending to a resource with text/* MIME type) and possibly 
>> "application/entity-append" (binary).
>>
> 
> Hmm, I would think we'd just want an octet stream, and not differentiate 
> between text and binary append -- just send octets.

Binary append would be the standard use case. Text append could take 
advantage of re-encoding. Thus, I could append to a text/* resource 
without having to know it's encoding.

Best regards, Julian

Received on Tuesday, 8 August 2006 08:36:14 UTC