[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: v98b formal ballot comments
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]
Powered by eList eXpress LLC