- From: Jim Whitehead <ejw@soe.ucsc.edu>
- Date: Mon, 7 Aug 2006 16:22:53 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Suma Potluri <suma@soe.ucsc.edu>, w3c-dist-auth@w3.org
> >> 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
Received on Monday, 7 August 2006 23:23:19 UTC