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

>
>> 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).

> 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?

>
> 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.

- Jim