This spec needs more explicit statement of some use cases, and this is causing some confusion expressed in various weblogs and on the TAG mailing list. For example, some are calling it "tunneling HTTP over SOAP over HTTP". There would be no need for a Representation Header in an open HTTP environment where the recipient could dereference any links in a SOAP message, but this (perhaps overwhelmingly obvious) point is not made anywhere in the spec. Some use cases that come to mind (based on my hazy recollection of discussions when I was on the XMLP WG) would be: - A SOAP message that references Web resources needed to process it is received by an HTTP gateway and then passed over a proprietary messaging system (e.g. MQ) to a system that is not on the Web. -- A SOAP message that references Web resources needed to process it is received by the DMZ outside a high-security environment. All arbitrary Web links must be dereferenced and vetted outsize the high-security environment and passed inside for processing. - - A SOAP message that references Web resources needed to process it is received by a performance-critical system; tasks that can be easily parallelized (such as HTTP GETs on the links) are done simultaneously, and the results combined and passed downstream to a process that must consider them all. Do these make sense, or am I also missing the point here?[email]
The XMLP WG considered your comment on their telephone conference this week and decided to amend the first paragraph of Section 2.1 to read: "The Representation header block is designed to allow applications to carry a representation of a Web resource in a SOAP message. Applications of this header include cases where the receiver has limited ability to get the representation using other means, for example because of access restrictions or because the overhead would be unacceptable. The representation header is also required when multiple references to the same extracted content are required but duplication of extracted content is undesirable. See UC 2 and UC 6 for details." where UC2 and UC6 will be bibliographic references to our use cases document.[email]
W3C Working Draft 09 February 2004 Section 4.3.1 Sending a SOAP message The XOP package is constructed as described in 3. An Optimized MIME Multipart Serialization of SOAP Messages with the following restriction: * Each optimized Node MUST generate exactly one extracted binary part in the resulting package, i.e., extracted binary parts MUST NOT be referenced with more than one xop:Include in the SOAP message part. If transmission optimization is the goal of this effort, why do you specifically disallow reuse of a binary package that has been isolated in the document? I realize this may make some processing models more complex but the potential benefit is very significant. Messaging in military systems tends to have repeated information (the exact value of which is not predictable in advance but which reoccurs daily in many messages of all types). When a value (such as GPS, time, call-sign, unit-id) is used it is often repeated. While XML design considerations might allow reuse of the information via ID and IDREF, the influence of legacy systems (an environment that would not accommodate such referential complexity very well) continues to make such an alternative infeasible. Independent of my operational concerns for the Army, it does seem that you would want to recognize that an optimization of the message transmission should allow the potential for re-use of a defined binary representation when an opportunistic optimizer "discovers" it.[email]
You raised an issue[1] regarding XOP and the cardinality of binary parts to xop:Include elements. The text you highlighted is no longer in the XOP specification, hence the restriction no longer applies in XOP itself. While such a restriction does exist in the MTOM specification at the level of the HTTP binding, other bindings of XOP can be constructed that do not have the restriction.[email]
In the fifth paragraph of the XOP working draft (http://www.w3.org/TR/2004/WD-xop10-20040209/) I think you have a minor typo: XOP is designed to carry sufficient information to reconstruct with full fidelity the supplied Data Model, including the return value of the dm:string-value accessor for each Node in the Data Model, except that the type property and the return value of the dm:typed-value accessor are generally not preserved. The type of base64Binary Element Bodes that were optimized is in fact conveyed, but the type of other Element Nodes as well as the type of Attribute Nodes is in general not preserved. In the last sentence I think that the "Bodes" reference could either have been a mistyped "Bodies" or "Nodes". But it leads me to a perfect word for some research I have been involved in with XML message types in the DOD. As I use it, "Bode" is a binary node hung in an XML tree that represents a reference to a payload digest element. I think that you will want to modify the online document but your word is perfect for covering a concept I had come up with for dynamic message compression. I guess this is a case of "thanks for the error!"[email]
The WG resolved to take no action since the text to which you referred no longer exists in the current XOP document.[email]
During last teleconference, I took an action to open issues regarding requirements R9 and R7, to ensure that they are actually met by the MTOM/XOP specifications. -- R9 The specification must describe its points of extensibility. See Use Cases and Requirements and M.Mahan's email.[email]
The XML Protocol Working Group has closed issue 464 ("Requirements
R9") by adding an appendix documenting XOP's relationships to
other specifications, including its extensibility mechanisms.
[email]
During last teleconference, I took an action to open issues regarding requirements R9 and R7, to ensure that they are actually met by the MTOM/XOP specifications. -- R7 The URI identification scheme must be robust under the addition and deletion of parts -- i.e., it must not require that URIs to other parts be altered, it must be relatively easy to avoid URI conflicts, etc. See Use Cases and Requirements and M.Mahan's email.[email]
Just out of curiosity: what happens with whitespace in base64Binary data? as i understand it, canonical base64Binary data may not contain any whitespace. is this intentional, because i think that many base64Binary does contain the linefeed characters required by rfc 2045. whitespace certainly would disappear in xop, and as i understand it, it cannot be reconstructed in the reconstituted dm. not that i think this would be a requirement, but i think this whole issue of whitespace in base64Binary data should be mentioned in the document.[email]
In XMLP issue 462 you are concerned with base64 data in the infoset that contains whitespace; and the handling of such data in XOP. The WG has resolved to close your issue by accepting the following explanation and adding it where appropriate in the specs' introduction chapters. The primary use-case for XOP is that an application wants to include a chunk of binary data (that the application has as an octet stream, not encoded for example as base64) in an XML document in some optimized form. Where XOP requires canonical base64 data, that is only a conceptual requirement, it is expected that any implementation will skip encoding the original data into the infoset (or data model) but will pass the data directly to the XOP layer which will put it directly into the MIME envelope. Conceptually therefore, the data may be viewed as present in the infoset in base64 canonical, even if the implementation doesn't contain any base64-encoding code. For the other use cases where the base64 form is actually used, we must choose one unambiguous form (because we are required to reconstruct the precise infoset at the receiving end), and we chose to reuse XML Schema's canonical form (yet to be published?).[email]
When designing xml schemas, i usually avoid using xml schema built-in types and create a layer of my own simple types, which then are used in instances. i do this to be able to restrict all simple types, for example with length facets. wouldn't it be desirable to be able to optimize base64Binary and restricted subtypes, rather than base64Binary only? as i currently understand xop, my xml instances would not be optimized at all, because they use types derived from base64Binary. or would this be a requirement for my own type augmentation software, to generate the appropriate type information so that xop optimization works for base64Binary and derived subtypes?[email]
In section 4.1 (creating xop packages) shouldn't it be left to an implementation to decide whether creating a part is worth the effort? as i understand them, the current rules specify that every base64Binary node must be optimized, which can increase rather than decrease message size for small binary parts.[email]
You raised an issue, 460[1], with respect to allowing implementations to choose when to optimize. The working group are amending the text you commented on to address this issue, amongst others. As an aside, I would note that the notion of starting with base64 and optimizing to binary is a specification convention. We actually expect that people will often start with the binary data and that it is just at the logical level that the base64 characters exist.[email]
During last teleconference, I took an action to open issues regarding requirements R9 and R7, to ensure that they are actually met by the MTOM/XOP specifications. -- R9 The specification must describe its points of extensibility. -- R7 The URI identification scheme must be robust under the addition and deletion of parts -- i.e., it must not require that URIs to other parts be altered, it must be relatively easy to avoid URI conflicts, etc. See Use Cases and Requirements and M.Mahan's email.[email]
Now that XML 1.1 is a recommendation, and allows characters not allowed in XML 1.0, it seems to me we need a review of our entire recommendation, as well as XOP and MTOM drafts, to make sure we are clear on issues such as: Are the new control characters allowed by XML 1.1 allowed in XML SOAP Envelope infosets? If so, do you indicate this in the version of the Infoset Document Information item? If allowed, I don't see how the HTTP binding would send them using the usual RFC 3203-based serialization, which my quick reading shows as XML 1.0. We refer in the rec to XML 1.0 whitespace, but XML 1.1 allows NEL (x85) as whitespace. Are we at least clear as to what is whitespace and what isn't for SOAP? Is it legal to write a new binding or media type that sends the new control chars, perhaps using XML 1.1 serialization? This would seem to break the equivalence among bindings. We should similarly make sure XOP and MTOM are clear on these issues.[email]
a) that the infoset for a SOAP message may use any recommendation level version of XML ( which at the time of writing encompasses XML 1.0 and XML 1.1 ). b) that bindings may restrict themselves to a particular version ( or versions ) of XML for serialization. c) that the application/soap+xml media type ( and hence the SOAP 1.2 HTTP binding ) will be restricted to XML 1.0 serialization. only. d) that the application/soap_xop+xml media type ( and hence the MTOM binding ) is similarly restricted to XML 1.0 serialization.[email]
The current resolution of issue 442 [1] allows extensions to provide protocol-dependent metainformation and context, but nothing is defined. An extension for HTTP (the most common case) or a subset of MIME-based protocol. One use case is an automatic update of a mesh of HTTP caches where a notification can carry a HTTP entity body and all meta-information (and context) needed for a HTTP cache.[email]
- Context Currently, section 3.1 [2] of MTOM [1] states: <current> For use with this serialization, the type property MUST be set to xs:base64Binary only for those Element Nodes known to be in the canonical lexical form for that type. The type property for all other Element Nodes MUST be set to xdt:untypedAny. </current> - Problem 1 In the last sentence, "all other" refers to Element Nodes whose content is not base64-encoded data in canonical lexical form. I think that the current constraint on those Element Nodes is too strong: the only thing we need to ensure is that for those "other" Element Nodes, their type property is not set to xs:base64Binary. A use case where the current constraint is inconvenient is when a user wishes to send a full fledged Data Model with precise type information on all the Element Nodes (for example a Data Model resulting from a query in a database). In such a case, with the current formulation, the user would have to remove all type information from his Data Model (expect for xs:base64Binary typed Element Nodes) before sending it with an optimized SOAP binding. - Problem 2 Moreover I think that the first sentence may be somewhat unclear about our real intent. I think we want to allow for Element Nodes with base64-encoded content in canonical lexical form NOT to be tagged with an xs:base64Binary type. In such a case, the Element Node will not be optimized. - Proposal Therefore I propose to remove those two sentences as I think that sufficient constraints are described in 2.3.1 which is refered to just before those sentences.[email]
The XMLP WG agreed to remove the sentence
"The type property for all other Element Nodes MUST be set to xdt:untypedAny."
from the spec.
[email]
This relates in part to issue 442 and to the proposed resolution [2]. The proposed resolution must be augmented, IMO, to describe its use of the SOAP processing model. I believe this will result in our specfying some rules for when a conforming implementation may use the representation header to resolve a retrieval request for a resource. Consider and example of an original sender, final destination and two intermediaries: S -> A -> B-> D If a representation header is addressed to the final destinatino D (default SOAP role), should a retreival request at A use it? I would think not, as that would be circumventing the usual mustUnderstand mechanisms of SOAP. If I want to specifically cause two different representations, of the same media type for the same resource, to be sent to A and B respectively, can I safely use multiple representation headers that differ in their soap:roles to do this? I would think so. In any case, I believe we must decide on and document the rules we want. The current proposal refers a bit to mustUnderstand, but doesn't really cover the rules in detail. I propose that we open a new issue to track this question.[email]
The text describing the Representation Header will state: 1. "The type of the reinsert attribute information item is xs:boolean . When this attribute is specified on the Representation header block with a value of "true", it indicates that a SOAP forwarding intermediary node processing the header block must reinsert the header block. This means that when used in conjunction with the relay attribute, defined in [SOAP Part 1] 5.2.4 SOAP Relay Attribute, with a value of "true", the Representation header block will always be relayed by a SOAP forwarding intermediary. When this attribute is specified on the Representation header block with a value of "false", the behavior of the SOAP node processing the header block is the same as that when the attribute is not specified, and normal SOAP processing rules apply. The presence of this attribute has no effect on the processing of a Representation header by a SOAP endpoint." 2. The reinsert attribute is not namespace qualified. 3. "Such Representation header blocks SHOULD NOT have the same metadata (such as media-type). If such Representation header blocks have the same metadata then any one of them may be used." 4. Implementations MAY need to process Representation header blocks BEFORE other header blocks that might dereference URIs.[email]
I had always assumed that in Miffy, all the parts except the root would be octet streams, probably labeled as application/octet-stream and sent in 8-bit format. Anish mentioned on the call today his assumption that a range of representations would be allowed on the wire, providing that content-transfer-encoding would be correctly set to indicate the representation used. The tradeoffs appear to be: a) variability is more flexible b) variability requires that all receivers/interpreters be capable of decoding all encodings if universal interop is to be achieved c) neither of us was sure whether the decision to fix the representation might be taken as a misuse of MIME.[email]
4) Consideration of packaging multipart payloads via use of the
'multipart/multiplexed' mechanism in RFC 3391 should be considered
as a valid MIFFY encoding mechanism.
In some use cases, it is desirable to interleave the base XML
document data with its referenced content.
A mechanism for doing so is described in RFC 3391. It is our
opinion that the mechanism described in RFC 3391 be a valid encoding
mechanism for MIFFY encoded documents. It presents little overhead
for decoders and has the desirable benefit of facilitating streamed
content with multiple referenced parts.
[email]
3) Addressing the 'data:' URI directly in the MIFFY specification is desirable. As currently defined, MIFFY may only optimise base64 data found as element content. In order to accommodate common practice in a number of vocabularies, notably SVG where it is a frequent occurrence, we believe that there would be great value in supporting data: URIs (RFC 2397) in MIFFY, through the addition of appropriate markup to your vocabulary. This would effectively allow us to use MIFFY directly, without requiring any backwards-incompatible change to SVG. We understand that XMLP may wish to without this feature in the SOAP context, but it appears to us that MTOM could profile MIFFY to eliminate it if you are so inclined.[email]
2) The referencing mechanism via 'Content-Type' and 'http' URI presents an ambiguous referencing mechanism and may require removal. The process of encoding a SOAP packet into an aggregated MIME multipart specifies two alternate encodings for referenced content. One uses the well-known 'cid:' URI which references the MIME sub-part by use of 'Content-Id' in the sub-part. An alternate referencing mechanism by use of an 'http:' URI and specification in the MIME sub-part by use of the 'Content-Location' field. This latter mechanism seems to present a potential ambiguity in its semantics. Firstly, if the process is a recoding mechanism, it is entirely unclear why two alternate schemes are needed. The 'cid:' referencing mechanism is well known and functional. An encoder can unambiguously encode content via this mechanism. The second mechanism via the use of 'http:' seems to be semantically incorrect. The specification of an 'http:' address in the XML content in the root part of the MIME package implies that an 'http:' request should be made to retrieve the referenced content. This is clearly not the desired behaviour. A greater concern is in malformed encodings where a matching MIME sub-part cannot be found. Should the decoder attempt to fetch the resource via 'http:'? If so, the message itself is in error, as the resources are not present in the packaged message. Also, should a decoder check if the referenced content is up to date, or just use the encapsulated MIME sub-part instead? The use of 'http:' as a referencing mechanism seems to be at odds with what the encoding represents. Placing a 'Content-Location' header field in the MIME sub-part is possibly useful as metadata, however we would suggest that the 'cid:' referencing mechanism be mandatory.[email]
1) Referenced parts MUST include the 'Content-Transfer-Encoding' field and should include the 'Content-Length' field. The MIFFY description as presented in the above referenced document presents a sound approach to encoding of compound or multipart payloads. It appears that the described encoding mechanism from SOAP data into MIME encoded multipart will produce arbitrary binary data for the encoded MIME sub-parts. In particular, when control characters, i.e. less than 32 decimal are encoded in base64, they will decode into raw control characters in the MIME part. The NUL (0x00) character in particular will very probably be problematic. MIME sub-parts encoded in such a manner assume an 8-bit clean transmission channel, which may not be available for general application of such an encoding. In the presence of an 8-bit clean channel, there must be a workable mechanism to allow the inclusion of arbitrary binary data. Such binary data may by its very nature include a valid MIME part delimiter. The mechanism for inclusion of arbitrary binary data inside a MIME sub-part is addressed in RFC 2045 by use of the 'Content-Transfer-Encoding' field with a parameter specified as 'binary'. In the case of using the 'binary' encoding, the MIME header MUST include a 'Content-Length' field indicating the number of bytes of raw binary data present in the sub-part (as specified in RFC 2543 etc.). It is our suggestion that the 'Content-Transfer-Encoding' and 'Content-Length' fields be present in all MIME sub-parts encoded using the MIFFY encapsulation. At minimum the contained data should be analysed for compatibility with non-binary transport gateways and the sub-part encoded using a well specified 'Content-Transfer-Encoding', be that base64, etc. For simplicity of encode/decode we would suggest that 'Content-Transfer-Encoding' and 'Content-Length' be mandatory in a MIFFY encoded sub-part and that the encoding be 'binary'. Note, that the CIP4 group using JDF already use such a scheme for transmission of multipart aggregated print jobs in pre-press production areas. In the absence of an 8-bit clean transmission channel, MIFFY should specify a preferred encoding mechanism for the sub-parts, most probably base64. In any case, transcoding at gateways should be possible.[email]
Can a message contain multiple representations of the same resource using the MTOM representation mechanism. E.g. can a message contain JPEG and PNG renditions of the same resource using the MTOM representation mechanism.[email]
What is the extensibility and versioning strategy for mtom elements? Do we allow extensibility of attributes and/or elements, and if so, what is the processing model for extensions? What is the policy related to the miffy namespace name for future elements and/or attributes? I have some thoughts on the right way to do this at http://www.w3.org/2001/tag/doc/versioning-20031003[email]
The xop:Include element allows extension attributes and child elements, as long as they may be safely ignored during processing. See the current Editors' Draft for the exact wording the WG intends.[email]
As requested at the f2f, this note is to remind us that we (should) have an open issue to determine how a SOAP HTTP implementation, receiving whatever content type we eventually decide on for MTOM, will make the determination to do MTOM processing. We must then make suitable updates to the HTTP section of the MTOM document.[email]
You raised an issue, give the number 447[1] with respect to how an MTOM/XOP aware SOAP node will make the determination as to whether or not to perform MTOM/XOP processing. The XMLP working group have decided that such processing will be triggered by the media type of the outer package, which in the MTOM case will be application/soap_xop+xml[email]
When the scope of MTOM was SOAP-only, it seemed that the likely rule would
be:
Don't use xbinc:include in the SOAP envelope, it's for use by
bindings.
Now that we are considering miffy, there are questions about including one
miffy-based format in another. Here's a concrete if somewhat contrived
example:
a) imagine a vcard-like XML format that allows inclusion of someone's
picture. Enable that for miffy so that the picture can be carried
efficiently.
b) Question: can you carry such a vcard as part of the content of a soap
body or header? What are the miffy processing rules of that SOAP envelope
is itself Miffy encoded?
This seems to be an example of a more general issue, relating to the
combination of miffy-enabled formats. Of course, this is all somewhat
complicated by the somewhat strange relationship of the
application/soap_mtom_xml media type to the surrounding multipart/related.
[email]
You raised issue 446 regarding whether MIFFY/XOP can serialize a data
model that already contains xop:Include elements. The XMLP WG adopted
the following text into Section 3 of the XOP document:
Note that the data model used as input to XOP processing MUST
NOT contain any element nodes with a dm:node-name
{http://www.w3.org/2003/06/soap/features/binary-inclusion;Include};
data models containing such elements cannot be serialized using XOP.
[email]
The name "Miffy" is copyright by "Mercis bv", see http://www.miffy.com/. I recommend that after completing its technical work, the XMLP WG choose a non-encumbered name to replace "Miffy".[email]
the WG has decided today at its telcon to change the name of the MIFFY
spec to XOP - XML binary Optimized Packaging, thus resolving issue 445.
[email]
In Sept. I sent an email to distApp announcing that the data model formulation of MTOM was ready for consideration by the XMLP Workgroup [1]. Subsequently, the workgroup agreed to adopt the DM formulation. In the email, I raised some concerns that should have turned into issues, but apparently we never formally added them to the list. Specifically, see the paragraph that says: "At least one set of details remains to be resolved if the DM formulation is to be used: the current draft does not discuss all of the accessors provided by the data model. For example, element nodes [5] provide a base-uri [6], which in principle can vary for each element. Future versions of the draft would need to explain that, like type information, such base URI and similar information is not transmitted. This limitation is consistent with the general philosophy that MTOM will transform the input data model to a different (but predictably different) output data model at the receiver. In general, the transmission will exactly preserve certain information, will lose other information such as base URI and type, and will not add or synthesize other information, except as directly follows from the losses (e.g. typed values change in the obvious way when type information is lost.)" So, as suggested on our telcon of today, this is a request to open an issue. I suggest that the issue be relatively broad, along the lines of "Do a thorough review of the DM, MTOM and if appropriate Miffy specs to ensure that all interdependency issues, including those raised in [1], have been dealt with in an appropriate manner."[email]
The issue basically calls for XMLP to ensure that our specification of data model accessors in XOP is complete and accurate. We believe this was attended to at the San Francisco face to face [2], and the intention is that the editors will reflect details of that resolution in future working drafts[email]
By media-typing I mean providing the media type as defined by RFC 2045
and 2046.
In July, I proposed [1] a new section to be added to our document, that
would cover PASWA [2] sections 3, 7 and appendix I. I basically copied
the appropriate text from PASWA. Mark Nottingham reacted [3] to that by
presenting a few different options for providing media types to binary
data in XML. On a related topic, Philippe le Hegaret summarized a few
different approaches [4] for the WS-Description WG. Subsequently, the
WS-Description WG has agreed to do some work in this area.
Media-typing binary data in XML is going to be useful (IMO necessary)
for the Representation header work we're about to start. As the actual
media-typing specification work has moved to the WS-Desc WG, I suggest
that we collect the requirements we have on the media-typing spec. Below
is a first-cut list of requirements that I gathered from what I think
Representation header will need:
1. It must be possible to indicate unambiguously the media type of
a piece of binary data that's present as base64-encoded
character content of an element information item.
2. It must be possible to indicate in XML Schema what media type
the character content of an element ii will have.
3. It should be possible to specify a set of such media types, see
the HTTP Accept header (RFC 2616).
All this can be done specifically for the Representation header if it
turns out a generic solution is too contentious or just not useful. 8-)
[email]
The XMLP WG has closed issue 443 by stating the following: "We have the 'Assigning Media Types to Binary Data in XML' document. That provides the xmlmime:ContentType attribute to indicate the media type of content in XML and a schema annotation for indicating acceptable media types in a schema description." The Assigning Media Types to Binary Data in XML' is located at [2]. Please note that the attribute name used in [2] is 'mediaType' and not 'ContentType'; this will be changed in a newer version of the 'Assigning Media Types to Binary Data in XML' document.[email]
I took an action item to write up a strawman proposal for metadata and the Representation header. Here it is: 1. For each MIME header create an attribute information item in the [attributes] of the Representation element information item 2. Set the [local name] of the AII to the name of the MIME header 3. Set the [namespace name] of the AII to http://www.w3.org/2003/11/soap/metadata (actual URI TBD). 4. Set the [normalized value] of the attribute is the value of the MIME header. Note that this is just a strawman to start discussion. My own take is that this approach is actually the reverse of what we actually want. I suggest that we actually start by deciding what metadata we care about in two cases: a. On a Representation element information item b. On an arbitrary element information item whose content is in canonical base64 and then define a mapping from that metadata to the appropriate MIME headers.[email]
the WG has decided to close issue 442 by accepting my proposal [2] with the friendly amendment stating that the Representation header can be used multiple times in one message if multiple representations are to be carried with that message. We expect to open an issue on providing an extension to this header that will enable full HTTP caching behavior of recipients. We also expect to open an issue on clarifying how the Representation header should play with the SOAP processing model, specifically with respect to roles and mustUnderstand. Providing media type information for the data in the Representation header is still an open issue - 443.
On today's call [Wed Oct 1], we adopted a proposal that says: " there is no property explicitly suggesting what to optimize. The rule is that a binding MAY optimize any, all or none of the items that are of dm:type xsd:base64binary. We agree to discuss later whether data to be optimized must be in canonical form, and if so what canonical." [...] So, we need to discuss whether to indicate that only canonical forms can be optimized by MTOM. If yes, we need to decide whether to adopt the canical form suggested in the errata to XML schema or some other form.[email]
The XMLP WG has closed this issue by stating that data to be optimized MUST
be in the canonical form of base64 as defined by XML Schema.
[email]
It occurs to me that in certain use cases the identical large binary might logically serve as content to multiple leaf nodes. This could in principle be done by reference to headers, but that changes the vocabularies and is not in all cases natural. I wonder whether we should allow a smart MTOM implementation to point multiple xbinc:Includes to the same mime part (I.e. use the same URI)? Seems like a win to me, and I can quite easily imagine implementations that would know from the construction of the DOM or similar structure that the content was identical. In any case, I think we should open an issue to make clear what the rule is, even if we just clarify that you must not link a given mtom part from more than (or perhaps less than?) a single xbinc:Include. My current leaning would be to allow flexibility in both directions. Multiple xbinc:Includes should be able to ref the same content, and it should be possible to carry content that is not referenced at all (e.g. to avoid the need for reference counting, or to maintain certain kinds of signatures, even if a header with a reference is removed.) That said, I wouldn't expect many implementations to avail themselves of the permission to send large useless content, but I think the sharing makes sense.[email]
See also:
[email, discussion, discussion]
The XMLP WG has resolved this issue as follows:
XOP will allow unreferenced MIME parts
MTOM and HTTP binding will allow unreferenced MIME parts but such MIME
parts play no part in SOAP processing.
XOP will allow multiple refs per binary part MTOM will allow multiple
refs per binary part HTTP binding will allow only one ref per binary
part
[email]
> Given that the type rule is extensible by IANA, it seems most sensible
>
> to NOT enumerate the current types. This leaves us with:
>
> [a-zA-Z0-9!#$%^&\*_-\+{}\|'.`~]+/[a-zA-Z0-9!#$%^&\*_-\+{}\|'.`~]+
Unless the working group/task force has reason to believe that the IANA
is going to change its long-standing policy of conservatism in the
approval of new types, this statement is not quite correct.
One new type has been added since the publication of the four MIME RFCs
("model"). There is good reason to suggest that an enumeration of types
is preferable to an open content model: what are you going to do with a
type you don't recognize? The reluctance of IANA to approve new types
is another factor, as is the reasoning behind it: new types are avoided
because they require changes to deployed software.
So, I would think that it would be better to enumerate, with an escape
to vendor-defined or random types. But the enumeration is valuable,
signalling the set of types that processors should (in some fashion)
support.
[email]
Amy,
The Working Group has conferred and believes that these issues have
already been considered.
[email] DISSENT: email
1. Should MTOM accommodate encodings/optimizations other than base64?
a. If so, should the list be open-ended (i.e., extensible)?
[email]
The XMLP WG has decided to close issue 438 by declining at the
moment to include other types than base64 because no other types are
necessary for the fulfillment of our usecases and requirements.
[email]
MTOM/PASWA can be used to carry encapsulated documents in SOAP. Such encapsulated documents may contain relative URIs. The workgroup must determine the rules for establishing base URIs for resolving such relative references (and if there are any other uses of base URIs, for them too.) Among other things, we need to decide whether the requirements are different for content carried as children of a Representation element [1] vs. for other Paswa content (Note that other Paswa content is not in general distinguishable by inspection of the SOAP infoset.)[email]
During the 29 Oct 2003 teleconference, the XMLP WG has decided to close this issue by adopting Jacek's proposal [1] inlined here: <<< For the general case of optimized pieces of data we should note that if the optimized data contains a relative URI, the base URI is the same as if the data wasn't optimized. In particular if we decide to identify optimized parts using some kind of URIs, these URIs don't affect the base URI of relative URIs in the optimized data. For the Representation (header) element (or whatever equivalent we come up with) we should say that it does in fact establish a base URI for relative URIs contained in the actual representation and that the base URI is the URI used by the Representation element to identify the resource whose representation it carries. >>>[email]
-- derived from 431 -- are intermediaries required to preserve optimization/non-optimization of element content? -- should we say anything about the responsibility of intermediaries?[email]
[see also email and following thread]
The WG has decided that this issue is now closed, having been adequately addressed by the closure text for Issue 431 at http://lists.w3.org/Archives/Public/xml-dist-app/2003Aug/0025.html and which now exists in sections 2.4.3 and 2.4.4 of the SOAP MTOM Editors Copy at http://www.w3.org/2000/xp/Group/3/06/Attachments/OptimizationMechanism.html.email
-- derived from 432 -- Another question that came up is how does a receiver determine which elements were optimized which led to discussion of a receiver side property 'OptimizedElements'. This may be worth recording as a separate issue.[email]
During the 22 Oct 2003 teleconference, the XMLP WG has decided to close
this issue with the following resolution:
"SOAP receiver cannot determine which elements were optimized"
[email]
2: "How does the binding determine which nodes to serialize as attachments ?"[email]
The XMLP WG has closed this issue by stating that data to be
optimized MUST be in the canonical form of base64 as defined by XML Schema.
So a binding is free to optimize any nodes that have such a lexical form.
[email]
1: "What are the semantics of attachments w.r.t. SOAP intermediaries. E.g. do we expect intermediaries to preserve what is serialized as attachments and what is serialized inside the SOAP envelope."[email]
Marc, you raised an issue (logged as #431, see http://www.w3.org/2000/xp/Group/xmlp-issues#x431) regarding the semantics of attachments with regard intermediaries. The XMLP WG yesterday agreed to close the issue using the text in http://lists.w3.org/Archives/Public/xml-dist-app/2003Aug/0025.html.[email]
there are two questions we identified on the PASWA proposal: 1) does the application see xbinc:Include? 2) does the SOAP processing model see xbinc:Include? Everyone seems to agree that the application should not see xbinc:Include. The second question can be re-framed as whether we want smart protocol bindings or whether bindings can be ignorant of xbinc:Include. The PASWA proposal is designed to be able to work with bindings ignorant of it, using the DoInclude header. On the other hand there is much appeal in creating smart protocol bindings that would hide xbinc:Include processing completely. So the issue is: do we allow protocol bindings to optimize transmission of SOAP Envelope infoset using the xbinc:Include technique? Even further, do we require that bindings take care of xbinc:Include and that the SOAP Processing model never sees an infoset with xbinc:Include element information items?[email]
We should allow xbinc:Include element to reach the SOAP Processing model and specify (if the proposal isn't clear enough already) how DoInclude header works and how the processing model doesn't change (e.g. it doesn't have to be re-run). We should also explicitly say that protocol bindings may be built which use xbinc:Include themselves, in which case the SOAP processor doesn't ever see xbinc:Include elements (or the DoInclude header).
We have resolved that our interest in xbInc:Include, as proposed in [2] is at most for use in bindings. It should not in general be visible to applications, and if present is in general to be interpreted by bindings prior to application of the SOAP processing model.[email]
[4th part of closed issue 375] "The compound SOAP structure model does not require that a SOAP receiver process, dereference, or otherwise verify any secondary parts of a compound SOAP structure. It is up to the SOAP receiver to determine, based on the processing context provided by the primary SOAP message part, which operations must be performed (if any) on the secondary part(s)." This paragraph troubles me deeply. I think that I understand the motivation behind the text, but I think it misses the point, at least from my perspective. See the second bullet above regarding what I perceive are the receiving SOAP node's responsibilities. I think that we need to be careful in the language that we choose. From SOAP1.2 part 1: "SOAP node The embodiment of the processing logic necessary to transmit, receive, process and/or relay a SOAP message, according to the set of conventions defined by this recommendation. A SOAP node is responsible for enforcing the rules that govern the exchange of SOAP messages (see 2. SOAP Processing Model). It accesses the services provided by the underlying protocols through one or more SOAP bindings." I think that we need to be very careful about articulating the responsibilities of a SOAP node with respect to any features that are defined. According to the definition above, a SOAP node's responsibilities include 'processing' which I believe we now mean to include the application-level processing. From SOAP 1.2 part 1 section 2.6: "4. Process all header blocks targeted at the node and, in the case of an ultimate SOAP receiver, the SOAP body. A SOAP node MUST process all SOAP header blocks targeted at it. A SOAP node MAY choose to ignore the application level processing specified by non-mandatory SOAP header blocks targeted at it." I believe that what the wording: "The compound SOAP structure model does not require that a SOAP receiver process, dereference, or otherwise..." is intended to mean that, just as the SOAP spec says nothing about what a receiving SOAP node does with the contents of a SOAP header block or the SOAP body, this feature imposes no requirement that the representations of the resources actually *be* processed, dereferenced or otherwise validated, etc. However, it DOES have a responsibility to provide for the means by which the references can be resolved in the event that the application-level processing determines that a particular reference be resolved.[email]
During the 11 September 2002 telcon, the WG has decided to close issue 382, 'Clarification of SOAP nodes'responsibilities' with the following resolution: The WG thinks the AF specification about SOAP nodes' responsibilities is clear enough. Therefore no action will be undertaken.[email]
[1st part of closed issue 375:]
"Compound SOAP structure
A compound SOAP structure consists of a primary SOAP message part
and zero or more related secondary parts."
I'm a little concerned that the term 'part' used in this spec will be
confused with the term 'part' as used in WSDL. It isn't clear to me that a
'part' in WSDL would equate to a 'part' as described in this spec.
The term 'part' as used in this context equates to MIME or DIME message
'part', which is certainly one way to look at this, but IMO, not the only way
to view it.
[email]
During the 11 September 2002 telcon, the WG has decided to close issue 379, 'Concern over the term "part"' with the following resolution: A note will be added in section 3. Terminology to clarify that the use of the term 'part' is independent of its use in other specifications.[email]
[2nd part of closed issue 375:] "Compound SOAP structure I'm also a little concerned with the use of the term 'compound SOAP structure'. The serialization of a SOAP message that contains references external to the SOAP envelope may be as a compound structure, but that again is just one way of achieving the objective of making the referents available to the receiving node(s). I look at the serialization of a SOAP message and its referents using MIME or DIME as an optimization that should be (nearly) invisible to both the sending and receiving application, not as its inherent structure.[email]
During the 11 September 2002 telcon, the WG has decided to close issue 380, 'Concern over the term "Compound Structure"' with the following resolution: The paragraph in section 6. Implementation starting with "Note: The compound SOAP structure model...", will be changed from a note to more normative prose by removing the term 'Note' at the beginning of the paragraph.[email]
[3rd part of closed issue 375:]
"4. Compound SOAP Structure Model
A compound SOAP structure consists of a primary SOAP message part and
zero or more related secondary parts that are distinct from the primary
SOAP message but related to it in some manner.
Secondary parts can be used to contain data that naturally represents a
resource in its own right or which is cumbersome to represent within the
primary SOAP message part. The latter can be due to the size, type, or
format of the data--a secondary part may be an audio clip, an image, or
a very large view of a database, for example."
Again, I look at the problem a little differently. A SOAP message may
contain references to resources that are external to the SOAP envelope itself.
The references themselves define the semantics of the relationship between the
SOAP message and the referent resource. It is outside the scope of this
specification to attribute specific semantic relationship between the SOAP
message and its constituent parts (SOAP header blocks and the contents of
the SOAP body) and the resources to which these may refer.
[email]
During the 11 September 2002 telcon, the WG has decided to close issue 381, 'specifying relationships between primary and secondary parts' with the following resolution: The paragraph from section 4. Compound SOAP Structure Model starting with "Secondary parts can be used to contain data..." is not intended as normative prose but rather as an example. To make this explicit, the words 'For exmample,' will be added at the beginning of this paragraph.[email]
[This is the last part of closed issue 374:] On the technical front I wonder whether the spec should require/specify support for at least the CID[3] referencing scheme, rather than punting this completely to the packaging spec specification. This wouldn't preclude a packaging spec introducing additional referencing schemes but would provide at least a minimum of functionality common to all packaging specs.[email]
During the 11 September 2002 telcon, the WG has decided to close issue 378, "CID support" with the following resolution: The AF spec will no require/specify support for the CID referencing scheme. Rationale: It is up to each particular binding (implementing AF) to chose which URI scheme(s) to use. One of the reason is that the 'natural' URI scheme to use will depend on the means used to move the attachments. However, the WG also decided to add some clarification that a secondary part can have multiple URIs, that a binding can use one or more URI schemes and that both absolute and relative URIs can be used.[email]
[This is the second part of closed issue 374:] I would also recommend that the bibliography entries for WS-Attachments, WS-Security and SOAP with Attachments be moved to a new section; "Non-normative References" in line with approach taken for parts 1 and 2 of the spec.[email]
During the 11 September 2002 telcon, the WG has decided to close issue
377, "move bib refs" with the following resolution:
The reference section will be split in two subpart, the first one being
normative, and the second one being informative. The second subpart will
contain the references to WS-Security, WS-Attachments, SOAP with
Attachments.
[email]
[This is the first part of closed issue 374:] On the editorial front I would like to recommend redressing the balance between MIME and DIME by adding a reference to the SOAP with Attachments note[1] rather than just MIME itself.[email]
During the 11 September 2002 telcon, the WG has decided to close issue 376, "Add a ref to SOAP Attachment Note" with the following resolution: A reference to the "SOAP Messages with Attachments" note will be added to the AF spec.[email]
"Compound SOAP structure
A compound SOAP structure consists of a primary SOAP message part
and zero or more related secondary parts."
I'm a little concerned that the term 'part' used in this spec will be
confused with the term 'part' as used in WSDL. It isn't clear to me that a
'part' in WSDL would equate to a 'part' as described in this spec.
The term 'part' as used in this context equates to MIME or DIME message
'part', which is certainly one way to look at this, but IMO, not the only way
to view it.
I'm also a little concerned with the use of the term 'compound SOAP
structure'. The serialization of a SOAP message that contains references
external to the SOAP envelope may be as a compound structure, but that again
is just one way of achieving the objective of making the referents available
to the receiving node(s). I look at the serialization of a SOAP message
and its referents using MIME or DIME as an optimization that should be
(nearly) invisible to both the sending and receiving application, not as its
inherent structure.
"4. Compound SOAP Structure Model
A compound SOAP structure consists of a primary SOAP message part and
zero or more related secondary parts that are distinct from the primary
SOAP message but related to it in some manner.
Secondary parts can be used to contain data that naturally represents a
resource in its own right or which is cumbersome to represent within the
primary SOAP message part. The latter can be due to the size, type, or
format of the data--a secondary part may be an audio clip, an image, or
a very large view of a database, for example."
Again, I look at the problem a little differently. A SOAP message may
contain references to resources that are external to the SOAP envelope itself.
The references themselves define the semantics of the relationship between the
SOAP message and the referent resource. It is outside the scope of this
specification to attribute specific semantic relationship between the SOAP
message and its constituent parts (SOAP header blocks and the contents of
the SOAP body) and the resources to which these may refer.
"It is important to note that the compound SOAP structure model does not
modify or supersede the message envelope concept defined by SOAP. Nor
does it define a processing model for any of the parts of a compound SOAP
structure including the primary SOAP message part. The processing model
for the primary SOAP message part is defined by SOAP. The application-defined
semantics of the SOAP message provides the processing context for the
secondary part(s)."
Actually, I believe that there *is* a processing model and that this
specification SHOULD articulate that processing in the abstract (not in
terms of specific bindings to a particular technology such as MIME or DIME).
To an extent, this is discussed in section 6, but it is not characterized in
the manner that I believe it should be.
I believe that the processing model should be as follows:
- a sending SOAP node implementing this feature must serialize the
referents of any references in accordance with the chosen "packaging" technology.
- a receiving SOAP node implementing this feature must provide necessary
functionality that enables any resources referenced within the SOAP
message to be resolved (dereferenced, whatever term of art is chosen to
mean make the bytes of the representation(s) of the identified resource is
made available to the application).
I believe that that is the essence of this feature in a nutshell.
"The compound SOAP structure model does not require that a SOAP receiver
process, dereference, or otherwise verify any secondary parts of a compound
SOAP structure. It is up to the SOAP receiver to determine, based on
the processing context provided by the primary SOAP message part, which
operations must be performed (if any) on the secondary part(s)."
This paragraph troubles me deeply. I think that I understand the
motivation behind the text, but I think it misses the point, at least from my
perspective.
See the second bullet above regarding what I perceive are the receiving
SOAP node's responsibilities. I think that we need to be careful in the
language that we choose.
From SOAP1.2 part 1:
"SOAP node
The embodiment of the processing logic necessary to transmit, receive, process
and/or relay a SOAP message, according to the set of conventions defined by
this recommendation. A SOAP node is responsible for enforcing the rules that
govern the exchange of SOAP messages (see 2. SOAP Processing Model). It
accesses the services provided by the underlying protocols through one or more
SOAP bindings."
I think that we need to be very careful about articulating the responsibilities
of a SOAP node with respect to any features that are defined. According to the
definition above, a SOAP node's responsibilities include 'processing' which I
believe we now mean to include the application-level processing.
From SOAP 1.2 part 1 section 2.6:
"4. Process all header blocks targeted at the node and, in the case of an
ultimate SOAP receiver, the SOAP body. A SOAP node MUST process all SOAP
header blocks targeted at it. A SOAP node MAY choose to ignore the application
level processing specified by non-mandatory SOAP header blocks targeted at it."
I believe that what the wording:
"The compound SOAP structure model does not require that a SOAP
receiver process, dereference, or otherwise..."
is intended to mean that, just as the SOAP spec says nothing about what a
receiving SOAP node does with the contents of a SOAP header block or the SOAP
body, this feature imposes no requirement that the representations of the
resources actually *be* processed, dereferenced or otherwise validated, etc.
However, it DOES have a responsibility to provide for the means by which
the references can be resolved in the event that the application-level
processing determines that a particular reference be resolved.
Bottom line for me is that we should define this feature in terms of SOAP,
not in terms of the anticipated technology that might implement the feature.
[email]
This issue is now covered by issues 379, 380, 381 and 382
[email]
On the editorial front I would like to recommend redressing the balance between MIME and DIME by adding a reference to the SOAP with Attachments note[1] rather than just MIME itself. I would also recommend that the bibliography entries for WS-Attachments, WS-Security and SOAP with Attachments be moved to a new section; "Non-normative References" in line with approach taken for parts 1 and 2 of the spec. On the technical front I wonder whether the spec should require/specify support for at least the CID[3] referencing scheme, rather than punting this completely to the packaging spec specification. This wouldn't preclude a packaging spec introducing additional referencing schemes but would provide at least a minimum of functionality common to all packaging specs.[email]
This issue is now covered by issues 376, 377 and 378
[email]
2) It isn't clear that we should not adopt the fragment identifier
meaning associated with application/xml. I don't think that
we want to preclude use of fragment identifiers.
7. Fragment identifiers
No meaning is associated with fragment identifiers for content
described by the "application/soap+xml" media type.
3) Base URI is not addressed and should be IMO (it is in RFC3023).
From section 6 of [SOAP12P1]:
SOAP does not define a base URI but relies on the mechanisms
defined in XML Base[11] and RFC 2396[6] for establishing a
base URI against which relative URIs can be made absolute.
Suggest that a section entitled "Base URI" be added to the ID
and suitable text (possibly directly from the spec, or maybe
just referencing where in the spec this is defined) be added.
(Added during TBTF teleconf of 15 Apr 2002: Check also encoding supported (UTF-8, etc...)
[email]1. with regard Fragment-Identifiers in the text of the SOAP 1.2 specification, include a reference to RFC-3023 2. with regards XML-Base in the text of the SOAP 1.2 specification, state that SOAP 1.2 uses XML Base and include a reference to the W3C XML Base Recommendation[email]
Has the WG considered whether to give advice about/dictate handling of the 'no-transform' cache-control directive, as well as the '214 Transformation applied' warning-value in the HTTP binding? It may be prudent to do so.[email]
In [1] you ask whether the WG has considered the various cache-control directives and in particular "no-transform" and how that applies to SOAP. The WG discussed the issue and came to the following conclusion: Any HTTP implementation should certainly take advantage of the features provided by HTTP. However, there is nothing particularly special about how the various cache-control directives apply to SOAP - they are defined in an entirely orthogonal manner and so the WG didn't see a reason for why the binding should say.[email]
Many moons ago, Paul Denning, David Clay, and myself took an action to start writing up a "module template" to essentially describe the framework for writing a SOAP 1.2 extension. For various reasons, this work fell by the wayside, but I note that we haven't come back to it or replaced it with anything else. I think it's critical that we have some section somewhere offering some guidance as to how to do this, since this is ostensibly going to be one of the major extensibility mechanisms by which a lot of people build on the platform we are creating. At a minimum, I would think such a section would indicate that a SOAP extension spec/module: * MUST identify itself with a URI (this becomes really critical when trying to describe services with something like WSDL, or when doing negotiation with an unknown party) * MUST clearly specify the content and semantics of the header blocks used to implement the behavior in question * MUST clearly specify any known interactions with other extensions in terms of semantics or sequence (for instance "this encryption extension will encrypt the contents of the body. On the receiving end, it MUST run before other extensions which rely on the unencrypted contents of the body.") * MAY indicate that the extension functions as an implementation of a SOAP feature as defined in sec 3 of part 1. In this case, the spec must also clearly specify the relationships (if appropriate) between any abstract properties defined in the feature spec (as described in sec 5 of part 2) and concrete instantiations in the SOAP envelope * SHOULD have a well-defined name of EITHER "SOAP extension" OR "module" :)[email]
3.2 SOAP Modules A SOAP module is a feature which is expressed as SOAP headers. A module specification follows the following rules. It: * MUST identify itself with a URI. This enables the module to be unambiguously referenced in description languages or during negotiation. * MUST clearly and completely specify the content and semantics of the header blocks used to implement the behavior in question, including if appropriate any modifications to the SOAP Processing model. * MAY utilize the property conventions defined in section 5 of part 2 in describing the functionality that the module provides. If these conventions are followed, the module specification MUST clearly describe the relationship between the abstract properties and their representations in the SOAP envelope. Note that it is possible to write a feature specification purely in terms of abstract properties, and then write a separate module specification which implements that feature, mapping the properties defined in the feature spec to SOAP header blocks in the module. * MUST clearly specify any known interactions with or changes to the interpretation of the SOAP body. Furthermore, it MUST clearly specify any known interactions with or changes to the interpretation of other SOAP features (whether or not those features are themselves modules). For example, we can imagine a module which encrypts the body and inserts a header containing a checksum and an indication of the encryption mechanism used. The spec for such a module would indicate that the decryption algortihm on the receiving side must run *prior* to any other modules which rely on the contents of the body.[email]
The current definition of SOAP Intermediaries in section 2.7.1 [1] takes into account only the case where the forwarding of the message is requested by one (or more) SOAP blocks or by the MEP. I think that some SOAP nodes may decide to forward a SOAP message using other criteria. Nevertheless, I think that those nodes MUST act in the role of a SOAP intermediary. I think in particular that that might be the case for active intermediaries.[email]
I think that a small change in section 2.7.1 would suffice to solve this problem by making clear that any SOAP node forwarding a message must act in the role of a SOAP intermediary. <original> The semantics of one or more SOAP blocks in a SOAP message, or the SOAP message exchange pattern used MAY request that the SOAP message be forwarded to another SOAP node on behalf of the initiator of the inbound SOAP message. In this case, the processing SOAP node acts in the role of a SOAP intermediary. </original> <proposal> When a SOAP node forwards a SOAP message received from another SOAP node, it MUST acts in the role of a SOAP intermediary. Such forwarding may be requested by the semantics of one or more SOAP blocks in the SOAP message, by the SOAP message exchange pattern used or by any other means. </proposal>
During the 24th April telcon, the XML Protocol Working Group has decided to close issue 202 [1] with the resolution proposed in [2].[email]
"An ultimate SOAP receiver MUST correctly process the immediate children of the SOAP body (see 5.3 SOAP Body). However, Part 1 of this specification (this document) mandates no particular structure or interpretation of these elements, and provides no standard means for specifying the processing to be done." We introduced this formulation during the great debate over body interpretation. In the non-fault case, I think I am happy with it. I think it also implies that ascribing semantics to a body containing a fault is optional (or, conversely, you might view the first and second sentences as contradictory in this respect.) In the case of faults, first of all, it contradicts the rest of the specification in claiming that we mandate no structure for the body. I suspect we should open an issue at least on that. My guess is that (with apologies in advance to Mark Baker) many of us had assumed that we wanted to mandate not just the structure, but also the interpretation in the case that a fault was received. Maybe the issue should be expanded to include that question as well, though knowing Mark's views, it may not be easy to achieve quick consensus on a resolution.[email]
"An ultimate SOAP receiver MUST correctly process the immediate children of the SOAP body (see 5.3 SOAP Body). However, with the exception of SOAP faults (see ....), part 1 of this specification (this document) mandates no particular structure or interpretation of these elements and provides no standard means for specifying the processing to be done."[email]
We should talk about whether we want to support two mechanisms for specifying "action" or not. If we want or need to support both, we should define what happens if they're both used at the same time. We also need to specify how the RequiredSOAPActionURI property interacts with the action parameter in this case.
[email]1) I would say that we should only have it in one place and like the direction of moving it entirely into the media type definition as a parameter. 2) This is the trickiest part - one of the important reasons for having a known content type is to indicate that *this* is a SOAP message. If two parties are not using a known content type then that information clearly is not there anymore. I can think of two ways to go: 2.A) We leave it entirely up to the media type being used to indicate in some manner that this is a SOAP message. 2.B) We maintain the SOAPAction in some manner (for example in an appendix) that allows is to be used with content types other than "application/soap+xml" indicating that this is a SOAP message. 3) The spec editors should add a note to the spec that we know that this is an ID with no standing. 4) This was carefully put together as the resolution [6] of issue 95 [5]. While some of the details regarding the status codes used will be changed slightly as a result of it being a media-type parameter, and that its value can't be relative, the overall resolution still stands.[email]
The WG has reviewed and accepted the proposed resolution described in [1] with the "2.A" option and not "2.B".[email]
1. Add the following to the top of the envelope schema[1];
<xs:import namespace='http://www.w3.org/XML/1998/namespace' />
2. Add a type definition as follows;
<xs:complexType name='faultstring' >
<xs:simpleContent>
<xsd:extension base='xs:string' >
<xs:attribute ref='xml:lang' />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
3. Amend the Fault type as follows;
<xs:complexType name="Fault" final="extension" >
<xs:annotation>
<xs:documentation>
Fault reporting structure
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="faultcode" type="tns:faultcode" />
<xs:element name="faultstring" type="tns:faultstring" />
<xs:element name="faultactor" type="xs:anyURI" minOccurs="0" />
<xs:element name="faultrole" type="xs:anyURI" minOccurs="0" />
<xs:element name="detail" type="tns:detail" minOccurs="0" />
</xs:sequence>
</xs:complexType>
4. Amend the description of faultstring as follows;
The faultstring element information item has:
A [local name] of faultstring .
A [namespace name] which has no value.
An optional attribute information item with a local name of lang and
namespace name of http://www.w3.org/XML/1998/namespace ( see [ref to
http://www.w3.org/TR/REC-xml.html#sec-lang-tag] )
[email]
There are three major usage modes or ways to think about SOAP. 1. as a very generic messaging framework, as described in part one of the specification. 2. as a remote procedure call mechanism as in Part 2, Section 5. 2 a) An encoding for parameter values 2 b) A method calling syntax 3. as an extension mechanism for HTTP, as discussed in 6 [... (cut, see email for full details) ...] I propose, therefore that SOAP be split, as XSL was split, into languages with unique names. I propose SOAP-Messaging, SOAP-RPC and the SOAP HTTP Binding. Arguably SOAP-RPC could also be split into the SOAP encoding and SOAP-RPC but it may not be helpful to slice that finely[email] After the first resolution sent by the WG, Paul replied with this:
No, it is not an acceptable resolution but I did not expect an acceptable resolution. I am just trying to be a good citizen in trying to influence the specifications rather than merely criticize them. You've referred me to an internal URI which I unfortunately cannot access. Nevertheless, let me reiterate that there is widespread confusion about what SOAP is. I think that this is in large part because under the one name there are very different technologies. The last specification I can remember that bundled so many diverse, seemingly independent pieces under one name was HyTime. Be afraid. Be very afraid. [...][email]
On 27 March 2002, the WG considered Paul Prescod's response to this WG's stated resolution, and the WG decided to stay with its resolution
"Conforming implementations of this binding:
1. MUST be capable of sending and receiving messages serialised using
media type application/soap+xml whose proper use and parameters are
described in [12].
2. MAY send requests and responses using other media types providing
that such media types provide for at least the transfer of SOAP XML Infoset.
3. MAY, when sending requests, provide an HTTP Accept header. This header:
(i) SHOULD indicate an ability to accept at minimum
application/soap+xml
(ii) MAY additionally indicate willingness to accept other media
types that satisfy 2 above."
[...]
[email, email]
As a result of the discussion, I think the table will look like this:
env:VersionMismatch 500 [see a]
env:MustUnderstand 500 [see b]
env:Sender 400 [see c]
env:Receiver 500 [see d]
[a] Similar to HTTP/1.1's 505 "HTTP Version Not Supported"
[b] Similar to HTTP/1.1's 501 "Not Implemented"
[c] Similar to HTTP/1.1's 400 "Bad Request"
[d] Similar to HTTP/1.1's 500 "Internal Server Error"
[e] Because the sender sends something that the receiver can't accept
[email]
I want to raise an issue with the model for RPC invocations and responses defined in Section 5, Using SOAP for RPC, of SOAP 1.2 Part 2. Specifically, mandating the "result" element from the "http://www.w3.org/2001/12/soap-rpc" namespace as the accessor for an RPC call's return value is problematic because that element is defined as being of anyType.(Comment: The commentator would prefer that we just mandate the local name, leaving the namespace name and type properties to be defined by some higher layer) [email]
The XMLP WG has decided to close issue #195 with the resolution at [1]. Essentially, QNames are used to identify the result. Please let us know immediately if you disagree with this resolution.[email]
I don't beleive that the schema as it stands allows for the encodingStyle attribute to appear on the Envelope or Header elements, whilst the prose allow for that situation, however my understanding of XSD is shakey enough that i could be wrong. Shouldn't the Envelope and Header complex types include an attributeGroup reference to the encodingStyle attribute group ? Also is there any reason why encodingStyle uses an attribute group ?[email, from original comment]
The encoding style attribute MUST NOT appear in ANY element defined in the envelope namespace[email]
<quote where="Section 2.6 Processing SOAP Messages, bullet 5"> In the case of a SOAP intermediary, and where the message is to be forwarded further along the message path, remove all SOAP header blocks targeted at the node, and possibly insert new SOAP header blocks. </quote>
originalAuthor="Noah" amendedBy="Jean-Jacques" In the case of a SOAP intermediary, and where the SOAP message exchange pattern and results of processing (e.g. no fault generated) require that the SOAP message be sent further along the SOAP message path, relay the message as described in Section 2.7 Relaying SOAP Messages.
In the case of a SOAP intermediary, and where the
SOAP message exchange pattern and results of
processing (e.g. no fault generated) require that
the SOAP message be sent further along the SOAP
message path, relay the message as described in
section 2.7 Relaying SOAP Messages.
email
I went over the binding framework and the HTTP binding and noticed a problem; no where is it stated how SOAP processors should recognize faults. The issue is that sometimes a SOAP node may want to send a message that includes a Fault, but is not intended to be processed as a Fault. An example would be if a SOAP node is asked, perhaps via a debugging interface, to return the last fault it sent. Using HTTP as an example, the HTTP response code is used as the authoritative determinant of the intent; if it's a 2xx response, then the Fault is not processed as a Fault. If it's a 4xx or 5xx, then it is.[email]
1) update the binding framework to state that each binding should declare that the authoritative determinant of whether a message is a fault or not should be the underlying protocol 2) update the default HTTP binding to state that a SOAP Fault MUST only be processed as a SOAP Fault if the response code is 4xx or 5xx.
The WG has reviewed and accepted the proposed resolution described in [2] with the following amendment to part 1) of the proposal which the editors have been instructed to incorporate: "Senders must not send messages that has a Fault element in the body and also additional elements. If a receiver receives such a message, the implications are undefined."[email, email]
The original is incoherent. A message with a DTD is not a SOAP message. Legal bindings don?t even accept infosets that contain DTDs for transmission. How could one be received?" <quote where="soap12-part1.html#soapenv"> On receipt of a SOAP message containing a Document Type Declaration, a SOAP receiver MUST generate a fault (see 4.4 SOAP Fault) with a fault code of "DTDNotSupported". </quote>[email]
This note is to formally announce that the workgroup has decided to close issue 191 in the manner proposed by me, as amended by Henrik.
[email]We can't keep applications from requiring validation for their own content. How can we keep applications from supplying defaults for their own purposes? We even do it for our own attributes." <quote> Therefore, SOAP REQUIRES that all attribute information items, whether specified in this specification or whether they belong to a foreign namespace be caried in the serialized SOAP envelope. </quote>[email]
Enchance the description of the Envelope encoding to include discussion stating that the values of the [version], [character encoding scheme] and [standalone] infoset properties are unimportant as far as SOAP is concerned.[email]
The attributes found in the XML declaration, namely version, encoding and standalone are modelled in the infoset as the [version], [character encoding scheme] and [standalone] properties of the Document Information Item. Having XML declarations in examples is thus completely coherent. I would also note that the latest editor's copy[2] makes explicit reference to the infoset properties listed above.[email]
During the F2F I was actioned to raise an Issue with respect to the first Ednote in SOAP 1.2 Part 2 section 7.4.1.2.1, part of the HTTP binding. The ednote states: <quote> As described this model tends to hide a malformed message from the local SOAP Node and handle the malformation in the binding - basically because it would not be possible to instantiate the CurrentMessage to pass up for processing. An alternate formulation might be to allow CurrentMessage to carry badly formed messages and let the SOAP processor/node deal with it. As presented here we can have define the bindings behaviour with respect to particular failures. </quote> The issue that the ednote raises is two fold: 1) From a descriptive point of view where do we place the responsibility to describe behaviour associated with the receipt of poorly formed SOAP messages? Malformations might include: XML that is not-well formed; Unsupported envelope version; some unsupported message encapsulation (eg MIME/DIME etc). 2) From a more practical point-of-view, is it right that a binding implementation 'hide' the receipt of such 'broken' messages from the SOAP processor/node. This may be more moot, because it probably makes inappropriate assumptions about the structure of an implementation.[email]
"the editors should check that the binding framework says that binding specification writers should ensure that bindings can handle all failures that may be anticipated within the binding."[email]
At the recent face-to-face it came to light that more prose was needed around the id and ref attributes in the SOAP Encoding section of Part 2 Specifically the uniqueness constraint needs to be made explicit. We cannot refer to XML Schema for this, because the uniqueness constraint is defined in XML Schema Part 1 as part of a validation episode and SOAP requires that no such episodes be mandated.Note that this issue is linked to issue 163 [