[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]