OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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. However, please see below.
 

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.
 
 
 
-----Original Message-----
From: Miller, Robert (GXS) <Robert.Miller@gxs.ge.com>
To: ebxml-transport@lists.ebxml.org <ebxml-transport@lists.ebxml.org>
Date: Thursday, March 29, 2001 3:51 PM
Subject: v98b formal ballot comments

>See attached file.
>
>Cheers,
>            Bob
>
> <<TRP-98bComments.doc>>
>
>

begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;One Network Drive;Burlington;Ma;01803-0903;USA
version:2.1
email;internet:chris.ferris@east.sun.com
title:Senior Staff Engineer
fn:Christopher Ferris
end:vcard


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC