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? Regards, Gerald McCobb IBM 8051 Congress Avenue Boca Raton, FL 33487 Tel. # 561-862-2109 T/L 975-2109