Re: Registration of media type application/xhtml-voice+xml

Gerald McCobb <> Wed, 13 July 2005 22:06 UTC

Received: from ( []) by (8.12.11/8.12.9) with ESMTP id j6DM6K71087201; Wed, 13 Jul 2005 15:06:20 -0700 (PDT) (envelope-from
Received: (from majordom@localhost) by (8.12.11/8.12.9/Submit) id j6DM6Kts087200; Wed, 13 Jul 2005 15:06:20 -0700 (PDT)
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.12.11/8.12.9) with ESMTP id j6DM6JCD087190 for <>; Wed, 13 Jul 2005 15:06:20 -0700 (PDT) (envelope-from
Received: from ( []) by (8.12.10/8.12.9) with ESMTP id j6DM6Efj503192 for <>; Wed, 13 Jul 2005 18:06:14 -0400
Received: from ( []) by (8.12.10/NCO/VER6.6) with ESMTP id j6DM6ESl411514 for <>; Wed, 13 Jul 2005 16:06:14 -0600
Received: from (loopback []) by (8.12.11/8.13.3) with ESMTP id j6DM6DsV008087 for <>; Wed, 13 Jul 2005 16:06:13 -0600
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id j6DM6DAb008073; Wed, 13 Jul 2005 16:06:13 -0600
In-Reply-To: <>
To: Chris Lilley <>
Cc:,, "" <>
MIME-Version: 1.0
Subject: Re: Registration of media type application/xhtml-voice+xml
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <>
From: Gerald McCobb <>
Date: Wed, 13 Jul 2005 18:06:17 -0400
X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 07/13/2005 16:06:12, Serialize complete at 07/13/2005 16:06:12
Content-Type: multipart/alternative; boundary="=_alternative 00796AE38525703D_="
Precedence: bulk
List-Archive: <>
List-ID: <>
List-Unsubscribe: <>

Chris Lilly wrote:

CL> GM> I asked the IESG to postpone the publication of the
GM> application/xhtml-voice+xml media type as an informational RFC.  The
CL> GM> registration is not correct.  It should be
GM> application/xhtml+voice+xml.  The application/xhtml+voice+xml media
CL> GM> type was the original submission.

CL> The entire reason that the +xml suffix was changed from the original
CL> -xml suffix was beczause there were a number of hyphenated types in
CL> use but little/no types where the terms were separated by +.

The application/xhtml+voice+xml media was chosen because it directly
maps to "XHTML+Voice", the name of the language, and is thus an easy
mnemonic help for authors - whereas I might imagine people getting
confused by XHTML+Voice using the application/xhtml-voice+xml or 
application/xhtml-plus-voice+xml type.

CL> GM> There is an issue with the original submission: 
CL> GM> One of the reviewers pointed out that "a certain class of error
CL> GM> could be avoided by renaming this
CL> GM> application/xhtml-plus-voice+xml... I don't know of any other
CL> GM> "+xml" [see RFC3023] media types that have a "+" in the name...
CL> GM> a poorly-constructed regexp looking for +xml along the lines of
CL> GM> /\+(.*)$/  would miss this one."

CL> I agree that so far there are no types with a + in the name, and
CL> that using some other allowed separator would be preferable.

As far as I know, XHTML+Voice is the first example of a compound document
format requesting registration of a media type.  There has not been
a reason before to have a type with a "+" in the name.  The fact that
"+" has not been used before is not a reason to exclude using it for the
first time.

CL> GM> 1. In particular there is the work in the W3C Compound Document
CL> GM> Format (CDF) working group.  They are looking at defining a
CL> GM> single media type that will handle the many possible document
CL> GM> format combinations of XHTML, SVG, Voice, SMIL, XForms, etc.
CL> GM> This media type may include multiple "+" put in a profile
CL> GM> attribute.

CL> Probably not (I for one would argue against it, being a member of
CL> that group). But 'may include' is pretty weak.

Regardless of what the CDF working group will eventually decide this
XHTML+Voice media type registration could set a precedent for all
formats that add language subsets to container languages (such as XHTML).
I'm not comfortable with setting a precedent for "xhtml-plus-svg-plus-
smil-plus-xforms", for example.

CL> GM> 2. The argument for having "+" in the subtype is unconvincing,
CL> GM> given that the simplest method to determine if something is XML
CL> GM> is also the safest, that is, if the last four characters are
CL> GM> "+xml" or "/xml" then the document is XML, otherwise it is not.
CL> GM> If that has to be done with regexps, instead of just examining
CL> GM> the last four bytes, that would be /[/+]xml$/.  If type and
CL> GM> subtype were split already it would be /\+?xml$/ for the
CL> GM> subtype.

CL> True.

Then we agreed that "poorly written regexps" is not a good reason for
excluding use of "+" in the type?

Gerald McCobb
8051 Congress Avenue
Boca Raton, FL 33487
Tel. # 561-862-2109 T/L 975-2109