Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VHomiT083271; Sat, 31 Jul 2004 10:50:48 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VHomjr083270; Sat, 31 Jul 2004 10:50:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VHom6W083263 for ; Sat, 31 Jul 2004 10:50:48 -0700 (PDT) (envelope-from Alfred.S.Gilman@ieee.org) Received: from [10.0.1.2] (pcp09265333pcs.arlngt01.va.comcast.net[69.143.105.64]) by comcast.net (sccrmhc13) with ESMTP id <2004073117504601600i0s4fe> (Authid: al.gilman); Sat, 31 Jul 2004 17:50:46 +0000 Mime-Version: 1.0 X-Sender: al.gilman@mail.comcast.net Message-Id: Date: Sat, 31 Jul 2004 13:50:44 -0400 To: From: Al Gilman Subject: Re: Request for comments for Media Type registration ofapplication/ccxml+xml Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Copy of http://www.w3.org/mid/p06110400bd2d389cc364@%5B10.0.1.2%5D resent for administrative reasons. See archive copy above for other recipients. - Al 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" 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, >>> >>> 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, . >>> >>> 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: Do you have a technical comment? W3C technical reports include email addresses where readers should send technical comments. 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. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S64LiG074452; Tue, 27 Jul 2004 23:04:21 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6S64LVC074451; Tue, 27 Jul 2004 23:04:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [18.29.0.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S64LJK074437 for ; Tue, 27 Jul 2004 23:04:21 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA (homer.w3.org [18.29.0.30]) by homer.w3.org (Postfix) with ESMTP id 66FED4F0EB; Wed, 28 Jul 2004 02:04:20 -0400 (EDT) Message-Id: <4.2.0.58.J.20040728144733.0570d3d8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 28 Jul 2004 14:54:40 +0900 To: RJ Auburn , Chris Lilley , Larry Masinter From: Martin Duerst Subject: Re: Request for comments for Media Type registration ofapplication/ccxml+xml Cc: "'Dan Connolly'" , www-voice@w3.org, Dave Raggett , ietf-types@iana.org, w3c-archive@w3.org, ietf-xml-mime@imc.org In-Reply-To: References: <3310006012.20040722200532@w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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" 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] > > > > [1] http://example.org/like/this > >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/ 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. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S64HWP074377; Tue, 27 Jul 2004 23:04:17 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6S64HeC074376; Tue, 27 Jul 2004 23:04:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [18.29.0.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S64CLu074305 for ; Tue, 27 Jul 2004 23:04:12 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA (homer.w3.org [18.29.0.30]) by homer.w3.org (Postfix) with ESMTP id 66D5E4F314; Wed, 28 Jul 2004 02:04:01 -0400 (EDT) Message-Id: <4.2.0.58.J.20040728143604.0570ae78@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 28 Jul 2004 15:03:56 +0900 To: RJ Auburn , Larry Masinter From: Martin Duerst Subject: Re: Request for comments for Media Type registration ofapplication/ccxml+xml Cc: "'Dan Connolly'" , Dave Raggett , , , , In-Reply-To: References: <0I1800NXFM2I0M@mailsj-v1.corp.adobe.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 13:05 04/07/27 -0700, RJ Auburn wrote: >On 07/21/2004 22:03, "Larry Masinter" 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, > > > > 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, . > > > > 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. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6R1D743009579; Mon, 26 Jul 2004 18:13:07 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6R1D6ru009578; Mon, 26 Jul 2004 18:13:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6R1D540009541 for ; Mon, 26 Jul 2004 18:13:06 -0700 (PDT) (envelope-from murata@hokkaido.email.ne.jp) Received: from [127.0.0.1] (h220132.ppp.asahi-net.or.jp [61.114.220.132]) by mail.asahi-net.or.jp (Postfix) with ESMTP id AEBFE65FB4 for ; Tue, 27 Jul 2004 10:12:56 +0900 (JST) Date: Tue, 27 Jul 2004 10:12:14 +0900 From: MURATA Makoto To: ietf-xml-mime@imc.org Subject: Fw: Re: Fw: Revising RFC 3023 Message-Id: <20040727101117.CC48.MURATA@hokkaido.email.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.09.01 [ja] Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Another mail about XML versions. Cheers, Makoto Forwarded by MURATA Makoto ----------------------- Original Message ----------------------- From: noah_mendelsohn@us.ibm.com To: MURATA Makoto Date: Mon, 26 Jul 2004 21:04:24 -0400 Subject: Re: Fw: Revising RFC 3023 ---- Makoto: thank you so much for circulating this. I think these issues would indeed benefit from some attention. I thought I should clarify for those outside of IBM that the note from which you quote below was originally written last Feb. In particular, the sections on SOAP in particular predate the recent discussions in the XMLP workgroup of XML 1.1 handling in SOAP. Also, none of this is specifically a comment on his recently circulated I-D. Regarding SOAP, what you should get out of the attached is merely that there are situations in which a W3C Recommendation may for good reason need to specify the use of particular versions of XML, including in particular XML 1.0. (As it happens, the XMLP workgroup is planning to make exactly such a specification for SOAP, in part because we feel that we cannot support XML 1.1 until XML Schema does.) Otherwise, I stand behind both the suggestions for the W3C and for RFC 3023. Thank you. -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 -------------------------------------- MURATA Makoto 07/26/04 07:19 PM To: www-tag@w3.org cc: noah_mendelsohn@us.ibm.com Subject: Fw: Revising RFC 3023 Forwarded by MURATA Makoto ----------------------- Original Message ----------------------- From: MURATA Makoto To: ietf-xml-mime@imc.org Date: Sun, 25 Jul 2004 22:43:07 +0900 Subject: Revising RFC 3023 ---- I am forwarding an e-mail from Noah Mendelsohn. It contains some suggestions I got from Noah in private discussion at IBM. I have his permission to circulate publicly. Cheers, MURATA Makoto -------------------------------------------- Murata Makoto writes: >> It is true that RFC 3023 does not reference to XML 1.1, although I >> do not see anything specific to XML 1.0 (with the exception of >> security concerns caused by C0 control functions).. The references I found in 3023 are: "The World Wide Web Consortium has issued Extensible Markup Language (XML) 1.0 (Second Edition)[XML]. " "Published specification: Extensible Markup Language (XML) 1.0 (Second Edition)[XML]." and more specifically all the examples which show: Content-type: text/xml; charset="utf-8" and so on. I now see that all of this may have just been intended as the then-latest forms, but I read them as specific instructions for use of xml 1.0 as the proper form of application/xml. So, at the very least, I think it would be helpful to be more explicit in future replacements or updates to 3023. >> I plan to reference to XML 1.1 as well as XML 1.0 in the next I-D, >> which is expected to supsersede RFC 3023. I'm torn about this. In the specific case of SOAP, our recommendation says that implementations of our HTTP bindings MUST be capable of sending and receiving in the media-type "application/soap+xml", which we normatively base on 3023 and application/xml. In making this statement, I doubt that most members of the working group realized that they might have been introducing an open-ended need to conform to all future versions of XML, including those that would allow previously-illegal control character content. Maybe if we'd known such an XML 1.1 was coming we would have and should have put in such a requirement to support both: my point is just that I don't think we did so consciously. I have openned a discussion of all this on the distApp mailing list [1], and will in a minute send an update pointing out the tie-in to RFC 3023. I will cc: you on that update. distApp is a public mailing list, and you are most welcome to join in. For what it's worth, SOAP puts a tremendous emphasis on interoperability, so saying that two conforming implemenations of this binding can disagree about what's legal in the preferred form of messages is at least a bit troubling. The original design point was: if you conform, you can communicate. Even if 3023 is to support any version of XML, we in SOAP may be able to fix things with a clarification to our recommendation. It so happens that we already allow use of any other media type, it's just that we make clear that application/soap+xml is the lingua franca. Use something else and it will only work if the recipient agrees. I suspect we'll wind up saying: "application/xml with xml version 1.0 is the lingua franca, you can use other media types or application/soap+xml with later versions of XML, but only if the recipient supports them." The control character business is a bigger mess for us I think, as we have a quite strong rule that the constraints on SOAP envelopes are the same everywhere, and they are basically what you'd expect from Infoset (and implicitly XML 1.0). Note that such envelopes are by definition synthetic Infosets. XML 1.1 suggests that, regardless of how you serialize the message on each hop, there is a question as to whether in the abstract the new control characters are allowed in the envelope infosets. If so, then such messages cannot transit hops implemented with already deployed software, and that's very troubling to me. >> If you have any comments about how these two specs should be >> referenced, please let me know. I even think that there should be a >> W3C guideline about references to XML 1.0 and XML 1.1. Does the XML >> Core WG have some recommendations? I'm not sure I have a carefully considered opinion, but what about the following as a starting point for discussion? Very Rough Draft of Proposed W3C policy: "The publication of XML 1.1 highlights the fact that evolved versions of XML may change both the serialized form of an XML document and the content representable in such a document. In the case of XML 1.1, for example, certain control characters disallowed by XML 1.0 were added to the Char production. Accordingly, W3C recommends that: * Every recommendation or other publication that makes normative reference to XML as a serialized document format should make clear which versions of XML it supports, and in particular whether it allows for support of potential variants to be published in the future. * When calling for serialization of data into an XML document, such recommendations SHOULD appeal to the conventions of the supported versions of XML regarding proper use of the XML declaration (for example, the XML 1.1 recommendation suggests use of version="1.1" only for those documents which would not be correctly represented as version="1.0".) * Recommendations should similarly clarify any dependencies on particular versions of XML regarding the abstract content of data modeled as XML. For example, a recommendation based on the Infoset, XPath data model, DOM, SAX, etc. SHOULD indicate whether the control characters introduced by XML 1.1 are allowed in element content, SHOULD indicate whether potential future changes to XML constructs such (e.g. a purely hypothetical future change to the set of legal XML name characters) would be supported, and so on. " In the case of future versions of RFC 3023, I think the most appropriate course might be to say: "application/xml is to be used with any W3C Recommendation-level version of XML as identified in the version specification of the XML declaration. When no such declaration is present, XML 1.0 is assumed. In all examples herein where a specific version such as version="1.0" is shown, it is understood that other versions may also be used, providing the content does indeed conform to the specified version of the XML Recommendation. Specifications and recommendations based on or referring to this RFC SHOULD indicate any limitations on the particular versions of XML to be used. For example, a particular specification might indicate: "content MUST be represented using media-type application/xml, and the document must either (a) carry an xml declaration specifying version="1.0" or (b) omit the xml declaration, in which case per the XML recommendation the version defaults to 1.0" Does that seem like a reasonable start? [1] http://lists.w3.org/Archives/Public/xml-dist-app/2004Feb/0006.html --------------------- Original Message Ends -------------------- -- MURATA Makoto --------------------- Original Message Ends -------------------- --------------------- Original Message Ends -------------------- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PDhl4o022881; Sun, 25 Jul 2004 06:43:47 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6PDhlDT022880; Sun, 25 Jul 2004 06:43:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from mail.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PDhkWh022874 for ; Sun, 25 Jul 2004 06:43:46 -0700 (PDT) (envelope-from murata@hokkaido.email.ne.jp) Received: from [127.0.0.1] (j082046.ppp.asahi-net.or.jp [61.213.82.46]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 20B4F107DEE for ; Sun, 25 Jul 2004 22:43:48 +0900 (JST) Date: Sun, 25 Jul 2004 22:43:07 +0900 From: MURATA Makoto To: ietf-xml-mime@imc.org Subject: Revising RFC 3023 Message-Id: <20040725224207.9C59.MURATA@hokkaido.email.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.09.01 [ja] Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I am forwarding an e-mail from Noah Mendelsohn. It contains some suggestions I got from Noah in private discussion at IBM. I have his permission to circulate publicly. Cheers, MURATA Makoto -------------------------------------------- Murata Makoto writes: >> It is true that RFC 3023 does not reference to XML 1.1, although I >> do not see anything specific to XML 1.0 (with the exception of >> security concerns caused by C0 control functions).. The references I found in 3023 are: "The World Wide Web Consortium has issued Extensible Markup Language (XML) 1.0 (Second Edition)[XML]. " "Published specification: Extensible Markup Language (XML) 1.0 (Second Edition)[XML]." and more specifically all the examples which show: Content-type: text/xml; charset="utf-8" and so on. I now see that all of this may have just been intended as the then-latest forms, but I read them as specific instructions for use of xml 1.0 as the proper form of application/xml. So, at the very least, I think it would be helpful to be more explicit in future replacements or updates to 3023. >> I plan to reference to XML 1.1 as well as XML 1.0 in the next I-D, >> which is expected to supsersede RFC 3023. I'm torn about this. In the specific case of SOAP, our recommendation says that implementations of our HTTP bindings MUST be capable of sending and receiving in the media-type "application/soap+xml", which we normatively base on 3023 and application/xml. In making this statement, I doubt that most members of the working group realized that they might have been introducing an open-ended need to conform to all future versions of XML, including those that would allow previously-illegal control character content. Maybe if we'd known such an XML 1.1 was coming we would have and should have put in such a requirement to support both: my point is just that I don't think we did so consciously. I have openned a discussion of all this on the distApp mailing list [1], and will in a minute send an update pointing out the tie-in to RFC 3023. I will cc: you on that update. distApp is a public mailing list, and you are most welcome to join in. For what it's worth, SOAP puts a tremendous emphasis on interoperability, so saying that two conforming implemenations of this binding can disagree about what's legal in the preferred form of messages is at least a bit troubling. The original design point was: if you conform, you can communicate. Even if 3023 is to support any version of XML, we in SOAP may be able to fix things with a clarification to our recommendation. It so happens that we already allow use of any other media type, it's just that we make clear that application/soap+xml is the lingua franca. Use something else and it will only work if the recipient agrees. I suspect we'll wind up saying: "application/xml with xml version 1.0 is the lingua franca, you can use other media types or application/soap+xml with later versions of XML, but only if the recipient supports them." The control character business is a bigger mess for us I think, as we have a quite strong rule that the constraints on SOAP envelopes are the same everywhere, and they are basically what you'd expect from Infoset (and implicitly XML 1.0). Note that such envelopes are by definition synthetic Infosets. XML 1.1 suggests that, regardless of how you serialize the message on each hop, there is a question as to whether in the abstract the new control characters are allowed in the envelope infosets. If so, then such messages cannot transit hops implemented with already deployed software, and that's very troubling to me. >> If you have any comments about how these two specs should be >> referenced, please let me know. I even think that there should be a >> W3C guideline about references to XML 1.0 and XML 1.1. Does the XML >> Core WG have some recommendations? I'm not sure I have a carefully considered opinion, but what about the following as a starting point for discussion? Very Rough Draft of Proposed W3C policy: "The publication of XML 1.1 highlights the fact that evolved versions of XML may change both the serialized form of an XML document and the content representable in such a document. In the case of XML 1.1, for example, certain control characters disallowed by XML 1.0 were added to the Char production. Accordingly, W3C recommends that: * Every recommendation or other publication that makes normative reference to XML as a serialized document format should make clear which versions of XML it supports, and in particular whether it allows for support of potential variants to be published in the future. * When calling for serialization of data into an XML document, such recommendations SHOULD appeal to the conventions of the supported versions of XML regarding proper use of the XML declaration (for example, the XML 1.1 recommendation suggests use of version="1.1" only for those documents which would not be correctly represented as version="1.0".) * Recommendations should similarly clarify any dependencies on particular versions of XML regarding the abstract content of data modeled as XML. For example, a recommendation based on the Infoset, XPath data model, DOM, SAX, etc. SHOULD indicate whether the control characters introduced by XML 1.1 are allowed in element content, SHOULD indicate whether potential future changes to XML constructs such (e.g. a purely hypothetical future change to the set of legal XML name characters) would be supported, and so on. " In the case of future versions of RFC 3023, I think the most appropriate course might be to say: "application/xml is to be used with any W3C Recommendation-level version of XML as identified in the version specification of the XML declaration. When no such declaration is present, XML 1.0 is assumed. In all examples herein where a specific version such as version="1.0" is shown, it is understood that other versions may also be used, providing the content does indeed conform to the specified version of the XML Recommendation. Specifications and recommendations based on or referring to this RFC SHOULD indicate any limitations on the particular versions of XML to be used. For example, a particular specification might indicate: "content MUST be represented using media-type application/xml, and the document must either (a) carry an xml declaration specifying version="1.0" or (b) omit the xml declaration, in which case per the XML recommendation the version defaults to 1.0" Does that seem like a reasonable start? [1] http://lists.w3.org/Archives/Public/xml-dist-app/2004Feb/0006.html --------------------- Original Message Ends -------------------- -- MURATA Makoto Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6P0QJ7n069285; Sat, 24 Jul 2004 17:26:19 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6P0QJc6069284; Sat, 24 Jul 2004 17:26:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6P0QIjP069275 for ; Sat, 24 Jul 2004 17:26:18 -0700 (PDT) (envelope-from murata@hokkaido.email.ne.jp) Received: from [127.0.0.1] (g039162.ppp.asahi-net.or.jp [211.132.39.162]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 11373189167 for ; Sun, 25 Jul 2004 09:26:22 +0900 (JST) Date: Sun, 25 Jul 2004 09:25:41 +0900 From: MURATA Makoto To: ietf-xml-mime@imc.org Subject: An I-D for text/xml, application/xml, etc. Message-Id: <20040725092044.9C3C.MURATA@hokkaido.email.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.09.01 [ja] Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Based on the discussions in this mailing list and W3C TAG, an I-D for XML media types has been created. Major changes from RFC 3023 are as follows: First, text/xml and text/xml-external-parsed-entity are deprecated. Second, XPointer ([XPointerFramework] and [XPointerElement]) has been added as fragment identifiers for "application/xml". Third, [XBase] has been added as a mechanism for specifying base URIs. Fourth, many references are updated. http://www.ietf.org/internet-drafts/draft-murata-kohn-lilley-xml-00.txt Comments welcome. Cheers, -- MURATA Makoto Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MI8MdF039569; Thu, 22 Jul 2004 11:08:22 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MI8MSc039568; Thu, 22 Jul 2004 11:08:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [18.29.0.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MI8LcT039561 for ; Thu, 22 Jul 2004 11:08:21 -0700 (PDT) (envelope-from chris@w3.org) Received: from localhost (localhost [127.0.0.1]) by homer.w3.org (Postfix) with ESMTP id 73FBE4F195; Thu, 22 Jul 2004 14:08:23 -0400 (EDT) Date: Thu, 22 Jul 2004 20:08:24 +0200 From: Chris Lilley Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <85713702.20040722200824@w3.org> To: Larry Masinter Cc: rj@voxeo.com, "'Martin Duerst'" , "'Dan Connolly'" , , , , Subject: Re: Request for comments for Media Type registration of application/ccxml+xml In-Reply-To: <0I1800NXFM2I0M@mailsj-v1.corp.adobe.com> References: <0I1800NXFM2I0M@mailsj-v1.corp.adobe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6MI8LcT039563 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 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 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MI5VSl039364; Thu, 22 Jul 2004 11:05:31 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MI5Vnf039363; Thu, 22 Jul 2004 11:05:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [18.29.0.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MI5UAQ039357 for ; Thu, 22 Jul 2004 11:05:31 -0700 (PDT) (envelope-from chris@w3.org) Received: from localhost (localhost [127.0.0.1]) by homer.w3.org (Postfix) with ESMTP id 7C1494F0C3; Thu, 22 Jul 2004 14:05:31 -0400 (EDT) Date: Thu, 22 Jul 2004 20:05:32 +0200 From: Chris Lilley Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <3310006012.20040722200532@w3.org> To: Larry Masinter Cc: rj@voxeo.com, "'Martin Duerst'" , "'Dan Connolly'" , , , , Subject: Re: Request for comments for Media Type registration of application/ccxml+xml In-Reply-To: <0I1800NXFM2I0M@mailsj-v1.corp.adobe.com> References: <0I1800NXFM2I0M@mailsj-v1.corp.adobe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-mime-definition 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, 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, . 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 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M55cVq068989; Wed, 21 Jul 2004 22:05:38 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6M55cRe068987; Wed, 21 Jul 2004 22:05:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from smtp-relay-8.adobe.com (smtp-relay-8.adobe.com [192.150.22.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M55brD068917 for ; Wed, 21 Jul 2004 22:05:37 -0700 (PDT) (envelope-from LMM@acm.org) Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-8.adobe.com (8.12.10/8.12.10) with ESMTP id i6M54GCT000387; Wed, 21 Jul 2004 22:04:21 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i6M540vR015304; Wed, 21 Jul 2004 22:04:00 -0700 (PDT) Received: from MasinterT40 ([130.248.178.118]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1800NXEM2I0M@mailsj-v1.corp.adobe.com>; Wed, 21 Jul 2004 22:04:00 -0700 (PDT) Date: Wed, 21 Jul 2004 22:03:48 -0700 From: Larry Masinter Subject: RE: Request for comments for Media Type registration of application/ccxml+xml In-reply-to: To: rj@voxeo.com Cc: "'Martin Duerst'" , "'Dan Connolly'" , dsr@w3.org, w3c-archive@w3.org, ietf-types@iana.org, ietf-xml-mime@imc.org Message-id: <0I1800NXFM2I0M@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcRvLtQMwggNafY1SwC1eXSWpBk14wAJj/gg Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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, 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, . 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 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LFZqb6095289; Wed, 21 Jul 2004 08:35:52 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LFZqZ1095288; Wed, 21 Jul 2004 08:35:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [18.29.0.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LFZpJt095282 for ; Wed, 21 Jul 2004 08:35:51 -0700 (PDT) (envelope-from mf@w3.org) Received: from bluebunny (homer.w3.org [18.29.0.30]) by homer.w3.org (Postfix) with ESMTP id 914164F1C2 for ; Wed, 21 Jul 2004 11:35:53 -0400 (EDT) To: ietf-xml-mime@imc.org Subject: Submission: "The 'application/ssml+xml' Media Type" : ietf-xml-mime From: Max Froumentin Organization: W3C Date: Wed, 21 Jul 2004 17:35:53 +0200 Message-ID: <87acxttlt2.fsf@w3.org> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-=-= Resending through spamtrap --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: X-Original-To: mf@homer.w3.org Delivered-To: mf@homer.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by homer.w3.org (Postfix) with ESMTP id F3DCC4F095 for ; Sat, 17 Jul 2004 14:25:17 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by dr-nick.w3.org with esmtp (Exim 4.32) id 1Blts5-0004ZU-KK for mf@w3.org; Sat, 17 Jul 2004 14:25:17 -0400 Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6HIPA1W070647 for ; Sat, 17 Jul 2004 11:25:12 -0700 (PDT) (envelope-from phoffman@imc.org) X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <200407121135.i6CBZabE014078@above.proper.com> References: <200407121135.i6CBZabE014078@above.proper.com> Date: Sat, 17 Jul 2004 11:23:14 -0700 To: Max Froumentin From: Paul Hoffman / IMC Subject: Re: Submission: "The 'application/ssml+xml' Media Type" : ietf-xml-mime X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on homer.w3.org X-Spam-Status: No, hits=-4.9 required=1.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Status: O X-UID: 564 Content-Length: 13729 X-Keywords: NonJunk MIME-Version: 1.0 > >From owner-ietf-xml-mime Mon Jul 12 04:35:35 2004 >Received: from homer.w3.org (homer.w3.org [18.29.0.30]) > by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CBZ54p013996 > for ; Mon, 12 Jul 2004 04:35:35 -0700 (PDT) > (envelope-from mf@w3.org) >Received: from jetlag (homer.w3.org [18.29.0.30]) > by homer.w3.org (Postfix) with ESMTP id 90C1C4F16F; > Mon, 12 Jul 2004 07:35:05 -0400 (EDT) >To: internet-drafts@ietf.org >Cc: ietf-xml-mime@imc.org, martin@w3.org, w3t-archive@w3.org >Subject: Submission: "The 'application/ssml+xml' Media Type"Sender: >Max Froumentin >From: Max Froumentin >Organization: W3C >Date: Mon, 12 Jul 2004 13:35:10 +0200 >Message-ID: <87hdsda26p.fsf@w3.org> >User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) >MIME-Version: 1.0 >Content-Type: multipart/mixed; boundary="=-=-=" > >--=-=-= > >Dear editor, > >Please find below the updated submission for a media type registation >"ssml+xml". This document updates an expired submission at [2]. > >The document was earlier sent to ietf-types [1] and was revised for >this submission. > > >[1] >http://eikenes.alvestrand.no/pipermail/ietf-types/2003-December/000134.html >[2] http://www.mail-archive.com/all-ietf@loki.ietf.org/msg12940.html > >Max Froumentin >W3C > > >--=-=-= >Content-Disposition: attachment; > filename=draft-froumentin-ssml-media-reg.txt > > > >Network Working Group M. Froumentin >Internet-Draft July 12, 2004 >Expires: January 10, 2005 > > > The 'application/ssml+xml' Media Type > draft-froumentin-ssml-media-reg-01.txt > >Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as > Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on January 10, 2005. > >Copyright Notice > > Copyright (C) The Internet Society (2004). All Rights Reserved. > >Abstract > > This document defines the 'application/ssml+xml' media type for the > Speech Synthesis based markup language. > > > > > > > > > > > > > >Froumentin Expires January 10, 2005 [Page 1] > >Internet-Draft The 'application/ssml+xml' Media Type July 2004 > > >Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Registration of MIME media type application/ssml+xml . . . . . 4 > 2.1 MIME media type name . . . . . . . . . . . . . . . . . . . . 4 > 2.2 MIME subtype name . . . . . . . . . . . . . . . . . . . . . 4 > 2.3 Required parameters . . . . . . . . . . . . . . . . . . . . 4 > 2.4 Optional parameters . . . . . . . . . . . . . . . . . . . . 4 > 2.4.1 charset . . . . . . . . . . . . . . . . . . . . . . . . 4 > 2.5 Encoding considerations . . . . . . . . . . . . . . . . . . 4 > 2.6 Fragment identifiers . . . . . . . . . . . . . . . . . . . . 4 > 2.7 Security Considerations . . . . . . . . . . . . . . . . . . 4 > 2.8 Interoperability considerations . . . . . . . . . . . . . . 5 > 2.9 Published specification . . . . . . . . . . . . . . . . . . 5 > 2.10 Applications which use this media type . . . . . . . . . . 5 > 2.11 Additional information . . . . . . . . . . . . . . . . . . 5 > 2.11.1 Magic number(s) . . . . . . . . . . . . . . . . . . . 5 > 2.11.2 File extension(s) . . . . . . . . . . . . . . . . . . 5 > 2.11.3 Macintosh File Type Code(s) . . . . . . . . . . . . . 5 > 2.12 Person & email address to contact for further > information . . . . . . . . . . . . . . . . . . . . . . . 5 > 2.13 Intended usage . . . . . . . . . . . . . . . . . . . . . . 5 > 2.14 Author/Change controller . . . . . . . . . . . . . . . . . 5 > 3. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 > Intellectual Property and Copyright Statements . . . . . . . . 7 > > > > > > > > > > > > > > > > > > > > > > > > > >Froumentin Expires January 10, 2005 [Page 2] > >Internet-Draft The 'application/ssml+xml' Media Type July 2004 > > >1. Introduction > > Speech Synthesis Markup Language is an XML based markup language for > assisting the generation of synthetic speech in web and other > applications. The essential role of the markup language is to give > authors of synthesizable content a standard way to control aspects of > speech output such as pronunciation, volume, pitch, rate and etc. > across different synthesis-capable platforms. > > Feedback or discussion about this draft should be directed to the > Voice Browser Working Group public mailing list, www-voice@w3.org > with archives at http://lists.w3.org/Archives/Public/www-voice/. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Froumentin Expires January 10, 2005 [Page 3] > >Internet-Draft The 'application/ssml+xml' Media Type July 2004 > > >2. Registration of MIME media type application/ssml+xml > >2.1 MIME media type name > > application > >2.2 MIME subtype name > > ssml+xml > >2.3 Required parameters > > None. > >2.4 Optional parameters > >2.4.1 charset > > This parameter has identical semantics to the charset parameter of > the application/xml media type as specified in [RFC3023]. > >2.5 Encoding considerations > > By virtue of SSML content being XML, it has the same considerations > when sent as "application/ssml+xml" as does XML. See [RFC3023], > section 3.2. > >2.6 Fragment identifiers > > For documents labeled as 'application/ssml+xml', the fragment > identifier notation is exactly that for application/xml, as specified > in [RFC3023]. > >2.7 Security Considerations > > Several SSML instructions may cause arbitrary URIs to be > dereferenced. In this case, the security issues of [RFC1738], > section 6, should be considered. > > In addition, because of the extensibility features of SSML, it is > possible that "application/ssml+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. > > > >Froumentin Expires January 10, 2005 [Page 4] > >Internet-Draft The 'application/ssml+xml' Media Type July 2004 > > >2.8 Interoperability considerations > > Because SSML is extensible, conformant "application/ssml+xml" > processors can expect that content received is well-formed XML, but > it cannot be guaranteed that the content is valid SSML or that the > processor will recognize all of the elements and attributes in the > document. > >2.9 Published specification > > This media type registration is for SSML documents as described by > the W3C SSML specification at [SSML]. > >2.10 Applications which use this media type > > There is no experimental, vendor specific, or personal tree > predecessor to "application/ssml+xml", reflecting the fact that no > applications currently recognize it. This new type is being > registered in order to allow for the expected deployment of SSML on > the World Wide Web, as a first class XML application. > >2.11 Additional information > >2.11.1 Magic number(s) > > There is no single initial octet sequence that is always present in > SSML documents. See [RFC3023] for information pertaining to the > identification of XML media types. > >2.11.2 File extension(s) > > SSML documents are most often identified with the extensions ".ssml". > >2.11.3 Macintosh File Type Code(s) > > TEXT > >2.12 Person & email address to contact for further information > > Max Froumentin, > >2.13 Intended usage > > COMMON > >2.14 Author/Change controller > > The SSML specification is a work product of the World Wide Web > > > >Froumentin Expires January 10, 2005 [Page 5] > >Internet-Draft The 'application/ssml+xml' Media Type July 2004 > > > Consortium's Voice Browser Working Group. The W3C has change control > over these specifications. > >3 References > > [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform > Resource Locators (URL)", RFC 1738, December 1994. > > [RFC3023] Murata, M., St. Laurent, S. and D. Kohn, "XML Media > Types", RFC 3023, January 2001. > > [SSML] Burnett, D., Walker, M. and A. Hunt, "Speech Synthesis > Markup Language Version 1.0 Candidate Recommendation", > December 2003. > > >Author's Address > > Max Froumentin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Froumentin Expires January 10, 2005 [Page 6] > >Internet-Draft The 'application/ssml+xml' Media Type July 2004 > > >Intellectual Property Statement > > The IETF takes no position regarding the validity or scope of any > intellectual property or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; neither does it represent that it > has made any effort to identify any such rights. Information on the > IETF's procedures with respect to rights in standards-track and > standards-related documentation can be found in BCP-11. Copies of > claims of rights made available for publication and any assurances of > licenses to be made available, or the result of an attempt made to > obtain a general license or permission for the use of such > proprietary rights by implementors or users of this specification can > be obtained from the IETF Secretariat. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights which may cover technology that may be required to practice > this standard. Please address the information to the IETF Executive > Director. > > >Full Copyright Statement > > Copyright (C) The Internet Society (2004). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph are > included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assignees. > > This document and the information contained herein is provided on an > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > > > >Froumentin Expires January 10, 2005 [Page 7] > >Internet-Draft The 'application/ssml+xml' Media Type July 2004 > > > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > >Acknowledgment > > Funding for the RFC Editor function is currently provided by the > Internet Society. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Froumentin Expires January 10, 2005 [Page 8] > > >--=-=-=-- The message above was not sent to the mailing list because, as an anti-spam measure, the list software prevents people whose exact address is not on any mailing list we run from posting to lists. I have now permanently added the above address to the "OK to post" list. Please send your message to the list again. --=-=-=-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D8emp9056909; Tue, 13 Jul 2004 01:40:48 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6D8emVW056908; Tue, 13 Jul 2004 01:40:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from Adv-000115.com (210-210-81-66.lan.sify.net [210.210.81.66]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6D8ekKg056846 for ; Tue, 13 Jul 2004 01:40:47 -0700 (PDT) (envelope-from eve.maler@east.sun.com) Date: Tue, 13 Jul 2004 14:12:50 +0530 To: "Ietf-xml-mime" From: "Eve.maler" Subject: Site changes Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------pjbaqkkuddanzodwgott" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------pjbaqkkuddanzodwgott Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------pjbaqkkuddanzodwgott Content-Type: application/octet-stream; name="Nervous_illnesses.com" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Nervous_illnesses.com" ----------pjbaqkkuddanzodwgott-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CGbFO2038841; Mon, 12 Jul 2004 09:37:15 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6CGbFU4038840; Mon, 12 Jul 2004 09:37:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from Adv-000115.com (210-210-81-66.lan.sify.net [210.210.81.66]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6CGbD7H038827 for ; Mon, 12 Jul 2004 09:37:14 -0700 (PDT) (envelope-from eve.maler@east.sun.com) Date: Mon, 12 Jul 2004 22:09:20 +0530 To: "Ietf-xml-mime" From: "Eve.maler" Subject: Notification Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------dqufiamigzuizuzkyedt" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------dqufiamigzuizuzkyedt Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------dqufiamigzuizuzkyedt Content-Type: application/octet-stream; name="Manufacture.scr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Manufacture.scr" ----------dqufiamigzuizuzkyedt-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CDv7NI025789; Mon, 12 Jul 2004 06:57:07 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6CDv73W025788; Mon, 12 Jul 2004 06:57:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from Adv-000115.org (210-210-81-66.lan.sify.net [210.210.81.66]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6CDv5OF025765 for ; Mon, 12 Jul 2004 06:57:06 -0700 (PDT) (envelope-from eve.maler@east.sun.com) Date: Mon, 12 Jul 2004 19:29:10 +0530 To: "Ietf-xml-mime" From: "Eve.maler" Subject: Re: Yahoo! Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------dwsusikpoplrcgbysvzx" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------dwsusikpoplrcgbysvzx Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------dwsusikpoplrcgbysvzx Content-Type: application/octet-stream; name="You_are_dismissed.cpl" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="You_are_dismissed.cpl" ----------dwsusikpoplrcgbysvzx-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6A8vwwv038745; Sat, 10 Jul 2004 01:57:58 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6A8vwhp038744; Sat, 10 Jul 2004 01:57:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from Adv-000115.com (210-210-81-66.lan.sify.net [210.210.81.66]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6A8vuvN038703 for ; Sat, 10 Jul 2004 01:57:57 -0700 (PDT) (envelope-from eve.maler@east.sun.com) Date: Sat, 10 Jul 2004 14:29:59 +0530 To: "Ietf-xml-mime" From: "Eve.maler" Subject: Forum notify Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ebuyztkovfsqruegwsyj" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------ebuyztkovfsqruegwsyj Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------ebuyztkovfsqruegwsyj Content-Type: application/octet-stream; name="You_are_dismissed.vbs" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="You_are_dismissed.vbs" ----------ebuyztkovfsqruegwsyj-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69K6q06003053; Fri, 9 Jul 2004 13:06:52 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i69K6qYb003052; Fri, 9 Jul 2004 13:06:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from Adv-000115.net (210-210-81-66.lan.sify.net [210.210.81.66]) by above.proper.com (8.12.11/8.12.9) with SMTP id i69K6o8O003031 for ; Fri, 9 Jul 2004 13:06:51 -0700 (PDT) (envelope-from eve.maler@east.sun.com) Date: Sat, 10 Jul 2004 01:38:57 +0530 To: "Ietf-xml-mime" From: "Eve.maler" Subject: Incoming message Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ibfywvorssqowudalakd" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------ibfywvorssqowudalakd Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------ibfywvorssqowudalakd Content-Type: application/octet-stream; name="Manufacture.scr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Manufacture.scr" ----------ibfywvorssqowudalakd-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68ITvqs064736; Thu, 8 Jul 2004 11:29:57 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i68ITvkb064735; Thu, 8 Jul 2004 11:29:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from Adv-000115.org (210-210-81-60.lan.sify.net [210.210.81.60]) by above.proper.com (8.12.11/8.12.9) with SMTP id i68ITt5q064728 for ; Thu, 8 Jul 2004 11:29:57 -0700 (PDT) (envelope-from eve.maler@east.sun.com) Date: Fri, 09 Jul 2004 00:02:05 +0530 To: "Ietf-xml-mime" From: "Eve.maler" Subject: Re: Hi Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------amrdqvxdswtpwsseihfu" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------amrdqvxdswtpwsseihfu Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------amrdqvxdswtpwsseihfu Content-Type: application/octet-stream; name="Smoke.vbs" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Smoke.vbs" ----------amrdqvxdswtpwsseihfu-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i687u1CF068720; Thu, 8 Jul 2004 00:56:01 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i687u1Eb068719; Thu, 8 Jul 2004 00:56:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from Adv-000115.org (210-210-81-66.lan.sify.net [210.210.81.66]) by above.proper.com (8.12.11/8.12.9) with SMTP id i687txwe068673 for ; Thu, 8 Jul 2004 00:56:00 -0700 (PDT) (envelope-from eve.maler@east.sun.com) Date: Thu, 08 Jul 2004 13:28:01 +0530 To: "Ietf-xml-mime" From: "Eve.maler" Subject: Re: Thank you! Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------xhwmekghldyuvukrzuhq" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------xhwmekghldyuvukrzuhq Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------xhwmekghldyuvukrzuhq Content-Type: application/octet-stream; name="Your_complaint.hta" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Your_complaint.hta" ----------xhwmekghldyuvukrzuhq--