OASIS ebXML Messaging Services TC

  • 1.  A first assessment of ebMS profiling for AS2

    Posted 03-05-2008 21:05
    
    
    
    
    
    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?
     
    2- MIME & HTTP bindings: mapping or keeping the AS additional MIME content-types, and HTTP headers?
     
    3- Header fields: ebMS header mapping or profiling of AS2 headers & system identifiers (AS-From...)
     
    4- security aspects: S/MIME vs XML DSig & Encryption, map AS security features to equivalent ebMS/WSS?
     
    5- MEP aspects: the "secure transfer loop": to be covered by appropriate (new / profiled?) ebMS MEP(s)
     
    6- error handling: new errors or error profiles needed?
     
     
     
     
    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


  • 2.  Re: [ebxml-msg] A first assessment of ebMS profiling for AS2

    Posted 03-05-2008 22:01
    
    
      
      
    
    
    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
    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"
    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


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

    Posted 03-05-2008 22:19
    
    
    
    
    
    
    
    
    
    
    

    Jacques noted a need for accomodating

    3- Header fields: ebMS header mapping or profiling of AS2 headers & system identifiers (AS-From...)

    Tim mentioned one approach:

    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

    AS4-To

    AS4-From

    and so on could be HTTP entity headers as in AS2.  (But that is not in the spirit of WS-* in that message metadata foi them is to be scrunched into the message bodyparts in various ways. ebMS follows this pattern.)

    I don’t think that WS-Addressing is relevant for AS4 identifiers, however. These party identifiers are logical identifiers of parties by values such as DUNS numbers that are used in the X12 EDI world, for example. Corresponding WS-Addressing values tend to be EPRs (or just URIs, er, IRIs).

    If these Froms and Tos were mapped into what is available in ebMS 3, however, I would say that

    AS4-To corresponds to the ebMS To field

    AS4-To corresponds to the ebMS From field.

    Service, Action, and Role correspond with no current metadata values in the EDIINT AS1 2 3 versions.

    Message-ID  Need to consider what that is used for. RM functionality (like duplicate checking) or MDN/NRReceipt functionality.

    Conversation-Id in ebMS has no corresponding value in EDIINT AS1,2,3.

    AS4-Version etc. also will need some discussion.



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

    Posted 03-07-2008 02:24
    
    
    
    
    
    
    
    inline


    From: Moberg Dale [mailto:dmoberg@axway.com]
    Sent: Wednesday, March 05, 2008 2:19 PM
    To: timothy@drummondgroup.com; Durand, Jacques R.
    Cc: ebxml-msg@lists.oasis-open.org
    Subject: RE: [ebxml-msg] A first assessment of ebMS profiling for AS2

    Jacques noted a need for accomodating

    3- Header fields: ebMS header mapping or profiling of AS2 headers & system identifiers (AS-From...)

    Tim mentioned one approach:

    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

    AS4-To

    AS4-From

    and so on could be HTTP entity headers as in AS2.  (But that is not in the spirit of WS-* in that message metadata foi them is to be scrunched into the message bodyparts in various ways. ebMS follows this pattern.)

    I don’t think that WS-Addressing is relevant for AS4 identifiers, however. These party identifiers are logical identifiers of parties by values such as DUNS numbers that are used in the X12 EDI world, for example. Corresponding WS-Addressing values tend to be EPRs (or just URIs, er, IRIs).

     

    If these Froms and Tos were mapped into what is available in ebMS 3, however, I would say that

    AS4-To corresponds to the ebMS To field

    AS4-To corresponds to the ebMS From field. 

     

    <JD> more precisely, eb:To/eb:PartyId and eb:From/eb:PartyId. (if AS4-To maps to eb:To, that means it maps to a complex element like partyid+role . I guess could be done using composed AS2-name - e.g. a quoted name of the form "partyId role").

    Service, Action, and Role correspond with no current metadata values in the EDIINT AS1 2 3 versions.

    Message-ID  Need to consider what that is used for. RM functionality (like duplicate checking) or MDN/NRReceipt functionality.

     

     

    Conversation-Id in ebMS has no corresponding value in EDIINT AS1,2,3.

    AS4-Version etc. also will need some discussion.



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

    Posted 03-07-2008 02:46
    
    
    
    
    
    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


  • 6.  Re: [ebxml-msg] A first assessment of ebMS profiling for AS2

    Posted 03-07-2008 06:04
    
    
      
    
    
    Yes, the One-Way/Push (sync and async) are what we are thinking, but we
    also have a end-user use case where we would need to the Two-Way/Push-and-Push (asynchronous only) MEP as
    well.

    There will be a few areas where we will be *extending* or provide value-add above and beyond the core AS2 functional requirements.

    Durand, Jacques R. wrote:
    0D4373E9E1236F42AB63FD6B5B306AA33F3970@SV-EXCHANGE.fjcs.net" type="cite">
    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

    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.



  • 7.  ETSI's Plugtests is pleased to invite you to the B2B Interoperability event that will be hosted on its premises on 7 - 11 July 2008.

    Posted 03-10-2008 10:20
     
    More information at:
     
    http://ebxml.xml.org/calendar-event/etsi-ebxml-b2b-plugtest
    http://www.etsi.org/plugtests/B2B/B2B.htm