W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2004

Re: MIME registration for application/gdiff

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 27 Sep 2004 18:47:30 +0200
Message-ID: <41584422.1020103@gmx.de>
To: Lisa Dusseault <lisa@osafoundation.org>
CC: Martin Duerst <duerst@w3.org>, HTTP working group <ietf-http-wg@w3.org>, Linus Walleij <triad@df.lth.se>

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 

Best regards, Julian

<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Monday, 27 September 2004 16:48:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:38 UTC