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

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

more inline <JD>

---

From: Timothy Bennett [mailto:timothy@drummondgroup.com]
Sent: Wednesday, March 05, 2008 2:01 PM
To: Durand, Jacques R.
Cc: ebxml-msg@lists.oasis-open.org
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