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

[Martin Duerst <[e-mail]>]

Hello Makoto,

At 00:20 03/12/20 +0900, MURATA Makoto wrote:

>On Thu, 18 Dec 2003 11:30:44 -0500
>Martin Duerst <[e-mail]> wrote:
>
> > There is some work starting on updating RFC 3023, and we hope that
> > we can use it to document the issues and questions that have
> > come up on the list. Chris has volunteered to coauthor, and I'll
> > help from the sidelines. Probably having all the information together
> > in one place, is better than having some of the information separated out.
>
>As a co-author, I also agree to add some guidelines for the omission of the
>charset parameter.  Chris and I will start this work shortly.

We are looking forward to this!


>When a media type uses UTF-8 only, I can agree to omit the charset
>parameter. "UTF-8" is already a recommended policy
>(http://www.w3.org/TR/charmod/#sec-UniqueEncoding).  I do not see strong
>reasons to specify charset="utf-8" always.  However, even in this case, I
>am sympathetic to Martin's worry ("we start to get into a patchwork").
>In all other cases, I do not want to allow omission of the charset
>parameter.  How do others feel?

There are two separate issues:
1) Does a registration allow the 'charset' parameter or not.
2) Does an actual entity have the 'charset' parameter or not.

It is not totally clear to me which one of these you are talking above.
In my opinion, it is highly preferable that all registrations
allow the 'charset' parameter, to avoid a patchwork. The draft
should contain some justification for this.

As for whether the actual entity should come with a 'charset'
parameter, we should also have a discussion of the various
issues in the draft.


>By the way, "The Standard Hex Format" uses UTF-8 only.
>
>http://www.ietf.org/internet-drafts/draft-strombergson-shf-00.txt

I have not found 'UTF-8' anywhere in this document, so I'm not
sure where you saw this restriction. The document contains:

 >>>>>>>>
9.1 Optional parameters

    none.

    There is no charset parameter. Character handling has identical
    semantics to the case where the charset parameter of the
    "application/xml" media type is omitted, as described in RFC3023 [4].
 >>>>>>>>

I think this should be fixed to reinstate the charset parameter
as discussed on this mailing list.


Another one is
http://www.ietf.org/internet-drafts/draft-sbml-media-type-02.txt.

This was approved by the IESG yesterday, so I guess it's too late
to try to change it. In practice, I very much hope that no implementation
will reject sbml data that comes with a redundant charset=utf-8.


Regards,    Martin.