OASIS ebXML Messaging Services TC

  • 1.  Groups - ebXML Messaging TC weekly call added

    Posted 02-01-2010 14:09
      |   view attached

    Attachment(s)

    ics
    ical_26593.ics   683 B 1 version


  • 2.  Minutes Feb 3, 2010 meeting

    Posted 02-09-2010 02:23
     Meeting notes Wednesday Feb 3, 2010:
    
    -----------------------
    1. Attendance:
    
    Present:
    
    
    Timothy Bennett
    Jacques Durand 
    Sander Fieten
    Dale Moberg
    Pim van der Eijk 
    
    Excused:
    
    Ian Jones
    
    
    2. Approval of previous minutes
    
    Postponed.
    
    3. V3 Advanced features - bundling
    
    - Dale presented the bundling addition for pipelining.
    - Options kept open for 1-Way and 2-Way MEPs.
    - Can pipelining apply to PullRequest (not idempotent)? Yes, a
    possibility, needs some attention in case of an empty pull-MPC, where
    returning warnings 0006 may need be done on pipelined PullRequests,
    before returning a user message in case submitted more recently. 
    - we agree to add the pipelining to bundling, in Chapter 4.
    
    4. V3 Final review
    
    - Pim edited latest update.
    - References to WS-Secure Conversation: presence in "Related Works" may
    not be justified, as we only mention that WS-SC can be used in
    combination with V3. (should rather WS-I Profiles be mentioned instead?)
    - Next MSH URI: set as value for wsa:To when routing through the
    I-Cloud, but not to be used on wsa:Action.
    - Pmode: Add "Addressing" before the EPR parameter: now 3 major sections
    under Addressing parameter: 
    O Addressing.address (not part of EPR)
    O Addressing.EPR
    O Addressing.action (not part of EPR)
    - Pim needs comments on his latest Examples
    - Section 2.5.1 neeeds be corrected: incompatible with the principle
    that intermediaries mustr not alter the message: "1.the pulled signal
    MUST be combined with an eb3:Error element with code: EBMS:0006". The
    intermediary must not add such an error header, when being pulled from
    over an empty MPC (or one that contains signals such as Receipt).
    - Instead, an intermediary - when being pulled from - MUST accept
    non-user messages (i.e. Receipts, errors and other signals) on a pull
    MPC, and send out these as responses to authorized pulling.
    - Debate whether the Addressing.EPR Pmode parameter must have its
    instances include all its parts, as "RoutingInput parameter node MUST
    conform to the RoutingInput schema" where this schema currently requires
    all be present, even if only a subset are known to participate in the
    routing ("effective routing input"). Consensus that schema stays as it
    is, and that RoutingInput parameter on the wire should conform: missing
    parts must be tolerated by an MSH. (can someone doublecheck this
    conclusion?)
    
    5. AS4 - Updates
    
    6. A.O.B.
    
    --------------------------
    
    Jacques
    
    
    


  • 3.  RE: [ebxml-msg] Minutes Feb 3, 2010 meeting

    Posted 02-09-2010 08:26
    Hello,
    
    In response to your question, "can someone doublecheck this
    conclusion?", here is (copied from the updated version .52
    posted last weekend) what I understood to be the conclusion
    of this discussion (not sure if that is the same as what you
    write):
    
    "The content of the ebint:RoutingInput XML header in ebMS
    SOAP messages MUST conform to the RoutingInput schema. This
    does not mean that all elements defined as required in the
    RoutingInput schema must be defined in the Pmode. An MSH
    SHOULD set the values of  elements not defined in the EPR
    based to the inferred values as described in section 2.6 .
    The EPR in the Pmode should define values for the effective
    routing input elements." 
    
    Dale's pipelining proposal is in chapter 4 (subsection 4.3)
    not in the bundling chapter 3.  Partly because chapter 4 is
    for other Pmode extensions (that need just a few paragraphs
    to specify), and partly because pipeling is at a different
    level and complementary to bundling as defined and described
    in chapter 3 (an MSH could bundle at ebMS SWA level and
    pipeline at HTTP level, or do one but not the other).
    
    Pim
      
    
    


  • 4.  Update of Minutes Feb 3, 2010 meeting

    Posted 02-09-2010 20:30
    Resending edited notes (from Pim's comments):
     
    
    -----------------------
    1. Attendance:
    
    Present:
    
    
    Timothy Bennett
    Jacques Durand
    Sander Fieten
    Dale Moberg
    Pim van der Eijk 
    
    Excused:
    
    Ian Jones
    
    
    2. Approval of previous minutes
    
    Postponed.
    
    3. V3 Advanced features - bundling
    
    - Dale presented the bundling addition for pipelining.
    - Options kept open for 1-Way and 2-Way MEPs.
    - Can pipelining apply to PullRequest (not idempotent)? Yes, a
    possibility, needs some attention in case of an empty pull-MPC, where
    returning warnings 0006 may need be done on pipelined PullRequests,
    before returning a user message in case submitted more recently. 
    - we agree to add the pipelining to bundling, in Chapter 4.
    Dale's pipelining proposal is in chapter 4 (subsection 4.3) not in the
    bundling chapter 3.  Partly because chapter 4 is for other Pmode
    extensions (that need just a few paragraphs to specify), and partly
    because pipeling is at a different level and complementary to bundling
    as defined and described in chapter 3 (an MSH could bundle at ebMS SWA
    level and pipeline at HTTP level, or do one but not the other).
    
    4. V3 Final review
    
    - Pim edited latest update.
    - References to WS-Secure Conversation: presence in "Related Works" may
    not be justified, as we only mention that WS-SC can be used in
    combination with V3. (should rather WS-I Profiles be mentioned instead?)
    - Next MSH URI: set as value for wsa:To when routing through the
    I-Cloud, but not to be used on wsa:Action.
    - Pmode: Add "Addressing" before the EPR parameter: now 3 major sections
    under Addressing parameter: 
    O Addressing.address (not part of EPR)
    O Addressing.EPR
    O Addressing.action (not part of EPR)
    - Pim needs comments on his latest Examples
    - Section 2.5.1 neeeds be corrected: incompatible with the principle
    that intermediaries mustr not alter the message: "1.the pulled signal
    MUST be combined with an eb3:Error element with code: EBMS:0006". The
    intermediary must not add such an error header, when being pulled from
    over an empty MPC (or one that contains signals such as Receipt).
    - Instead, an intermediary - when being pulled from - MUST accept
    non-user messages (i.e. Receipts, errors and other signals) on a pull
    MPC, and send out these as responses to authorized pulling.
    - Debate whether the Addressing.EPR Pmode parameter must have its
    instances include all its parts, as "RoutingInput parameter node MUST
    conform to the RoutingInput schema" where this schema currently requires
    all be present, even if only a subset are known to participate in the
    routing ("effective routing input"). 
    Consensus is:
    The content of the ebint:RoutingInput XML header in ebMS SOAP messages
    MUST conform to the RoutingInput schema. This does not mean that all
    elements defined as required in the RoutingInput schema must be defined
    in the Pmode. An MSH SHOULD set the values of  elements not defined in
    the EPR based to the inferred values as described in section 2.6 .
    The EPR in the Pmode MUST define values for the effective routing input
    elements.
    
    
    5. AS4 - Updates
    
    6. A.O.B.
    
    --------------------------
    
    Jacques
    
    
    
    ---------------------------------------------------------------------
    To unsubscribe from this mail list, you must leave the OASIS TC that
    generates this mail.  Follow this link to all your TCs in OASIS at:
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php