Re: [apps-discuss] draft-ietf-appsawg-xml-mediatypes vs. JSON and BOM and UTF-8

[Larry Masinter <[e-mail]>]

> > It cannot be right that everyone specifying a text-based media type should
> > have to go through the process of deciding, for themselves, independently,. ...


> It may not be "right" but it is the reality of the situation.

Agree it's the reality.

> > If the future is UTF-8, UTF-8, UTF-8, then the two documents should say so,
> > right at the beginning.
> 
> I believe the future is UTF-8, including but not limited to its use in XML, and
> we should do what we can to promote it. But beliefs about the future don't
> necessarily belong in an RFC.

We have many documents that give guidelines. 

> Moreover, is this the right place and the right organization to make such a
> statement about XML? The IETF doesn't own the XML specification, the W3C  does.
> And this is a document about how to register XML media types, not about how
> to  use XML.

Organization: yes. We're giving guidelines for communicating text using MIME,
and the interaction of the 'charset' parameter in the metadata with other
sources of encoding information.

Place: Partly.  Guidelines for future text media types belong in a MIME BCP.

> Mind you, given my own beliefs I don't personally object to such a statement if
> there is consensus to include it. I just wonder if it is appropriate.

Although the general policy doesn't belong in appsawg-xml-mediatypes, but
It would be appropriate to advise senders of text/xml and application/xml
to send UTF-8, to not include a BOM, to recommend whether or not to use
 a charset="UTF-8" parameter, to recommend whether or not to include
an internal charset declaration, even when receivers recognize and interpret
other encodings.

This is an interoperability consideration for a revised specification of 
a widely deployed protocol, based on the belief that UTF-8 is becoming
generally even more the default in text-based MIME types.

Those kinds of forward-interoperability requirements seem to be
common in protocols... a SHOULD introduces a new policy to
correct past interoperability difficulties.

Larry
--
http://larry.masinter.net