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

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

Le 20 juil. 2012 à 17:23, Jon Moore a écrit :

> On Fri, Jul 20, 2012 at 9:40 AM, Eric Prud'hommeaux <eric@w3.org> 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
> _______________________________________________
> ietf-types mailing list
> ietf-types@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-types