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

On Jul 20, 2012 8:46 PM, "Paul Libbrecht" <paul@hoplahup.net> wrote:
>
> 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.

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.

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