Re: Request for review of EmotionML media type: application/emotionml+xml

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 =E0 19:12, Kazuyuki Ashimura a =E9crit :

> =

> 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 consideratio=
ns when sent as "application/emotionml+xml" as does XML. See RFC 3023 (or i=
ts 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 i=
s possible that "application/emotionml+xml" will describe content that has =
security implications beyond those described here. However, if the processo=
r follows only the normative semantics of this specification, this content =
will be ignored. Only in the case where the processor recognizes and proces=
ses the additional content, or where further processing of that content is =
dispatched to other processors, would security issues potentially arise. An=
d in that case, they would fall outside the domain of this registration doc=
ument.
> =

> Interoperability considerations:
> --------------------------------
>    This specification describes processing semantics that dictate the req=
uired 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 proce=
ssors SHOULD NOT assume that the content is valid EmotionML or expect to re=
cognize all of the elements and attributes in the document.
> =

> Published specification:
> ------------------------
>    This media type registration is extracted from Appendix B of the "Emot=
ion Markup Language (EmotionML) 1.0" specification.
> =

> Additional information:
> -----------------------
>    Magic number(s):
> =

>        There is no single initial octet sequence that is always present i=
n 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, <[email protected]>.
> =

> Intended usage:
> ---------------
>    COMMON
> =

> Author/Change controller:
> -------------------------
>    The EmotionML specification is a work product of the World Wide Web Co=
nsortium'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
> =

> =