proposed media type registration: application/voicexml+xml

[distobj at acm.org (Mark Baker)]

On Sat, Dec 20, 2003 at 12:20:01AM +0900, MURATA Makoto wrote:
> 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?

Do we know that all existing application/*+xml types define the charset
param by reference to 3023?  If so, then I agree;  I believe that the
benefit of this simplification outweighs the cost of (potential)
redundancy.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>From [e-mail]  Fri Dec 19 19:55:31 2003
From: duerst at w3.org (Martin Duerst)
Date: Fri Dec 19 19:55:46 2003
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <[e-mail]>
References: <4.2.0.58.J.20031218112549.00a93ad0@localhost>
	<1071764448.22957.11.camel@felicia>
	<4.2.0.58.J.20031218112549.00a93ad0@localhost>
Message-ID: <4.2.0.58.J.20031219133801.06ffa768@localhost>

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.
>From [e-mail]  Sat Dec 20 15:52:56 2003
From: murata at hokkaido.email.ne.jp (MURATA Makoto)
Date: Sat Dec 20 15:56:22 2003
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <4.2.0.58.J.20031219133801.06ffa768@localhost>
References: <[e-mail]>
	<4.2.0.58.J.20031219133801.06ffa768@localhost>
Message-ID: <[e-mail]>

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

1)

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

RFC 3023 already provides a registration template which introduces the 
charset parameter.  But the recommendation to introduce the charset parameter 
is a SHOULD rather than a MUST.  People read RFC 3023 but they intentionally 
dropped the charset.

I studied existing +xml media types registered at IANA.  
Here is the result.

1. IETF tree

With the exception of application/cnrp+xml, all +xml media types 
have the charset parameter.

1) beep+xml  	[RFC3080]
This keeps the charset parameter.

2) cnrp+xml  	[RFC3367]
This omits the charset parameter.  Not restricted to UTF-8.

3) cpl+xml 	[RFCXXXX]	
http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-08.txt
This keeps the charset parameter.

4) pidf+xml 	[RFC-ietf-impp-cpim-pidf-08.txt]
http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-pidf-08.txt
This keeps the charset parameter.

5) reginfo+xml 	[RFC-ietf-sipping-reg-event-00.txt]
http://www.ietf.org/internet-drafts/draft-ietf-sipping-reg-event-00.txt
This keeps the charset parameter.

6) watcherinfo+xml 	[RFC-ietf-simple-winfo-format-04.txt]
http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-format-04.txt
This keeps the charset parameter.

7) xhtml+xml 	[RFC3236]
http://www.rfc-editor.org/rfc/rfc3236.txt
This keeps the charset parameter.


2. Vendor tree

Only two media types have the charset parameter.  Since media types in
the vendor tree do not always have accompanying documents, we do not
know if there are good reasons to omit the charset.

1) vnd.criticaltools.wbs+xml 	[Spiller]

http://www.iana.org/assignments/media-types/application/vnd.criticaltools.wbs+xml
This omits the charset parameter.
The details of this structure are proprietary to Critical Tools, Inc.

2) vnd.irepository.package+xml 	[Knowles]

http://www.iana.org/assignments/media-types/application/vnd.irepository.package+xml
This omits the charset parameter.
Use of this MIME type is limited to users of Lucidoc and associated
document management tools published by iRepository.net, Inc.

3) vnd.liberty-request+xml 	[McDowell]

http://www.iana.org/assignments/media-types/application/vnd.liberty-request+xml
This omits the charset parameter.

4) vnd.llamagraphics.life-balance.exchange+xml 	[White]

http://www.iana.org/assignments/media-types/application/vnd.llamagraphics.life-balance.exchange+xml
This keeps the charset parameter.

5) vnd.mozilla.xul+xml 	[McDaniel]

http://www.iana.org/assignments/media-types/application/vnd.mozilla.xul+xml
This keeps the charset parameter.

6) vnd.pwg-xhtml-print+xml 	[Wright]

http://www.iana.org/assignments/media-types/application/vnd.pwg-xhtml-print+xml
This omits the charset parameter.

7) vnd.wv.csp+xml 	[Ingimundarson]

http://www.iana.org/assignments/media-types/application/vnd.wv.csp+xml
This omits the charset parameter.  
They wrote "No parameters are required - covered by client-server capability
negotiation."

8) vnd.wv.csp+wbxml 	[Salmi]

http://www.iana.org/assignments/media-types/application/vnd.wv.csp+wbxml
This omits the charset parameter.  
They wrote "No parameters are required since WV capability negotiation
covers this."

9) vnd.wv.ssp+xml 	[Ingimundarson]

http://www.iana.org/assignments/media-types/application/vnd.wv.ssp+xml
This omits the charset parameter.  


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

I am afraid that I made a mistake.  We have discussed this issue in 
the mailing list, but nothing is written down yet.

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

Now we have two exceptions in the IETF tree.

Practically, what can we do?

Cheers,

-- 
MURATA Makoto <[e-mail]>