Request for comments for Media Type registration of application/ccxml+xml
*This message was transferred with a trial version of CommuniGate(tm) Pro* This is a request for comments on the registration of the application/ccxml+xml mime type. The request is published as part of the CCXML 1.0 specification and is copied below. The url of the request is: http://www.w3.org/TR/ccxml/#ccxml-mime-definition Please send any comments on this request to rj@voxeo.com Thanks, RJ Appendix I - CCXML Media Type This appendix registers a new MIME media type, "application/ccxml+xml". I.1 Registration of MIME media type application/ccxml+xml MIME media type name: application MIME subtype name: ccxml+xml Required parameters: None. Optional parameters: charset This parameter has identical semantics to the charset parameter of the application/xml media type as specified in [RFC3023]. Encoding considerations: By virtue of CCXML content being XML, it has the same considerations when sent as "application/ccxml+xml" as does XML. See RFC 3023, section 3.2. Security considerations: Several CCXML instructions may cause arbitrary URIs to be referenced. In this case, the security issues of RFC1738, section 6, should be considered. 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. 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 "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. Published specification: This media type registration is for CCXML documents as described by this specification. Additional information: Magic number(s): There is no single initial octet sequence that is always present in CCXML documents. File extension(s): CCXML documents are most often identified with the extensions ".ccxml". Macintosh File Type Code(s): TEXT Person & email address to contact for further information: RJ Auburn, <rj@voxeo.com>. 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.
These comments are as much about the general "IETF MIME type registration from W3C recommendation" as they are about this particular registration: ------------- 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. Your translation from HTML to ASCII left out line breaks before heading lines, which made your template hard to read. 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.
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.
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?
"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?
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.
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).
Person & email address to contact for further information:
RJ Auburn, <rj@voxeo.com>.
Should there be a W3C contact as well?
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. Larry -- http://larry.masinter.net
On Thursday, July 22, 2004, 7:03:48 AM, Larry wrote: LM> These comments are as much about the general "IETF MIME type LM> registration from W3C recommendation" as they are about this LM> particular registration: LM> ------------- LM> It might be helpful if the registration template explained LM> that "ccxml" stood for "Call Control eXtensible Markup Language" LM> for use in voice browser applications, and that the registration LM> is in a document intended to become a W3C recommendation. I agree that this sort of context, although obvious when the W3C document as a whole is studies, is fairly opaque when a single appendix is extracted and sent as an email message. Prepending the 'Abstract' of the specification, and giving a link to the full specification, would be helpful. LM> I'm not sure this is necessary, but since we're getting LM> W3C recommendations registering MIME types, I wondered LM> if making the registration template just a little bit LM> more explanatory would be useful. Certainly. LM> Your translation from HTML to ASCII left out line breaks LM> before heading lines, which made your template hard LM> to read. LM> Specific comments:
this case, the security issues of RFC1738, section 6, should be considered.
LM> RFC 1738 has been superseded quite a while ago, by 2396. When citing an RFC abcd, it is useful to do a Google search for "Obsoletes: abcd" and "Updates: abcd" because RFCs do not have 'latest version' URIs (or indeed canonical URIs at all).
Published specification:
This media type registration is for CCXML documents as described by this specification.
'This specification' should be a link to the main page of the document, even if that is a link to itself for a short document, and inline URIs should be indicated in the ascii text version by a numbered link [1] [1] http://example.org/like/this A conversion to text can be obtained for any W3C document by appending ,text to the URI (before any fragment) for example http://www.w3.org/TR/ccxml/,text#ccxml-mime-definition which is redirected to (watch out for line wrapping): http://cgi.w3.org/cgi-bin/html2txt?url=http://www.w3.org/TR/ccxml/#ccxml-mim... LM> I'm not 100% sure if this is necessary, but I'd expect LM> if the template were to appear elsewhere to see LM> a bibliographic citation, e.g., LM> "Voice Browser Call Control: CCXML Version 1.0", W3C LM> Working Draft, 30 April 2004, W3C, <http://www.w3.org/TR/ccxml/> I agree. LM> Is "this specification" (or the whole specification) precise LM> enough? Not when the appendix is transmitted separately, no. LM> In some other cases, a single W3C recommendation defines LM> many different data types. Perhaps it would be useful to LM> say, somewhere, e.g., that the MIME type refers to XML bodies that LM> conform to the DTD/Schema referenced in Appendix B and C and LM> interpreted by the rules in the cited specification.
Additional information: Magic number(s):
There is no single initial octet sequence that is always present in CCXML documents.
LM> While this section is titled "Magic number", I think LM> what we're seeing in MIME registrations for XML content LM> is a description of how to recognize CCXML if it isn't LM> labeled. It would be useful here to identify the namespace LM> expected and the likely root XML element name(s). Yes, I agrre that this is current good practice. The text in this registration is fine, but it should add something like: This media type is expected to be handled by an XML processor, as indicated by "+xml". XML processors may detect ccXML by its namespace URI, http://www.w3.org/2001/vxml Hmm the revision to RFC 3023 should probably supply suggested boilerplate for this and, indeed, perhaps a registration template with the common items for all +xml types.
Person & email address to contact for further information:
RJ Auburn, <rj@voxeo.com>.
LM> Should there be a W3C contact as well? The person listed is the W3C Editor of the specification. The fact that they are the document editor should be noted since its not apparent from the appendix in isolation.
Intended usage:
COMMON Author/Change controller:
The CCXML specification is a work product of the World Wide Web LM> Consortium's Voice Browser Working Group. The W3C has change control over these specifications.
LM> Or perhaps the W3C contact address should be listed here. LM> Larry -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group
Chris: Comments and replies are inline. Let me know if there are any other issues: On 07/22/2004 11:05, "Chris Lilley" <chris@w3.org> wrote:
I agree that this sort of context, although obvious when the W3C document as a whole is studies, is fairly opaque when a single appendix is extracted and sent as an email message.
Prepending the 'Abstract' of the specification, and giving a link to the full specification, would be helpful.
Sorry. I should have done this. Martin: any chance we could update the w3c page with some examples of what should be sent to this list? I think it might be helpful to have some pointers to good example requests.
When citing an RFC abcd, it is useful to do a Google search for "Obsoletes: abcd" and "Updates: abcd" because RFCs do not have 'latest version' URIs (or indeed canonical URIs at all).
Thanks for the tip...
Published specification:
This media type registration is for CCXML documents as described by this specification.
'This specification' should be a link to the main page of the document, even if that is a link to itself for a short document, and inline URIs should be indicated in the ascii text version by a numbered link [1]
This section now reads: 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 of the CCXML specification [1]. [1] http://www.w3.org/tr/ccxml/
A conversion to text can be obtained for any W3C document by appending ,text to the URI (before any fragment) for example http://www.w3.org/TR/ccxml/,text#ccxml-mime-definition which is redirected to (watch out for line wrapping): http://cgi.w3.org/cgi-bin/html2txt?url=http://www.w3.org/TR/ccxml/#ccxml-mim... definition
Good hint. I did not know that...
LM> I'm not 100% sure if this is necessary, but I'd expect LM> if the template were to appear elsewhere to see LM> a bibliographic citation, e.g.,
LM> "Voice Browser Call Control: CCXML Version 1.0", W3C LM> Working Draft, 30 April 2004, W3C, <http://www.w3.org/TR/ccxml/>
I agree.
I will try to do that next time around...
LM> Is "this specification" (or the whole specification) precise LM> enough?
Not when the appendix is transmitted separately, no.
Once again apologies...
LM> While this section is titled "Magic number", I think LM> what we're seeing in MIME registrations for XML content LM> is a description of how to recognize CCXML if it isn't LM> labeled. It would be useful here to identify the namespace LM> expected and the likely root XML element name(s).
Yes, I agrre that this is current good practice. The text in this registration is fine, but it should add something like:
This media type is expected to be handled by an XML processor, as indicated by "+xml". XML processors may detect ccXML by its namespace URI, http://www.w3.org/2001/vxml
Hmm the revision to RFC 3023 should probably supply suggested boilerplate for this and, indeed, perhaps a registration template with the common items for all +xml types.
Ok, this is what it will look like now: Magic number(s): There is no single initial octet sequence that is always present in CCXML documents. This media type is expected to be handled by an XML processor, as indicated by "+xml". XML processors may detect CCXML by its namespace URI, http://www.w3.org/2002/09/ccxml Is this ok with folks? --- RJ Auburn CTO, Voxeo Corporation tel:+1-407-418-1800
At 14:37 04/07/27 -0700, RJ Auburn wrote:
Chris:
Comments and replies are inline. Let me know if there are any other issues:
On 07/22/2004 11:05, "Chris Lilley" <chris@w3.org> wrote:
I agree that this sort of context, although obvious when the W3C document as a whole is studies, is fairly opaque when a single appendix is extracted and sent as an email message.
Prepending the 'Abstract' of the specification, and giving a link to the full specification, would be helpful.
Sorry. I should have done this. Martin: any chance we could update the w3c page with some examples of what should be sent to this list? I think it might be helpful to have some pointers to good example requests.
Yes. For that, we first have to have good examples. I'm looking forward to use your next mail to this list as such an example.
Published specification:
This media type registration is for CCXML documents as described by this specification.
'This specification' should be a link to the main page of the document, even if that is a link to itself for a short document, and inline URIs should be indicated in the ascii text version by a numbered link [1]
This section now reads:
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 of the CCXML specification [1].
I personally think that this kind of '[1]' citation is a bit of overkill. If you get that from a text conversion on the W3C Web site, feel free to use it. But I think something like 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 of the CCXML specification at http://www.w3.org/tr/ccxml/. is more readable, and more popular in plain text formats such as email.
Ok, this is what it will look like now:
Magic number(s):
There is no single initial octet sequence that is always present in CCXML documents. This media type is expected to be handled by an XML processor, as indicated by "+xml". XML processors may detect CCXML by its namespace URI, http://www.w3.org/2002/09/ccxml
Is this ok with folks?
Okay with me. Regards, Martin.
On Thursday, July 22, 2004, 7:03:48 AM, Larry wrote: LM> Or perhaps the W3C contact address should be listed here. One more comment. From the Status of this Document:
This document is for public review. Comments and discussion are welcomed on the public mailing list < www-voice@w3.org >. To subscribe, send an email to <www-voice-request@w3. org> with the word subscribe in the subject line (include the word unsubscribe if you want to unsubscribe). The archive for the list is accessible on-line.
Since the review includes the appendix, perhaps review comments on the registration appendix should also be sent to the above review address and handled like other Last call comments? -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group
On 07/22/2004 11:08, "Chris Lilley" <chris@w3.org> wrote:
On Thursday, July 22, 2004, 7:03:48 AM, Larry wrote: LM> Or perhaps the W3C contact address should be listed here. One more comment. From the Status of this Document:
This document is for public review. Comments and discussion are welcomed on the public mailing list < www-voice@w3.org >. To subscribe, send an email to <www-voice-request@w3. org> with the word subscribe in the subject line (include the word unsubscribe if you want to unsubscribe). The archive for the list is accessible on-line.
Since the review includes the appendix, perhaps review comments on the registration appendix should also be sent to the above review address and handled like other Last call comments?
Please do. I have gone ahead and added it to the CC list of this thread. RJ --- RJ Auburn CTO, Voxeo Corporation tel:+1-407-418-1800
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
At 13:05 04/07/27 -0700, RJ Auburn wrote:
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?
Yes. For everybody's information, RJ is following the procedure laid out at http://www.w3.org/2002/06/registering-mediatype.html#Planned. Because he is the first to do so, this is a very good case to see where we have to tweak that description. I have already made two additions: 1) Added a sentence "Make sure that this part of the specification is readable on its own, without the context of the specification." [for further details, a good example is probably better than a lot of explanations] 2) Added a sentence "To make it easier for your WG to track comments on the Media Type section, you may cross-post the comments list for your specification." [I want to leave this to the group for the moment. They have to show that they addressed comments to the IESG, so having that documented in a last call table may have advantages and disadvantages.] Also, I'm planning to add some pointers to examples to the above description, once we have them. That should make it easier for others to do this.
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...
I guess that can wait for the next time you send something anyway, but I hope this will be soon.
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
'this specification' -> 'of this specification'
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?
Adding the name of a staff contact or so might be a good idea.
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?
The W3C is 'on the Web', not at a particular physical location. This kind of wording has been used in some previous registrations, and should be okay. Regards, Martin.
At 3:03 PM +0900 7/28/04, Martin Duerst wrote:
At 13:05 04/07/27 -0700, RJ Auburn wrote:
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?
Yes. For everybody's information, RJ is following the procedure laid out at http://www.w3.org/2002/06/registering-mediatype.html#Planned. Because he is the first to do so, this is a very good case to see where we have to tweak that description. I have already made two additions: 1) Added a sentence "Make sure that this part of the specification is readable on its own, without the context of the specification." [for further details, a good example is probably better than a lot of explanations] 2) Added a sentence "To make it easier for your WG to track comments on the Media Type section, you may cross-post the comments list for your specification." [I want to leave this to the group for the moment. They have to show that they addressed comments to the IESG, so having that documented in a last call table may have advantages and disadvantages.]
Also, I'm planning to add some pointers to examples to the above description, once we have them. That should make it easier for others to do this.
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...
I guess that can wait for the next time you send something anyway, but I hope this will be soon.
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
'this specification' -> 'of this specification'
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?
Adding the name of a staff contact or so might be a good idea.
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?
The W3C is 'on the Web', not at a particular physical location. This kind of wording has been used in some previous registrations, and should be okay.
Actually, Martin, the W3C should come up with something better. This is a detail of the "life after Rec[ommendation status is achieved]" that I am not aware we have laid out adequately. There is a slight problem because the W3C has studiously avoided being a legal entity which could be identified in standard X.500 terms. But if we take the specification http://lists.w3.org/Archives/Member/w3c-wai-pf/2004JulSep/0075.html The document identifies a contact address of mailto:www-dom@w3.org This is standard practice, viz: <quote cite= "http://www.w3.org/Consortium/Contact"> Do you have a technical comment? W3C technical reports include email addresses where readers should send technical comments. </quote> The Consortium has also assiduously avoided promising to answer questions about its utterances, other than that one may post 'comments' in the above manner. Clearly a 'comment' alleging that there is an inconsistency in the provisions of a specification, if read and found to be accurate, may result in something being added to the errata for a document. I would suggest that the 'comments to' email address be included in the contact information provided in a MIME type registration request. As far as identifying The Consortium it should suffice to use the URI http://www.w3.org/ as identification in this context. It would be helpful, but probably not required by the IETF pro-formas, to also allude to the process for change control by a reference to the W3C Process Document identified as: http://www.w3.org/Consortium/Process/ Al
Regards, Martin.
participants (6)
-
Al Gilman -
Chris Lilley -
Larry Masinter -
Martin Duerst -
RJ Auburn -
RJ Auburn