Update of Minutes Feb 3, 2010 meeting

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

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