RE: One last change request to ebXML TRP.

["Kasi, Jay" <jay.kasi@commerceone.com>]

Hello Bernd.  

Thanks for your response. It further clarifies things for me. I agree with
your
assessment about traceheaderlist, although I had the same concern about
XMLDSIG
over PKCS#7 (which is what is commonly used today).  

David clarified that the specification in the via overrides the
specification in 
the header over a hop. It would be good to clarify this in the spec because
I 
misunderstood the spec in this area. I thought the receiving intermediary
has to 
copy fields in the via to the appropriate fields (via is understood only by
the 
intermediary, not the MSH/transport) in the header because only the fields
in the header count.  

I think there is definitely a use case to be able to change reliability
method from 
ebXML to transport or vice versa at every hop without compromising the end
to 
end reliability specification specified by the original client. We
for example support multiple transports for each leg with any subset of 
transports supported per leg. I am sure many implementors would prefer to
just reject a 
message requesting transport level exactly once if a hop does not support a
exactly once 
transport. However, I dont think customers will accept this semantic, or
disallowing exactly 
once for a non exactly once transport and they might will be forced to bite
the bullet and 
implement ebXML exactly once algorithm over a hop despite the complexity.

There is also a use case for a service/action being inserted by a
intermediary router
in the via. The semantic could be (It should be specified in the spec) that
the via 
service/action take priority over the header service/action. This way, an
intermediary
can reroute the message to a interception service which can remove the
service/action 
in the via and route the message to the original destination. Same approach
can be used
for a copy routed to a logging service. 

Please note that all this can be done transparently by the MSH/intremediary
and this 
addresses my concern about the client not knowing anything at all. 

Thanks a lot for your insights. 

ragards, 
Jay kasi  

-----Original Message-----
From: Eckenfels. Bernd [mailto:B.Eckenfels@seeburger.de]
Sent: Friday, May 04, 2001 11:16 AM
To: Kasi, Jay; 'ebxml-transport@lists.ebxml.org'
Subject: RE: One last change request to ebXML TRP.


Hello,

> David Burdett educated me on ebXML's thinking on via and 
> traceheader. It
> does make 
> sense now that I fully understand it (I was not privy to any 
> of the ebXML
> discussions).

If we look at the most widely used messaging/routing implementations (SMTP
and IP) we will see, that both have a "Source Routing" or "Next Hop" Option
(Unix Bang-Style or Domain Routing Addresses for SMTP and IP Source Route
Option for IP) and both are rarely used and always make trouble for
implementations. Therefore I agree, that the VIA Element is not an good
Idea, we should depricate it's use.

On the Other Hand a Trace-Header (like Received in RFC822) is a good Tool
for Diagonstics. So TraceHeader should be mustUnderstand=false, but still
present. It is of course not considered in the Envelop Signature. Of course
this requires us XML-Level Signatures which are a major pain to impleent
(opposed to simple PKCS#7 Signatures like RosettaNet is doing.)

But since we already agreed in XML Sign, it is not a big issue, I think.

Greetings
Bernd

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org