Subject: PATCH thoughts...

From: Justin Chapweske <[email-masked]>
Date: Wed, 28 Apr 2004 16:45:29 -0500

Hello Lisa,

The PATCH proposal is interesting and well designed for the task at
hand.  A couple of thoughts:

o I'm concerned that the provided use cases for PATCH is a bit too
narrow and the system may not be flexible enough to encompass future use
cases.

For example, it may be desirable to create a new file that is the
combination of the PATCH request body and a totally different resource,
rather than patching a file in place.

Another possible use case is that it may be desirable to have the patch
body retrieved from a third-party URI rather than embedded directly in
the request.

Of course, at a quick blush you could simply say that these cases are
out of scope.  But, I think it is worth thinking deeper about the
problem space to see if an even more generic solution doesn't arise.

o Secondly, I would like to see PATCH advocate at least one generic
binary delta format.  Unless I am mistaken, gdiff is only useful for
text documents.

Thanks for your time and effort in writing this document.

-Justin

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 28 Apr 2004 15:21:06 -0700

Would it solve all these use cases if we provided a "Source: <url>" 
header?  The job of the server is then to take the Source resource, 
apply the patch body, and save it at the destination (the request URI). 
  I'd probably define this so that if the Source header were missing, 
then the Request URI is both the source and the destination.

Would anybody else find this useful?

Bear in mind that I'm not trying to solve all use cases.  Narrow use 
cases are a great thing to actually make progress and get to standard.  
This may be one of the situations where it's pretty safe to extend the 
use cases and functionality but we'll see.

lisa

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 28 Apr 2004 23:21:15 +0100

> binary delta format.  Unless I am mistaken, gdiff is only useful for

Is there a binary delta format being used, or planned, for delta
transmission of cached documents?

What I mean is that if I have a cached entity with etag "abcdefg", and
I request it with If-None-Match, then maybe a server or cache could
send me the delta between what I have and the current entity - just to
reduce bandwidth.

If there's such a standard being proposed or even still being
designed, it would probably be good to pick the same binary delta
format.

-- Jamie

---

From: Jeffrey Mogul <[email-masked]>
Date: Wed, 28 Apr 2004 15:32:53 -0700

IETF Proposed Standards:
    RFC3229: Delta encoding in HTTP
	    http://www.ietf.org/rfc/rfc3229.txt

    RFC3284: The VCDIFF Generic Differencing and Compression Data Format
	    http://www.ietf.org/rfc/rfc3284.txt

RFC3229 lists a few other possible formats, but vcdiff seems
to be the consensus (among experts in the area) for the best
choice.

-Jeff

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 28 Apr 2004 16:40:04 -0600 (MDT)

On Wed, 28 Apr 2004, Lisa Dusseault wrote:

> header?

Would Content-Location header be appropriate for this purpose?

   The Content-Location entity-header field MAY be used to supply the
   resource location for the entity enclosed in the message when that
   entity is accessible from a location separate from the requested
   resource's URI.

> The job of the server is then to take the Source resource, apply the
> patch body, and save it at the destination (the request URI).  I'd
> probably define this so that if the Source header were missing, then
> the Request URI is both the source and the destination.

Sounds like a too complicated task for a web server, especially if
source URI points to a different server. Also opens a nice door for
"outsourcing" DoS attacks. If a server supports patching "local"
objects only, how can it indicate that?

> Would anybody else find this useful?

It would be nice to see a real use case for that feature.

> use cases and functionality but we'll see.

For a given scope, starting with a minimal but extendible
functionality is ideal, of course. IMHO, if you think Source URI or
equivalent feature can be added to your core PATCH protocol without
core modifications, then do not add it. Let others document that
extension when/if needed! If core modifications are required, then it
becomes a question of either protocol scope or protocol extensibility.

Alex.

> > narrow and the system may not be flexible enough to encompass
> > future use cases.
> >
> > combination of the PATCH request body and a totally different
> > resource, rather than patching a file in place.
> >
> > Another possible use case is that it may be desirable to have the
> > patch body retrieved from a third-party URI rather than embedded
> > directly in the request.
> >
> > Of course, at a quick blush you could simply say that these cases
> > are out of scope.  But, I think it is worth thinking deeper about
> > the problem space to see if an even more generic solution doesn't
> > arise.

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 28 Apr 2004 15:42:43 -0700

You're in luck, GDIFF is entirely generic.

"The format does not make any assumptions about the type or contents of 
the files, and thus can be used to describe the differences between 
text files as well as binary files."

http://www.w3.org/TR/NOTE-gdiff-19970901

Lisa

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 28 Apr 2004 15:47:29 -0700

Only partial answers inline...

>    entity is accessible from a location separate from the requested

I don't think so -- that implies something different.  Could be 
confusing.  In this case we're thinking of providing a URL that isn't 
the resource location for the enclosed entity.

> objects only, how can it indicate that?

Agreed, I'd propose only supporting local resources as a MUST or 
SHOULD, and define an error whenever the server didnt' want to follow 
the link to the source.

> becomes a question of either protocol scope or protocol extensibility.

It can't be added without core modifications, unfortunately -- it is a 
required-to-understand header, otherwise the server would ignore it and 
do something the client didn't want to do.  Unless there's a 
"mandatory" flag for headers that's actually widely supported that I'm 
unaware of.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 28 Apr 2004 15:51:52 -0700

> apply the patch body, and save it at the destination (the request  
> URI).  I'd probably define this so that if the Source header were  
> missing, then the Request URI is both the source and the destination.
>

No, I would find it actively harmful.  The same can be accomplished
by a MOVE followed by a PATCH without introducing unnecessary
complexity and without requiring servers that have no interest in
that feature to embed client code just to support it.

