Re: [media-types] Mime type for patch files?

["Eric Prud'hommeaux" <[e-mail]>]

On Thu, Nov 1, 2018 at 8:23 AM Henrik Andersson <[e-mail]> wrote:
>
> Eric Prud'hommeaux skrev:
> > I think this negotiation must happen with the tool maintainers which
> > currently recognize text/x-{patch,diff}. Given that that's probably
> > impossible, the answer is almost certainly that you are stuck with
> > "x-". Thanks for picking this up.
> >
> > I tried to answer your question but ended up puzzled by this text in
> > [RFC6838]:
> > [[
> >    Note that types with names beginning with "x-" are no longer
> >    considered to be members of this tree (see [RFC6648]).  Also note
> >    that if a generally useful and widely deployed type incorrectly ends
> >    up with an "x-" name prefix, it MAY be registered using its current
> >    name in an alternative tree by following the procedure defined in
> >    Appendix A.
> > ]]
> >
> > The only "x-" subtree in [IMT] is "x-www-form-urlencoded", and maybe
> > it's an exception. The tricky question is whether x-{diff,patch}
> > deserve the same exception. On one hand, we don't want a slippery
> > slope of exceptions, on the other hand, the tree's job is to document
> > current or achievable reality.
> >
> >
> > [RFC6838] https://tools.ietf.org/html/rfc6838#section-3.4
> > [IMT] https://www.iana.org/assignments/media-types/media-types.xhtml#application
> >
> In short, don't use the "x-" prefix. And don't use the "x." prefix
> either. Those explicitly mean "not registered". The mentioned exception
> is a sad reality that only came to pass because of the insane costs to
> change it. There are no such costs here.

That depends on the levers we have available. I was assuming that we
can't change the
deployed media type to get rid of the "x-". It appears that some of
the tooling makes that not too problematic because it has
infrustructure for aliases. I'm all in favor of getting rid of "x-"
when possible. It's possible the right thing to do is to register all
four (or maybe only one of text/{diff,patch} and gradually migrate the
tooling (a non-trivial task as i've been seeing tools DTRT with
patches for decades). A dual registration reflects both current and
intended reality, which is arguably its purpose.
-- 
-ericP
office: +1.617.258.5741
mobile: [phone]