[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: updated issue list, proposed priorities in agenda
|
Attached, updated issues list (most with proposed resolutions),
adjusted for 0.8 WD. Many of these issues are editorial in nature. I would suggest to deal in priority (add to call agenda) with:
I'd like also to raise the following issue for discussion: As we have started to implement pipes and pulling, we realize
the following use cases are not well supported by the current pipe definition,
which would need to be tightened up if we do: (1) Many Sending MSHs
to the same Receiving MSH: a Receiving MSH publishing one "pipe
name" to be shared by several authorized senders possibly unknown yet.
The intent is of partitioning the inflow of messages on receiving side, based
on their business nature, not their source. The pipe name is currently
presented as a unique identifier for pipes, to be used only between 1 pair of
MSHs. (2) One Sending MSH
to several Receiving MSHs: There are cases where one may want more than one
Receiving MSH to pull from the same Sending MSH and on the same pipe name. Cases
include: (a) some failover case (first Receiving MSH fails) where the sender
does not have to be updated to switch, (b) joint and indiscriminate
processing of the same pool of messages by two equivalent but distant
applications (e.g. trouble tickets handlers). Jacques |
Remiaining proposed and agreed updates on latest WD 0.8: (Feb 15) ----------------------------------------------------------------------- ----------------------------------------------------------------------- 5) Subsubsection 5.1.3 (ebXML SOAP Envelope Extension ) should be moved to 5.1.4, and a new subsubsection 5.1.3 should be added having the title Example. STATUS: Agreed that a complete example be provided in its own section. Some disagreement as to placement of Example section. Some feel it should be first; others would like the normative specification text first with example following. EDIT: Just need detailed proposal ----------------------------------------------------------------------- 6) In examples, the element eb:Partref still contains the attributes: (and Partref to be renamed PartInfo I believe) 5.a- eb:id : agreed to remove (replaced by XML Id) 5.b- eb:idref. Use instead "href" (a SOAP standard attribute). STATUS: agreed. EDIT: Just need detailed proposal (see SOAP 1.2 appendix which uses it) ----------------------------------------------------------------------- 7) remove sections related to SOAP actors: In Part 1: - Remove sections 5.1.3.8 , 5.1.3.9, 5.1.3.10 about SOAP actors & mustUnderstand, as the related topologies that such actors support are relevant to Part 2. (see proposed changes for Section 3 below) In Part II: - introduce the additional topologies that are handled. - address the routing issue for MEPs in a more generic way, and add SOAP actors as needed. STATUS: agreed. Issue 8 takes care of scoping Part 1 to remove needs for handling intermediaries. EDIT: TO DO (Part 1) ----------------------------------------------------------------------- 8) Remodeling of Section 3: 8.a- Remove 3.4 and in Section 1 Intro (1.2 "Scope") add: "Features defined in Part 1 only support the point-to-point MSH topology, where no MSH or SOAP intermediary is assumed. Part 2 takes into account topologies with intermediaries, hub or multi-hop, as well as topologies where the ultimate MSH acts as a SOAP intermediary." 8.b- move section 3.3 "Message Service Processing Model" at the end of Section 2 (Messaging Model), replace title as "Messaging Service Processing Model" or "MSH Processing Model". 8.c- Replaces what is left of Section 3 (3.1 + 3.2) with proposal posted. 8.d- Section 3 should then be renamed "Processing Modes" STATUS: Proposal has already been discussed and reviewed, no overall objection. EDIT: Ready for inclusion review draft. ----------------------------------------------------------------------- 9) @soapresp attribute: STATUS: Agreed to remove. (references to it still in from 2.2.3.1 and 2.2.3.3) EDIT: TO DO ------------------------------------------------------------------ 10) Security: - too many examples that may not add value, redundant with WSS examples? - Ric notes that the security examples are incorrect, where the references are supposed to be to the SOAP Body, but instead contain a cid:xxx. STATUS: Agreed in general. Needs detailed proposal. EDIT: -------------------------------------------------------------------- 11) reliability of "Internal" Service/Action (such as msg:service/Ping): Last bullet item in 8.2.2: Relax the requirement: "... For example, in the case of At-Least-Once delivery, the MSH must ensure that if a message that has been submitted (Submit) fails before RM-Submit is invoked, then the user layer (Producer) gets a notification of failure (Notify invocation), as would be the case if the message processing failed just after RM-Submit was invoked. Similarly, if a message fails to be delivered on receiver side (Deliver) even after RM-Deliver has been successfully invoked, then a notification to the Consumer must occur on the receiver side (Notify)." as: "...For example, in the case of At-Least-Once delivery, the MSH must ensure that if a message that has been submitted (Submit) fails before RM-Submit is invoked, then a delivery failure Error is generated, as would be the case if the message processing failed just after RM-Submit was invoked. Similarly, if a message fails to be delivered on receiver side (Deliver) even after RM-Deliver has been successfully invoked, then a delivery failure Error must be generated. The reporting of these errors obeys the P-Mode.errorHandling." At the end of 8.2.2 (Reliability section) add: "Messages that have eb:CollaborationInfo/eb:Service set to “urn:oasis:names:tc:ebxml-msg:service” are not intended to be delivered (Deliver) to an MSH Consumer, although they may be submitted by an MSH Producer. They are intended for internal MSH consumption. They may also be subject to reliability contracts. In this case, the at-least-once contract is fulfilled with a successful RM-delivery. In case of at-least-once delivery, a failure do deliver must cause the generation of a delivery failure Error. If this message was submitted or initiated by an MSH Producer (Submit) instead of the MSH itself (e.g. a Ping initiated by the Producer), the Producer may be notified (Notify) of the failure depending on the reporting mode, as for regular user messages." Also, in 8.1, L2822, replace "may be subject" with "is subject". STATUS: Correction by author. EDIT: Ready for inclusion review draft. ----------------------------- Error section: --------------------- 12) - Add 1 error EBMS:0010 "ProcessingModeMismatch", severity: failure, category: Processing "the ebMS header is not compatible with expected content based on the associated P-Mode." - in Reliability errors, Add 1 error EBMS:0201 "DysfunctionalReliability" severity: failure, category: Processing "some reliability function as implemented by the Reliability module, is not operational, or the reliability state associated with this message sequence is not valid." - renumber the error code for "DeliveryFailure"as: EBMS:0202 (instad of 0010) - renumber the error code for "Failed Authentication" as: EBMS:0101 (instad of 0011) STATUS: Correction by author. Renumbering is editorial. The new errors are to be discussed. EDIT: ------------------------------------------------------------------ 13) Section 2.2.2.1: reword: The response message, in case a two-way underlying protocol is used: (a) may contain a SOAP envelope with a SOAP body that is always empty, in which case the One-way MEP is qualified as "composable". (b) may contain a SOAP envelope with a SOAP body that is either empty or contains a SOAP Fault. In that case the MEP is qualified as "fault supporting" in addition to being composable. (c) may never contain a SOAP envelope, in which case the SOAP One-way MEP is qualified as “strict”. STATUS: Correction by author. EDIT: Ready for inclusion review draft. ------------------------------------------------------------------ 14) Section 4.1: reword as: "...ways with another MSH, engaging in a client-server type of interaction with the remote MSH, without any need to open a port to incoming requests. This MEP also supports exchanges with a partner that is intermittently connected: instead of periodically polling for partner presence, a sending MSH will simply wait for the partner MSH to pull messages." Example: A mobile, occasionally connected device without static IP address and with limited storage capability can only initiate requests and receive messages as synchronous responses to these. The One-way Pull MEP allows this device to enable and control the flow of received messages, and to adjust it to its own resources. L752: "...without a need to transfer filter expressions. " --> "...without a need to transfer and process filter expressions. " STATUS: Correction by author. EDIT: Ready for inclusion review draft. -------------------- Operation COntext --> P-Mode ---------------- 15) Section 2.4.3: "...This is done by sharing the message pipes operation context (see OpCtx_MessagePipes in Section 3)." replace with: "...This is done by sharing the message pipes processing mode feature (see P-Mode.messagePipes in Section 3)." Section 5.2.9: "... AgreementRef is a string value that identifies the operation context that governs the exchange. The recipient of a message MUST be able to resolve the AgreementRef to this operation context, or to the related agreement between the Sending and Receiving parties." replace with: "... AgreementRef is a string value that identifies the agreement that governs the exchange. The P-Mode under which the MSH operates for this message MUST be aligned with this agreement." Section 7: "... Error generation and error reporting are treated here as orthogonal concepts. Some aspects of error handling - in particular, reporting - are best specified within the operation context for error handling (OpCtx-ErrorHandling) e.g. as resulting from an agreement." replace with: "... Error generation and error reporting are treated here as orthogonal concepts. While the generation of errors is a matter of conformance, the reporting of errors may be subject to an agreement. Consequently, the way errors are to be reported is specified in the P-Mode (P-Mode.errorHandling feature) that results from such an agreement." Section 7.5: "... Except for some cases defined in this specification, Error escalation policies are left to an agreement between users, represented in the operation context of an MSH ( OpCtx-ErrorHandling)." replace with: "... Except for some cases defined in this specification, Error escalation policies are left to an agreement between users, represented in the processing mode of an MSH ( P-Mode.errorHandling )." Section 7.7.1: EBMS:0003 : replace operationn context with "processing mode" Section 8.1 (end): "... Note that depending on the reliability operation context (OpCtx-Reliability), notification of delivery failure may be detected on either side." replace with: "... Note that depending on the reliability processing mode (P-Mode.reliability), awareness of delivery failure may occur on either side." STATUS: Editorial effect of replacing Section 3. Follows from agreement on (8) EDIT: Ready for inclusion review draft ------------------------- ---------------- 16) Section 10 "Reliability Protocol Bindings" Replace: "It is not the intent of ebMS to open too many options, but the case of reliability is a particular one, as each one of the two OASIS reliability specifications has strong arguments in its favor." with: "Although either one of the above OASIS reliability specifications is sufficient, each one has strong arguments in favor of its use." In 10.1.3: in the table: ".. two additional requirements MUST be satisfied" only the two first bullets apply, bullet 3 should not be part of this sublist. In 10.1.4: in the table: ".. two additional requirements MUST be satisfied" The two conditions should be singled out , e.g. with dashes or bullets. STATUS: Correction by author. EDIT: Ready for inclusion review draft. --------------------------------------------- 17) Insert COnformance Appendix, latest update (Feb 14). STATUS: 3rd iteration, latest updates to be discussed. EDIT: Ready for inclusion review draft. --------------------------------------------- 18) Insert SOAP 1.2 binding Appendix. Remove previous Appendix 11. STATUS: SOAP 1.2 latest agreed. Appendix 11 removal to be discussed / confirmed. no general objection. EDIT: ? --------------------------------------------- 19) Security Module (Section 6.3) security of attachments WSS1.0 vs WSS 1.1 STATUS: Proposal to handle this by a new COnformance profile (Level 2) in Part1. Linked to Issue 17. EDIT: Need to describe both WSS 1.0 and WSS 1.1 + WSS-SWA options. --------------------------------------------- 20) Update the packaging figures Section 5 (fig 7 and 8) - remove StatusRequest / Response signals. STATUS: Need concrete proposal EDIT: ------------------------------------------ 21) Section 10.2.1: WS-RM binding: should specify that: - RM QoS applies to an entire sequence, and is communicated in the CS extension point. (need to decide of a format for interoperability ! propose a default, can be override in P-Mode ?) STATUS: Need discussion, concrete proposal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]