OASIS Reliable Messaging TC Issues List

Last update: 01 Sept 2004

Issues regarding the documents produced by the OASIS Reliable Messaging TC should be reported to wsrm-comment@lists.oasis-open.org (public archives).

Comments on this issues list should be sent to the wsrm@lists.oasis-open.org mailing list (Archives).

Comments on documents contributed by members of this TC should be sent to the wsrm@lists.oasis-open.org mailing list (Archives).

Summary List of Outstanding Issues

idTitleStatusSpecTopicClassSection

Detailed List of Issues

idSpecSectionTopicClassStatusRaised ByOwner
PC1.1 Spec Editorial Closed Sunil Kunisetty
Title: line 760
Description: Replace the lines 760-764 with the following: For ordered messages, the Sender MUST include this attribute in the first message and its value MUST be "Start". Subsequent messages in the group, except the last, MAY include this attribute and if it is included, MUST have "Continue" as its value. The group may be ended by denoting the last message in the group as the last one by including this attribute with a value "End". A group may also be ended using group termination parameters. When this attribute is omitted, the default value of this attribute is "Continue".
Proposal: Accommodated by new text from Sunil/Jacques action item which eliminates START value
Resolution: Accomodated by PC5.2
PC1.2 Spec Editorial Closed Sunil Kunisetty
Title: line 507
Description:
Proposal: Replace lines 507 - 513 with the following: If the RMP sending a Reliable Message does not receive an Acknowledgment or a Fault for a sent message that has not yet expired, then the Sender MAY either Poll the Receiver for the status of that message or MAY resend the same message with same Message Id as long as it is not expired (i.e. ExpiryTime is not passed).
Resolution: Proposal incorporated in .992
PC1.3 Spec Editorial Closed Jacqeus Durand
Title:
Description: 1) For those messages that have neither been delivered (Acked) or been Faulted at the time a PollRequest is received, the doc is not clear on what should be done in the response element. The text seems contradictory: implies that a response element will simply not say anything about such messages (Section 4.4.2.1, and also Example 3 ), but also that all messages MUST be replied (4.3.1).
Proposal: 4.3.1 L883 replace: "...MUST send back all RM-replies for the messages received in the MessageId" with: "...MUST send back RM-replies for non-expired messages that were either delivered or faulted in that message range" L886: replace: "...MUST return RM-reply for messages received..." with : "... MUST return RM-rplies for non-expired delivered or fault messages for messages received ..."
Resolution: proposal incorporated into draft .993
PC1.4 Spec Editorial Closed Jacques Durand
Title: line 845
Description: Change to _determine status_
Proposal: L845 (section 4.3) replace: "...to determine non-expired messages which have been delivered." with: "...to determine the status of non-expired messages."
Resolution: proposal put in .995 but sentence removed in .996 with refactoring
PC1.5 Spec Editorial Closed Jacques Durand
Title: status of expired message
Description: 2) It will not be technically possible to provide status for any past message, especially if they have expired. Proposal: A Receiver should only be required to send Acks (and Faults) for messages that have not expired yet. So a Response is exempt from reporting on expired messages.
Proposal: No change required, already clearly stated in document
Resolution: no change required
PC1.6 Spec Editorial Closed Jacques Durand
Title: fixed retry interval not always appropriate
Description: 3) The RetryTimeInterval RM agreement item, as described in 3.1 (Line512) is specifying the interval between two retries. A fixed interval may not be appropriate, and a more dynamic one may be better, and may be dynamically adjusted based on context of operations. Plus, this resending technique does not really make sense when using PollRequest: we would expect the Sender to only resend *after* doing the PollRequest (which may be done for several messages). The spec is mute on what should be the resending policy in that case. frequently for a [group of] particular messages.
Proposal: Accommodated by Jacques Action item to remove resend parms Agreed to remove these resend parameters from spec.
Resolution: accom by PC8.1 resolution
PC2.1 Spec Editorial Closed Sunil Kunisetty
Title: sender vs sending RMP
Description: While mostly we use the words Sender or Receiver RMP, there are occurrences of Sending and Receiving RMP terms. We need to be consistent.
Proposal: Had Agreed to change sending to sender and receiving to receiver as a qualification of RMP. This was implemented in .993 Editor_s draft.. This was overridden by 7.3 resolution which chose _receiving_ and _sending_.
Resolution: Superceded by Resolution to PC7.3
PC2.2 Spec Editorial Closed Sunil Kunisetty
Title: lne 1122
Description: The lines 1122-1125 needs rewording
Proposal: section 5.1.2 _ last sentence first para: and first sentence of second para change to: "These two items can be considered as Group Termination parameters that control the persistence of the group data. The corresponding message header attributes are groupExpiryTime and groupMaxIdleDuration respectively"
Resolution: proposal included in draft .995
PC2.3 Spec Editorial Closed Sunil Kunisetty
Title: line 1135
Description:
Proposal: Line 1135: We don't have InvalidGroupParameter fault. It should be replaced with InvalidMessageParameters fault.
Resolution: proposal included in draft .993
PC2.4 Spec Editorial Closed Sunil Kunisetty
Title: line 1136
Description:
Proposal: Line 1136: Uppercase MUST
Resolution: proposal included in draft .993
PC2.5 Spec Editorial Closed Sunil Kunisetty
Title: line 1148
Description: Line 1148: Lowercase 'c' in criteria Line 1181: clarify that both parameters may not be present
Proposal: Section 5.1.2 _ last sentence Line 1148: change _C_ to Lowercase 'c' in criteria subcase T.3.1 _ context, first sentence Line 1181: Change the sentence to. _The group had either groupExpiryTime or GroupMaxIdleDuration specified, but not both._
Resolution: accomodated by refactoring of text in .996
PC2.6line 1270 Spec Editorial Closed Sunil Kunisetty
Title:
Description:
Proposal: Line 1270: Reword as following: Guaranteed Delivery will be most commonly used for request message for WSDL one-way operation as the Sender does not know the status of the message delivery otherwise.
Resolution: proposal included in draft .995
PC2.7 Spec Editorial Closed Sunil Kunisetty
Title: line 1277
Description:
Proposal: Line 1277: Uppercase P in Poll
Resolution: in draft .993
PC2.8 Spec Editorial Closed Sunil Kunisetty
Title: line 1278
Description:
Proposal: Line 1278: Replace is with has as in "for a message it has to inquire".
Resolution: proposal included in draft .993
PC2.9 Spec Editorial Closed Sunil Kunisetty
Title: line 1279
Description:
Proposal: Line 1279: Replace acknowledgment with RM-Reply
Resolution: proposal incorporated in draft .993
PC2.10 Spec Editorial Closed Sunil Kunisetty
Title: line 1280
Description:
Proposal: Line 1280: Replace acknowledgments with RM-Replies
Resolution: proposal included in draft .993
PC2.11 Spec Editorial Closed Sunil Kunisetty
Title: line 1329
Description:
Proposal: Line 1329: Response pattern MUST not have replyTo attribute.
Resolution: Proposal included in draft .993
PC2.12 Spec Editorial Closed Sunil Kunisetty
Title: no contents
Description: Term _no contents_ needs clarification
Proposal: Line 1371, 1375, 1447: Agreed to replace _no contents_ with _no HTTP message body_ in lines 1371, 1375 and 1447
Resolution: proposal included in draft .993
PC2.13 Spec Editorial Closed Sunil Kunisetty
Title: two ways to respond to poll
Description: Line 1439: We need to have 2 sub-sections: one for the sync. Poll response case and other for async. Poll response..
Proposal: Figure 9 can be used for the former. For the latter, line (4) should be shown as HTTP request. The example for Async. Poll request will take a replyTo attribute Sunil given action item to have two subsections for 6.3.
Resolution: accomodated by resolution to PC5.1
PC3.1 Spec Editorial Closed Jun Tatemura
Title: fault for missing messageID
Description: How the receiver RMP can return InvalidPollRequest fault in a Response element when a PollRequest message does not have MessageId?
Proposal: Action item to Jun and Sunil to provide replacement text
Resolution: accomodated by reslution to PC 5.3
PC3.2 Spec Editorial Closed Jun Tatemura
Title: groupID reuse
Description: The receiver can forget previous group IDs after group state removal but the sender MUST NOT reuse group IDs. The spec shuold explicitly note about the sender side here. One engineer thought the sender could re-open a group
Proposal: Accomodated by Jacques proposal for 4.1 clarification
Resolution: accomdated by resolution to PC4.1
PC3.3 Spec Editorial Closed Jun Tatemura
Title: use of term group complete
Description: It should be explicitly noted that receiving "status=end" does not mean "Group Closing."
Proposal: In (t3)(t4), the spec uses another terminology "complete," which also confuses readers. For the receiver side group closing, we can define two categories: (a) group completion: the receiver RMP received all messages from start to end. (b) group timeout: (b1) the receiver RMP observes that groupExpiryTime specified is over or (b2) the receiver RMP observes that groupMaxDuration specified is over. Once we define these at the first time, termination rules would be much simpler and easier to understand Accommodated by Jacques proposal for 4.1 Clarification
Resolution: accomodated by resolution to PC4.1
PC3.4 Spec Editorial Closed Jun Tatemura
Title: when to update groupExpiryTime at receiver
Description: It is not clear that when the spec states "groupExpryTime is over" in the sender side, which groupExpiryTime is observed by the sender. Is it based on the last message the sender sent? Or the last message for which the sender received ack? In fact, either cases are okay for reliable messaging. But this ambiguity confuses readers
Proposal: Clarified by resolution to PC4.1
Resolution: accomodated by resolution to PC4.1
PC3.5 Spec Editorial Closed Jun Tatemura
Title: receiver vs receiving
Description: Line 548 Section 3.3 _the receiver's RMP_ must be _the receiver RMP_
Proposal: agreed to use receiving rmp throughout. accomodated by resolution to PC7.3
Resolution: accomodated by resolution to PC 7.3
PC3.6 Spec Editorial Closed Jun Tatemura
Title: line 701
Description:
Proposal: Section 4.2.1.1 (l.701-703) "the receiver of the message MUST make messages available to the application layer only after all messages with the same groupId value and a lower number value have been made available to the application." must be "the receiver RMP MUST NOT deliver the message until all messages with the same groupId value and a lower number value have been delivered."
Resolution: proposal incorporated in draft .993
PC3.7 Spec Editorial Closed Jun Tatemura
Title: table 3
Description:
Proposal: Section 4.2.1.1 Table 3 Remove "See 3.1.2 for details", since there is no section such as 3.1.2
Resolution: proposal incorporated in draft .993
PC3.8 Spec Editorial Closed Jun Tatemura
Title: 4.2.1.1
Description: 4.2.1.1 (ll.763-767) When an application is .... This discussion should not be done in 4.2.1.1(4). This part should be moved to somewhere in 3.3 or totally removed.
Proposal: Section 4.2.1.1 (l.763-767) Remove "When an application is ....", since this discussion should not be done in 4.2.1.1 (4).
Resolution: proposal included in draft .993
PC3.9 Spec Editorial Closed Sunil Kunisetty
Title: line 846
Description:
Proposal: Section 4.3 (l.846) "notSupportedFeature" must be "NotSupportedFeature"
Resolution: proposal included in draft .993
PC3.10 Spec Editorial Closed Jun Tatemura
Title: sent vs thrown
Description: Section 4.5.2 (l.1052 and Table 17) Faults are somtimes "thrown" and sometimes "sent."
Proposal: For consistent use of terminology, a fault should be "sent." Agreed to use _sent_ throughout document
Resolution: proposal included in .993
PC3.11 Spec Editorial Closed Jun Tatemura
Title: clarify terminatio rules
Description: 5.1.2 (l.1133) > termination rules t1, t2 or t3 described below should be > termination rules t1, t2, t3, or t5 described below since t5 is applied even when a group persistence parameter is present. 5.1.3 (3) (ll.1021-1202) Even in case of subcase 3.2, the state can become subcase 3.1 by receiving missing message before reaching states t1 or t2. The sentence could be something like "Then the Receiver RMP MUST apply termination rules of (t1) or (t2) or apply termination rule of (t3.1) after all message have been delivered"
Proposal: accomodated by text for PC4.1
Resolution: accomodated by resolution to PC4.1
PC3.12 Spec Editorial Closed Alan Weissberger
Title: relation to other specs
Description: Section 1.4 Relation to Other Specs On line 144 it says that WS Reliability can be used with WS Security-WSS (which I think has now been completed in OASIS and a BSP working draft is available from WS-I). How?
Proposal: Accommodated by future work on architecture/overview document. This new document could explain how reply patterns, configuration parameters, protocol capabilities work with each WSS message type.
Resolution: accomodated by resolution to PC 3.19
PC3.13 Spec Editorial Closed Alan Weissberger
Title: changing agreements
Description: Section 1.7.2 RM Agreement Items: Setting, conveying, or changing the Agreement items listed here, is beyond the scope of this specification
Proposal: accomodated by clarifications in PC8.1 proposal
Resolution: accomodated by PC8.1 resolution
PC3.14 Spec Editorial Closed Alan Weissberger
Title: Not Supported Feature Fault condition
Description: Line 408-406: If a reply pattern is sent that had not been previously agreed upon, it will be rejected, with a Fault message: Non Supported Feature returned to the sender Alan suggested: MUST BE
Proposal: the text regarding send for faults should be stated in a general manner to accommodate polling or delayed callback. A single section to explain what _sending a fault_ means. Agreed at 5/18 meeting that statements of when faults MUST be send should be left for profile activities.
Resolution: Did not agree to add condition for MUST return fault. Text was clarified in .997 draft regarding publishing faults
PC3.15 Spec Editorial Closed Alan Weissberger
Title: scope of agreement items
Description: Section 1.7.3 Messaging Scope of Agreement items: For all scopes: Setting, conveying, or changing the Agreement items listed here, is beyond the scope of this specification
Proposal: Need clarification: Are the values for retry parameters in message scope (s3) and/or Group scope (s2) related to a particular Reply pattern or are the values the same for ALL Reply patterns over the same binding/ transport connection between sender and receiver? Accommodated by proposal to remove retry parameters.
Resolution: accomodated by resolution to PC8.1
PC3.16 Spec Editorial Closed Alan Weissberger
Title: abort delivery
Description: Section 3.3. Guaranteed Message Ordering Failure Case Line 563-565: Is the decision to abort ordered delivery totally implementation dependent? Can we specify a Maximum Persistance time parameter for a received out of order message, so that after that time receiver aborts ordered delivery. Otherwise, a skimpy implementation could give up almost immediately vs a robust implementation trying to recover for a much longer time after receiving multiple out of order messages without receiving any retransmitted sequential messages
Proposal: Jacques took action item to propose clarification about faults for aborted ordered delivery
Resolution: accomodated by resolution to PC 8.1
PC3.17 Spec Editorial Closed Alan Weissberger
Title: can grop expiry time change
Description: Line 726: groupExpiry Time attribute: Clarification: No mention whether this parameter can be changed. Suggest forward reference to line 1148- 1149. 6. Line 1148- 1149
Proposal: Suggest reference to appropriate section Add the following to both groupexpiryTime and groupMaxIdleTime definitinons in 4.2.1.1 _Constraints on allowd values for this attribute are specified in section 5.
Resolution: Proposal included in draft .995
PC3.18 Spec Editorial Closed Alan Weissberger
Title: group expiry vs message expiry
Description: Line 1148- 1149 d) changing Group Expiry time It would be most helpful to provide 2 examples illustrating the change of Group Expiry time when sending sequential messages: -one correct/ permitted change; the other incorrect (decremented below Max Value of Expiry time)
Proposal: Clarification: What is the relationship between Expiry time (section 4.2.2) and Group Expiry time (line 726), i.e. why are they dependent here? While Group Expiry time can be modified, Expiry time (only sent in Request messages) can not be modified. I always thought that Expiry time was sent in a single Request message while Group Expiry time was sent in each sequential Reply message of a Group. In other words, they would never be sent in same direction This clarification is accommodated by Jacques clarification of section 5.1
Resolution: accom by resolution to PC4.1
PC3.19 Spec Editorial Closed Alan Weissberger
Title: need implementers guide
Description: Suggestion: WSRM TC should consider producing a new document: An Implementors/ Users Guide to WS Reliability.
Proposal: Alan: suggest we work on two new documents while maintaining the ws-reliability spec: _ First document - Users Guide _ Second document describes relationship of ws-reliability to other ws standards. These would better explain how to use the protocol features, tips on setting and conveying configuration parameters, and how WS Reliability would communicate with WS Applications via platform neutral APIs Jacques: Not clear to me that we need these to be two separate specs.
Resolution: no changes to spec, will work on informative document
PC4.1 Spec Editorial Closed Jacques Durand
Title: clarify terminatio rules
Description:
Proposal: Whole Section 5.1 was updated with the document JacquesProposal
Resolution: proposal included in draft .993
PC5.1 Spec Editorial Closed Sunil Kunisetty
Title: fix section 6.3 for both poll response types
Description:
Proposal: action033004-2
Resolution: proposal included in draft .996
PC5.2 Spec Editorial Closed Sunil Kunisetty
Title: Start value is redundant
Description: Jacques and Sunil action item to remove START value
Proposal: detailed updates entailed by removing @status
Resolution: proposal included in draft .993
PC5.3 Spec Editorial Closed Sunil Kunisetty and Jun Tatemura
Title: clarify missingID fault case
Description: Jun and Sunil action item
Proposal: actionItem040404-2
Resolution: proposal included in draft .993
PC6.1 Spec Editorial Closed W3C XMLP group thru Pete Wenzel
Title: normative vs non normative references
Description: 1. Examples throughout the specification are inconsistent with its normative reference to SOAP 1.2 (Line 1547) and non-normative reference to SOAP 1.1 (Line 1573). The examples should conform to a normative syntax
Proposal: Jeff Moved to collapse the two reference sections into one, Iwasa seconded. Call it References. No opposition to the motion. Motion passes.
Resolution: proposal included in draft .995
PC6.2 Spec Editorial Closed W3C XMLP group thru Pete Wenzel
Title: relationship to SOAP processing model
Description: 2. The relationship of Reliable Messaging Processor (Lines 278-281) to the SOAP processing model requires definition. Statements that the RMP is a "module" that exposes "submit", "notify" and "deliver" operations directly to an application imply a layered processing approach, which is not explicitly defined. Also, the SOAP term "node" is used in several instances where possibly "RMP" is meant, which contributes to the lack of clarity.
Proposal: Pete proposed the following additional changes (based on WD 0.996) to close this issue. _ 1.1 WS-Reliability is a SOAP Module (as defined by [SOAP 1.2]), which fulfills reliable messaging requirements that are critical in some applications of Web Services. SOAP ([SOAP 1.1] and [SOAP 1.2]) over HTTP [RFC2616] is not sufficient when an application-level messaging protocol must also guarantee some level of reliability and security.... _ [Continue with remaining text as-is.] 1.2 [Change first paragraph to:] _ Reliable Messaging (RM) is the execution of a transport-agnostic protocol based on SOAP for providing quality of service in the reliable delivery of messages. _ [Continue with remaining paragraphs.] [Replace these two definitions:] _ 1.6 Reliable Messaging (RM): The act of processing the set of transport-agnostic SOAP Features defined by WS-Reliability, resulting in a protocol which guarantees certain qualities of service. This includes the processing of Acknowledgment indications, re-sending of messages, duplicate message elimination, and message ordering. _ _ Reliable Messaging Processor (RMP): A SOAP Node (as defined by [SOAP 1.2]), or a subset or superset thereof, capable of performing Reliable Messaging as described by this specification. With regard to the transmission of a Reliable Message from one RMP to another, the former will be referred to as the Sending RMP, and the latter as the Receiving RMP. _ --Pete Pete moved to close the issue with accepting the proposed text with amendments above. Jacques seconded. No opposition, motion passes.
Resolution: proposal in draft .998
PC7.1 Spec Editorial Closed Pete Wenzel
Title: targeting headers
Description: Line 98: Says "This specification addresses end-to-end reliability, and is not concerned with intermediaries." However, there is nothing to prevent someone targeting Reliability headers to "next" role/actor. This case should be explicitly forbidden, rather than left undefined.
Proposal: Concerns expressed by Peter Furniss. RE: [wsrm] Comments on WS-Reliability CD 0.992 From Jacques Durand on 5 May 2004 19:31:28 -0000 Title: about "next" role/actor Should we say anything about the use of "next" role/actor on RM headers? The use of "next" seems inappropriate in general, as our model ignores intermediaries. However I would not forbid this: after all, the receiving party may have deployed several SOAP nodes to process incoming messages, the first one being supposed to handle reliability. So this may be a topology that is assumed between sender and receiver, even if an unlikely one. (E.g. we could imagine that there is a reliability contract between each pair of intermediaries.) Jacques Proposal: warn that reliability headers should not be targeted to SOAP intermediaries, unless it is the intent that the reliability contract precisely ends at the first intermediary.
Resolution: Agreed at 5/11 Teleconference that no change is required.
PC7.2 Spec Editorial Closed Pete Wenzel
Title: reuse of namespace prefix
Description: Lines 129, 1620: Reuse of "wsrm" prefix for different namespaces is confusing. Choose a different one for the feature namespace in the appendix
Proposal: Pete moved to change the namespace qualifier in appendix to wsrmf, Doug B seconded. No opposition, motion passes.
Resolution: proposed resolution included in draft .996
PC7.3 Spec Editorial Closed Pete Wenzel
Title: line 134 of .993
Description: needs clarification
Proposal: Line 134: Change "This specification defines reliable messaging protocol embedded in the SOAP Header." to "This specification defines reliable messaging protocol features, expressed as extension header blocks embedded in the SOAP Header."
Resolution: proposal include in draft .995
PC7.4 Spec Editorial Closed Pete Wenzel
Title: ws security title
Description: Line 140 Use official name of the standard. Its title must be "WS-Security 2004", not just "WS-Security", to avoid confusion with prior incarnations. Remove the last sentence of this paragraph, which is already obsolete
Proposal: Line 140: Agreed to use the official reference for WS-Security "WS-Security 2004" Delete Last sentence of para.
Resolution: proposal included in draft .995
PC7.5 Spec Editorial Closed Pete Wenzel
Title: ws-security reference
Description: Line 1581 _ Fix WS-Security reference
Proposal: Line 1581, reference should be: [WSS] "OASIS Web Services Security: SOAP Message Security 1.0 (WS-Security 2004)". Available at ...
Resolution: proposal included in draft .995
PC7.6 Spec Editorial Closed Pete Wenzel
Title: early examples
Description: Section 1.5: Examples are placed in an awkward location. Should appear after the protocol and features are described. Suggest moving them to a non-normative appendix
Proposal: Agreement to move examples to a later section or annex of the document, position to be determined. Examples were moved to directly after where each header element is defined.
Resolution: proposal included in draft .996
PC7.7 Spec Editorial Closed Pete Wenzel
Title: line 279 of .993
Description: Line 279: Change "A module capable of processing and enforcing Reliable Messaging as described in this specification." to "A SOAP Processor capable of processing Reliable Messaging SOAP header blocks."
Proposal: To resolve with XMLP comment 2.
Resolution: accomodated by resolution to PC6.2
PC7.8 Spec Editorial Closed Pete Wenzel
Title: receiving vs receiver
Description: Line 281, 317 (and throughout document): Prefer the more grammatical forms "Sending RMP"/"Receiving RMP" rather than "Sender RMP" and "Receiver RMP".
Proposal: Pete moves to change _sender rmp_ with _sending rmp_ and _receiver rmp_ with receiving rmp_ Jacques seconded. No opposition motion passes. This requires a change to .993 which implemented opposite choice for resolution of same problem. Replace instances where just "sender"/"receiver" are used, to be more specific that we are referring to a sending or receiving RMP.
Resolution: proposal include in draft .995
PC7.9 Spec Editorial Closed Pete Wenzel
Title: sequence number not a feature
Description: 569: Sequence Number is not a Feature; it is simply a mechanism used to Implement Guaranteed Message Ordering. Should not be given equal status to the other 3 features
Proposal: Defer to the general document restructuring exercise. Jacques took an action on where to move the current section 3.4, with perhaps a re-title of section 3. Jacques will also propose a new document structure to accommodate this and other problems he encounters. Done
Resolution: proposal included in draft .996
PC7.10 Spec Editorial Closed Pete Wenzel
Title: need for soap fault for request/response unclear
Description: 1025-1030: Example in which SOAP Fault may also convey an RM Acknowledgment requires a confusing or impossible processing order. (Process RM headers, remember that an Ack needs to be sent, continue with header processing and SOAP Body validation and finally "application processing space outside the realm of the receiving RMP".) How does the RMP know when all processing has been completed, then intercept a possible SOAP Fault in order to attach its Ack?
Proposal: Re: [wsrm] response to action item to clarify soap faults and WSRMresponses Jacques took action item to incorporate the latest proposal from Tom and Pete, above into a new section on request/response. Replacement text provided by Jacques
Resolution: proposal incorporated into draft .996
PC7.11 Spec Editorial Closed Pete Wenzel
Title: anex D not needed
Description: 1990: Remove appendix if there is nothing to say here; the sole item listed is already done (App A)
Proposal: Agreed to delete appendix D futures list
Resolution: proposal included in draft .995
PC7.12 Spec Editorial Closed Pete Wenzel
Title: no reference to normative schema
Description: The specification contains no reference to the schemas.
Proposal: The two schemas should be listed in the normative appendix, and introduced at an appropriate location in the text, perhaps at the beginning of Section 4 Agreed to have a new normative appendix which points at the schema URL. It also has to have the precedence statement copied from the schema. At publication time the OASIS staff can decide to place the actual schema text.
Resolution: proposal in draft .998
PC7.13 Spec Editorial Closed Pete Wenzel
Title: editorial corrections
Description:
Proposal: 269: Remove line break in the middle of "response". 501: "the Sender RMP notifies a delivery failure" should be "the Sending RMP is notified of a delivery failure". 522: "an" should be "a". 526: "nor to notify failure on the sender side" should be "nor to notify the RMP Sender of the failure". 527: "it's" should be "its". Schemas: "it's" (in comment blocks) should be "its".
Resolution: Proposed text changes accomodated by Jacques clarificaigton edits in .997. Schema changed to "its" on 5/04
PC8 Spec Editorial Closed Martin Chapman
Title: Agreements section needs clarification
Description: Fwd: Comments on WS-Reliabilty CD 992 Agreements section is in wrong place and needs to be clarified.
Proposal: The result of an email dialogue between Jacques and Martin can be found at: JacquesMartinDialogue Jacques took action item to clarify agreements and to address all of Martin's editorial concerns
Resolution: accomodated by Resolution to PC 9.3
PC9.1 Spec Editorial Closed Sunil Kunisetty and Jacques Durand
Title: Remove Retry Parameters
Description: Action item on Jacques and Sunil to provide text necessary to remove retry parameters from normative tex.
Proposal: reworded section on agreements
Resolution: proposal incorporated in draft .996
PC9.2 Spec Editorial Closed Alan Weissberger and Jacques Durand
Title: aborted sequence fault code
Description: action item on Jacques and Alan to add text for fault on group abort
Proposal: action item output at: treatment of aborted out-of-order seq GroupAborted fault code added, but text stating _MUST send_ was not added Agreed at 5/11 meeting to not make statements about when a fault MUST be sent. These should be left for profile specifications.
Resolution: new processing fault includded in Draft .996 " GroupAborted: All processing for the groupID associated with the reliable message request has been aborted by the Receiving RMP. No subsequent messages within that group will be delivered by the Receiving RMP. "
PC9.3 Spec Editorial Closed Jacques Durand
Title: Refactor text for readability
Description:
Proposal: Jacques propoed changes were edited directly into draft .996
Resolution: Proposed changes in draft .996
PC10 Spec Editorial Closed Sunil Kunisetty
Title: various edits
Description: SunilEditorialComments
Proposal: accept all non controversial editorial comments. any comment which required discussion has had its own issue generated
Resolution: all agreed editorial correctios incopporated into draft .995
PC10.3 Spec Editorial Closed Sunil Kunisetty
Title: callbacks
Description: For Callbacks, response POST context URI doesn_t match the replyTo URI in the request agreed editorial change
Proposal: change the callback example to match the reply to URI in the request example. In all callback examples, have the post context URI (eg, /xyz/servlet/wsrListener in example 15 of draft .997) match the replyTo uri (e.g., /wsr-sender.org/abc/wsrListnener"
Resolution: proposal in draft .998
PC10.14 Spec Editorial Closed Sunil Kunisetty
Title: first can be last
Description: We also need to mention that the first message in the group can also have this attribute with a value _true_, i.e., to indicate the first message in the group is also the last message, something similar to a singleton message
Proposal: Jacques it does not hurt to have a guideline document. As I do my action item for the document reorg, I will put any such removed guidance text into a preliminary cut at the implementers guide. And will place Sunil_s sentence above with that text
Resolution: accomodated by resolution to PC9.3
PC11 Spec Editorial Closed Tony Graham
Title: Tony Graham Editorial Scrub
Description: Editorial comments on 0.993 /
Proposal: Iwasa given action item to apply all non controversial edits, an to idenfy a new issue for each which need further discussion
Resolution: agreed edits are in draft .995, items needing further discussion have their own issue for resoultion
PC11.5 Spec Editorial Closed Tony Graham
Title: section 1.3 notiation conventions
Description: section 1.5 - xml declarations in example
Proposal: It was agreed at the 5/18 meeting to remove the XML Declarations since they are unnecessary.
Resolution: Removed XML Declarations in examples , done in draft .998
PC11.6 Spec Editorial Closed Tony Graham
Title: line 178 of .993
Description: section 1.5 line 178 Change "wsr-example.org" to "wsr.example.org" or "example.org/wsr" to properly use the "example.org" example domain name.
Proposal: Agreed at 5/11 meeting to use "example.org/wsr"
Resolution: changed to "example.org/wsr" in draft .998
PC11.9 Spec Editorial Closed Tony Graham
Title: Lines 229, 260, 262 of .993
Description: Use 'straight' quotes instead of 'smart' quotes around attribute values.
Proposal: Kept them as-is for consistency with example1 ,2 and 3
Resolution: all Smart Quotes were removed in draft .998.
PC11.11 Spec Editorial Closed Tony Graham
Title: Section 1.6 line 288, 304
Description: Why must the time be identifiable? Why is it not sufficient to just preserve the order of submissions, e.g., in a queue?
Proposal: Proposal: replacing _The time_ with _The order_
Resolution: Proposal agreed at 5/18 meeting, done in draft .998
PC11.13 Spec Editorial Closed Tony Graham
Title: Line 316, 317, 319 Acknolwedgement Message
Description: "Acknowledgment messages" are not defined. There are now only "Acknowledgment indications".
Proposal: The following lines in draft .996 need to change Acknowledgement message or fault message to acknowledgment indication or rm-fault indication.: 229, 230, 232, 264,633, 661, 662, 813, 814, 661, 662, 823, 825, 877, 1234, 1237, 1239, 1245, 1299, 1452, 1478, 1309, 1373, 1391
Resolution: Changed "message" to "indication" when used after the words acknowledgement or fault, in .998
PC11.14 Spec Editorial Closed Tony Graham
Title: line 329 of .993
Description: How can a "Reliable Messaging Fault Indication" signal a failure to receive a message when this specification "expects that the transport layer will not deliver a corrupted message" (line 1308) and there are no fault codes for non-delivery of messages?
Proposal: Agreed at 5/11 teleconf to change last sentencd of rm fault indication to the following: " It signals to the Sending RMP of the referred message that there was a failure to invoke the deliver operation for the message. " Last sentence was changed to "It signals a failure to deliver the referred message." in draft .997, however this still does not use the words "invoke the deliver operation for the message".
Resolution: proposal in draft .998
PC11.15 Spec Editorial Closed Tony Graham
Title: line 336 of .993
Description: A reply may now include multiple Acknowledgment Indications.
Proposal: Agreed at 5/25 meeting Lines 204-206 currently state: " Reliable Messaging Reply (RM-Reply): An indication referring to a previous message, that is either an Acknowledgment Indication or a Reliable Messaging Fault Indication. " Change the definition to: " An indication referring to a previous reliable message, that is either an Acknowledgement Indication or a Reliable Messaging Fault Indication. For the Callback and Poll reply patterns, RM-Reply indications for multiple reliable messages MAY be included in a single Reliable Messaging Response. "
Resolution: Agreed proposal included in draft .999
PC11.19 Spec Editorial Closed Tony Graham
Title: line 366 of .993
Description: "between the application layer, the sender and receiver RMPs" does not scan.
Proposal: I believe we shouldn_t mention RM is a contract between application and RMP. Reliable Messaging is for between Sending RMP and Receiving RMP only, but not application and RMP. We can_t guarantee the delivery to the application and should not do that when we don_t define neither protocol between RMP and application, nor RMP API. Even in the ordering case, we don_t guarantee the delivery of a message to the application, and it is completely appropriate. In conclusion, we should not say the RM agreement is an agreement between application and RMP. Sending RMP can_t and shouldn_t guarantee the delivery of a message to the application.
Resolution: Accomodated by the Editing by Jacques to remove "application Layer" from spec, in draft .997
PC11.20 Spec Editorial Closed Tony Graham
Title: Section 1.7.2, RM Agreement Items
Description: Line 388, 390, 392 Change "details" to "details.".
Proposal: agreed at 5/11 teleconf to add the missing "."
Resolution: Added missing periods "." in table 3 - rm agreement items in .998.
PC11.24 Spec Editorial Closed Tony Graham
Title: Section 3, Reliability Features
Description: "Business payload" is undefined. Line 499 Needs definition for Business payload or replacement text
Proposal: At 5/25 meeting Pete moved to remove prefix Business in front of payload wherever used, and, to define payload as: _information intended for the consumer of the reliable message_,
Resolution: accepted proposal included in draft 1.01
PC11.25 Spec Editorial Closed Tony Graham
Title: figure and table numbers
Description: Line 1263 Number the table and make this the title for the table.
Proposal: Table number, examples, Figures will be renumbered after restructuring of the spec
Resolution: proposal done in draft .998
PC12 Spec Editorial Closed Tom Rutt
Title: Two Schemas not required
Description: Two schemas and namespaces are unnecessary for two soap versions
Proposal: Do we really need a separate schema for soap 1.1 and soap 1.2 Agreed to have only one schema remove explicit soap must understand attribute. Also: Version number should be in the title of the document as version 1.1. on 5/25 the TC agreed to make the followoing changes to draft .999 Annex A _ lines 1562-1564: Change: _ When used with SOAP1.1, the SOAP1.1 mustUnderstand attribute MUST be present with value equal to 1 in all RM header blocks. When used with SOAP1.2, the SOAP1.2 mustUnderstand attribute MUST be present with value equal to 1 in all RM header blocks. _ to: _ The SOAP mustUnderstand attribute, from the same namespace as used for the soap:envelope element, MUST be present in all Reliable messaging specified header blocks, with the following restrictions: _ For SOAP 1.1 the must understand attribute value is restricted to _1_ . _ For SOAP 1.2, the must understand attribute value is restricted to _1_ or _true_. _ Then change, on lines 501 in 4.2, 725 in 4.3, and 820 in 4l4: _ SOAP mustUnderstand attribute with a value of _1_ _ to: _ SOAP must understand attribute, as specified in Appendix A. _
Resolution: full proposal completed in draft 1.01
PC13 Spec Editorial Closed Tom Ruttl
Title: HTTP POST Binding Clarification
Description: We need to clarifiy that the mandatory binding in the spec is to use htttp post. This is not stated clearly. In fact we need to clarify the exsting lines 1310, 1311, 1312 " (3) The Acknowledgment Message is sent with another HTTP connection from the Receiving RMP to the Sending RMP. Example 15 is an example of this message. (4) The HTTP response for (3) has no HTTP message body. Example 14 is an example for this HTTP Response. " to require an http post request. This clarification is needed, for interoperability, to avoid the use of http get when http post is expected.
Proposal: the following proposal was agreed at 5/25 meeting: Re: [wsrm] Action item 052504-4 - Clarification of HTTP Binding
Resolution: agreed proposal inclluded in draft 1.01
PC14 Spec Technical Closed Anish Karmarkar
Title: replyTo attribute extensibility
Description: For the poll and callback pattern WS-R has an attribute 'replyTo' of type xs:anyURI. The value of this attribute in the request message specifies the poll/callback location. This is problematic for the following reasons: AnishEmailMay04
Proposal: Agreed to change ReplyTo as an element with open content (any) for extensibility) with default restriction (in absence of other agreements) for HTTP POST Binding to be a URL for HTTP request
Resolution: Motion passed as 5/18 teleconf to accept the complete proposal for changes required in : Action 051104-9 (Anish) -- modified proposal for the 'replyTo' attribute with correction of URI for type schema in b) done in draft .998
PC15 Spec Editorial Closed Sunil Kunisetty
Title: Sunil editorial comments on .998
Description: Sunil editorial comments on draft .998
Proposal: Table 2(line 138) should also include the namespace for ServiceReferenceType schema.. Prefix: ref Namespace: http://www.oasis-open.org/committees/wsrm/schema/1.1/reference Agreed editorial, Iwasa should implement in next version Line 176/Definition of _Deliver_. I_m uncomfortable with the usage of the word _transfer_ in the definition of the _payload_. I prefer the words _makes available_. Proposed new definition: Transfers implies the consumer is ready. The word makes available. Pete: responsibility for the payload is transferred. Deliver: An abstract operation supported by the RMP. When invoked, the operation transfers the payload data of one reliable Message from the receiving RMP to the Payload Consumer (e.g., a request to the application layer to take responsibility for the Reliable Message). Sunil: Jacques : we should make the example more straight forward. Example (eg, the payload is placed into a queue by the receiving RMP). Or Sunil moved, Doug seconded to Change definition of deliver to: An abstract operation supported by the RMP. When invoked, the operation makes the payload of one reliable Message available to the Consumer (for example, in one specific implementation choice, the payload is placed into a queue by the receiving RMP to be consumed by an application component). No opposition, motion passes. Line 274 should be reworded to also cover the async. case. I believe I_ve mentioned this couple of times before. Proposal, change to the following _The RM-Reply can either be sent in underlying response of the request or sent as a different request._ Agree as editiorial change. Table 3/Line 309: Is ReplyTo to an agreement item? The schema on page 59 (line 1743) seem to include this, where as the table doesn_t reflect it. I believe it shouldn_t be there, and table content is correct. If so, we need to update the schema. Easiets fix is to delete A.V.D Reply to property and remove reply to from the schema in A.VI Sunil moved to delete _reply to_ property section A.V.D and to delete that property from schema. , Iwasa seconded. No opposition motion passes. Example 1 (pg. 17/line 510) still uses the old version of ReplyPattern type. Same thing with Example 3/Pg 23/Line 683. Should use the new ReplyPattern with Value sub-element. Same thing with Example 10. Agreed editorial fix. Appendix A: Please include links to the 2 new schemas (fnp.xsd for the F,P, and C constructs and wsrmf.xsd for WSRM properties). Agreed to Put in a table with four rows, on row per schema. Column 1 is namespace, and column 2 is a URL to the WSRM web page. Remove the schema A.VI. from the document. If it has to be included, it needs to be correct with the correct namespaces. Agreed to remove section A.VI from the document, already has been placed into a file. Examples A.VII.A, A.VII.C, and A.VII.D use _wsrmf:DuplicateElimination_ which should be replaced with _wsrmf:NoDuplicateDelivery_. Agreed editorial fix.
Resolution: proposal included in draft 1.01
PC16 Spec Editorial Closed Sunil Kunisetty
Title: Namespaces and Schema location
Description: Need to change namespaces of our schemata to be the same as URL for final location on OASIS server. Also, may need to revisit the use of version 1.1 in our namespace as a _direictory_. Oasis has given us a document directory http://docs.oasis-open.org/wsrm WS security followed the convention of year and month.
Proposal: Re: [wsrm] Action Item status as of 6/3/04 From Sunil Kunisetty All namespaces qualified with both year/month and filename with 1.1 included in name
Resolution: Proposal agreed at June 08 meeting, incorporated in draft 1.03
PC17 Spec Editorial Closed Pete Wenzel
Title: Pete Wenzel Editorial comments on .999
Description:
Proposal: Folowing agreed at 5/25 meeting: 1205-1206: This section describes the three binding pattern - "Response", "Callback", and "Poll" binding pattern for HTTP. These binding pattern is -> This section describes the HTTP bindings for the three message reply patterns - "Response", "Callback", and "Poll". These patterns are [Other uses of "binding pattern" throughout this chapter?] agreed to change "binding pattern" to "reply pattern" 1474: Insert new paragraph: It has implemented all required syntax, features and behaviors. other Editorial agreed changes: Table of Contents: Page numbers off by one beginning around Chapter 6. Can the ToC items be turned into hyperlinks for easier navigation? 105-106, 946-952: extraneous highlighting 240: extraneous hyphen 248: distinguishes two -> distinguishes between two 250: reliable -> reliability 254: derive -> are derived 270: to -> of 277: as different -> as a different 358: to initially have knowledge of the RM Agreement -> to have knowledge of the RM Agreement initially 382: will however greatly -> will, however, greatly 393: notify a delivery error to the Payload Producer -> notify the Payload Producer of a delivery error 394: receiving -> Receiving 407: with same identity -> with the same Message Identifier 656: of ReplyTo element -> of the ReplyTo element 674: Request/ MessageOrder -> Request/MessageOrder 905-906: extraneous line break and spaces 1022, 1308: extraneous blue text color 1472: conform -> conformant 1485: to NOT implement -> NOT to implement Section numbering: 579: 4.2.1.3 584: 4.2.1.4 592: 4.2.1.5 599: 4.2.1.6 655: 4.2.3.2.1
Resolution: proposal included in draft 1.01
PC18 Spec Editorial Closed Jacques Durand
Title: Clarification on when to sent Soap Fault
Description: In section 4.5 the requirement to use SOAP Faults in specific cases, may not be feasible: Because the RMP is unable to distinguish a message that belongs to a Req-Resp MEP, from one taht belongs to a One-Way, it is not clear how the RMP can behave differently based on this: - One-Way should not return SOAP Faults in HTTP response (to be WS-I 1.0 compliant) - but Req-Resp are required to do so in case below: "In case of a Request-Response WSDL operation type, when the message cannot be passed to the consumer due to a failure in processing the RM headers, and therefore no application response can be returned, a SOAP Fault MUST be returned. If the RM Fault is a Message Format fault, a SOAP client fault MUST be returned. If it is a Message Processing fault, a soap:server fault MUST be returned. The latter case also applies to responses to duplicate messages that are not delivered. In case a "Response" ReplyPattern was required, the RM-Reply MUST be returned in the header of the SOAP Fault message..." The intent here , if I remember, was to make sure that the lack of application response would be escalated properly as a fault / exception to the Sender app (or "producer"), which would be achieved by adding a SOAP Fault in the HTTP response. One way out of this would be to link the use of SOAP Faults in HTTP responses to the replypattern "Response", instead of to the WSDL op type (The response reply pattern is supposed to be used only for WSDL Req-Resp ops.) Also, in case replypattern is something else: do we still need to use SOAP Faults? (I don't believe there is a point to it.)
Proposal: Motion passed at 6/01 teleconf to accept the complete proposal for changes required in : Section 4.5 editorial update
Resolution: proposal included in draft 1.01
PC19 Spec Editorial Closed Tony Graham
Title: Tony Graham Editorial comments on draft .999
Description: 0.999 Editorial comments
Proposal: The following edits were agreed at the 6/01 meeting Line Comment 93, etc. Change the many occurrences of two spaces, e.g. in 'else "notify"', to a single space. 105 Add a comma after "side" 107 Change "quality of service" to either "quality-of-service" or "QoS". The present text reads like it's about the quality of the "service contracts". 118 Change "and and" to "and". 119 Change "Message resending" to "message resending". 135, 138 Add a space after "Table". 135 Remove "Cardinality =". 135 Change "And type" to "The type". 140 Add a new paragraph stating that XPaths are used in titles and other places in Section 4. Also add a reference to XPath 1.0 in Section 8. 165 Change "will be" to "is". 176 Change "receiving RMP" to "Receiving RMP". 185, 188 Change "producer party" to "Producer" "Party" was used without explanation in Section 1.2 for the combination of the Producer and the Sending RMP. It should not be used again for something different. 185 Change "sending RMP" to "Sending RMP". 186, 190 Be consistent about whether the parallel sentences are one sentence or two and about whether the sentences finish inside or outside the parentheses. 192 Remove the comma after "header". 192 Change "identifies reliable messages" to "identifies a reliable message". 204 Change "message which encountered" to "message that encountered". 227 Change "E.g., Sending RMP" to "E.g., the Sending RMP". 228 Change "sent with Callback" to "sent using the Callback". 229 The definition of "Reply Publishing" uses none of the previously-defined terminology. For example, "error or acknowledgment" isn't consistent with other terminology. 239 Put the definition for "Intermediary" in the terminology section since it also appears in Section 1.2. 277 Change "response to this request" to "response to this second request". 288 Change "sequence number which is an integer, and which is unique within a group" to "sequence number, which is an integer that is unique within a group". 291 Change "althouh allowed" to "although it is allowed". 294 Change "a sequence number" to "a unique sequence number". 300 Change "A Reliability agreement for messaging" to "An agreement for messaging reliability". 300 Change the hyphens to en-dash (0x2013 in the StarOffice "Special Character" dialog box). 303 Change "protocol features, including details about choreography between sending and receiving RMPs, and timing parameters" to "protocol features, including timing parameters and details about choreography between sending and receiving RMPs". It currently sounds like "timing parameters" is a third level. 311 Change the first sentence to "Table 3 shows the Agreement Items that this specification uses."
Resolution: proposal included in draft 1.01
PC20 Spec Editorial Closed Tom Rutt
Title: Editorial Cleanup
Description: Edits proposed in Detailed Editorial Fixes for Sections 1 - 4 of ED 1.01 and Editorial changes for Sections 5 onward to Draft 1.01
Proposal: accept all proposed edits with following exceptions agreed at 6/08/04 meeting: line 231: Do not add proposed definition for reply publishing, but instead to add new defintion to 1.01 text for publish as folows: "Publish An abstract operation making an rm-reply available to its destination. For the various rm-reply patterns this entails: _ response reply pattern : publishing the reply requires sending the rm-reply on the response of the underlying transport protocol. _ callback reply pattern: publishing the reply requires sending a callback message including the RM-reply information. _ poll reply pattern: publishing the reply requires making the RM-Reply information available to be returned to the sender in response to a poll request " Lines 961 thru LInes 965: At the 6/08 meeting it was agreed to change the second bullet. Doug B provided the following text for the second bulle in proposed wording for bullet in 4.5, Doug Bunting "When the Response RM-Reply Pattern is in use and the message cannot be delivered to the Consumer, the underlying protocol response MUST contain a SOAP Fault (in the SOAP Body) in addition to the appropriate RM Fault (in the SOAP Header). The sending RMP and producer expect either a complete response or a SOAP Fault when using the Response RM-Reply Pattern and this equirement satisfies those expectations. More details are given in the HTTP Binding section." Also: lines 949-951change the following sentence: " These protocol specific fault codes are returned by the Receiving RMP within the response header element. Reliable Message Faults are carried in the SOAP Header, and do not rely on the SOAP Fault model for the following reasons: " to " These protocol specific fault codes are returned by the Receiving RMP within the response header element. Reliable Message Faults are carried in the SOAP Header, and do not rely exclusively on the SOAP Fault model for the following reasons: " Also: Lines 1273, 1339, 1421: Leave the following text from 1.01 as is: _due to a failure in processing the RM headers_
Resolution: applied to draft 1.03
PC21 Spec Editorial Closed Jacques Durand
Title: Editorial corrections to 1.01
Description: Re: [wsrm] editorial comments on 101, J Durand
Proposal: Accept all of Jacques edits , with following change proposed for the introduction paragraph to Table 26: "This specification supports Reliable Messaging capabilities for WSDL 1.1 [WSDL 1.1] One-way and Request-response operation types only. While a Request-Reponse operation can use any of the three RM-Reply patterns to receive acknowledgments or faults, a One-way operation SHOULD (for WS-I BP 1.0 conformance) only use either Callback or Poll RM-Reply pattern. Table 26 indicates recommended usage of reply patterns, for two WSDL operaton typed. An RMP MUST, at leat, support the recommended combinations in Table 26, for the reply patterns it supports. However, an RMP is not requried to disinguish WSDL operation types."
Resolution: Applied to draft 1.03
PC22 Spec Editorial Closed Mark Peel
Title: Editorial comments on 1.01
Description:
Proposal: All comments except the one on Line 629 was applied to editing draft 1.01I. Full sentence is allowed to be introduced by Note: prefix in specifications. Also removing redundant "@foo attribute" to become "@foo" throughout.
Resolution: applied in Working Draft 1.03
PC23 Spec Editorial Closed Tony Graham
Title: Editorial comments from Tony Graham
Description: Re: [wsrm] 1.1-1.02 editorial
Proposal: Agree to proposal, include in editing draft 1.01I
Resolution: applied to working draft 1.03
PC24 Spec Technical Closed Doug Bunting
Title: Payload inclusion and MEPs other than request/response
Description: Re: more on payload(s) inclusion and MEPs than our Request-ResponseMEP discussion covers
Proposal: Jacques Durand proposed changes to resolve issue posted at: Uploaded contribution (June 30) on messaging model - MEP update Iwasa posted updated figures to go along with the new text proposed by Jacques at: Updated Figures for 1.05 Motion to resolve issue with these updates passed at 7/6/04 meeting
Resolution: Accomodated by changes in 1.05
PC25 Spec Technical Closed Doug Bunting
Title: Duplicate message responses
Description: http://www.oasis-open.org/archives/wsrm/200406/msg00078.html
Proposal: The following text was approved to resolve this issue at the July 06 2004 meeting: Final text of proposal: _ When the Response RM-Reply Pattern is requested with duplicate elimination for a reliable message, and a resend of that message cannot be delivered to the Consumer by the Receiving RMP because it is a duplicate of a previously delivered message, and when a consumer response payload is expected, the response of the SOAP MEP instance must contain one or the other of the following, but not both: - a copy of the original response payload returned for that message ID (in the SOAP Body) in addition to the rm-acknowledgement indication (in the SOAP Header)., or; - a SOAP server Fault (in the SOAP Body) in addition to the rm-acknowledgment indication (in the SOAP Header). The Sending RMP and Producer expect either a complete response or a SOAP Fault when using the Response RM-Reply Pattern and these two allowed behaviors satisfy those expectations. _
Resolution: Approved text included in editor's draft 1.05
PC26 Spec Technical Closed Sunil Kunisetty
Title: Soap Fault with RM-Fault
Description: Sunil Mail 1Sunil Mail 2Sunil Mail 3
Proposal: Agreed at 7/4 meeting that the rm fault MUST be carried in Soap Fault. However the following text, was agreed, by voted motion, to be added to the bullet in Section 4.5 (lost in editing from CD .992): _ If the RM-Fault encountered was due to a problem with the request header element, and a consumer response payload is expected, a SOAP client fault MUST be returned. If the RM Fault encountered was due to a problem with processing by the receiving RMP, and a consumer response payload is expected, a SOAP server fault must be returned. _
Resolution: Agreed resolution included in editor's draft 1.05
PC27 Spec Technical Closed Tom Rutt
Title: RM Fault without AckRequested
Description: It was agreed at the 6/29/04 meeting that it needs to be clarified whether an rm-fault indication may be returned without AckRequested element in the request header for the message.
Proposal: Discussion at the 7/6/2004 meeting: The replyPattern element is mandatory, implying that there will be behaviours which require an rm-reply, even if ackRequested is not present. The Sending RMP should be made aware when it sends request elements in a message which are badly formed The following text was approved by voted motion at the 7/06/2004 meeting of the WSRM TC: " The Receiving RMP MAY publish an rm-fault indication for a reliable message, even if the AckRequested element is not present in the request element for that message. "
Resolution: Approved text included in editor's draft 1.05
PC28 Spec Technical Closed Doug Bunting
Title: Reply Pattern on rm:response
Description: The reply pattern as an attribute of the response is not requried. Also, the response should allow arbitrary coallation sequences.
Proposal: Technical issues as I go through action items...
Resolution: Motions in Aug 4 TC meeting accepted proposal. Approved text included inCD 1.086

Table Legend

id
Issue number:
Title
Short title/name of the issue
Spec
Document referred to by issue:
Description
Short description of issue, possibly including link to origin of issue
Section
Reference to specification/document section that motivated this issue
Topic
Rough topic categorisation, one of:
Class
Design or Editorial
Status
One of:
Proposal
Current proposal for resolution of issue, possibly including link to further text
Resolution
Short description of resolution, possibly including link to a more elaborate description
Raised by
Person who raised the issue
Owner
Reliable Messaging TC Member responsible for the issue

Drafts

Official drafts of this TC will be linked to from this area as they become available.

Contributions

Below are a selection of documents that have been submitted to this TC by its members. The full list of contributions is available from the WSRM TC document area on the OASIS web site.
Maintained by Tom Rutt.