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

From: Jon Moore <[email-masked]>
Date: Tue, 10 Jul 2012 21:12:22 -0400

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.

Any guidance would be appreciated!

Thanks,
Jon
--
........
Jon Moore

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Jul 2012 09:24:57 +0200

> Given the recent arrival of HTTP PATCH in RFC 5789[1], it seems like

2+ years :-)

> Does anyone know where this landed? I'd like to pick up the torch and

Nowhere, as far as I can tell.

> Any guidance would be appreciated!

My recollection is that I got lost in the output format variations and 
potential copyrights.

So please go ahead; the IETF APPSAWG mailing list probably is a good 
place to get feedback.

Best regards, Julian

---

From: Jon Moore <[email-masked]>
Date: Wed, 11 Jul 2012 05:02:26 -0400

Well, 2+ years is pretty recent in IETF time. :)

Thanks for the guidance, I'll follow up with APPSAWG. 

Jon
........
Jon Moore

On Jul 11, 2012, at 3:24 AM, Julian Reschke <[email-masked]> wrote:

> My recollection is that I got lost in the output format variations and potential copyrights.
> 
> So please go ahead; the IETF APPSAWG mailing list probably is a good place to get feedback.
> 
> Best regards, Julian

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 19 Jul 2012 14:12:46 +0200

> if this had actually run into technical trouble, or if it just ran out

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

---

From: Jon Moore <[email-masked]>
Date: Thu, 19 Jul 2012 09:24:15 -0400

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

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 19 Jul 2012 15:39:36 +0200

Jon Moore <[email-masked]> writes:

> 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).

Agreed.

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

I would prefer one document, for easier review and less text
duplication.

/Simon

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Jul 2012 22:27:01 +0200

> practice.  Thus I lean towards a application/patch.

Could you elaborate of what exactly you think would be easier to specify 
using application/patch instead of text/patch?

Best regards, Julian

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 20 Jul 2012 12:38:14 +0200

Julian Reschke <[email-masked]> writes:

> Could you elaborate of what exactly you think would be easier to
> specify using application/patch instead of text/patch?

Some reasons that I had in mind were:

* There is no character set issues -- the encoder doesn't need to know
  which character encoding was used.  The specification doesn't have to
  talk about character sets (which makes up a big chunk of the current
  spec.)

