Re: Request for comments for Media Type registration of application/ccxml+xml

Larry,

Thanks for these comments. Sorry for the delay in getting back to you on
these. I am going to try and address/comment on them can inline:



On 07/21/2004 22:03, "Larry Masinter" <LMM@acm.org> wrote:

> These comments are as much about the general "IETF MIME type
> registration from W3C recommendation" as they are about this
> particular registration:


Martin: Would you be the person to handle/address the general issues?


> It might be helpful if the registration template explained
> that "ccxml" stood for "Call Control eXtensible Markup Language"
> for use in voice browser applications, and that the registration
> is in a document intended to become a W3C recommendation.
> 
> I'm not sure this is necessary, but since we're getting
> W3C recommendations registering MIME types, I wondered
> if making the registration template just a little bit
> more explanatory would be useful.

Good points.

> Your translation from HTML to ASCII left out line breaks
> before heading lines, which made your template hard
> to read.

If needed I can resubmit a nicer looking version. Let me know...

> Specific comments:
> 
>> this case, the security issues of RFC1738, section 6, should
>> be considered.
> 
> RFC 1738 has been superseded quite a while ago, by 2396.


Thanks. I have updated the document.


>> In addition, because of the extensibility features for CCXML, it is
> possible
>> that "application/ccxml+xml" may describe content that has security
>> implications beyond those described here. However, if the processor
> follows
>> only the normative semantics of this specification, this content will be
>> ignored. Only in the case where the processor recognizes and processes the
>> additional content, or where further processing of that content is
>> dispatched to other processors, would security issues potentially arise.
> And
>> in that case, they would fall outside the domain of this registration
>> document.
> 
> I don't think it's true that it falls outside the domain,
> and the argument is just confusing. One major purpose of the
> "security considerations" section is to help firewall
> and security perimeter vendors decide what they need
> to do when they see content marked with this type.
> 
> If receivers are likely to interpret extensions and the
> extensions are likely to cause security problems if interpreted,
> you should say so. If the document explains, in allowing for
> extensions, how to avoid security problems, then say so.


Dave/Max: This has to do with the idea of people using name spaces or
something like that to put in other markup that's not CCXML. I do not think
this really needs to be here. Should I remove this? Or craft something
completely new?


>> Interoperability considerations:
>> 
>> This specification describes processing semantics that dictate behavior
> that
>> must be followed when dealing with, among other things, unrecognized
>> elements.
>> 
>> Because CCXML is extensible, conferment
> 
> conformant?


Fixed...


>> "application/ccxml+xml" processors
>> can expect that content received is well-formed XML, but it cannot be
>> guaranteed that the content is valid CCXML or that the processor will
>> recognize all of the elements and attributes in the document.
> 
> 
> I think the main purpose of "interoperability considerations" is
> to talk about reasons why multiple implementations might not
> interoperate.  I don't know if you have any of those, but
> I don't think what you say here (that someone might send
> non-conformant content labeled with this MIME type)
> really fits. Are all conforming CCXML implementations guaranteed
> to be interoperable? If not, why not?


There are a number of features that are considered optional in the
specification. Do we need to put something about them here?


>> Published specification:
>> 
>> This media type registration is for CCXML documents as
>> described by this specification.
> 
> I'm not 100% sure if this is necessary, but I'd expect
> if the template were to appear elsewhere to see
> a bibliographic citation, e.g.,
> 
> "Voice Browser Call Control: CCXML Version 1.0", W3C
> Working Draft, 30 April 2004, W3C, <http://www.w3.org/TR/ccxml/>
> 
> Is "this specification" (or the whole specification) precise
> enough?  In some other cases, a single W3C recommendation defines
> many different data types. Perhaps it would be useful to
> say, somewhere, e.g., that the MIME type refers to XML bodies that
> conform to the DTD/Schema referenced in Appendix B and C and
> interpreted by the rules in the cited specification.


Pointing at the schema/dtd sections seems reasonable.  How is this for text:

Published specification:
    This media type registration is for XML bodies that
    conform to the DTD/Schema referenced in Appendix B and C and
    interpreted by the rules this specification




>> Additional information:
>> Magic number(s):
>> 
>> There is no single initial octet sequence that is always
>> present in CCXML documents.
> 
> While this section is titled "Magic number", I think
> what we're seeing in MIME registrations for XML content
> is a description of how to recognize CCXML if it isn't
> labeled. It would be useful here to identify the namespace
> expected and the likely root XML element name(s).


How about:

Magic number(s):

    All CCXML documents will contain a <ccxml> element that
    belongs to the "http://www.w3.org/2002/09/ccxml" namespace.



>> Person & email address to contact for further information:
>> 
>> RJ Auburn, <rj@voxeo.com>.
> 
> Should there be a W3C contact as well?


Dave/Max/Martin: Thoughts?


>> Intended usage:
>> 
>> COMMON
>> Author/Change controller:
>> 
>> The CCXML specification is a work product of the World Wide Web
> Consortium's
>> Voice Browser Working Group. The W3C has change control over these
>> specifications.
> 
> Or perhaps the W3C contact address should be listed here.

Dave/Max/Martin: Thoughts?




---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800

Received on Tuesday, 27 July 2004 16:07:26 UTC