Re: proposed media type registration: application/voicexml+xml

Hello Ben,

[Putting [email protected] back on the cc list, because
I think quite some of this discussion may make its way into
the next version of RFC 3023 in one way or another.]

At 18:17 03/12/17 +0000, [email protected] wrote:
>At  4pm on 16/12/03 Martin Duerst wrote:
> > I just by chance realized that you had removed the 'charset'
> > parameter from the registration for application/voicexml+xml,
> > and also for application/ssml+xml. I have found something similar
> > in other recent registration proposals.

>The usual intent when omitting the 'charset' parameter from the
>registration is that the XML *must* be encoded in UTF8 or UTF16.

This is an interesting idea. Can you point to any actual
registrations where this is the case?


>If this is done, then the entity will not need to include a charset
>declaration in the body either, and will be universally understood
>everywhere.

Yes, this is true for application/foo+xml. For text/foo+xml,
it is not true, but then I hope nobody is talking about that anyway.


>I would suggest that those registrations which do not
>specify a charset be updated to state that encodings other than UTF8
>and UTF16 may not be used.

I'm not really sure that this helps. It would not work together
with any of the points I have brought up:

- Generic xml processors would still accept 'charset' parameters,
   even if the registration forbade it. They also would still
   accept content in other encodings (with quite some variation,
   of course), whether declared with a 'charset' parameter or
   with the encoding pseudo-attribute on an XML declaration.
- Technology such as JSP and databases would still produce
   'charset' parameters, even if the registration didn't allow it.

There may be cases where one wants a certain media type to be
restricted to UTF-8 and UTF-16 (or even in some cases only
one of them), but just saying
"no charset parameter on media type == UTF-8 or UTF-16 only"
doesn't really cut it.


Regards,    Martin.