OASIS ebXML Messaging Services TC

 View Only
  • 1.  Groups - ebMS-multi-hop-v2.doc uploaded

    Posted 02-26-2008 20:24
    This is a new version with some changes based on remarks made during the
    call last week.
    
    
     -- Mr. Sander Fieten
    
    The document revision named ebMS-multi-hop-v2.doc has been submitted by Mr.
    Sander Fieten to the OASIS ebXML Messaging Services TC document repository.
     This document is revision #1 of ebMS-multi-hop.doc.
    
    Document Description:
    A document describing definitions of, assumptions about and requirements
    for the multi-hop scenario.
    
    View Document Details:
    http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?document_id=27352
    
    Download Document:  
    http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/27352/ebMS-multi-hop-v2.doc
    
    Revision:
    This document is revision #1 of ebMS-multi-hop.doc.  The document details
    page referenced above will show the complete revision history.
    
    
    PLEASE NOTE:  If the above links do not work for you, your email application
    may be breaking the link into two pieces.  You may be able to copy and paste
    the entire link address into the address field of your web browser.
    
    -OASIS Open Administration
    


  • 2.  Re: [ebxml-msg] Groups - ebMS-multi-hop-v2.doc uploaded

    Posted 02-27-2008 17:19
    All,
    
    in this document the intermediary is not explicitly defined. From the 
    figures and text I would assume it's a special case of a MSH. But, as 
    Pim did, we can also distinguish SOAP intermediaries. From what I know 
    about the SOAP and WS-* specs there's not much defined about such 
    intermediaries.
    
    I'm wondering if we need to take these SOAP intermediaries into 
    consideration. And if we do, what functionality do we expect from them 
    and what does this require from MSH's?
    
    Regards,
    Sander
    
    sander@fieten-it.com wrote:
    > This is a new version with some changes based on remarks made during the
    > call last week.
    >
    >
    >  -- Mr. Sander Fieten
    >
    > The document revision named ebMS-multi-hop-v2.doc has been submitted by Mr.
    > Sander Fieten to the OASIS ebXML Messaging Services TC document repository.
    >  This document is revision #1 of ebMS-multi-hop.doc.
    >
    > Document Description:
    > A document describing definitions of, assumptions about and requirements
    > for the multi-hop scenario.
    >
    > View Document Details:
    > http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?document_id=27352
    >
    > Download Document:  
    > http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/27352/ebMS-multi-hop-v2.doc
    >
    > Revision:
    > This document is revision #1 of ebMS-multi-hop.doc.  The document details
    > page referenced above will show the complete revision history.
    >
    >
    > PLEASE NOTE:  If the above links do not work for you, your email application
    > may be breaking the link into two pieces.  You may be able to copy and paste
    > the entire link address into the address field of your web browser.
    >
    > -OASIS Open Administration
    >   
    


  • 3.  RE: [ebxml-msg] Groups - ebMS-multi-hop-v2.doc uploaded

    Posted 02-27-2008 19:21
    SOAP intermediaries are supposed to follow SOAP processing rules and
    somehow know that they are intermediaries and not ultimate destinations.
    Unless they are "active intermediaries" the forwarding intermediaries
    have to be moderately well-behaved. Active intermediaries are, from a
    security standpoint, basically indistinguishable from MITM attackers.
    
    SOAP 1.2 section 2.7.2.1 Relayed Infoset has some detail on forwarding
    intermediaries.
    
    I would have liked MSH intermediaries to have been SOAP forwarding
    intermediaries, but I don't think our current goals/aspirations can be
    met by forwarding intermediaries. From the RM and WSS perspectives MSH
    will (also) be constrained active SOAP intermediaries, I think.
    
    In general, I think we should first see what we can do to meet the
    scenario-based functionality, and then tidy up our conceptions about
    what the intermediary MSHes are in terms of underlying specifications'
    terminology.