Subject: Re: [Fwd: Re: I-D for the PATCH method]

From: Lisa Dusseault <[email-masked]>
Date: Tue, 15 Aug 2006 16:15:12 -0700

On Aug 15, 2006, at 4:01 PM, Suma Potluri wrote:

>
>> OK, there are two ways to approach that:
>>
>> 1) either make sure that each of the patch formats indeed has it's  
>> own
>> MIME type,
>>
>> 2) use generic types, and have an additional request header  
>> specify the
>> type of operation.
>>
>>  From a spec writing point of view, 1) seems to be preferable to  
>> me. If
>> you choose 2), you will essentially have to invent a new registry for
>> types (IANA??), and have to maintain specifications for these types
>> (which can be just pointers to existing specs). It's not entirely  
>> clear
>> to me how this is better than registering MIME types for these  
>> formats.
>>
>
> Since using the content-type header for the patch format seems to  
> be the
> preferable in general, we could update the draft accordingly. The  
> required
> patch format text/normal-diff could be the used for text files and  
> another
> (optional??) patch format application/gdiff could be used for all
> resources. The normal-diff format for text files seems to be  
> preferable
> over the gdiff format because it is a widely used diff format and  
> could be
> easily generated by the clients using the existing tools. We can  
> include
> the MIME type registration information in the draft for text/normal- 
> diff
> and application/gdiff patch formats.

Do you have a proper reference for the normal-diff format?  Are you  
legally allowed to document it yourself in an Internet-Draft?  If  
not, it might be difficult in practice to register a MIME type for  
the normal-diff algorithm.  Part of the IETF's attempt to generally  
protect software developers from the position of having to implement  
a standard requiring technology they're not allowed to use.

Lisa

---

From: "Suma Potluri" <[email-masked]>
Date: Tue, 15 Aug 2006 16:01:09 -0700 (PDT)

> 1) either make sure that each of the patch formats indeed has it's own
> MIME type,
>
> 2) use generic types, and have an additional request header specify the
> type of operation.
>
>  From a spec writing point of view, 1) seems to be preferable to me. If
> (which can be just pointers to existing specs). It's not entirely clear
> to me how this is better than registering MIME types for these formats.
>

Since using the content-type header for the patch format seems to be the
preferable in general, we could update the draft accordingly. The required
patch format text/normal-diff could be the used for text files and another
(optional??) patch format application/gdiff could be used for all
resources. The normal-diff format for text files seems to be preferable
over the gdiff format because it is a widely used diff format and could be
easily generated by the clients using the existing tools. We can include
the MIME type registration information in the draft for text/normal-diff
and application/gdiff patch formats.

Jim Whitehead didn't think that there would be any issue with the IPR
requirements for the gdiff patch format. But if anyone knows better, we'd
like to know.

> Binary append would be the standard use case. Text append could take
> advantage of re-encoding. Thus, I could append to a text/* resource
> without having to know it's encoding.
>

OK I agree that APPEND could be a special case of the PATCH method. And if
there is sufficient interest to keep the append free from the patch
formats, we could define a new MIME type such as application/entity-append
as you've suggested earlier.

-Suma

---

From: "Suma Potluri" <[email-masked]>
Date: Tue, 15 Aug 2006 16:34:34 -0700 (PDT)

> a standard requiring technology they're not allowed to use.

The normal-diff format is a part of the GNU project which is free
software. I added a reference to this in the Internet-Draft.

http://www.gnu.org/software/diffutils/manual/diff.html

I found this on the gnu home page (http://www.gnu.org/home.html)

"We support the FSF's mission to preserve, protect and promote the freedom
to use, study, copy, modify, and redistribute computer software, and to
defend the rights of Free Software users. "

I felt that this was sufficient information to use the normal-diff format.
But I'd like to know if anyone has more information that would restrict
its use for this purpose.

Thanks,
-Suma

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 15 Aug 2006 17:53:10 -0700

I believe this URL is not a stable reference, which a RFC would need  
to have.  It looks like the GNU organization could update the  
algorithm and change the man page -- there's no versioning  
information or guarantee that it's a final version.  It's also not  
adequate by itself as a normative reference because there are options  
like whether to suppress blank lines -- those options would have to  
be nailed down if the single point of negotiation is the MIME type.

I understand that the GNU license allows us to copy the spec text  
entirely: the page you link to says "Verbatim copying and  
distribution of this entire article is permitted in any medium,  
provided this notice is preserved. ".  Still, that doesn't  
necessarily mean one can excerpt and rewrite the man page, nor does  
it mean that implementations can freely use the algorithm without  
being subject to other GNU licensing conditions.  IANAL, but I worry  
whether using a GNU algorithm could mean that software written to  
conform to a PATCH specification would be forced to be open source!

If you want to pursue using this diff format, we'd have to  
investigate these issues at some point.

Lisa

---

From: Joe Feise <[email-masked]>
Date: Tue, 15 Aug 2006 22:06:41 -0700

> investigate these issues at some point.

diff predates the FSF and GNU by a large margin.
A quick search shows that the algorithm was implemented in the early 1970s and
described by James Hunt and Doug McIlroy in 1976 in a Bell Labs tech report:
http://www.cs.dartmouth.edu/~doug/diff.ps
Bibtex reference (http://www.cs.dartmouth.edu/~doug/doug.bib):
@techreport{McIlroy76b,
   author = {J. W. Hunt and M. D. McIlroy},
   title = {An Algorithm for Differential File Comparison},
   institution = {Bell Laboratories},
   address = {Murray Hill, NJ},
   number = {CSTR 41},
   year = {1976}
}

It is my understanding that what is now called "normal diff" was the original
implementation's output. Context and unified outputs were added later.

-Joe