- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 21 Jul 2004 09:10:03 -1000
- To: Yves Lafon <ylafon@w3.org>
- Cc: XMLP Dist App <xml-dist-app@w3.org>
I thought we were going to wait for the startinfo discussion? On Jul 21, 2004, at 3:45 AM, Yves Lafon wrote: > All, > The media type is defined in the W3C Last Call Working Draft of > "SOAP Message Transmission Optimization Mechanism" [1] > Below is a full text version for convenience. [2] > Please direct comments to xmlp-comments@w3.org. > Best regards, > > [1] http://www.w3.org/TR/soap12-mtom/#media_type > [2] > A The application/soap_xop+xml Media Type > A.1 Introduction > > SOAP version 1.2 ([SOAP Part 1] and [SOAP Part 2]) is a lightweight > protocol intended for exchange of structured information between peers > in a decentralized, distributed environment. It defines an extensible > messaging framework that contains a message construct based on XML > technologies that can be exchanged over a variety of underlying > protocols. > > The XML-binary Optimized Packaging Mechanism [XOP] is an alternate > serialization of the XML Infoset, intended to make processing and > representation of certain types of content (specifically, that which > is base64-encoded) more efficient. Such serializations, when > free-standing, are called XOP Packages; the portion of the XOP Package > that represents the structure and non-optimized content of the Infoset > are called XOP Documents, and are serialized as XML. > > This appendix defines the media type application/soap_xop+xml which > can be used to identify SOAP 1.2 message envelopes that have been > serialized as XOP Documents using XML 1.0 ([XML 1.0]). > > The application/soap_xop+xml media type explicitly identifies the XOP > Document portion of a SOAP 1.2 message envelope, serialized as XML > 1.0. In other words, it identifies the serialized XML after the > extraction of any content into the XOP Package; it does not identify > the package itself. > > XOP Documents not serialized as XML 1.0 or representing message > envelopes with a different SOAP namespace version MUST NOT use it. > A.2 Registration > > * > > MIME media type name: > > application. > * > > MIME subtype name: > > soap_xop+xml > * > > Required parameters: > > none > * > > Optional parameters: > o > > "charset": > > This parameter has identical semantics to the charset > parameter of the application/xml media type as specified in RFC 3023 > [RFC 3023]. > o > > "action": > > This optional parameter can be used to specify the URI > that identifies the intent of the message. In SOAP 1.2, it serves a > similar purpose as the SOAPAction HTTP header field did in SOAP 1.1. > Namely, its value identifies the intent of the message. > > The value of the action parameter is an absolute > URI-reference as defined by RFC 2396 [RFC 2396]. SOAP places no > restrictions on the specificity of the URI or that it is resolvable. > Although the purpose of the action parameter is to indicate the intent > of the SOAP message there is no mechanism for automatically computing > the value based on the SOAP envelope. In other words, the value has to > be determined out of band. > > It is recommended that the same value be used to identify > sets of message types that are logically connected in some manner, for > example part of the same "service". It is strongly RECOMMENDED that > the URI be globally unique and stable over time. > > The presence and content of the action parameter MAY be > used by servers such as firewalls to appropriately filter SOAP > messages and it may be used by servers to facilitate dispatching of > SOAP messages to internal message handlers etc. It SHOULD NOT be used > as an insecure form of access authorization. Use of the action > parameter is OPTIONAL. SOAP Receivers MAY use it as a hint to optimize > processing, but SHOULD NOT require its presence in order to operate. > * > > Encoding considerations: > > Identical to those of application/xml as described in RFC 3023 > [RFC 3023], section 3.2, as applied to the SOAP envelope Infoset. > * > > Security considerations: > > Because SOAP 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 SOAP message based on the semantics of > the MIME wrapper alone. Therefore, whenever using the > application/soap_xop+xml media type, it is strongly RECOMMENDED that > the security implications of the context within which the SOAP message > is used is fully understood. The security implications are likely to > involve both the specific SOAP binding to an underlying protocol as > well as the application-defined semantics of the data carried in the > SOAP message (though one must be careful when doing this, as discussed > in SOAP 1.2 Part 1 [SOAP Part 1], 7.3.1 Binding to > Application-Specific Protocols. > > Also, see SOAP 1.2 Part 1 [SOAP Part 1], 7. Security > Considerations. > > In addition, as this media type uses the "+xml" convention, it > shares the same security considerations as described in RFC 3023 [RFC > 3023], section 10. > * > > Interoperability considerations: > > There are no known interoperability issues. > * > > Published specification: > > SOAP 1.2 Part 1 [SOAP Part 1], SOAP 1.2 Part 2, [SOAP Part 2], > and XOP [XOP]. > * > > Applications which use this media type: > > No known applications currently use this media type. > * > > Additional information: > o > > File extension: > > SOAP messages are not required or expected to be stored as > files. > o > > Fragment identifiers: > > Identical to that of application/xml as described in RFC > 3023 [RFC 3023], section 5. > o > > Base URI: > > As specified in RFC 3023 [RFC 3023], section 6. Also see > SOAP 1.2 Part 1 [SOAP Part 1], 6. Use of URIs in SOAP. > o > > Macintosh File Type code: > > TEXT > * > > Person and email address to contact for further information: > > Mark Nottingham <mnot@pobox.com> > * > > Intended usage: > > COMMON > * > > Author/Change controller: > > The SOAP 1.2 specification set is a work product of the World > Wide Web Consortium's XML Protocol Working Group. The W3C has change > control over these specifications. > > -- > Yves Lafon - W3C > "Baroula que barouleras, au tiéu toujou t'entourneras." -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 21 July 2004 15:12:59 UTC