more inline <JD>
From: Timothy Bennett
[mailto:]
Sent: Wednesday, March 05, 2008
2:01 PM
To: Durand, Jacques R.
Cc:
Subject: Re: [ebxml-msg] A first
assessment of ebMS profiling for AS2
My thoughts inline...
On Wed, 2008-03-05 at 13:02 -0800,
Durand, Jacques R. wrote:
After a quick
scan of the AS2 specification, here are the main areas where I see
profiling work to do, for achieving similar functions on top of
ebMS3:
1- Receipts: MDN
replaced by a combination of RM acks and eb:Receipt?
Definitely eb:Receipt (if that is the MDN-like mechanism that Dale
spoke about that ebMS has). Not sure how much RM the profile will support
"out-of-the-box" but am open for discussion
<JD> if the goal is to replicate AS2 functionality as a profile, it
appears RM is not needed as far as I can tell (at least for a "minimal
profile") . So eb:Receipts
should do the job.
2- MIME & HTTP
bindings: mapping or keeping the AS additional MIME content-types, and HTTP
headers?
No thoughts
at the moment...
3- Header fields:
ebMS header mapping or profiling of AS2 headers & system identifiers
(AS-From...)
For endpoint
resolution (AS-To, AS-From, MessageId, etc), was thinking along the lines of
what WS-Addressing provides, and honestly I'm not sure how ebMS 3.0 incorporates
WS-Addressing
4- security aspects:
S/MIME vs XML DSig & Encryption, map AS security features to
equivalent ebMS/WSS?
Definitely
going with WSS here... XML DSig and Encryption constrained to X.509
tokens
5- MEP aspects: the
"secure transfer loop": to be covered by appropriate (new / profiled?) ebMS
MEP(s)
I think we try to use the ebMS MEP(s) as much as possible.
There's only a couple of these that we interested in "out-of-the-box"
<JD> It may be that the One-Way/Push (and all its flavors) might be sufficient. Technically that also covers
the case of async MDNs, as MDNs will likely be mapped as "eb Signals"
(eb:Receipt) and these do not count as first class messages in the abstract eb
MEP definitions - they are just part of the execution mode of the
MEP.
6- error handling:
new errors or error profiles needed?
No thoughts
at the moment...
Ian: I believe that
assisting the creation of such a profile would fall under our current charter
line:
"- prepare Technical Reports,
White Papers and other documents to further the consistent adoption of
messaging service specifications"
The outcome being
here "technical report" defining a profiling of ebMS V3 that would
support AS2 equivalent.
Am I
right?
Jacques