RE: [ebxml-msg] A first assessment of ebMS profiling for AS2

From
Durand, Jacques R. <>
Date
2008-03-07T02:46:01+00:00
ID
Thread
RE: [ebxml-msg] A first assessment of ebMS profiling for AS2
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