* It can deal with diff's of files with different character sets,
  e.g. converting ISO-8859-1 files to UTF-8.  Like the draft says now,
  the text/* approach is unable to deal with this.

* Sometimes text/* parts are modified by gateways, and this is usually
  avoided by using an application/* type.  So the spec doesn't have to
  talk about these concerns.

However I support doing both media types.  For some situations,
text/patch is appropriate.

/Simon

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Jul 2012 13:17:10 +0200

On 2012-07-20 12:38, Simon Josefsson wrote:
> ...
> ...

The encoder needs to be aware of lines, which implies that it knows that 
octet sequence(s) are line endings.

>    the text/* approach is unable to deal with this.

I don't see that the problem is.

 From a media type of view, the patch consists on instructions how to 
patch certain lines in a text file. So to make this work properly, the 
encoding of both the patch and the file-to-be-patched need to be known, 
but they don't need to be the same.

>    talk about these concerns.

If a gateway every changed the charset, it would need to do it properly. 
Otherwise it's broken anyway (and I would be surprised if it handled 
PATCH properly).

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 20 Jul 2012 13:22:48 +0200

>but they don't need to be the same.

So, if you have a patch file that turns a ISO-8859-1 encoded file into
a UTF-8 encoded file, what would be "the encoding" of the patch file?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Jul 2012 13:48:41 +0200

> a UTF-8 encoded file, what would be "the encoding" of the patch file?

Always these trick questions :-)

So do you believe we need a variant that is encoding-agnostics except 
for CRLF detection?

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 20 Jul 2012 14:13:01 +0200

>So do you believe we need a variant that is encoding-agnostics except 

Certainly. An "encoding-aware" variant seems much less necessary.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: "Eric Prud'hommeaux" <[email-masked]>
Date: Fri, 20 Jul 2012 09:40:01 -0400

> Certainly. An "encoding-aware" variant seems much less necessary.

Writing off this use case means I don't need to know the *resulting*
character encoding, but that doesn't mean I don't want to know the
character encoding of a patch which someone mails me or I encounter on the
web. Presuming that the patch matches the target is unreliable and invites
a proliferation of doubly-encoded Ås and buried f'ed up authors' names and
math symbols.

If we then say that we need a charset parameters, a naive agent already has
what it needs to suss out line breaks and render text. I'd rather not see
two media types with no principled descriminator so I'd like to see text/
with the usual charset rules.

> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

---

From: Jon Moore <[email-masked]>
Date: Fri, 20 Jul 2012 11:23:30 -0400

On Fri, Jul 20, 2012 at 9:40 AM, Eric Prud'hommeaux <[email-masked]> wrote:
> character encoding, but that doesn't mean I don't want to know the character
> encoding of a patch which someone mails me or I encounter on the web.
> Presuming that the patch matches the target is unreliable and invites a
> proliferation of doubly-encoded Ås and buried f'ed up authors' names and
> math symbols.

Yes, I was thinking about this too. I believe for the application/*
format, we might want to have two (optional) parameters defaulting to
us-ascii, perhaps "source-charset" and "target-charset", as a way to
describe the "mixed" character set case (where I'm converting from
iso-8859-1 to utf-8, for example). Perhaps "charset" as a shorthand
for specifying both when they match. We'll have to document what the
precedence is among these options if they are over-specified, but this
seems tractable.

> with the usual charset rules.

Agreed. If a patch can be represented as a text/* type then it should
have a singular charset parameter describing the patch as a whole. The
draft I-D(*) I'm working up (https://github.com/jonm/text-diff)
already contemplates this.

Jon

(*) I don't think what I currently have there is a viable RFC
candidate, so I haven't formally submitted it as an I-D yet. On the
other hand, saying "draft Internet-Draft" begs a certain question, and
I don't have enough IETF experience to make the call. Is what's there
useful enough to start a conversation like this one (meaning I should
go ahead and issue version 00 of the I-D), or should I wait until I
think there's something closer to a "release candidate"? Any opinions?
........
Jon Moore

---

From: Paul Libbrecht <[email-masked]>
Date: Fri, 20 Jul 2012 20:46:09 +0200

Erm... source charset makes sense to me (this is "the charset of the patch").
But target charset makes no sense into a media-type... this is "after applying a patch" which is beyond the scope of a single file.

Paul

---

From: "Eric Prud'hommeaux" <[email-masked]>
Date: Fri, 20 Jul 2012 15:07:50 -0400

On Jul 20, 2012 8:46 PM, "Paul Libbrecht" <[email-masked]> wrote:
> But target charset makes no sense into a media-type... this is "after
applying a patch" which is beyond the scope of a single file.

Just to be clear, I am quite happy to write off the encoding transformation
use case. My argument was that, even without that use case, we need a
charset. Given that constraint, we may as well use the text tree.

> >> character encoding, but that doesn't mean I don't want to know the
character

---

From: Jon Moore <[email-masked]>
Date: Fri, 20 Jul 2012 16:49:18 -0400

> But target charset makes no sense into a media-type... this is "after applying a patch" which is beyond the scope of a single file.

No, the issue is that the patch file could have mixed charsets. If the
change is 'convert README from iso-8859-1 to utf-8', then the patch
file itself will have two character sets:

1. The lines that begin with '-' or ' ' will be iso-8859-1.
2. The lines that begin with '+' will be utf-8.

Since these are incompatible charsets (neither is a superset of the
other), we need two charset parameters to describe them, and this
patch is not capable of being a text/* document. I'm open to other
names besides 'source' and 'target', but I'm not sure how we get
around having two of them for this case.

Jon
-- 
........
Jon Moore

---

From: Paul Libbrecht <[email-masked]>
Date: Fri, 20 Jul 2012 22:55:52 +0200

> around having two of them for this case.

Thanks Jon,

that clarifies and makes sense.

I still believe you could ignore such a difference and expect the patch-application-engine to know the charset of its source and thus the normal (single) charset annotations would suffice.

Paul

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 21 Jul 2012 15:52:09 +0900

On 2012/07/21 5:49, Jon Moore wrote:
> On Fri, Jul 20, 2012 at 2:46 PM, Paul Libbrecht<[email-masked]>  wrote:

Just use application/patch. I don't think current diff programs are able 
to deal with character encoding parameters. I don't think people 
necessarily need to know the source/target encoding in the above 
example, unless something weird happens and they need to debug (in which 
case, they'll find out by themselves through trial and error anyway).

I also don't think there is much of a use case for:
- Originator: Has files in Latin-1, makes a diff in that encoding,
   sends to receiver.
- Receiver: Has files in UTF-8, wants to apply patch and wants a
   conversion from Latin-1 to UTF-8 to happen automatically.

So I very much agree with Björn here.

Regards,   Martin.

---

From: "Eric Prud'hommeaux" <[email-masked]>
Date: Sat, 21 Jul 2012 06:11:25 -0400

to deal with character encoding parameters. I don't think people
necessarily need to know the source/target encoding in the above example,
unless something weird happens and they need to debug (in which case,
they'll find out by themselves through trial and error anyway).
>   conversion from Latin-1 to UTF-8 to happen automatically.

I'm not saying that any conventional tools do this (though it would be nice
for them to grow into this functionality), but as someone who manages
public input on a fair number of docs, I receive a lot of 1252 or 8859
undermining my precious UTF-8 docs. If these are properly labeled, I can
iconv them our pull them into emacs and transcode them before applying
them.i expect that the burgeoning popularity of distributed version control
will accentuate this need as people become more adept at managing diffs.