Re: PATCH Draft

Lisa Dusseault wrote:
> 
> Hi Mark,
> 
> I fail to understand the overall thrust of your proposed changes. 
> Several are proposals for removing requirements   with little to gain
>> from removing them.  I'd like to see a lot more benefit to removing a 
> requirement before opening up what should be a simple feature to more 
> variation and complexity.

Well, on the other hand I'd prefer to see a lot more benefit for having 
a requirement in the first place, in particular if it wasn't in RFC2068.

> Specific comments inline,
> 
> On Jul 4, 2007, at 11:07 AM, Mark Baker wrote:
> 
>>
>> "The server MUST NOT create a new resource with the contents of the
>> request body"
>>
>> Why not?  I don't see the problem.
> 
> This is to require that the server not treat the PATCH like a PUT.  If 
> there's a way to *apply* the patch to an empty body that might be fine, 
> but the server should not save the delta algorithm as the resource body. 
> If that's what the client wanted, it would do a PUT.

Yes. So it seems we agree there are use cases to allow PATCH to act on 
"non-existing" resource, so a MUST NOT requirement is clearly a bad 
thing here.

If the concern is that some servers may do the wrong thing when there's 
no existing entity, just add a warning/explanation.

 >> ...
>> "Therefore, the client MUST verify that it is applying the delta
>> encoding to a known entity by first acquiring the strong ETag [...]"
>>
>> I don't see why this is required.  Of course, if the client wants the
>> guarantees provided by strong etags, it can get them.  But why does
>> that matter to a protocol specification?  Suggest removal of that
>> paragraph.
> 
> Why remove it?  What's the harm in making this requirement that clients 
> behave properly?

As previously stated, there are many use cases for PATCH where a client 
doesn't care what the current state is, such as for an append-like 
operation.

>> I suggest the use of 422 instead of 400 in the "malformed delta
>> encoding" case of sec 2.2.2.
> 
> What's 422?

Hint: it's defined in RFC4918 :-). (as in RCF2518).

>> Sec 2.3 seems to over specify a few things.  For example, the Allow
>> response header isn't required to list "all the allowed methods" so
>> there's no need for "MUST" there.  I think that all you really need in
>> this section is the definition of the Accept-Patch header.
> 
> The benefit of this requirement is so that clients can count on the 
> Allow header for at least this case.  What's the harm of this requirement?

The harm is that the spec walks into a territory where it doesn't need 
to go. Is there any benefit in *practice* from having stricter 
requirements for Allow/PATCH compared to Allow/RFC2616?

 > ...

Best regards, Julian

Received on Wednesday, 4 July 2007 20:59:04 UTC