[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: v98b formal ballot comments
Chris, In my comments, I equate "SOAP application" with "SOAP Processor". I envision a 'generic' SOAP application/processor that will parse the SOAP Header. This generic processor will maintain knowledge of the Namespace handlers, and will pass to these handlers their respective first level elements. This model supports a clean interface between the SOAP application/processor and the supporting handlers, such as the ebXML handler. Consider then a SOAP message constructed as follows: SOAP:Header ebXML:Header SOAP:mustUnderstand="1" ebXML:Via SOAP:actor=[next] SOAP:mustUnderstand="1" DSIG:Header SOAP:mustUnderstand="1" ebXML:Trace SOAP:actor=[next] SOAP:mustUnderstand="1" NOTE: For simplicity, I have ignored the ebXML:Manifest and any other ebXML first level elements for this discussion. A SOAP processor would identify the four first level elements and verify that handlers exist for each, since each has mustUnderstand="1". A SOAP processor would then dispatch some handlers. How it would do this is not clear. Let's suppose the SOAP applicaiton/processor interface to the handler was: Call HandlerForNamespace(FirstLevelElement(i),MIMEBodyParts) for i=1,4 Let's now assume that the ebXML handler was acting in the role of an intermediary. i=1 The ebXML handler would process the ebXML:Header element, note that it was not the intended recipient, and return to the SOAP processor the result. i=2 The ebXML handler would process he ebXML Via element, act upon the element, and return a 'next-destination' result to the SOAP processor. Note that this invocation does not have access to the ebXML:Header element i=3 The DSIG Handler would process the DSIG:Header element, note that it was not the intended recipeint, and return to the SOAP processor the result. i=4 The ebXML handler would process the ebXML:Trace element, act upon the element, and return a new ebXML:Trace element to the SOAP processor The SOAP Processor would reconstruct the SOAP message, discarding the two 'spent' elements, adding the new ebXML:Trace element. It would then invoke lower level processes to construct the MIME envelope and transport the message to the new destination. In this scenario, each invocation of the ebXML handler would have implied access to the ebXML:Header (via the first MIMEBodyPart), but there would be three separate instantiations of the ebXML handler, and the handler fould have to parse the entire SOAP header to locate information of interest to it. I don't like the scenario, but I cannot fault such a SOAP Processor implementation. Now consider the same information, arranged as follows: SOAP:Header ebXML:Header SOAP:mustUnderstand="1" SOAP:actor=[next] ebXML:Via DSIG:Header SOAP:mustUnderstand="1" ebXML:Trace In this scenario, the SOAP processor makes a single dispatch, to the ebXML handler. The ebXML handler is in control of invocation of the DSIG handler. It has access to the entire ebXML:Header construct in a single element. The handler processes the entire ebXML:Header message, returns a new ebXML:Header message and new destination. The ebXML handler decides whether to invoke the DSIG handler and if it does invoke that handler, it decides what to do with the returned results. Of course, if the DSIG signatues had not originated from actions of an ebXML handler in the first place, it would have appeared in the SOAP envelope as a first level element, and been handled independently from the ebXML header element. But based on my understanding of the ebXML architecture, it is the ebXML handler that would have invoked the DSIG handler (figure at line 155 of TRP spec). As I've said, I don't really know how the SOAP architecture is expected to process the SOAP envelope content. So the above is just conjecture on my part based on my many years of systems design. But from the above, you should now have a better understanding of my comments to the TRP specification. One could integrate the SOAP processing and handlers in a single SOAP application (I really don't like that! On the other hand, my guess also is that this strikes nearer the truth of current SOAP processors/applications. Has anyone actually tried putting two first level elements for differing namespaces in a Soap message and seeing what the receving SOAP application did with them?), or the SOAP handler could recognize that only two handlers were required, and pass each handler the entire message in some perdetermied invocation order. Regardeless, I believe the organization of elements in the second scenario is preferable to the ordering in the first scenario, and it certainly makes moot the question of how the SOAP processor performs its tasks. By the way, ebXML:Via looks like something that should more appropriately be SOAP:Via, since its applicability would seem to extend beyond ebXML to other SOAP-based applications. As it is not part of SOAP now, it has to be ebXML:Via, but I hope we have requrested W3 consider adding it to the SOAP wish list. You did not comment on my argument that ebXML:Manifest should be located in the SOAP:Header area (as it might change as it passes through intermediaries). You appear not to have understood my argument on positioning the Acknowledgment and StatusData elements in the SOAP Header. My argument on each of the ebXML elements that appear in the SOAP:Body is that they may be intended for processing (and removal or replacement) by an intermediary. Placing them in the SOAP:Header accomodates the use of the SOAP:Actor attribute to enable such removal/replacement. None of the message flow diagrams explored use of the Acknowledgement and StatusData elements in a multi-hop environment. I relied therefore on wording of the stated 'purpose' (see lines 1074-1075 and 1118-1119) of these elements to infer that they need not be limited only to exchange with the recipient MSH. In an A-B-C-D MSH scenario, either A or B could request Status Data from either/both C and/or D by appropriately using the actor attribute to determine "who dropped the ball". I think the SOAP requirement that the SOAP Body is mandatory so colored the discussions on placement of ebXML elements that the usefulness of the actor attribute was overlooked. WRT to my comment on the use of the actor attribute on Via, you state that the team specifically avoided the issue of 'source routing'. But wait a minute, I thought the intent of 'Via' was in fact to control routing, and since a Via doesn't magically 'materialize' in a message after it is received by an MSH, it must have been put there by the [source] MSH. Sounds like that means the source is doing some routing there somehow! I would certainly expect that a 'business model' would encompass the routing of a message from its source, through any intermediaries required by the model to the recipient. For example, the model might provide a routing Sender-SendersBank-RecipientsBank-Recipient. Note that these are logical addresses, not physical addresses. The intermediate MSH's would accept the Via directed by their role, and would effect the translation from logical desitination to physical destination for the next hop of the message journey. That seems sensible to me, and more likely than using a single [actor=next], which fails to make full intneded business routing. Please note by the wasy that the argument for relocating these elements within the SOAP Header is independent of the argument to locate them specifically within the ebXML header. WRT to who is responsible for removing the 'spent-actor' elements, SOAP is clear that they 'must' be removed, whereas the TRP specification says 'Recommended'. Cheers, Bob -----Original Message----- From: Chris Ferris [mailto:email@example.com] Sent: Thursday, March 29, 2001 5:37 PM To: Miller, Robert (GXS); firstname.lastname@example.org Subject: Re: v98b formal ballot comments Bob, Thanks for the thoughtful review of the specification. Some comments follow interspersed in the text of your submitted comments in italics and indented. Cheers, Chris Line Reference Comments Entire Document (NOTE: Specific reference comments follow this comment) The late-in-process introduction of the SOAP protocol layer requires more thought be given to process flow and message organization. This specification as currently written does not adequately address multi-hop processing, and it locates some elements of the ebXML header information where they are not addressable by Actor roles other than the Default Actor role. Also, it introduces multiple first level SOAP Envelope elements within the same Namespace and intended for processing by the same SOAP actor. This may cause a SOAP Processor to invoke the ebXML processor multiple times to process the single message. My understanding of the SOAP protocol is that at each intermediate hop in a multi-hop transmission, the entire SOAP Header (but not the SOAP Body) is screened by a generic SOAP MSH looking for elements whose Actor attribute match a supported Actor role of the MSH. Every intermediate MSH must support the Actor role 'Next'. I would expect that at least one ebXML element directed to an intermediate ebXML MSH would be required to trigger execution of the ebXML MSH. That is, an ebXML elemetn directed to the default actor would not trigger ebXML processing within an intermediate MSH. The Via element is intended to serve this purpose. Possibly, there should be some language added that makes this more clear and that requires use of the Via element when messages are to be processed by intermediary MSH nodes. It is not clear to me from the SOAP specification whether the ebXML MSH would have access to the entire SOAP envelope content, or would only have access to the specific element directed to the ebXML MSH. The SOAP specification does provide some instruction on this in its documentation section 2. It states it will: 1)Identify all parts of the SOAP message intended for that application (see section 4.2.2) 2)Verify that all mandatory parts identified in step 1 are supported by the application for this message (see section 4.2.3) and process them accordingly. ... 3)If the SOAP application is not the ultimate destination of the message then remove all parts identified in step 1 before forwarding the message. It is not clear from the above what is implied in 2) by "process them accordingly". Mandatory parts are indicated by the mustUnderstand attrubute. But elements may belong to multiple Namespaces, each of which has its own associated application. Each of which MAY have its own associated handler. Whether all of the elements associated with a single Namespace are to be handled by a single invocation, or each is to be handled by a separate invocation is not clear. Rather, the SOAP specification simply states in the text succeeding the above list: Processing a message or a part of a message requires that the SOAP processor understands, among other things, the exchange pattern being used (one way, request/response, multicast, etc.), the role of the recipient in that pattern, the employmnet (if any) of RPC mechanisms such as the one documented in section 7, the representation or encoding of data, as well as other semantics necessary for correct processing. How the SOAP processor will acquire this 'understanding' is not clear. Some if not all of this information may be available in the ebXML TPA, but neither this specification nor the TPA specification speaks to the need to map this information to the [apparently implementation dependent] SOAP interface for providing this information. An ebXML MSH would then process those parts of the SOAP envelope that were defined in the ebXML Namespace, and the SOAP processor would remove those ebXML parts specifically directed to the ebXML MSH acting as an intermediary. The ebXML MSH might add other content to the SOAP Header, SOAP Body, or MIME Payload as it returned the message to the SOAP processor for further processing and dispatch to the next MSH. The SOAP Processor is not responsible for, nor identified as being the entity that removes SOAP:Header element content that has an actor attribute with the meaning of 'next'. From the SOAP 1.1 W3C NOTE: "Not all parts of a SOAP message may be intended for the ultimate destination of the SOAP message but, instead, may be intended for one or more of the intermediaries on the message path. The role of a recipient of a header element is similar to that of accepting a contract in that it cannot be extended beyond the recipient. That is, a recipient receiving a header element MUST NOT forward that header element to the next application in the SOAP message path. The recipient MAY insert a similar header element but in that case, the contract is between that application and the recipient of that header element." I will grant that the language used here is a little loose as the term 'recipient' is not formally defined as being the either SOAP application or the SOAP processor. I would interpret this statement as meaning that it is the responsibility of the recipient SOAP application to remove the element content that was designated to it by virtue of an actor attribute of 'next' or of the URI of the SOAP application itself. In any event, I would be suspect of a SOAP processor that implemented functionality to modify the message by removing such content of the message. How would it distinguish between the original element and a similar header element that just happened to be identical to the original? A SOAP envelope may include elements from multiple Namespaces. SOAP provides little advice regarding the order in which services addressed by such Namespaces are invoked. For this reason, this specification should declare whether the services performed by an ebXML MSH are considered to be independent of any services provided by another MSH. Also for this reason, if an intermediate ebXML MSH is invoked, all ebXML constructs in the SOAP envelope should be contained within a single ebXML element. It is true that the SOAP specification is a little unclear as to whether or not the element content of a SOAP Message that belongs to a foriegn namespace w/r/t the namespace of the declared handler for a given element is available to that handler. However, in my experience, each processor provides access to the "whole" message, not just the namespace qualified content that matches the namespace of the registered handler and the actor URI. This assumption may be a bit broad, since I've only direct experience with two SOAP toolkit implementations, (Apache and IBM's TRLSOAP) but it would seem to me to be a valid assumption with any successful implementation. Take the example of signing or validating the signature of a message. The handler/application processing the signature MUST have access to all of the content over which the signature has digested/signed. Without it, the signature is a fairly useless thing. I also believe that omitting an actor attribute (thus, establishing it as destined to the ultimate destination of the message or default actor) for the ebXML namespace qualified content of the SOAP:Header element is appropriate for our use. As you noted in your comments, the Via element provides support for intermediary MSH by use of the 'next' actor. The intermediate MSH node will still have access to the other content of the SOAP message, but clearly, an intermediary will need to "know" that it is an intermediary and not an ultimate destination. Certainly, by inspecting the To/PartyId it can clearly discern that the message is destined for another MSH than itself;-) In my opinion, the integration of the SOAP protocol into the ebXML Transport, Routing, and Packaging Specifications raises both SOAP and ebXML issues which have neither been identified nor addressed in these two specifications. These issues in turn prevent successful implementation of at least some of the features defined in the specification. I certainly concur that the adoption of SOAP by ebXML will highlight some of the issues, known or unknown, with both SOAP and ebXML's use of SOAP. I believe that all issues related to the use of the SOAP envelope can be resolved, and I also believe that use of the SOAP protocol is advantageous., However, I doubt there is time to address all of the SOAP-related issues in the time remaining before the May ebXML meeting. I also concur with this comment. We can certainly endeavor to explore the issues that you and others raise, but it is not clear that we'll have time to address them fully, especially if they involve significant change. I also believe that many of the issues I identify in this comment submission can be readily addressed by packaging all ebXML elements within a single outer level ebXML Header element, and by imbedding in this same ebXML element those XMLDSIG elements used to provide security services for ebXML messages. Of this I am not so certain. Please see my ensuing comments. If the issues raised in this comment cannot be satisfactorily addressed in the time remaining before the May ebXML meeting, I recommend the outstanding issues and their impact upon implementation of the specification be made explicit in the document as it is submitted for approval. This certainly sounds reasonable. 176, 245-246,968,972-1072 The Manifest element belongs in the SOAP Header section, not in the SOAP body section. Argument supporting comment: 1)Per the SOAP specification, the SOAP body is: "a container for mandatory information intended for the ultimate recipient of the message" 2)Each ebXML message handler in the path between the sending and recipient parties may have need to: 3)Access content referenced in the current manifest 4)Delete content from the message and manifest 5)Add content to the message and manifest Example Usage: An ebXML message handler for a bank might need to access the ebXML payload, and then add to the payload a NACHA message instructing funds transfer to a bank account at a bank used by the recipient 1)Intermediate ebXML messsage handlers are not "the ultimate recipient of the message" I would also like to note that multiple Manifest elements directed to the end recipient might be an appropriate choice to address the functionality of 2)C) above. In that way, signatures over the original manifest may be maintained, and the added manifest may be separately signed by the parties adding content. 763 The statement: "The Via element is a SOAP Header ..." is incorrect. The Via element is an ebXML header composite element that resides within the SOAP Header 241-242,976 First reference says an application payload must be carried in a Payload Container, whereas second reference says "It is RECOMMENDED that no payload data be present in the SOAP-ENV:Body." With respect to this inconsistency, I favor the 'RECOMMENDED" wording. 1073-1116 The StatusData Element belongs in the SOAP Header section, not in the SOAP Body section. Argument supporting comment: 1)1074-1075 states: "The StatusData element is used by one MSH to ..." 2)Data directed to an intermediate MSH must be located in the SOAP Header so that it may accept the SOAP actor attribute. 1117-1173 The Acknowledgment Element belongs in the SOAP Header section, not in the SOAP Body section. Argument Supporting Comment : 1)As with the Manifest and StatusData elements, this message is intended for message service handlers, of which there may be several. 276,341-347,958-1202 Although the Manifest, StatusData, and Acknowledgment elements may be of specific interest to a given MSH, and so may be required to reside in the SOAP Header area , the SOAP specification states in 4.3.1 that "A body entry is semantically equivalent to a header entry intended for the default actor and with a SOAP mustUnderstand attribute with a value of "1". Therefore, it could be acceptable to allow these three ebXML elements to reside in the SOAP Body in the case that they are directed to the default actor, if the designers so wish. Of course by that argument the other ebXML elements now located in the SOAP Header area could just as well appear in the SOAP Body if the default Actor is implied. For simplicity, I recommend that this specification prohibit the appearance in the SOAP Body of any of the ebXML elements defined in this specification. Assuming this restriction is made, all appearances of the term 'Body' must be located, and changes made as appropriate. Your suggestion that all ebXML extension element content currently specified as being child elements of the SOAP:Body element (Acknowledgment, StatusData and Manifest) should instead be child elements of the SOAP:Header based upon the fact that element content of the SOAP:Body is syntactically equivalent to having an mustUnderstand=1 and the default actor (the ultimate destination of the message) seems to me to be a more compelling argument for inclusion of these elements in the SOAP:Body than not. An ebXML MSH is essentially an application to the SOAP processor. It in turn is responsible for dispatch the contents of the received message to the aplication component that it determines should handle the message. All of the ebXML defined content of the SOAP:Body is designated as being directed TO the MSH itself, including the Manifest, Acknowledgment, and StatusData elements. Thus, the terminal MSH *is* the ultimate destination (SOAP application) of the messages containing these elements. 1202 Whereas the Via element is SOAP Actor 'next' qualified, the limitation of "One-and-only-one Via element MAY be present" is true since the MSH which processes a Via element must remove it. But of course, the MSH may construct a new Via element prior to forwarding the message. In fact, it MUST as per the SOAP specification. Technically, it could leave the existing Via element as it is in the case that the MSH would be inserting a "similar" element. Since the restriction noted here is an implied result of the SOAP specification and the requried use of the SOAP Actor 'next' attribute on that element, I recommend this paragraph be deleted. Separately, I question whether it is appropriate to restrict the Via element use of the SOAP Actor to 'next'. We have explicitly avoided "source routing" of messages, which is what would be implied if we were to provide for a) multiple Via elements and/or b) use of alternate values for the actor attribute. 791 'SHOULD NOT be forwarded' conflicts with SOAP specification 4.2.2 "MUST NOT forward' Note also that the SOAP Specification accepts responsibility for removing the local actor directed element before forwarding. SOAP Specification? See my comment above. I think you meant SOAP Processor, but as I have indicated, I don't believe that 'recipient' was intended to be interpreted as meaning the SOAP processor, but rather the SOAP application or handler. 155 It is not clear to me why the box lableled "Authentication, authorization and repudiation services" feeds into "Header Processing", rather than being directed from "Header Processing" as is done for "Encryption and/or Digital Signatures". I was unable to find any supporting (or contradicting) this interface positioning elsewhere in this specification. 271-273 The reporting of MIME errors in SOAP protocol as specified in [SOAP] is outside the scope of this specification. The reporting of errors in ebXML protocol, whether such errors originate in MIME or in SOAP is within the scope of this specification. Such reporting is addressed in a separate section of the specification. This section (7.6) should be removed from the specification. 658-761 As defined, the TraceHeaderList element needs SOAP attribute actor=[next] in the case of multi-hop, so that it may be consumed and rewritten at each intermediate hop. Properly defined, the TraceHeaderList element should be a child of the ebXML Header element, and it is that element that should carry the SOAP attribute actor=[next] This makes sense to me. I concur that we should add the actor attribute to the TraceHeaderList element. 762-850 As I understand the SOAP specification, the SOAP processor will separately invoke handlers for each element it encounters within a SOAP Header, based upon the Namespace of that handler. If multiple first level ebXML elements exists, that furhter suggests that the SOAP Processor will invoke the ebXML handler multiple times. I conclude that there should be just one ebXML Namespace element (at least for a given Actor attribute) within a SOAP Header, and that all other ebXML namespace elements should be descendants of this 'Header' ebXML Namespace element. Note that this comment also appies to other ebXML elements in this specification not specifically referenced in this comment reference range. This issue needs further exploration. 787-792 Why does this specification preclude the use of the SOAP actor attribute with a value other than [next]. Might not a business model require that a named actor effect a Via service directed by the sender to other than the first intermediate MSH? The purpose of the Via element is to provide for intermediary support. I think I see where you are going with this comment. If there is a non-MSH-aware SOAP intermediary that does not understand the ebXML namespace, then what would be the expected behavior of that node? This needs to be further explored. 870 "0.98b" matches the current specification version, and presumably will be updated to "1.0" when this specifcation is approved for publication. In any event, I don't think a letter should appear in the final version. The final draft will have "1.0" which will be consistent with the version of the specification upon its approval. 155,176,907-909,1565-1577 The specification is not clear regarding the interaction between the MIME Error Reporting and Processing, the SOAP Error Reporting and Handling and the ebXML Error Reporting and Handling. "SOAP Messages with Attachments" declares SOAP's independence from MIME wrappers. That is, SOAP appears not to provide a means to report MIME errors through the SOAP Fault Code mechanism. The diagram at line 155 shows a single interface from the [ebXML] Header Processing to the [presumably SOAP] Message Packaging. The first set of reference lines provides instruction on how to report a MIME error location, which presumably (see diagrams at line 155 and 176) has been extracted from a SOAP error which in turn is reporting a MIME error. (NOTE: This information should be located within the second referenced section.) The ebXML error codes (line 946) include "DeliveryFailure" which presumably encompasses both MIME errors reported through the SOAP interface, and other errors originating in the SOAP service processor. Reference lines 907-909 give specific instruction on reporting MIME errors, but no such specific instruction is given on reporting SOAP generated errors. Additional material, and possibly changes to the depicted architecture are needed to provide sufficient advice on handling of errors occurring at or below the level of "Message Packaging". 155,947-957 The diagram at line 155 shows that [ebXML] Header Processing invokes "Encryption and/or Digital Signatures" processing services. The text of 947-957 states that the XMLDSIG elements resides as a standalone SOAP Header element in the XMLDSIG Namespace.. That in turn implies that it is the SOAP Processor that invokes "Digital Signautre" services, not the ebXML processor. Also, since the SOAP processor does not specify the order in which multiple Namespace services are performed, it is not clear that the architecture as presented will work properly. The interface diagram suggests that he Signature Element (in the XMLDSIG Namespace) be a dependent of some ebXML Header element, such that the SOAP processor does not 'see' that Namespace. None In submitting these comments prior to the close of the ballot period, I reserve the right to submit additional comments on this specification prior to the close of the ballot period on April 6, 2001.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC