Re: PATCH Draft

Henrik Nordstrom wrote:
> mån 2007-06-25 klockan 22:27 +0200 skrev Stefan Eissing:
> 
>> Personally, I think this is not helpful. PATCH cannot require servers  
>> to support such a format. For every format it is trivial to think of  
>> an application where it does not make sense.
> 
> Sure, but for interoperability it helps a lot if there is at least one
> text and one binary format that most clients can expect to be supported
> on most servers, therefore one or two recommendations on formats to use
> helps a lot.

Sort; that depends on the context. I do agree that it would be good if 
all WebDAV servers that support arbitrary binary content support the 
same binary patch format. Likely, it would be good if all AtomPub 
servers that do support PATCH agree on a patch format for entries.

But I just don't see how the PATCH spec can mandate that. And also 
consider that as of now there's not a single well-defined, IPR-free and 
media-typed format we *could* mandate or even recommended.

Let's de-couple these efforts. Trying not to was one of the reasons 
there hasn't been any progress on this for 2.5 years.

> This do not mean that every server MUST support those formats, or that
> there SHOULD NOT be any other formats supported. Only that there is an
> established recommendation on what formats to use unless there is strong
> reasons not to, in order to make interoperability reasonable.
> 
>>>   * Should it be possible to create new resources with PATCH
>> Non-issue in my mind: up to the application. See above.
> 
> I disagree. Part of this should be in the protocol. Most importanly if
> it should be possible for the client to ask the server that a new
> resource should be created based on another "template" resource and a
> delta.

That's interesting but seems to be a new requirement (new request 
header?). Also, it sounds that's already solved by COPY.

Independently from that, I think PATCH must allow servers to support 
patch formats that create new resources; insisting on a prior PUT of an 
empty body is just silly.

>>>   * Should it be required to use If-Match and If-Unmodified-Since
>>>     on PATCH.
>> Definitely not. Let's say subversion wants to use PATCH, using the  
>> good old diff format on text files. It is definitely counter- 
>> productive to require it to fail on changed ETags when it clearly  
>> does not want to.
> 
> I'd say it should be a SHOULD requirement unless the delta format in
> question has it's own conflict resolution.

Sounds like overspecification. People will do the right thing without 
the spec making requirements here.

>> On the other hand, one can think of applications using PATCH to save  
>> bandwidth. Using some simple binary patch format. Such applications  
>> will make heavy use of If-Match headers and rightly so.
> 
> Needs to be clearly mentioned, or I'm afraid there will be lots of
> implementations which overlooks this.

No problem with mentioning that.

>> Replace: "The server MUST NOT create a new resource with the contents  
>> of the request body, although it MAY (depending on the delta  
>> encoding) apply the request body to an empty resource."
>> By: "If the server accepts PATCH on a non-existing resource is up to  
>> the server implementation."
>> Reason: there may be applications where it makes sense, others might   
>> strictly forbid it.
> 
> Why? There is already the PUT method for creating entities. Unless we
> talk about creating a resource from a template + delta ofcourse..

Use cases:

- define a PATCH format that can bundle data and metadata (body + WebDAV 
properties, media resource + atom entry) into a single, atomic request

- create/append access

So no, I don't think a restriction to existing resources makes sense in 
general. See also RoyF's comment in 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2004AprJun/0086.html>:

RF> There is no reason to require that the resource already exists
RF> (such a requirement is nonsensical in any case, since in HTTP the
RF> resource is the temporal invariance found in mapping of URI to content,
RF> not some file in storage).  The requirement should be that the PATCH
RF> media type define whether an existing representation is necessary
RF> or not, which is trivial for the server to discover when applying
RF> the patch (it is a conflict, like any other conflict).


>> Idea: Only describe difference of PATCH responses to PUT responses
> 
> Perhaps.
> 
>> Idea: should "Accept-Patch" header also appear in responses to PATCH?
> 
> Yes, I'd say so. The modified resource do not need to support further
> PATCH modifications, depending on the application.

Good point.

Best regards, Julian

Received on Tuesday, 26 June 2007 10:26:57 UTC