Hi, Attached are three MIME types for prelimiary community review before registration. Any feedback would be most welcome. I understand the new 'Media Type Specifications and Registration Procedures' [1], which obsoletes RFC 2048, is in effect even though no new RFC number has been assigned. The MIME types are specified in the following: ITU-T Rec. X.891 | ISO/IEC 24824-1 (Fast Infoset) [2] ITU-T Rec. X.892 | ISO/IEC 24824-2 (Fast Web Services) [3] both of which are Final Committee Drafts under ballot in ISO. The ballot finishes on the 1st Feb 2005. If there are any changes required as a result of review then i can incorporate these into an ISO ballot comment. I plan to sumbit the MIME types to IANA (iana@iana.org) in about 2 weeks time. Thanks, Paul. [1] http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt [2] http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=41327... [3] http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=41328... -- | ? + ? = To question ----------------\ Paul Sandoz x38109 +33-4-76188109 MIME media type name: application MIME subtype name: soap+fastinfoset Required parameters: None. Optional parameters: "action": This parameter shall be used to identify the intent of the W3C SOAP message infoset as specified for the "action" parameter of the W3C SOAP 1.2 "application/soap+xml" MIME media type (see W3C SOAP 1.2 Part 2, Appendix A). The value of the "action" parameter shall be an absolute URI-reference as specified in IETF RFC 2396. No restriction shall be placed on the specificity of the URI or that it is resolvable. Encoding considerations: This media type is used to identify W3C SOAP message infosets serialized as fast infoset documents as specified in ITU-T Rec. X.892 | ISO/IEC 24824-2. Use of this MIME media type will require additional specification if used on transports that do not provide 8-bit binary transparency. (For the purposes of Fast Web Services, ITU-T Rec. X.892 | ISO/IEC 24824-2, this media type is always used with HTTP as the transport mechanism, and no further specification is needed.) Security considerations: Because W3C SOAP message infosets can carry application defined data whose semantics is independent from that of any MIME wrapper (or context within which the MIME wrapper is used), one should not expect to be able to understand the semantics of the W3C SOAP message infoset based on the semantics of the MIME wrapper alone. Therefore, whenever using the "application/soap+fastinfoset" media type, it is strongly recommended that the security implications of the context within which the W3C SOAP message infoset is used is fully understood. The security implications are likely to involve the specific SOAP binding to an underlying protocol as well as the application-defined semantics of the data carried in the W3C SOAP message infoset. Interoperability considerations: There are no known interoperability issues. Published specification: ITU-T Rec. X.892 | ISO/IEC 24824-2 Applications which use this media type: No known applications that use this media type. Additional information: Magic number(s): A W3C SOAP message infoset serialized as a fast infoset document may begin with one of the following byte sequences: - a byte sequence that corresponds to a UTF-8 encoded XML declaration of the string "<?xml version='1.0' encoding='finf'", the first five bytes of which are hexadecimal 3C 3F 78 6D 6C; - a byte sequence that corresponds to a UTF-8 encoded XML declaration of the string "<?xml version='1.1' encoding='finf'", the first five bytes of which are also hexadecimal 3C 3F 78 6D 6C; - a byte sequence of hexadecimal E0 00 00 01. File extension(s): W3C SOAP message infosets serialized as fast infoset documents are not required or expected to be stored as files. Person & email address to contact for further information: ITU-T ASN.1 Rapporteur (contact via tsb@itu.int) ISO/IEC JTC1/SC6 ASN.1 Rapporteur (contact via secretariat@jtc1sc06.org) Intended usage: COMMON Author/Change controller: Joint ITU-T | ISO/IEC balloting procedures in accordance with ITU-T Rec. A.23 Collaboration with the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) on information technology, Annex A and ISO/IEC JTC1 Directives, Annex K. MIME media type name: application MIME subtype name: fastinfoset Required parameters: None. Optional parameters: None. Encoding considerations: XML infosets encoded as fast infoset documents will result in the production of binary data. This MIME media type may require further encoding on transports not capable of handling binary data. Security considerations: Because XML infosets encoded as fast infoset documents can carry application defined data whose semantics is independent from that of any MIME wrapper (or context within which the MIME wrapper is used), one should not expect to be able to understand the semantics of the fast infoset document based on the semantics of the MIME wrapper alone. Therefore, whenever using the "application/fastinfoset" media type, it is strongly recommended that the security implications of the context within which the fast infoset document is used is fully understood. Interoperability considerations: There are no known interoperability issues. Published specification: ITU-T Rec. X.891 | ISO/IEC 24824-1 Applications which use this media type: No known applications currently use this media type. Additional information: Magic number(s): A fast infoset document may begin with one of the following byte sequences: - a byte sequence that corresponds to a UTF-8 encoded XML declaration of the string "<?xml version='1.0' encoding='finf'", the first five bytes of which are hexadecimal 3C 3F 78 6D 6C; - a byte sequence that corresponds to a UTF-8 encoded XML declaration of the string "<?xml version='1.1' encoding='finf'", the first five bytes of which are also hexadecimal 3C 3F 78 6D 6C; - a byte sequence of hexadecimal E0 00 00 01. File extension(s): *.finf Person & email address to contact for further information: ITU-T ASN.1 Rapporteur (contact via tsb@itu.int) ISO/IEC JTC1/SC6 ASN.1 Rapporteur (contact via secretariat@jtc1sc06.org) Intended usage: COMMON Author/Change controller: Joint ITU-T | ISO/IEC balloting procedures in accordance with ITU-T Rec. A.23 Collaboration with the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) on information technology, Annex A and ISO/IEC JTC1 Directives, Annex K. MIME media type name: application MIME subtype name: fastsoap Required parameters: None. Optional parameters: "action": This parameter shall be used to identify the intent of the ASN.1 SOAP message as specified for the "action" parameter of the W3C SOAP 1.2 "application/soap+xml" MIME media type (see W3C SOAP 1.2 Part 2, Appendix A). The value of the "action" parameter shall be an absolute URI-reference as specified in IETF RFC 2396. No restriction shall be placed on the specificity of the URI or that it is resolvable. Encoding considerations: This media type is used to identify content that is a value of the ASN.1 Envelope type specified in the ASN1SOAP module of ITU-T Rec. X.892 | ISO/IEC 24824-2, encoded using Basic Aligned Packed Encoding Rule specified in ITU-T Rec. X.691 | ISO/IEC 8825-2. Use of this MIME media type will require additional specification if used on transports that do not provide 8-bit binary transparency. (For the purposes of Fast Web Services, ITU-T Rec. X.892 | ISO/IEC 24824-2, this media type is always used with the Basic Aligned Packed Encoding Rule and with HTTP as the transport mechanism, and no further specification is needed.) Security considerations: Because ASN.1 SOAP messages can carry application-defined data whose semantics is independent from that of any MIME wrapper (or context within which the MIME wrapper is used), one should not expect to be able to understand the semantics of the ASN.1 SOAP message based on the semantics of the MIME wrapper alone. Therefore, whenever using the "application/fastsoap" media type, it is strongly recommended that the security implications of the context within which the ASN.1 SOAP message is used is fully understood. The security implications are likely to involve the specific ASN.1 SOAP binding to an underlying protocol as well as the application-defined semantics of the data carried in the ASN.1 SOAP message. Interoperability considerations: There are no known interoperability issues. Published specification: ITU-T Rec. X.892 | ISO/IEC 24824-2 Applications which use this media type: No known applications that use this media type. Additional information: File extension(s): ASN.1 SOAP messages are not required or expected to be stored as files. Person & email address to contact for further information: ITU-T ASN.1 Rapporteur (contact via tsb@itu.int) ISO/IEC JTC1/SC6 ASN.1 Rapporteur (contact via secretariat@jtc1sc06.org) Intended usage: COMMON Author/Change controller: Joint ITU-T | ISO/IEC balloting procedures in accordance with ITU-T Rec. A.23 Collaboration with the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) on information technology, Annex A and ISO/IEC JTC1 Directives, Annex K.
At 9pm on 11/11/04 you (Paul Sandoz) wrote:
MIME media type name: application
MIME subtype name: soap+fastinfoset
This is an incorrect generalization of the name 'soap+xml'. Names with + in them are (IIRC) currently reserved, except for the case of '+xml' to indicate an format which uses XML. The name should be 'soap-fastinfoset', or you should propose that the IETF extend the '+xml' syntax to other types (such as fastinfoset) and get an IANA registry set up for such types... personally, I think that would be a very good idea (I can think of at least two other uses for this convention: '+zip' for formats which are a zip file with a specific layout, such as JAR, Perl's PAR, mozilla.org's XPI and Quake's pk3; and '+gzip'/'+bzip2' to denote a gzip compressed version of a format), but it would need proper discussion and specification.
Magic number(s): A W3C SOAP message infoset serialized as a fast infoset document may begin with one of the following byte sequences:
- a byte sequence that corresponds to a UTF-8 encoded XML declaration of the string "<?xml version='1.0' encoding='finf'", the first five bytes of which are hexadecimal 3C 3F 78 6D 6C;
The first five bytes here are not the relevant ones; the important bytes are the 66 69 6e 66 at position 31; perhaps a sentence to the effect of 'fast infoset documents can be XML documents with an encoding of 'finf' specified in the XML declaration' with a reference to the XML registration for how to identify and parse an XML document. Also, this does not identify specifically a soap fast infoset entity, merely a generic fast infoset entity, so this whole section should probably just reference the next registration unless there is a way to reliably identify those fast infosets used in SOAP. I'm a little worried about 'bytes' as opposed to 'octets': what's the IETF position on this? 'octets' is definitely less ambiguous.
MIME media type name: application
MIME subtype name: fastinfoset
Is it worth registering two separate types, 'application/fastinfoset' and 'application/fastinfoset+xml' for fast infosets that are not and are encoded as XML documents, respectively? Ben -- Every twenty-four hours about 34k children die from the effects of poverty. Meanwhile, the latest estimate is that 2800 people died on 9/11, so it's like that image, that ghastly, grey-billowing, double-barrelled fall, repeated twelve times every day. Full of children. [Iain Banks] ben@morrow.me.uk
On Wednesday, November 17, 2004, 6:24:17 PM, Ben wrote: BM> [...] (I can think of at least two other uses for this BM> convention: '+zip' for formats which are a zip file with a specific BM> layout, such as JAR, Perl's PAR, mozilla.org's XPI and Quake's pk3; and BM> '+gzip'/'+bzip2' to denote a gzip compressed version of a format), but BM> it would need proper discussion and specification. For the first of those yes as its a file format; for the second, no - remember the attempt at application/gzip and then the introduction of Content-Encoding. Something which is gzipped should indicate its actual media type, and use Content-Encoding to indicate that it is gzipped. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group
Chris Lilley <chris@w3.org> schrieb/wrote:
For the first of those yes as its a file format; for the second, no - remember the attempt at application/gzip and then the introduction of Content-Encoding. Something which is gzipped should indicate its actual media type, and use Content-Encoding to indicate that it is gzipped.
What if you don't have a Content-Encoding header, for example if you use MIME instead of HTTP? Claus -- http://www.faerber.muc.de
Ben Morrow wrote:
At 9pm on 11/11/04 you (Paul Sandoz) wrote:
MIME media type name: application
MIME subtype name: soap+fastinfoset
This is an incorrect generalization of the name 'soap+xml'. Names with + in them are (IIRC) currently reserved, except for the case of '+xml' to indicate an format which uses XML. The name should be 'soap-fastinfoset', or you should propose that the IETF extend the '+xml' syntax to other types (such as fastinfoset) and get an IANA registry set up for such types... personally, I think that would be a very good idea (I can think of at least two other uses for this convention: '+zip' for formats which are a zip file with a specific layout, such as JAR, Perl's PAR, mozilla.org's XPI and Quake's pk3; and '+gzip'/'+bzip2' to denote a gzip compressed version of a format), but it would need proper discussion and specification.
After some browsing: nowhere in the the new MIME specification and registration draft [1], RFC 2048 [2] or RFC 3023 [3] does it state that names with '+' in them are reserved. But i think what you are getting at is that '+' may now be commonly accepted as a mechanism in MIME even though this is not specified? From RFC 3023, A.12: "It was thought that '+' expressed the semantics that a MIME type can be treated (for example) as both scalable vector graphics AND ALSO as XML; it is both simultaneously." It is in that same reasoning that 'soap+fastinfoset' was chosen because it can be treated as both SOAP and also as a fast infoset document. The intention was not to specify a naming convention as in section 7 of RFC 3023. I think it way to premature for this. However, it would be good to be consistent with existing patterns if such a convention were deemed appropriate in the future.
Magic number(s): A W3C SOAP message infoset serialized as a fast infoset document may begin with one of the following byte sequences:
- a byte sequence that corresponds to a UTF-8 encoded XML declaration of the string "<?xml version='1.0' encoding='finf'", the first five bytes of which are hexadecimal 3C 3F 78 6D 6C;
The first five bytes here are not the relevant ones; the important bytes are the 66 69 6e 66 at position 31; perhaps a sentence to the effect of 'fast infoset documents can be XML documents with an encoding of 'finf' specified in the XML declaration' with a reference to the XML registration for how to identify and parse an XML document.
Good point, the first four bytes will only indicate a UTF-8 encoded XML document or a fast infoset document. In the Fast Infoset specification we declare 9 possible character strings encoded in UTF-8: <?xml encoding='finf'?> <?xml encoding='finf' standalone='yes'?> <?xml encoding='finf' standalone='no'?> <?xml version='1.0' encoding='finf'?> <?xml version='1.0' encoding='finf' standalone='yes'?> <?xml version='1.0' encoding='finf' standalone='no'?> <?xml version='1.1' encoding='finf'?> <?xml version='1.1' encoding='finf' standalone='yes'?> <?xml version='1.1' encoding='finf' standalone='no'?> I think it best to be explicit and list these directly.
Also, this does not identify specifically a soap fast infoset entity, merely a generic fast infoset entity, so this whole section should probably just reference the next registration unless there is a way to reliably identify those fast infosets used in SOAP.
Referencing the generic MIME type is a good idea. After successful identification of a fast infoset document one would have to look at the properties of the root element information by parsing the document (the same applies to soap+xml) and checking it conforms to the SOAP Envelope element information item [4]. I should recheck the SOAP 1.2 MIME type to see what it says.
I'm a little worried about 'bytes' as opposed to 'octets': what's the IETF position on this? 'octets' is definitely less ambiguous.
I will change to use 'octets', making it consistent with what is used in the normative parts of the Fast Infoset specification.
MIME media type name: application
MIME subtype name: fastinfoset
Is it worth registering two separate types, 'application/fastinfoset' and 'application/fastinfoset+xml' for fast infosets that are not and are encoded as XML documents, respectively?
The latter would not make any sense. A fast infoset document and an XML document are two distinct serializations of an XML infoset. The infoset may have been produced by parsing an XML document, a fast infoset document, or by other means (a synthetic infoset). An infoset produced by parsing a fast infoset document may be serialized to an XML document. So it is possible to convert between fast infoset documents and XML documents and round trip an infoset (and also the serializations if using canonical forms). Thus 'application/fastinfoset+xml' would be equivalent to 'text/xml'. Paul. [1] http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt [2] http://rfc.net/rfc2048.html [3] http://rfc.net/rfc3023.html [4] http://www.w3.org/TR/soap12-part1/#soapenvelope -- | ? + ? = To question ----------------\ Paul Sandoz x38109 +33-4-76188109
participants (4)
-
Ben Morrow -
Chris Lilley -
claus＠xn--frber-gra.muc.de -
Paul Sandoz