- Ietf-types - alvestrand.no

Media Type Request for comments: WS-CDL 1.0
by Yves Lafon 18 Nov '05

18 Nov '05

[ Notes: We slipped up in not sending this along with the Last Call announcement; please accept our apologies. Comments on the MIME-related part of the document may be made on the ietf-types mailing list or in the public-ws-chor-comments(a)w3.org mailing list.. See the "Status of this Document" section for further information. We are following http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-05.txt here, and the text is written to be part of a larger document. Finally, as WS-CDL is a description format and not something directly executable, the Working Group didn't identify any need for a specific security section. ] The current specification is at: http://www.w3.org/TR/2005/CR-ws-cdl-10-20051109/ The MIME Type template at http://www.w3.org/TR/ws-cdl-10/#Mime-Type-definition One typo already spotted, in the Author/Change controller, http://www.w3.org/2002/ws/chor/ should be a link with a text value of "Web Services Choreography Working Group". Thanks, Registration of MIME Media Type application/cdl+xml --------------------------------------------------- MIME media type name: application MIME subtype name: cdl+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 [RFC 3023]. Encoding considerations: Identical to those of "application/xml" as described in RFC 3023 [RFC 3023], section 3.2. Security considerations: WS-CDL has the same security considerations described in RFC3023 [RFC 3023], section 10. Interoperability considerations: There are no known interoperability issues. Published specification: This document Applications which use this media type: No known applications currently use this media type. Additional information: File extension: CDL Fragment identifiers: Identical to that of "application/xml" as described in RFC 3023 [RFC 3023], section 5. Base URI: As specified in RFC 3023 [RFC 3023], section 6. Macintosh File Type code: TEXT Person and email address to contact for further information: Yves Lafon <ylafon(a)w3.org> Intended usage: COMMON Author/Change controller: The WS-CDL 1.0 specification is a work product of the World Wide Web Consortium's http://www.w3.org/2002/ws/chor/. The W3C has change control over this specification. -------------------------------------------------------------- -- Yves Lafon - W3C "Baroula que barouleras, au tiéu toujou t'entourneras."

2 1

Request for media type review of audio/tone and audio/telephone-event
by Magnus Westerlund 15 Nov '05

15 Nov '05

This is the request of media type review of audio/telephone-event and audio/tone media types documented in section 7.1 of http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bis-12.txt The document is currently in WG last call in AVT WG. Please send any comments on these media types before Tuesday 29th of November to this list and to us AVT WG chairs (me and Colin Perkins). Thanks Magnus Westerlund AVT WG chair Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com

1 0

Registration of MIME media type application/mxf
by Thomas Edwards 04 Nov '05

04 Nov '05

This is a MIME media type registration for the Material Exchange Format (MXF) standard of the Society of Motion Picture and Television Engineers (SMPTE - http://www.smpte.org) MXF is a standard wrapper format developed for the interchange of audiovisual material, including both audiovisual essence and rich metadata. MXF and the .mxf file extension are used by many broadcast and digital cinema vendors today. The standard definition can be found in SMPTE 377M. Thomas Edwards Senior Manager, Interconnection Engineering Interconnection Replacement Office PBS 1320 Braddock Place Alexandria, VA 22314 Phone:(703) 739-5270 Fax: (703) 739-5770 Email: tedwards(a)pbs.org --------------- MIME media type name: application MIME subtype name: mxf Required parameters: none Optional parameters: none Encoding considerations: binary Security considerations: Application/mxf objects are not signed but may be partially encrypted internally. External security mechanisms must be employed to ensure content confidentiality. MXF, through metadata extensions, may allow executable code to be transferred in the file. It is suggested that no unauthenticated executables decoded from an MXF file be executed. Some compressed essence types carried in MXF may carry a risk that certain pathological bitstreams could lead to potential denial-of-service attacks against these essence decoders. Interoperability considerations: MXF provides a standard wrapping for a number of audio and video essence types according to a number of different Operational Patterns (OP). Thus interoperability depends upon the MXF file decoder having the capability to match the features of the MXF file encoder. An Application Specification (AS) can ensure that MXF encoders and decoders can effectively interoperate. Published specification: SMPTE 377M Applications which use this media type: MXF is a wrapper for many types of audio and video essence types in use by many applications in the broadcast and digital cinema industries. Additional information: Magic number(s): none File extension(s): .mxf Macintosh File Type Code(s): MXFF Object Identifier(s) or OID(s): none Person & email address to contact for further information: Thomas Edwards email: tedwards(a)pbs.org Intended usage: COMMON Author/Change controller: Thomas Edwards e-mail: tedwards(a)pbs.org ___________________________________________________________________ Big Big Friends are coming your way for Big Big Friend Day on PBS KIDS! On November 25th, join pals from CLIFFORD and DRAGON TALES For fun, surprises, and a peek at some brand new friends! pbskids.org ___________________________________________________________________ This email may contain material that is confidential or proprietary to PBS and is intended solely for use by the intended recipient. Any review, reliance or distribution of such material by others, or forwarding of such material without express permission, is strictly prohibited. If you are not the intended recipient, please notify the sender and destroy all copies. __________________________________________________________________

1 0

W3C Last Call and Media Type request for comments: XSLT 2.0
by Liam Quin 09 Sep '05

09 Sep '05

[ Notes: We slipped up in not sending this along with the Last Call announcement; please caaept our apologies. We are using bugzilla to track comments on this document; comments on the MIME-related part of the document may be made on the ietf-types mailing list or in Bugzilla. See the "Status of this Document" section for further information. We are following http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-05.txt here, and the text is written to be part of a larger document. Finally, as for XQuery, we'll probably expand the Security Considerations after gaining more implementation experience. ] Registration of MIME Media Type application/xslt+xml ---------------------------------------------------- MIME media type name: application MIME subtype name: xslt+xml Required parameters: None. Optional parameters: charset This parameter has identical semantics to the charset parameter of the application/xml media type as specified in [RFC3023]. Encoding considerations: By virtue of XSLT content being XML, it has the same considerations when sent as "application/xslt+xml" as does XML. See RFC 3023, section 3.2. Security considerations: Several XSLT instructions may cause arbitrary URIs to be dereferenced. In this case, the security issues of [RFC3986], section 7, should be considered. In addition, because of the extensibility features for XSLT, it is possible that "application/xslt+xml" may describe content that has security implications beyond those described here. However, if the processor follows only the normative semantics of this specification, this content will be ignored. Only in the case where the processor recognizes and processes the additional content, or where further processing of that content is dispatched to other processors, would security issues potentially arise. And in that case, they would fall outside the domain of this registration document. Interoperability considerations: This specification describes processing semantics that dictate behavior that must be followed when dealing with, among other things, unrecognized elements. Because XSLT is extensible, conformant "application/xslt+xml" processors can expect that content received is well-formed XML, but it cannot be guaranteed that the content is valid XSLT or that the processor will recognize all of the elements and attributes in the document. Published specification: This media type registration is for XSLT stylesheet modules as described by this specification. It is also appropriate to use this media type with earlier and later versions of the XSLT language. Applications which use this media type: Existing XSLT 1.0 stylesheets are most often described using the unregistered media type "text/xsl". There is no experimental, vendor specific, or personal tree predecessor to "application/xslt+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 XSLT 2.0 on the World Wide Web, as a first class XML application. Additional information: Magic number(s): There is no single initial octet sequence that is always present in XSLT documents. File extension(s): XSLT documents are most often identified with the extensions ".xsl" or ".xslt". Macintosh File Type Code(s): TEXT Person & email address to contact for further information: Norman Walsh, <Norman.Walsh(a)Sun.COM>. Intended usage: COMMON Author/Change controller: The XSLT specification is a work product of the World Wide Web Consortium's XSL Working Group. The W3C has change control over these specifications. B.2 Fragment Identifiers For documents labeled as "application/xslt+xml", the fragment identifier notation is exactly that for "application/xml", as specified in RFC 3023. -- Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/ http://www.holoweb.net/~liam/

6 8

Registration for application/mediaservercontrol+xml
by Eric Burger 23 Aug '05

23 Aug '05

This is a request for comments regarding the internet draft draft-vandyke-mscml-06 for media type "application/mediaservercontrol+xml". This media type is for media server control markup language documents. The MSCML specification is located at http://www.ietf.org/internet-drafts/draft-vandyke-mscml-06.txt Thanks.

1 0

Registration of media type application/wsdl+xml
by Hugo Haas 17 Aug '05

17 Aug '05

Following the procedure outlined in How to Register an Internet Media Type for a W3C Specification[1], I would like to request comments about the definition of the application/wsdl+xml media type. This new media type is defined in Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, W3C Working Draft 3 August 2005, which is a Last Call Working Draft[2], for which comments are invited until 19 September 2005 to the public-ws-desc-comments(a)w3.org mailing list (Reply-To set appropriately). The Web Services Description Language Version 2.0 (WSDL 2.0) is an XML language for describing Web services. Note that a previous Last Call Working Draft was published on 3 August 2005, for which feedback on the registration of application/wsdl+xml was requested on 4 October 2004[3] and the comment received[4] has been addressed in this new version. The definition of the media type can be found in appendix A. The application/wsdl+xml Media Type[5] of Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. A text copy of the section follows: A. The application/wsdl+xml Media Type This appendix defines the "application/wsdl+xml" media type which can be used to describe WSDL 2.0 documents serialized as XML. A.1 Registration MIME media type name: application MIME subtype name: wsdl+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]. Encoding considerations: Identical to those of "application/xml" as described in [RFC 3023 ], section 3.2, as applied to the WSDL document Infoset. Security considerations: See section A.3 Security considerations. Interoperability considerations: There are no known interoperability issues. Published specifications: This document and [WSDL 2.0 Adjuncts]. Applications which use this media type: No known applications currently use this media type. Additional information: File extension: wsdl Fragment identifiers: Either a syntax identical to that of "application/xml" as described in [RFC 3023], section 5 or the syntax defined in A.2 Fragment Identifiers. Base URI: As specified in [RFC 3023], section 6. Macintosh File Type code: WSDL Person and email address to contact for further information: World Wide Web Consortium <web-human(a)w3.org> Intended usage: COMMON Author/Change controller: The WSDL 2.0 specification set is a work product of the World Wide Web Consortium's Web Service Description Working Group. The W3C has change control over these specifications. A.2 Fragment Identifiers This section defines a fragment identifier syntax for identifying components of a WSDL 2.0 document. This fragment identifier syntax is compliant with the [XPointer Framework]. A WSDL 2.0 fragment identifier consists of zero or more xmlns pointer parts followed by a pointer part as defined below. The pointer parts have a scheme name that corresponds to one of the standard WSDL 2.0 component types, and scheme data that is a path composed of names that identify the components. The scheme names all begin with the prefix "wsdl." to avoid name conflicts with other schemes. The names in the path are of type either QName, NCName, IRI, URI, or Pointer Part depending on the context. For QNames, any prefix MUST be defined by a preceding xmlns pointer part. If a QName does not have a prefix then its namespace name is the target namespace of the WSDL 2.0 document. The fragment identifier is typically constructed from the {name} property of the component and the {name} properties of its ancestors as a path according to Table A-1. The first column of this table gives the name of the WSDL 2.0 component. Columns labeled 1 through 4 specify the identifiers that uniquely identify the component within its context. Identifiers are typically formed from the {name} property, although in several cases references to other components are used. These identifiers are then used to construct the pointer part in the last column. Table A-1. Rules for determining pointer parts for WSDL 2.0 components ┌───────────┬─────────┬─────────────────────────┬───────┬───────┬──────────────────────────────┐ │ Component │ 1 │ 2 │ 3 │ 4 │ Pointer Part │ ├───────────┼─────────┼─────────────────────────┼───────┼───────┼──────────────────────────────┤ │Description│n/a │n/a │n/a │n/a │wsdl.description() │ ├───────────┼─────────┼─────────────────────────┼───────┼───────┼──────────────────────────────┤ │Element │element │n/a │n/a │n/a │wsdl.elementDeclaration( │ │Declaration│QName │ │ │ │element) │ ├───────────┼─────────┼─────────────────────────┼───────┼───────┼──────────────────────────────┤ │Element │element │system URI │n/a │n/a │wsdl.elementDeclaration( │ │Declaration│QName │ │ │ │element,system) │ ├───────────┼─────────┼─────────────────────────┼───────┼───────┼──────────────────────────────┤ │Type │type │n/a │n/a │n/a │wsdl.typeDefinition(type) │ │Definition │QName │ │ │ │ │ ├───────────┼─────────┼─────────────────────────┼───────┼───────┼──────────────────────────────┤ │Type │type │system URI │n/a │n/a │wsdl.typeDefinition(type, │ │Definition │QName │ │ │ │system) │ ├───────────┼─────────┼─────────────────────────┼───────┼───────┼──────────────────────────────┤ │Interface │interface│n/a │n/a │n/a │wsdl.interface(interface) │ │ │NCName │ │ │ │ │ ├───────────┼─────────┼─────────────────────────┼───────┼───────┼──────────────────────────────┤ │Interface │interface│fault NCName │n/a │n/a │wsdl.interfaceFault(interface/│ │Fault │NCName │ │ │ │fault) │ ├───────────┼─────────┼─────────────────────────┼───────┼───────┼──────────────────────────────┤ │Interface │interface│operation NCName │n/a │n/a │wsdl.interfaceOperation( │ │Operation │NCName │ │ │ │interface/operation) │ ├───────────┼─────────┼─────────────────────────┼───────┼───────┼──────────────────────────────┤ │Interface │interface│ │message│ │wsdl.interfaceMessageReference│ │Message │NCName │operation NCName │NCName │n/a │(interface/operation/message) │ │Reference │ │ │ │ │ │ ├───────────┼─────────┼─────────────────────────┼───────┼───────┼──────────────────────────────┤ │Interface │interface│ │message│fault │wsdl.interfaceFaultReference( │ │Fault │NCName │operation NCName │NCName │QName │interface/operation/message/ │ │Reference │ │ │ │ │fault) │ ├───────────┼─────────┼─────────────────────────┼───────┼───────┼──────────────────────────────┤ │Binding │binding │n/a │n/a │n/a │wsdl.binding(binding) │ │ │NCName │ │ │ │ │ ├───────────┼─────────┼─────────────────────────┼───────┼───────┼──────────────────────────────┤ │Binding │binding │fault QName │n/a │n/a │wsdl.bindingFault(binding/ │ │Fault │NCName │ │ │ │fault) │ ├───────────┼─────────┼─────────────────────────┼───────┼───────┼──────────────────────────────┤ │Binding │binding │operation QName │n/a │n/a │wsdl.bindingOperation(binding/│ │Operation │NCName │ │ │ │operation) │ ├───────────┼─────────┼─────────────────────────┼───────┼───────┼──────────────────────────────┤ │Binding │binding │ │message│ │wsdl.bindingMessageReference( │ │Message │NCName │operation QName │NCName │n/a │binding/operation/message) │ │Reference │ │ │ │ │ │ ├───────────┼─────────┼─────────────────────────┼───────┼───────┼──────────────────────────────┤ │Binding │binding │ │fault │message│wsdl.bindingFaultReference( │ │Fault │NCName │operation QName │QName │NCName │binding/operation/fault/ │ │Reference │ │ │ │ │message) │ ├───────────┼─────────┼─────────────────────────┼───────┼───────┼──────────────────────────────┤ │Service │service │n/a │n/a │n/a │wsdl.service(service) │ │ │NCName │ │ │ │ │ ├───────────┼─────────┼─────────────────────────┼───────┼───────┼──────────────────────────────┤ │Endpoint │service │endpoint NCName │n/a │n/a │wsdl.endpoint(service/endpoint│ │ │NCName │ │ │ │) │ ├───────────┼─────────┼─────────────────────────┼───────┼───────┼──────────────────────────────┤ │ │parent │ │ │ │ │ │Feature │Pointer │feature IRI │n/a │n/a │wsdl.feature(parent/feature) │ │ │Part │ │ │ │ │ ├───────────┼─────────┼─────────────────────────┼───────┼───────┼──────────────────────────────┤ │ │parent │ │ │ │ │ │Property │Pointer │property IRI │n/a │n/a │wsdl.property(parent/property)│ │ │Part │ │ │ │ │ ├───────────┼─────────┼─────────────────────────┼───────┼───────┼──────────────────────────────┤ │Extensions │namespace│identifier │n/a │n/a │wsdl.extension(namespace, │ │ │URI │extension-specific-syntax│ │ │identifier) │ └───────────┴─────────┴─────────────────────────┴───────┴───────┴──────────────────────────────┘ Note that the above rules are defined in terms of component properties rather than the XML Infoset representation of the component model. The following sections specify in detail how the pointer parts are constructed from the component model. A.2.1 The Description Component wsdl.description() A.2.2 The Element Declaration Component wsdl.elementDeclaration(element) wsdl.elementDeclaration(element,system) 1. element is the {name} property of the Element Declaration component. 2. system is the absolute URI of the extension type system used for the Element Declaration component. This parameter is absent if XML Schema is the type system. A.2.3 The Type Definition Component wsdl.typeDefinition(type) wsdl.typeDefinition(type,system) 1. type is the {name} property of the Type Definition component. 2. system is the absolute URI of the extension type system used for the Type Definition component. This parameter is absent if XML Schema is the type system. A.2.4 The Interface Component wsdl.interface(interface) 1. interface is the local name of the {name} property of the Interface component. A.2.5 The Interface Fault Component wsdl.interfaceFault(interface/fault) 1. interface is the local name of the {name} property of the parent Interface component. 2. fault is the local name of the {name} property of the Interface Fault component. A.2.6 The Interface Operation Component wsdl.interfaceOperation(interface/operation) 1. interface is the local name of the {name} property of the parent Interface component. 2. operation is the local name of the {name} property of the Interface Operation component. A.2.7 The Interface Message Reference Component wsdl.interfaceMessageReference(interface/operation/message) 1. interface is the local name of the {name} property of the grandparent Interface component. 2. operation is the local name of the {name} property of the parent Interface Operation component. 3. message is the {message label} property of the Interface Message Reference component. A.2.8 The Interface Fault Reference Component wsdl.interfaceFaultReference(interface/operation/message/fault) 1. interface is the local name of the {name} property of the grandparent Interface component. 2. operation is the local name of the {name} property of the parent Interface Operation component. 3. message is the {message label} property of the Interface Fault Reference component. 4. fault is the {name} property of the Interface Fault component referred to by the {interface fault} property of the Interface Fault Reference component. A.2.9 The Binding Component wsdl.binding(binding) 1. binding is the local name of the {name} property of the Binding component. A.2.10 The Binding Fault Component wsdl.bindingFault(binding/fault) 1. binding is the local name of the {name} property of the parent Binding component. 2. fault is the {name} property of the Interface Fault component referred to by the {interface fault} property of the Binding Fault component. A.2.11 The Binding Operation Component wsdl.bindingOperation(binding/operation) 1. binding is the local name of the {name} property of the parent Binding component. 2. operation is the {name} property of the Interface Operation component referred to by the {interface operation} property of the Binding Operation component. A.2.12 The Binding Message Reference Component wsdl.bindingMessageReference(binding/operation/message) 1. binding is the local name of the {name} property of the grandparent Binding component. 2. operation is the {name} property of the Interface Operation component referred to by the {interface operation} property of the parent Binding Operation component. 3. message is the {message label} property of the Interface Message Reference component referred to by the {interface message reference} property of the Binding Message Reference component. A.2.13 The Binding Fault Reference Component wsdl.bindingFaultReference(binding/operation/fault/message) 1. binding is the local name of the {name} property of the grandparent Binding component. 2. operation is the {name} property of the Interface Operation component referred to by the {interface operation} property of the parent Binding Operation component. 3. fault is the {name} property of the Interface Fault component referred to by the {interface fault} property of the Interface Fault Reference component referred to by the {interface fault reference} property of the Binding Fault Reference component. 4. message is the {message label} property of the Interface Fault Reference component referred to by the {interface fault reference } property of the Binding Fault Reference component. A.2.14 The Service Component wsdl.service(service) 1. service is the local name of the {name} property of the Service component. A.2.15 The Endpoint Component wsdl.endpoint(service/endpoint) 1. service is the local name of the {name} property of the parent Service component. 2. endpoint is the {name} property of the Endpoint component. A.2.16 The Feature Component wsdl.feature(parent/feature) 1. parent is the pointer part of the parent component. 2. feature is the {ref} property of the Feature component. A.2.17 The Property Component wsdl.property(parent/property) 1. parent is the pointer part of the parent component. 2. property is the {ref} property of the Property component. A.2.18 Extension Components WSDL 2.0 is extensible and it is possible for an extension to define new components types. The XPointer Framework scheme for extension components is: wsdl.extension(namespace, identifier) 1. namespace is the namespace URI that identifies the extension, e.g. for the WSDL 2.0 SOAP 1.2 Binding the namespace is http:// www.w3.org/2005/08/wsdl/soap. 2. identifier is defined by the extension using a syntax specific to the extension. The owner of the extension must define any components contributed by the extension and a syntax for identifying them. A.3 Security considerations This media type uses the "+xml" convention, it shares the same security considerations as described in [RFC 3023], section 10. Regards, Hugo 1. http://www.w3.org/2002/06/registering-mediatype#Planned 2. http://www.w3.org/2004/02/Process-20040205/tr.html#last-call 3. http://eikenes.alvestrand.no/pipermail/ietf-types/2004-October/000438.html 4. http://www.alvestrand.no/pipermail/ietf-types/2005-February/000595.html 5. http://www.w3.org/TR/2005/WD-wsdl20-20050803/#ietf-draft -- Hugo Haas - W3C mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

1 0

Registration of MIME media type application/ocsp-response
by DCY 16 Aug '05

16 Aug '05

ietf-types，您好！　　　　　　　　致礼！　　　　　　　　DCY 　　　　　　　　210313041(a)suda.edu.cn 　　　　　　　　　　2005-04-19

2 1

Registration of media type application/xenc+xm
by Jose Kahan 16 Aug '05

16 Aug '05

(Resending as the previous post failed. Sorry for the duplicate posting. -jk) This is a media type registration as defined in Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures [MIME-REG] and Media Type Specifications and Registration Procedures [MEDIA-TYPE-REG]. XML Encryption Syntax and Processing [XML-Encryption] specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption element which contains or references the cipher data. The application/xenc+xml media type allows XML Encryption applications to identify encrypted documents. Additionally it allows applications cognizant of this media-type (even if they are not XML Encryption implementations) to note that the media type of the decrypted (original) object might be a type other than XML. --------------- Type name: application Subtype name: xenc+xml Required parameters: none. Optional parameters: charset, as defined in section 3.1 of RFC 3023 [XML-MT]. Encoding considerations: The encoding considerations are identical to those given for 'application/xml' in section 3.2 of RFC 3023 [XML-MT]. Security considerations: See section 6 of the [XML-Encryption]. Interoperability considerations: none. Published specification: [XML-Encryption]. Applications which use this media type: XML Encryption is device-, platform-, and vendor-neutral and is supported by a range of Web applications. See also section 4 of [XML-Encryption]. Additional information: Magic number(s): none Although no byte sequences can be counted on to consistently identify XML Encryption documents, they will be XML documents in which the root element's QName's LocalPart is 'EncryptedData' or 'EncryptedKey' with an associated namespace name of 'http://www.w3.org/2001/04/xmlenc#'. The application/xenc+xml type name MUST only be used for data objects in which the root element is from the XML Encryption namespace. XML documents which contain these element types in places other than the root element can be described using facilities such as [XML-schema]. File extension(s): .xml Macintosh file type code(s): "TEXT" Person & email address to contact for further information: jose+xe(a)w3.org xml-encryption(a)w3.org (public archived mailing list for the XMLENC Recommendation) Intended usage: COMMON Restrictions on usage: none. Author: The XML Encryption Recommendation is a work product of the World Wide Web Consortium (W3C) and was edited by: Donald Eastlake <dee3(a)torque.pothole.com> Joseph Reagle <reagle(a)w3.org> Change controller: The World Wide Web Consortium (W3C) has change control over the XML Encryption Recommendation and its related media types. References: [MEDIA-TYPE-REG] draft-freed-media-type-reg-05: Media Type Specifications and Registration Procedures. N. Freed, J. Klensin. Internet-Draft, July 26, 2005. http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-05.txt [MIME-REG] draft-freed-mime-p4-07: Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. N. Freed, J. Klensin. Internet-Draft, August 5, 2005. http://www.ietf.org/internet-drafts/draft-freed-mime-p4-07.txt [XML-Encryption] XML Encryption Syntax and Processing. D. Eastlake and J. Reagle (eds). W3C Recommendation, December 2002. http://www.w3.org/TR/2002/CR-xmlenc-core-20020802/ [XML-MT] RFC 3023: XML Media Types. M. Murata, S. St. Laurent, and D. Kohn. Informational, January 2001. http://www.ietf.org/rfc/rfc2376.txt [XML-schema] XML Schema Part 1: Structures D. Beech, M. Maloney, and N. Mendelsohn. W3C Recommendation, May 2001. http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ XML Schema Part 2: Datatypes. P. Biron and A. Malhotra. W3C Recommendation, May 2001. http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

1 0

Registration of media type application/xenc+xml
by Jose Kahan 16 Aug '05

16 Aug '05

This is a media type registration as defined in Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures [MIME-REG] and Media Type Specifications and Registration Procedures [MEDIA-TYPE-REG]. XML Encryption Syntax and Processing [XML-Encryption] specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption element which contains or references the cipher data. The application/xenc+xml media type allows XML Encryption applications to identify encrypted documents. Additionally it allows applications cognizant of this media-type (even if they are not XML Encryption implementations) to note that the media type of the decrypted (original) object might be a type other than XML. --------------- Type name: application Subtype name: xenc+xml Required parameters: none. Optional parameters: charset, as defined in section 3.1 of RFC 3023 [XML-MT]. Encoding considerations: The encoding considerations are identical to those given for 'application/xml' in section 3.2 of RFC 3023 [XML-MT]. Security considerations: See section 6 of the [XML-Encryption]. Interoperability considerations: none. Published specification: [XML-Encryption]. Applications which use this media type: XML Encryption is device-, platform-, and vendor-neutral and is supported by a range of Web applications. See also section 4 of [XML-Encryption]. Additional information: Magic number(s): none Although no byte sequences can be counted on to consistently identify XML Encryption documents, they will be XML documents in which the root element's QName's LocalPart is 'EncryptedData' or 'EncryptedKey' with an associated namespace name of 'http://www.w3.org/2001/04/xmlenc#'. The application/xenc+xml type name MUST only be used for data objects in which the root element is from the XML Encryption namespace. XML documents which contain these element types in places other than the root element can be described using facilities such as [XML-schema]. File extension(s): .xml Macintosh file type code(s): "TEXT" Person & email address to contact for further information: jose+xe(a)w3.org xml-encryption(a)w3.org (public archived mailing list for the XMLENC Recommendation) Intended usage: COMMON Restrictions on usage: none. Author: The XML Encryption Recommendation is a work product of the World Wide Web Consortium (W3C) and was edited by: Donald Eastlake <dee3(a)torque.pothole.com> Joseph Reagle <reagle(a)w3.org> Change controller: The World Wide Web Consortium (W3C) has change control over the XML Encryption Recommendation and its related media types. References: [MEDIA-TYPE-REG] draft-freed-media-type-reg-05: Media Type Specifications and Registration Procedures. N. Freed, J. Klensin. Internet-Draft, July 26, 2005. http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-05.txt [MIME-REG] draft-freed-mime-p4-07: Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. N. Freed, J. Klensin. Internet-Draft, August 5, 2005. http://www.ietf.org/internet-drafts/draft-freed-mime-p4-07.txt [XML-Encryption] XML Encryption Syntax and Processing. D. Eastlake and J. Reagle (eds). W3C Recommendation, December 2002. http://www.w3.org/TR/2002/CR-xmlenc-core-20020802/ [XML-MT] RFC 3023: XML Media Types. M. Murata, S. St. Laurent, and D. Kohn. Informational, January 2001. http://www.ietf.org/rfc/rfc2376.txt [XML-schema] XML Schema Part 1: Structures D. Beech, M. Maloney, and N. Mendelsohn. W3C Recommendation, May 2001. http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ XML Schema Part 2: Datatypes. P. Biron and A. Malhotra. W3C Recommendation, May 2001. http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

1 0

Request for comments regarding draft-mccobb-xv-media-type-00
by Gerald McCobb 12 Aug '05

12 Aug '05

This is a request for comments regarding the internet draft draft-mccobb-xv-media-type-00 for media type "application/xv+xml". This media type is for XHTML+Voice documents. The XHTML+Voice specification is located at http://www.voicexml.org/specs/multimodal/x+v/12/ . Network Working Group G. McCobb Internet-Draft IBM Corporation Expires: January 27, 2006 July 26, 2005 XHTML+Voice - application/xv+xml draft-mccobb-xv-media-type-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 27, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes the registration of the MIME sub-type application/xv+xml. This sub-type is intended for use as a media descriptor for XHTML+Voice multimodal language documents. The XHTML+ Voice 1.2 language specification is maintained by the VoiceXML Forum at <http://www.voicexml.org/specs/multimodal/x+v/12/>. McCobb Expires January 27, 2006 [Page 1] Internet-Draft XHTML+Voice - application/xv+xml July 2005 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1]. 2. Introduction XHTML+Voice is a member of the XHTML family of document types, as specified by XHTML Modularization [6]. XHTML+Voice extends XHTML 1.1 [7] with a modularized subset of VoiceXML 2.0 [11], XML Events [9], and a few extensions to both XHTML and VoiceXML 2.0. XHTML 1.1, VoiceXML 2.0 and XML Events are W3C Recommendations. The language integration defined by XHTML+Voice supports all modules defined by XHTML Modularization, and adds voice interaction to XHTML elements to enable multimodal applications. The defined document type for XHTML+Voice is XHTML Host language document type conformant. XHTML+Voice 1.2 [10] is maintained by the VoiceXML Forum, at URI location <http://www.voicexml.org/specs/multimodal/x+v/12/>. 2.1 application/xv+xml Usage The application/xv+xml media type is intended to be a media descriptor for XHTML+Voice multimodal documents. It is used to inform applications that additional markup for running a voice browser component and activating handlers for DOM Level 2 events via XML Events [9] can be processed. This media type registration is not intended for e-mail usage. 3. IANA Registration To: ietf-types(a)iana.org Subject: Registration of MIME media type application/xv+xml MIME media type name: application MIME subtype name: xv+xml Required parameters: none Optional parameters: charset: has the same semantics as the charset parameter of the "application/xml" media type specified in [3]. McCobb Expires January 27, 2006 [Page 2] Internet-Draft XHTML+Voice - application/xv+xml July 2005 Encoding considerations: XHTML+Voice has the same media type encoding considerations specified in section 3.2 of [3]. Security considerations: XHTML+Voice is an extension of XHTML and has the same security issues as XHTML. These include interpreting anchors and forms in XHTML documents, and scripting languages and other dynamic interactive capabilities. See section 7 of [4]. In addition, the scripting language can be accessed by both the XHTML and the VoiceXML 2.0 markup embedded in the XHTML+Voice document. See section 1.3.1.5 of [10]. XML-Events [9] allows an author to attach a handler to any node in the document. The handler that is activated in response to a specified event may be either a voice dialog or a script that can be either in the same or an external document. Interoperability considerations: Because XHTML+Voice is built upon W3C standard recommendations, it is designed to be interoperable across a wide range of platforms and client devices. Because the extensions to XHTML are identified by their namespaces, all browsers that have namespace support can run an XHTML+Voice document as an XHTML document without voice interaction. Published specification: The latest published version of XHTML+Voice is [10]. Applications which use this media type: XHTML+Voice documents are intended to be deployed on the World Wide Web and rendered by multimodal browsers that support the visual and voice modes of interaction. Because XHTML+Voice is an application of XML, authors can expect XHTML+Voice user agents to be conformant XML 1.0 [5] processors. See section 2 of [4]. Additional information: Magic number(s): There is no single string that is always present. File extension(s): mxml, xhvml, xvml, xvm Macintosh File Type Code(s): TEXT McCobb Expires January 27, 2006 [Page 3] Internet-Draft XHTML+Voice - application/xv+xml July 2005 Person & e-mail address to contact for further information: Gerald McCobb mccobb(a)us.ibm.com Intended usage: LIMITED USE Author/Change controller: Gerald McCobb Further information: 4. Fragment Identifiers See section 3 of [4]. Following [4], fragment identifiers for XHTML+ Voice documents designate the element with the corresponding ID attribute value (see [5] section 3.3.1). While XHTML+Voice adds new ID attributes with fragment identifier namespaces that are not in the same namespace as XHTML, uniqueness of the ID attribute values is preserved within the document. See sections 1.3.1 and 5.3 of [10]. 5. Recognizing XHTML+Voice files Because XHTML+Voice is XML, an XHTML+Voice document [optionally] starts with an XML declaration which begins with "<?xml" and has a DOCTYPE declaration "<!DOCTYPE html". XHTML+Voice 1.2 has the following DOCTYPE declaration: <!DOCTYPE html PUBLIC "-//VoiceXML Forum//DTD XHTML+Voice 1.2//EN" "http://www.voicexml.org/specs/multimodal/x+v/12/dtd/xhtml+voice12.dtd"> Because XHTML+Voice is in the XHTML family of languages, the root element of an XHTML+Voice document is 'html' and '<html' can be found near the top of the document. 6. Security Considerations Security considerations for this media type are discussed in the MIME type registration that appears in section 3. McCobb Expires January 27, 2006 [Page 4] Internet-Draft XHTML+Voice - application/xv+xml July 2005 7. IANA Considerations As described in Section 3, this document specifies the registration of a MIME type for XHTML+Voice documents according to [3]. 8. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels, BCP 14", RFC 2119, March 1997. [2] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [3] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [4] Baker, M. and P. Stark, "The 'application/xhtml+xml' Media Type", RFC 3236, January 2002. [5] Bray, T. and others, "Extensible Markup Language (XML) 1.0, W3C Recommendation, http://www.w3.org/TR/REC-xml", February 2004. [6] Dooley, S. and others, "Modularization of XHTML, W3C Recommendation, http://www.w3.org/TR/xhtml-modularization", April 2001. [7] Altheim, M. and S. McCarron, "XHTML 1.1 - Module-based XHTML, W3C Recommendation, http://www.w3.org/TR/xhtml11/", May 2001. [8] Pixley, T., "Document Object Model Level 2 Events Specification, W3C Recommendation, http://www.w3.org/TR/DOM-Level-2-Events/", November 2000. [9] Pemberton, S., Raman, T., and S. McCarron, "XML Events - An events syntax for XML, W3C Recommendation, http://www.w3.org/TR/xml-events/", January 2002. [10] Axelsson, J. and others, "XHTML+Voice Profile 1.2, http://www.voicexml.org/specs/multimodal/x+v/12/", March 2004. [11] McGlashan, S. and others, "Voice Extensible Markup Language (VoiceXML), W3C Recommendation, http://www.w3.org/TR/voicexml20/", March 2004. McCobb Expires January 27, 2006 [Page 5] Internet-Draft XHTML+Voice - application/xv+xml July 2005 Author's Address Gerald McCobb International Business Machines Corporation 8051 Congress Ave. Boca Raton, FL 33487 USA Phone: +1 561 862 2109 Email: mccobb(a)us.ibm.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr(a)ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. McCobb Expires January 27, 2006 [Page 6] Internet-Draft XHTML+Voice - application/xv+xml July 2005 Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. McCobb Expires January 27, 2006 [Page 7] Regards, Gerald McCobb IBM 8051 Congress Avenue Boca Raton, FL 33487 Tel. # 561-862-2109 T/L 975-2109

1 0