Re: FYI: I-D ACTION:draft-dusseault-http-patch-02.txt

That's certainly one way to model the interaction -- that the delta 
data is a manipulation of some instance.  However, I'm not sure yet why 
we can't model the patch as simply the entity->instance that the client 
wishes to send to the server.

If we were to use PUT, and model the IM header as indicating what the 
delta format in the body was and how to apply it to the resource 
already there, then I agree we'd have to model patching as an instance 
manipulation.  But re-using PUT seems a little scary and I haven't even 
had anybody suggest that.

Note that modeling the delta as an instance manipulation -- and using 
IM header -- would possibly create a dependency on RFC 3229.  But it's 
not really the same as 3229 because that spec doesn't define the IM 
header as a client request header -- so we'd also have to define what 
the server must do with the IM header and which instance manipulations 
it had to support.

Generally, the entity-instance-manipulation model isn't as clearly 
defined for client requests as it is for server responses -- nor should 
it be, and it may simply not be needed there as much.

Lisa

On Jul 9, 2004, at 11:44 AM, Jeffrey Mogul wrote:

>     On Fri, 2004-07-09 at 12:42, Lisa Dusseault wrote:
>> As you point out, not all deltas apply to all formats.  That makes it
>> harder for the server to create an empty representation to patch.  How
>> would it work for, say, GDIFF?  What kind of file would the server
>> create?  Would it be a text/plain file or some other MIME type?
>
>     Ultimately, servers are going to have to choose a patch application
>     method based on the content-type of the PATCH content.  That 
> method will
>     know what it can patch, and will have to indicate an error should 
> it be
>     applied inappropriately - empty or non-existent resources are edge 
> cases
>     that don't need to be discussed at all in the description of PATCH.
>
> I tend to think of "edge cases" not as details that could be left
> out of the specification, but as test cases for whether the 
> specification
> makes sense.  I think we would normally prefer to see a simple
> specification that adequately covers the edge cases (without special
> treatment) rather than one that doesn't, or one that ends up with
> layers of complexity to cover edge cases.
>
> At the risk of sounding like a broken record, this seems to me
> like a clear justification for separating "content-type" and
> "instance-manipulation".  That is, in the PATCH request, use
> IM to describe what kind of delta format (or range update, or
> whatever) is being applied, and use Content-Type to indicate
> the, umm, Content-type of the resource being updated.
>
> In the normal case (the resource already exists), the Content-type
> header of the request is either redundant, or (if you're paranoid) a
> way of doing type-checking.  In the edge case (no resource yet),
> the Content-type header tells the server what to create.  Seems
> simple to me :-)
>
> -Jeff

Received on Friday, 9 July 2004 15:04:01 UTC