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

["Pim van der Eijk" <pvde@sonnenglanz.net>]

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
  

-----Original Message-----
From: Jacques R. Durand [mailto:JDurand@us.fujitsu.com] 
Sent: 09 February 2010 03:23
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Minutes Feb 3, 2010 meeting

 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



------------------------------------------------------------
---------
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_work
groups.php