Re: [ietf-types] Status of application/patch or text/patch?

[Jon Moore <[e-mail]>]

I think application/{diff,patch} and text/{diff,patch} both have their places. The application/* version will be easier to specify, for sure. However, a very, very common use case for diff is exchanging source code diffs against ASCII-encoded files; being able to have a text/* version means, for example, that many clients will be able to treat them as generic text files--for example, a browser could just display the diff rather than downloading it. So the text/* version might be more generally consumable. 

There are probably some very simple rules by which a producer could run 'diff' and know that the output could be labelled 'text/diff' without much extra work (for example, if the two documents given as arguments to diff have the same encoding, and it is one of us-ascii, iso-8859-*, or utf-8,then you're good). 

My intent would be to document both media types. Does anyone have opinions regarding whether this should be one or two RFCs?

Jon
........
Jon Moore


On Jul 19, 2012, at 8:12 AM, Simon Josefsson <[e-mail]> wrote:

> Jon Moore <[e-mail]> writes:
> 
>> Hi folks,
>> 
>> Given the recent arrival of HTTP PATCH in RFC 5789[1], it seems like
>> registering a media type for the output of the 'diff' utility would be
>> a good idea. I found this thread from 2007 where Julian Reschke
>> proposed this exact thing:
>> 
>> http://www.ietf.org/mail-archive/web/ietf-types/current/msg00591.html
>> 
>> Does anyone know where this landed? I'd like to pick up the torch and
>> at least work on text/diff (using the unified diff format, and limited
>> to those diffs that can be rendered as valid text/* types). I've
>> started putting together an Internet Draft for it, but was wondering
>> if this had actually run into technical trouble, or if it just ran out
>> of steam in 2007.
> 
> The issue of how to deal with different character encodings were
> unresolved, and I think it is important to get right.  The approach to
> specify an application/patch is the easy way out.  Trying to resolve it
> for a text/patch may be possible, but I fear it will be problematic in
> practice.  Thus I lean towards a application/patch.
> 
> /Simon