Please note that PATCH was originally defined in section 8.6 of

http://ftp.ics.uci.edu/pub/ietf/http/history/draft-ietf-http-v11-spec- 
01.txt

....Roy

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 28 Apr 2004 17:00:12 -0600 (MDT)

On Wed, 28 Apr 2004, Lisa Dusseault wrote:

> It can't be added without core modifications, unfortunately -- it is
> a required-to-understand header, otherwise the server would ignore
> it and do something the client didn't want to do.

Good point. I guess you are being bitten by the HTTP inability to
specify required-to-understand extensions without negotiation.

One way to "solve" the problem without modifying your core is to
require compliance with the HTTP extensions RFC 2774 or equivalent.
That way others can add Source-to-Patch, Patch-Source, and many other
headers without modifying the PATCH core.

Alex.

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 28 Apr 2004 16:01:25 -0700

Or a COPY followed by a PATCH.  Good point.  I agree.

Who should I acknowledge for the original definition of PATCH?

Lisa

On Apr 28, 2004, at 3:51 PM, Roy T. Fielding wrote:

> http://ftp.ics.uci.edu/pub/ietf/http/history/draft-ietf-http-v11-spec 
> -01.txt
>
> ....Roy
>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 28 Apr 2004 16:10:43 -0700

> Who should I acknowledge for the original definition of PATCH?

Me and Henrik, I guess, though you can simply mention that it was
originally proposed in early drafts HTTP/1.1, but removed from that
specification due to lack of maturity compared to the core protocol
and based on the theory that the at-that-time future WebDAV group
would take it up eventually.

....Roy

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 29 Apr 2004 10:00:57 -0700

I looked into VCDiff a little more.
  - RFC3283 doesn't define a MIME type for VCDiff.
  - RFC3229 uses VCDiff but since there isn't a MIME type simply uses 
the string 'vcdiff' to identify it.

Sadly, in looking up the MIME registry I discovered that even though 
the W3C note for GDIFF defines a MIME type 
(http://www.w3.org/TR/NOTE-gdiff-19970901), that MIME type does not 
appear in the registry.  So that leaves us with no diff formats with 
registered MIME types.  I had thought that having a registered MIME 
type was the one reason to use GDIFF above others but that's not true 
after all.

I really don't know which delta formats are likely to be most commonly 
available besides diff -e (also mentioned in RFC3229).  I also don't 
have a strong allegiance to using MIME types over short strings as 
RFC3229 does, except that some of the use cases will certainly involve 
XML diff (or transformation) file definitions, and MIME registration 
avoids conflicts there.

So please voice your opinions on this issue to help me off this fence.  
Should PATCH require support for one diff format, and if so, what?  
Should it use MIME types or strings to identify diff formats?  Should 
it register MIME types for VCDiff and/or GDiff (ouch)?

Lisa

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 29 Apr 2004 12:13:34 -0600 (MDT)

On Thu, 29 Apr 2004, Lisa Dusseault wrote:

> So please voice your opinions on this issue to help me off this
> fence.  Should PATCH require support for one diff format, and if so,
> what?

Is there a diff format that accommodates all of these:
	- text patching with fuzzy offsets (like Larry Wall's patch)
	- binary patching based on offsets
	- patching not based on offsets

If yes, use it at a SHOULD level. If not, then it looks like it would
be a mistake to pick a "winner" at this time.

> Should it register MIME types for VCDiff and/or GDiff (ouch)?

Looks like out of PATCH scope to me. Can be done in a separate
document if needed.

$0.02,

Alex.

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 30 Apr 2004 10:50:05 +0100

> 	- patching not based on offsets

Larry Wall's patch (when given unified or context diffs) can be used
without fuzzy offsets (just disable fuzzy matching in the patcher),
and it can be used on binary files (ugly an inefficient, because it's
still line based and depends crucially on LF bytes).  It doesn't use
byte offsets in either case.

> be a mistake to pick a "winner" at this time.

I agree, there isn't a suitable "winner" at this time.

What does DAV + Delta-V propose at the moment?

The obvious format for PATCH is to pick the same format that can be
_fetched_, CVS-style, to update a workspace.  Is that in Delta-V?

Another capability to aim for is a patch format that is helpful for
resolving fuzzy matches in a 3-way merge in the same way as CVS-style
merging -- again, choose the same as Delta-V.

Finally, it would be nice to have VCDIFF-style compression integrated,
although compressing normal patches works ok so it's not that important.

-- Jamie

---

From: Julian Reschke <[email-masked]>
Date: Fri, 30 Apr 2004 12:05:37 +0200

> What does DAV + Delta-V propose at the moment?

Nothing.

 From a simple DAV p.o.v., simulating file i/o (skip, write, truncate) 
may be enough.

DeltaV probably would benefit more from a "true" patch format, such as 
gdiff.

Note that the former case seems to be a subset of the latter.

> _fetched_, CVS-style, to update a workspace.  Is that in Delta-V?

No. But it maybe in Subversion. Is a Subversion developer following this 
thread? Greg S.?

> merging -- again, choose the same as Delta-V.

Yep, but that's something we don't want as REQUIRED support. Let's focus 
on the simple things first, and then let extensibility take care of the 
rest.

> although compressing normal patches works ok so it's not that important.

If normal HTTP compression works fine, there's no reason to complicate 
the method.

Regards, Julian

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

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 30 Apr 2004 08:37:37 -0700

There's no diff format chosen by DeltaV, but RFC3229 identifies several 
for HTTP:

VCDIFF is a RFC, and GDIFF is a W3C Note -- those have been used by 
IETF in the past.

Lisa