Re: MIME registration for application/gdiff

Lisa Dusseault wrote:
 > ...
> The design of the PATCH headers, and whether to use a MIME type in the 
> Content-Type field or whether to apply an instance manipulation, has 
> already been discussed in the HTTP Working Group mailing list somewhat, 
> so I'm cc'ing ietf-http-wg and bcc'ing ietf-types (in replying to 
> Martin's mail on ietf-types).
> 
> I wasn't aware of any servers that actually allowed content negotiation 
> between static representations.  I did think about this problem, but as 
> far as I know there's no standard way of telling the server to create a 
> new representation of an existing resource.  What happens if you have a 
> resource that is in one Content-Type and you PUT a body that's another 
> Content-Type?  I would think the correct action would normally be for 
> the server to replace the resource with one of a new Content-Type.  How 
> do you create a new representation of an existing resource in a new 
> content type and how does that request differ from overwriting an 
> existing representation with the new content type?
> 
> How does <http://www.w3.org/International/iri-edit/draft-duerst-iri> 
> work?  Is it a dynamic resource where the different output content types 
> are generated from XML by the server?  Or is it really a static resource 
> that has several static stored representations of different types?  If 
> it's the former, then there's no problem with PATCH as designed, as far 
> as I can see.  If it's a static resource, then I'd need to know how 
> those different representations are created and modified, as I'm unaware 
> of any standard way of doing so.

I agree that the issue of PATCHing a content-negotiated resource is 
identical to applying PUT to it. So whatever the answer for PUT is, it 
also should apply to PATCH.

As far as I know, the current wisdom seems to disallow put on a 
content-negotiated resource, and to modify the "content" resource 
(Content-Location response header, see 
<http://greenbytes.de/tech/webdav/rfc2616.html#header.content-location>) 
instead.

Best regards, Julian

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

Received on Monday, 27 September 2004 16:48:14 UTC