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

[Jon Moore <[e-mail]>]

On Fri, Jul 20, 2012 at 9:40 AM, Eric Prud'hommeaux <[e-mail]> wrote:
> 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.

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.

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

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