Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4NNanRZ003195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 May 2012 16:36:49 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.5/8.13.5/Submit) id q4NNana2003194; Wed, 23 May 2012 16:36:49 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from hamachi (hamachi.keio.w3.org [49.212.18.197]) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4NNal3U003188 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 23 May 2012 16:36:48 -0700 (MST) (envelope-from ashimura@w3.org) Received: from s78.22.229.222.fls.vectant.ne.jp ([222.229.22.78] helo=[192.168.0.5]) by hamachi with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SXL6g-0002OP-DC; Thu, 24 May 2012 08:36:42 +0900 Message-ID: <4FBD7445.3030404@w3.org> Date: Thu, 24 May 2012 08:35:33 +0900 From: Kazuyuki Ashimura User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Bjoern Hoehrmann CC: ietf-types@iana.org, ietf-xml-mime@imc.org, www-multimodal@w3.org Subject: Re: Request for review of EmotionML media type: application/emotionml+xml References: <4FABECC0.4050805@w3.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Bjoern, Thank you very much for your thoughtful comments. And very sorry for the delay. I was on business travel for a while, and got some trouble with sending emails after that. Could you please see inline below for my response? On 05/11/2012 10:22 AM, Bjoern Hoehrmann wrote: > > * Kazuyuki Ashimura wrote: >> W3C has just published a Candidate Recommendation for "Emotion Markup >> Language (EmotionML)" at: >> >> http://www.w3.org/TR/2012/CR-emotionml-20120510/ >> >> I am sending this request to ask the Ietf-types list for comments on >> the Media Type section of the EmotionML specification following the >> procedure defined at: >> >> http://www.w3.org/2002/06/registering-mediatype > > The procedure requires Working Groups to ask for ietf-types review when > making a Last Call announcement. I have not been able to find any such > request in the archive. If the Working Group failed to follow the pro- > cedure, it would be helpful if you could put that on the record. Sorry but as you pointed out we failed to send out a review request when we published the Last Call Working Draft. >> MIME media type name: >> --------------------- >> application > > This is using an outdated template. The current one is in RFC 4288. In > it, some field names are different and some fields are organized in a > different manner. Thank you for pointing out that, Bjoern. I've checked RFC4288 at: http://tools.ietf.org/html/rfc4288 and think we should say: [[ Type name: application Subtype name: emotionml+xml ]] instead here. >> Optional parameters: >> -------------------- >> charset >> >> This parameter has identical semantics to the charset parameter >> of the application/xml media type as specified in [RFC3023] or its >> successor. >> >> Encoding considerations: >> ------------------------ >> By virtue of EmotionML content being XML, it has the same >> considerations when sent as "application/emotionml+xml" as does XML. See >> RFC 3023 (or its successor), section 3.2. > > RFC 3023 has boilerplate for this, but the above seems close enough. Thanks. So the revised version of the EmotionML media type definition should be the following. Please note I've added "Applications that use this media type" field and "Restrictions on usage" field based on the RFC4288 template. Also I've split "Author/Change controller" field into "Author" field and "Change controller" field. [[ Type name: application Subtype name: emotionml+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 [RFC 3023] or its successor. Encoding considerations: By virtue of EmotionML content being XML, it has the same considerations when sent as "application/emotionml+xml" as does XML. See RFC 3023 (or its successor), section 3.2. Security considerations: EmotionML elements may include arbitrary URIs. Therefore the security issues of [RFC 3986], section 7, should be considered. In addition, because of the extensibility features for EmotionML, it is possible that "application/emotionml+xml" will 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 the required behavior for dealing with, among other things, unrecognized elements. Because EmotionML is extensible, conformant "application/emotionml+xml" processors MAY expect that content received is well-formed XML, but processors SHOULD NOT assume that the content is valid EmotionML or expect to recognize all of the elements and attributes in the document. Published specification: This media type registration is extracted from Appendix B of the "Emotion Markup Language (EmotionML) 1.0" specification. Additional information: Magic number(s): There is no single initial octet sequence that is always present in EmotionML documents. File extension(s): EmotionML documents are most often identified with the extensions ".emotionml". Macintosh File Type Code(s): TEXT Person & email address to contact for further information: Kazuyuki Ashimura, . Intended usage: COMMON Restrictions on usage: None. Author: The EmotionML specification is a work product of the World Wide Web Consortium's Multimodal Interaction Working Group. Change controller: The W3C has change control over these specifications. ]] Thanks, Kazuyuki -- Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice Tel: +81 466 49 1170 Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4B1MD0t073554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 18:22:13 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.5/8.13.5/Submit) id q4B1MDPH073553; Thu, 10 May 2012 18:22:13 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by hoffman.proper.com (8.14.5/8.14.3) with SMTP id q4B1MC7q073547 for ; Thu, 10 May 2012 18:22:12 -0700 (MST) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 11 May 2012 01:22:10 -0000 Received: from dslb-094-223-210-213.pools.arcor-ip.net (EHLO HIVE) [94.223.210.213] by mail.gmx.net (mp030) with SMTP; 11 May 2012 03:22:10 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19P2ecqCWZPPVSkFqvI9OpAogpaBUxt+InFhfEq/9 3HNqoCH3zGwaGB From: Bjoern Hoehrmann To: Kazuyuki Ashimura Cc: ietf-types@iana.org, ietf-xml-mime@imc.org, www-multimodal@w3.org Subject: Re: Request for review of EmotionML media type: application/emotionml+xml Date: Fri, 11 May 2012 03:22:10 +0200 Message-ID: References: <4FABECC0.4050805@w3.org> In-Reply-To: <4FABECC0.4050805@w3.org> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * Kazuyuki Ashimura wrote: >W3C has just published a Candidate Recommendation for "Emotion Markup >Language (EmotionML)" at: > > http://www.w3.org/TR/2012/CR-emotionml-20120510/ > >I am sending this request to ask the Ietf-types list for comments on >the Media Type section of the EmotionML specification following the >procedure defined at: > > http://www.w3.org/2002/06/registering-mediatype The procedure requires Working Groups to ask for ietf-types review when making a Last Call announcement. I have not been able to find any such request in the archive. If the Working Group failed to follow the pro- cedure, it would be helpful if you could put that on the record. >MIME media type name: >--------------------- > application This is using an outdated template. The current one is in RFC 4288. In it, some field names are different and some fields are organized in a different manner. >Optional parameters: >-------------------- > charset > > This parameter has identical semantics to the charset parameter >of the application/xml media type as specified in [RFC3023] or its >successor. > >Encoding considerations: >------------------------ > By virtue of EmotionML content being XML, it has the same >considerations when sent as "application/emotionml+xml" as does XML. See >RFC 3023 (or its successor), section 3.2. RFC 3023 has boilerplate for this, but the above seems close enough. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4AJVRpg037458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 12:31:27 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.5/8.13.5/Submit) id q4AJVRFB037457; Thu, 10 May 2012 12:31:27 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4AJVPSE037452 for ; Thu, 10 May 2012 12:31:26 -0700 (MST) (envelope-from paul@hoplahup.net) Received: from [192.168.178.32] (p5DDEC430.dip0.t-ipconnect.de [93.222.196.48]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0M7A5y-1SEzxv19a2-00wRnn; Thu, 10 May 2012 21:30:57 +0200 Subject: Re: Request for review of EmotionML media type: application/emotionml+xml Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Paul Libbrecht In-Reply-To: <4FABF6EE.80103@w3.org> Date: Thu, 10 May 2012 21:30:56 +0200 Cc: ietf-types@ietf.org, ietf-xml-mime@imc.org, www-multimodal@w3.org Message-Id: <119C90DA-0C41-4BA0-9FAA-477E6CA610AD@hoplahup.net> References: <4FABF6EE.80103@w3.org> To: Kazuyuki Ashimura X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:SyDH1SDAuLzpEHUgDpo11HLSf/ZzJPPkoK/QEPJ1UjR 7tS/4RV4AnphyKWK82qxWSZ13DJMxyvwPiTOCWZ3lb/kcqa+CZ agwOS1vUrIAjXA4EDbZevAEQSuewleM6iAhVYLGdcLk75w+f7D wNWOzTTRtm2RP7LDkNtU5f/u9fSqZc9zddhfZrE5f+ye32YxB6 L+52wXjs1CoD9fSD6dj1z7SHm16AjvITBiLqMTuwbekWC9eLPw kivzkS27Qj6BKHHinn2SjRHzXEIvy7slp9cdwiwhzGmwWRW5f+ t0Q9fVHL12fseTcVHHUsM68KF0YRtn40T6zuuzTDfDzUWRaBHV Qv9Ob/Jw0D9C44t6MxwnMBBN26IiVV5uyEvAOIiSbjI/WPcTgC 0Rzqkb4+ve7Pw== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id q4AJVQSE037453 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Kazuyuki, would you think as conceivable to put EmotionML into a clipboard? If yes it would be nice to include in this specification: - a Windows clipboard name (more or less, just a string) which applications would register at start - a Macintosh Uniform Type Identifier (which application descriptors could register) thanks in advance Paul Le 10 mai 2012 à 19:12, Kazuyuki Ashimura a écrit : > > Dear list, > # sorry but resending because I used wrong address for my previous post. > > W3C has just published a Candidate Recommendation for "Emotion Markup > Language (EmotionML)" at: > > http://www.w3.org/TR/2012/CR-emotionml-20120510/ > > I am sending this request to ask the Ietf-types list for comments on > the Media Type section of the EmotionML specification following the > procedure defined at: > > http://www.w3.org/2002/06/registering-mediatype > > --- > The Media Type section of the EmotionML specification is available > at: > > http://www.w3.org/TR/2012/CR-emotionml-20120510/#MIME-type > > and a plain text copy is also available below. > > MIME media type name: > --------------------- > application > > MIME subtype name: > ------------------ > emotionml+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] or its successor. > > Encoding considerations: > ------------------------ > By virtue of EmotionML content being XML, it has the same considerations when sent as "application/emotionml+xml" as does XML. See RFC 3023 (or its successor), section 3.2. > > Security considerations: > ------------------------ > EmotionML elements may include arbitrary URIs. Therefore the security issues of [RFC3986], section 7, should be considered. > > In addition, because of the extensibility features for EmotionML, it is possible that "application/emotionml+xml" will 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 the required behavior for dealing with, among other things, unrecognized elements. > > Because EmotionML is extensible, conformant "application/emotionml+xml" processors MAY expect that content received is well-formed XML, but processors SHOULD NOT assume that the content is valid EmotionML or expect to recognize all of the elements and attributes in the document. > > Published specification: > ------------------------ > This media type registration is extracted from Appendix B of the "Emotion Markup Language (EmotionML) 1.0" specification. > > Additional information: > ----------------------- > Magic number(s): > > There is no single initial octet sequence that is always present in EmotionML documents. > > File extension(s): > > EmotionML documents are most often identified with the extensions ".emotionml". > > Macintosh File Type Code(s): > > TEXT > > Person & email address to contact for further information: > ---------------------------------------------------------- > Kazuyuki Ashimura, . > > Intended usage: > --------------- > COMMON > > Author/Change controller: > ------------------------- > The EmotionML specification is a work product of the World Wide Web Consortium's Multimodal Interaction Working Group. The W3C has change control over these specifications. > > > ---------------------- > Normative References: > ---------------------- > > RFC 3023 > XML Media Types, M. Murata et al., Editors. IETF RFC 3023, January 2001. > > Sincerely, > > Kazuyuki > > -- > Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice > Tel: +81 466 49 1170 > > Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4AHDUKS022960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 10:13:30 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.5/8.13.5/Submit) id q4AHDUHc022957; Thu, 10 May 2012 10:13:30 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from hamachi (hamachi.keio.w3.org [49.212.18.197]) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4AHDSpR022946 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 10 May 2012 10:13:29 -0700 (MST) (envelope-from ashimura@w3.org) Received: from s1106153.xgsspn.imtp.tachikawa.spmode.ne.jp ([1.72.6.153] helo=[192.168.43.172]) by hamachi with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SSWve-0006Cs-0w; Fri, 11 May 2012 02:13:26 +0900 Message-ID: <4FABF6EE.80103@w3.org> Date: Fri, 11 May 2012 02:12:14 +0900 From: Kazuyuki Ashimura User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: ietf-types@ietf.org CC: ietf-xml-mime@imc.org, www-multimodal@w3.org Subject: Request for review of EmotionML media type: application/emotionml+xml Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear list, # sorry but resending because I used wrong address for my previous post. W3C has just published a Candidate Recommendation for "Emotion Markup Language (EmotionML)" at: http://www.w3.org/TR/2012/CR-emotionml-20120510/ I am sending this request to ask the Ietf-types list for comments on the Media Type section of the EmotionML specification following the procedure defined at: http://www.w3.org/2002/06/registering-mediatype --- The Media Type section of the EmotionML specification is available at: http://www.w3.org/TR/2012/CR-emotionml-20120510/#MIME-type and a plain text copy is also available below. MIME media type name: --------------------- application MIME subtype name: ------------------ emotionml+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] or its successor. Encoding considerations: ------------------------ By virtue of EmotionML content being XML, it has the same considerations when sent as "application/emotionml+xml" as does XML. See RFC 3023 (or its successor), section 3.2. Security considerations: ------------------------ EmotionML elements may include arbitrary URIs. Therefore the security issues of [RFC3986], section 7, should be considered. In addition, because of the extensibility features for EmotionML, it is possible that "application/emotionml+xml" will 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 the required behavior for dealing with, among other things, unrecognized elements. Because EmotionML is extensible, conformant "application/emotionml+xml" processors MAY expect that content received is well-formed XML, but processors SHOULD NOT assume that the content is valid EmotionML or expect to recognize all of the elements and attributes in the document. Published specification: ------------------------ This media type registration is extracted from Appendix B of the "Emotion Markup Language (EmotionML) 1.0" specification. Additional information: ----------------------- Magic number(s): There is no single initial octet sequence that is always present in EmotionML documents. File extension(s): EmotionML documents are most often identified with the extensions ".emotionml". Macintosh File Type Code(s): TEXT Person & email address to contact for further information: ---------------------------------------------------------- Kazuyuki Ashimura, . Intended usage: --------------- COMMON Author/Change controller: ------------------------- The EmotionML specification is a work product of the World Wide Web Consortium's Multimodal Interaction Working Group. The W3C has change control over these specifications. ---------------------- Normative References: ---------------------- RFC 3023 XML Media Types, M. Murata et al., Editors. IETF RFC 3023, January 2001. Sincerely, Kazuyuki -- Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice Tel: +81 466 49 1170 Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4AGU4BF019258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 May 2012 09:30:04 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.5/8.13.5/Submit) id q4AGU4td019257; Thu, 10 May 2012 09:30:04 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from hamachi (hamachi.keio.w3.org [49.212.18.197]) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4AGU2u1019252 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 10 May 2012 09:30:04 -0700 (MST) (envelope-from ashimura@w3.org) Received: from s1106153.xgsspn.imtp.tachikawa.spmode.ne.jp ([1.72.6.153] helo=[192.168.43.172]) by hamachi with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SSWFc-0006AI-Qk; Fri, 11 May 2012 01:30:00 +0900 Message-ID: <4FABECC0.4050805@w3.org> Date: Fri, 11 May 2012 01:28:48 +0900 From: Kazuyuki Ashimura User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: ietf-types@iana.org CC: ietf-xml-mime@imc.org, www-multimodal@w3.org Subject: Request for review of EmotionML media type: application/emotionml+xml Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear list, W3C has just published a Candidate Recommendation for "Emotion Markup Language (EmotionML)" at: http://www.w3.org/TR/2012/CR-emotionml-20120510/ I am sending this request to ask the Ietf-types list for comments on the Media Type section of the EmotionML specification following the procedure defined at: http://www.w3.org/2002/06/registering-mediatype --- The Media Type section of the EmotionML specification is available at: http://www.w3.org/TR/2012/CR-emotionml-20120510/#MIME-type and a plain text copy is also available below. MIME media type name: --------------------- application MIME subtype name: ------------------ emotionml+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] or its successor. Encoding considerations: ------------------------ By virtue of EmotionML content being XML, it has the same considerations when sent as "application/emotionml+xml" as does XML. See RFC 3023 (or its successor), section 3.2. Security considerations: ------------------------ EmotionML elements may include arbitrary URIs. Therefore the security issues of [RFC3986], section 7, should be considered. In addition, because of the extensibility features for EmotionML, it is possible that "application/emotionml+xml" will 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 the required behavior for dealing with, among other things, unrecognized elements. Because EmotionML is extensible, conformant "application/emotionml+xml" processors MAY expect that content received is well-formed XML, but processors SHOULD NOT assume that the content is valid EmotionML or expect to recognize all of the elements and attributes in the document. Published specification: ------------------------ This media type registration is extracted from Appendix B of the "Emotion Markup Language (EmotionML) 1.0" specification. Additional information: ----------------------- Magic number(s): There is no single initial octet sequence that is always present in EmotionML documents. File extension(s): EmotionML documents are most often identified with the extensions ".emotionml". Macintosh File Type Code(s): TEXT Person & email address to contact for further information: ---------------------------------------------------------- Kazuyuki Ashimura, . Intended usage: --------------- COMMON Author/Change controller: ------------------------- The EmotionML specification is a work product of the World Wide Web Consortium's Multimodal Interaction Working Group. The W3C has change control over these specifications. ---------------------- Normative References: ---------------------- RFC 3023 XML Media Types, M. Murata et al., Editors. IETF RFC 3023, January 2001. Sincerely, Kazuyuki -- Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice Tel: +81 466 49 1170