http://docs.oasis-open.org/ws-rx/issues/ Date: 2006/04/28 Revision: 37 core soap wsdl policy schema all unassigned active pending done deferred resolved closed dropped Restated issue The current draft of the WS-ReliableMessaging specification defines the wsrm:Offer element as follows: "This element, if present, enables an RM source to offer a corresponding Sequence for the reliable exchange of messages transmitted from RM destination to RM source". As per the text above, the spec does not constrain what messages an offered sequence can be used to send, nor does it define when an offer element must or must not be present. However, WSRX-ReliableMessagingPolicy document, lines 221-226, states that an offer element must be present if and only if the endpoint declares output messages. "Per WS-ReliableMessaging [WS-RM], a wsrm:CreateSequence request MAY contain an offer to create an "inbound" Sequence. If the RM policy assertion is attached to an endpoint declaring only input messages, the endpoint MUST reject a wsrm:CreateSequence request containing a wsrm:Offer to create a corresponding Sequence. If the assertion is attached to an endpoint declaring both input and output messages, the endpoint MUST reject a wsrm:CreateSequence request that does not contain a wsrm:Offer to create a corresponding Sequence." IMO, an offer is an optimization to allow a reverse reliable sequence to be set up without going through the whole CreateSequence handshake. Thus, this limitation in the policy documents seems to be unnecessary. core design F2F - Lei Jin Lei Jin There are cases when I need to send reliable messages to an endpoint, but I don't require responses to be sent back reliably. (see i021) In that case, requiring an offer is unnecessary. There are also cases when the destination endpoint doesn't declare output messages, but needs to send messages reliably to the source endpoint in other types of MEP (eg: oneway, callback MEP). In that case, having an offer is a useful optimization. From restated issue Delete lines 221-226 of WSRX-ReliableMessagingPolicy document. Proposal 1 accepted on Sept. 1 call. Completed in CD 01 i021 Should the AckTo EPR be allowed to change during the lifetime of a sequence? core design F2F - Anish Karmarkar Anish Karmarkar Raised at F2F Issue i002 was raised during the 1st F2F. The issue was raised in the context of long running Sequences where it was possible for the AcksTo EPR to change. There was also some discussion on unending sequences (I think Steve Winkler brought this up). In a long running Sequence it is possible that the AcksTo EPR may change and therefore the RMS needs the ability to let the RMD know of the new AcksTo. Subsequently, I have been talking with our mobile folks and they have brought up a different usecase (but which has the same issue): In the mobile world there are cases where the RMS is expected to have different EPRs throughout the life of the Sequence (the device changes cells/location/countries or is intermitantly offline), therefore it necessary to provide the capability to change the AcksTo EPR for a particular Sequence in progress. Here is the outline of a proposed solution: See message See message Close with no action. Proposal 2 accepted on Nov 10 TC call Which pair of EPRs define the scope of a sequence? core design F2F - Anish Karmarkar Anish Karmarkar Raised at F2F Close with no action Proposal 1 accepted at Sept. 22 F2F What are the uniqueness requirements for the wsa:messageID values used for messages retransmitted with the same wsrm:{sequenceID, MessageNumber} pair as a prior transmission of the same reliable message? core design F2F - Steve Winkler Marc Goodner Raised at F2F Close with no change required Proposal 1 accepted Is the sender required to resend a message identified in a Nack, if it has already received an ack for that same messageNumber? core design F2F - Steve Winkler Steve Winkler Raised at F2F An RMD MUST NOT issue a <SequenceAcknowledgement> containing a <Nack> for a message(s) that it has previously acknowledged within an <AcknowledgementRange>. An RMS SHOULD ignore a <SequenceAcknowledgement> containing a <Nack> for a message(s) that has previously been acknowledged within an <AcknowledgementRange>. Proposal 1 made and accepted on Sept. 8th TC call. Completed in CD 01 Is there a requirement that the sender can assert that the receiver must deliver a particular reliability assurance on a given sequence? core design F2F - Tom Rutt Tom Rutt Raised at F2F. Also raised on list by Tom Rutt. See mail: close issue with no changes to specfication. see message Use the wsrmp:DeliveryAssurance element (as defined in the resolution of i009) in the CS message as follows: <wsrm:CreateSequence ...=""> <wsrm:AcksTo ...=""> wsa:EndpointReferenceType </wsrm:AcksTo> <wsrm:Expires ...=""> xs:duration </wsrm:Expires> ? <wsrm:Offer ...=""> <wsrm:Identifier ...=""> xs:anyURI </wsrm:Identifier> <wsrm:Expires ...=""> xs:duration </wsrm:Expires> ? ... </wsrm:Offer> ? <wsrmp:DeliveryAssurrance ...=""/>? ... </wsrm:CreateSequence> This would allow the Application Sender to signal the RMD/AD of the DA. If the DA is something that is not supported or conflict the policy at the RMD/AD, the RMD may send a CreateSequenceRefused fault. This element of course does not change the protocol on the wire, but lets the RMD/AD know exactly the DA that is expected for the Sequence. Closed with no action at December 14th F2F meeting Must the ws-reliable messaging spec support tokens produced for both ws-security 1.0 and ws-security 1.1? core design F2F - Paul Cotton Marc Goodner Raised at F2F From Marc Goodner To make it explicit that WSS 1.1 is supported I propose the following changes to the specifications to allow referencing of WSS 1.1. The namespaces and references will need to be updated with the final dates after public review closes. WS-ReliableMessaging Add prefix and namespace for WSS 1.1 to table at line 142: wsse11 http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-wssecurity-secext-1.1.xsd Add reference to WSS 1.1 after [WSSecurity] (lines 844-847): [WSSecurity11] Web Services Security: SOAP Message Security 1.1 (WS-Security 2005) http://www.oasis-open.org/committees/download.php/13396/wss-v1.1-spec-pr-SOAPMessageSecurity-01.htm Anthony Nadalin, Chris Kaler, Ronald Monzillo, Phillip Hallam-Baker, eds, OASIS Standard xxxxxx, final date WS-ReliableMessagingPolicy Add reference to WSS 1.1 after [WSS] (lines 306-308): [WSSecurity11] Web Services Security: SOAP Message Security 1.1 (WS-Security 2005) http://www.oasis-open.org/committees/download.php/13396/wss-v1.1-spec-pr-SOAPMessageSecurity-01.htm Anthony Nadalin, Chris Kaler, Ronald Monzillo, Phillip Hallam-Baker, eds, OASIS Standard xxxxxx, final date Proposal 2 accepted at March 22nd F2F. Is there a need to attach policy assertion to something other than an endpoint? The current WS-reliable messaging contribution does not support the application of reliability quality of service at a finer granularity than port type. F2F minutes identified as "Policy requirements for more than endpoints". policy design F2F - Tom Rutt Tom Rutt Raised at F2F Also raised on list by Tom Rutt. From Tom Rutt: Add the following text after the text added for resolution of Issue 021: Attaching reliability policy to a wsdl description at a finer level than endpoint-subject level is outside the scope of this version of the specification. Such out-of-scope policy attachments are considered extension points. Closed with no action at the March 22nd F2F as it was addressed by resolution to i021. In the specification, the delivery assurances are part of a private contract between the RM destination and the application destination. They are not published and they are not visible to the "outside" world - i.e. to the source. core design Chris Ferris Chris Ferris "I certainly CAN see a use case for giving the client the visibility as to the QoS capabilities of the service endpoint and using that information to decide whether it wanted to use that service or select another that offered the desired QoS." <wsrm:DeliveryAssertion mode="[AtLeastOnce|AtMostOnce|ExactlyOnce]" ordered="[xs:boolean]"? ...="" > /wsrm:DeliveryAssertion A policy assertion that makes a claim as to the delivery assurance policy observed by the destination endpoint. /wsrm:DeliveryAssertion/@mode This required attribute specifies whether or not all of the messages within an RM Sequence will be delivered by the RM Destination to the Application Destination, and whether or not duplicate messages will be delivered. A value of 'AtMostOnce' means that messages received by the RM Destination will be delivered to the Application Destination at most once, without duplication. It is possible that some messages in a sequence may not be delivered. A value of 'AtLeastOnce' means that every message received by the RM Destination will be delivered to the Application Destination. Some messages may be delivered more than once. A value of 'ExactlyOnce' means that every message received by the RM Destination will be delivered to the Application Destination without duplication. /wsrm:DeliveryAssertion/@ordered This attribute, of type xs:boolean, specifies whether, or not, the destination endpoint ensures that the messages within an RM Sequence will be delivered in order, by the RMD to the AD. Order is determined by the value of the RM message number. Ordered delivery would mean that the messages would be delivered in ascending order of the message number value. A value of 'true' indicates that messages will be delivered in order. A value of 'false' makes no claims as to the order of delivery of the messages within a RM Sequence. If omitted, the default implied value is 'false'. Proposal 1 accepted at Sept. 22 F2F, new issue to be opened to define whether the above is an assertion or a parameter. Completed in CD 01 Is there a need to allow a single sequence to span multiple ports? core design Doug Davis Doug Davis "Having a single sequence span multiple ports (much like an MQ queue does) could be needed as well." See this email and attachment See attachment in this message Proposal 2 accepted on Oct. 27th TC call Completed in CD 2 Per the schema spec a zero second duration needs to have the "T" designator - so it should be PT0S not P0S. core editorial Doug Davis Doug Davis align with schema spec ( http://www.w3.org/TR/xmlschema-2/#duration ) simple search and replace of P0S with PT0S Proposal accepted at July 21st TC meeting , no objections. Completed in CD 01 If the AcksTo EPR is set to use the anonymous IRI, then all subsequent acknowledgements for that reliable sequence will be sent back synchronously on the http response path of either the application message or an ack request message. soap design Lei Jin Lei Jin From new issue post. First of all, if an application message is one way (or asynchronous), a RM source may receive something back on the http response(the WS-RM ack). Nothing really precludes this usage, but it introduces unnecessary dependency between WS-RM (acknowledgement messages) and WS-Addressing (normal MEP). From new issue post. Specifically call out that the AcksTo EPR should not use the anonymousIRI. -- One reason to use an anonymous IRI is so that the acknowledgement may reach sending endpoints that may be sitting behind a NAT or firewall. But we have to deal with the same problem with asynchronous response messages anyway. From new issue post. Specifically call out that an anonymous IRI in the AcksTo EPR would indicate acknowledgement message will only be sent back in response to ack request messages where the ack request message should be a standalone synchronous invoke. Response to each proposal above from Chris Ferris, proposal 1 out of scope and proposal 2 not an issue. Close issue without change to spec. Proposal 4 made and accepted on Sept. 8 TC call. There is no common way to communicate to an RM Source the highest message number the RM destination will accept, in case it is lower than the maximum authorized in the specification. core design Doug Davis Doug Davis Without knowing in advance what the highest message number is the RM source may exceed it, causing the entire sequence to be terminated - when it may have been able to start a 2nd sequence to continue its work. By allowing the RM source the option of terminating the sequence gracefully it can still deliver lost messages for the original sequence. As it stands now, if the sequence is terminated the lost messages will not be resent. Original proposal from raised issue , revised proposal In the WS-RM Policy doc: After line 173, add to the normative outline: ?]]> After line 202, add to the more verbose section of the normative outline: /wsrm:RMAssertion/wsrm:MaxMessageNumber A parameter that specifies the maximum message number that the RM Destination will accept. If omitted, the default value of the maximum unsigned long will be assumed. /wsrm:RMAssertion/wsrm:MaxMessageNumber/@Number The maximum message number. After line 434, add to the schema: ]]> Friendly ammendment , in the WS-RM Policy doc, after line 155: The assertion defines a maximum message number parameter that the RM Destination MAY include to indicate the maximum message number the RM Destination will accept. This is useful for RM Destinations that may be running in constrained environments that can not accept values as large as the default value of a maximum unsigned long. Proposal 1 accepted at August 11 TC call. Completed in CD 01 Should the "names" of the normative documents remain the same as the submission documents or should they be changed? This issue applies to both WS-ReliableMessaging and WS-RM Policy. core editorial Gilbert Pilz Gilbert Pilz The name of a document effects a number of things such as the document identifier, URIs etc. Link Preserve the name of the documents as submitted. Changing the names would increase confusion (already at a high level) around "OASIS and RM" and result in extra effort. There does not seem to be any reasons for changing the names forcefull enough to override these concerns. Therefore the names of the normative documents should be Web Services Reliable Messaging Protocol (WS-ReliableMessaging) and Web Services Reliable Messaging Policy Assertion (WS-RM Policy). First proposal accepted on Aug. 4th conf call , no objections OASIS guidelines require that the artifacts (documents, schemas, etc.) produced by a TC should have a minimum set of of metadata that describes these artifacts. core editorial Gilbert Pilz Gilbert Pilz OASIS requirement. Link We propose the following values for each specification: WS-ReliableMessaging: artifactName: TBD tc: TBD product: wsreliablemessaging productVersion: 01 artifactType: spec stage: wd descriptiveName: Web Services Reliable Messaging Protocol Specification WS-RM Policy: artifactName: TBD tc: TBD product: wsrmpolicy productVersion: 01 artifactType: spec stage: wd descriptiveName: Web Services Reliable Messaging Policy Assertion Specification Note that the product names of these two artifacts differ. Link WS-ReliableMessaging: tc: wsrx product: wsrm productVersion: 1.1 artifactType: spec stage: wd descriptiveName: Web Services Reliable Messaging Protocol Specification WS-RM Policy: tc: wsrx product: wsrmp productVersion: 1.1 artifactType: spec stage: wd descriptiveName: Web Services Reliable Messaging Policy Assertion Specification Proposal 2 accepted on TC call on Aug. 18th i074 The artifacts (documents, schemas, etc.) produced by the WS-RX must be uniquely identified. We need to decide on the identifiers for WS-ReliableMessaging and WS-RM Policy core editorial Gilbert Pilz Gilbert Pilz Self-evident Link According to the OASIS guidelines and in light of the proposed artifact metadata, the documents should currently be identified as: wsreliablemessaging-01-spec-wd-01.* wsrmpolicy-01-spec-wd-01.* Note that some identifiers may have the final sub-version removed. The * indicates that these documents may be formatted in either HTML (.html) or PDF (.pdf). Link wsrm-1.1-spec-wd-01.* wsrmp-1.1-spec-wd-01.* Link Proposal 2 accepted on Aug 18th TC call i074 We need to decide upon the normative XML namespace URIs that must be used by implementations of these specifications schema editorial Gilbert Pilz Gilbert Pilz Self-evident Link The namespace URIs for WS-RX-defined schemas should be URLs that resolve to RDDL documents that provide information about the schema as well as links to the corresponding specification(s). Per OASIS guidelines, the RDDL documents must be hosted by OASIS. Therefore the exact URL values will need to be co-ordinated with OASIS but, in general, they should look something like the following: xmlns:wsrm="http://www.oasis-open.org/committees/ws-rx/wsreliablemessaging-200507.html" xmlns:wsrmp="http://www.oasis-open.org/committees/ws-rx/wsrmpolicy-200507.html" Note that the 200507 in the URL is represents the schema version as a date (July, 2005). From Chris Ferris I propose that we resolve issue i017 [1] as follows: The namespace URI used for our specs should follow the draft AIR guidelines. e.g. http://docs.oasis-open.org/[productname]1 where [productname] is whatever we conclude for issue i015 [2] for the respective specs. The trailing '1' signifies the "version" of the *namespace* but is NOT in any way tied to the version/revision of the corresponding schema for that namespace (see my previous rants on this subject). This will allow us to assign a final namespace URI for the specifications that we are chartered to produce (rather than having to either guess at a date, or worse yet, change the namespace name with each successive published draft -- BLECH!) I would also assert that we do not need to resolve i015 before resolving that the form of the namespace URI will be as above... we just fill in the blank once we have settled on a [productname] for our specs. Benefits: this yields a nice SHORT namespace URI (see my previous rants) it allows us to assign a final URI now, rather than waiting until we are essentially done (good for implementation as it reduces unnecessary churn to tweak the namespace URI in code). [1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13809/ReliableMessagingIssues.xml#i017 [2] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13809/ReliableMessagingIssues.xml#i015 From Marc Goodner The namespace URI used for our specs should follow the draft AIR Guidelines as follows: http://docs.oasis-open.org/yyyy/mm/[productname] Where [productname] is the name from the resolution of issue i015 [2] for the respective specs and yyyy/mm is the date of the published version of the specification. [1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13809/ReliableMessagingIssues.xml#i017 [2] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13809/ReliableMessagingIssues.xml#i015 Link http://docs.oasis-open.org/wsrm/yyyymm/ http://docs.oasis-open.org/wsrmp/yyyymm/ Link Proposal 4 made and accepted on Aug 18th TC call. i074 The existing specification includes the clause "If the message number exceeds the internal limitations of an RM Source or RM Destination ...". This allows a source or destination to handle unexpected failures gracefully. It does not clearly allow, require, or prevent the implementation to be designed or deployed with a message number limit. Should we support such a limitation? core design Doug Bunting Doug Bunting Issue below presupposes a "yes" answer to this question. Should decide this larger question before deciding how to fill gap left if the answer is "yes". Link I lean toward "no" but could be convinced otherwise. If "no" is the answer, the specification could change to make it clear a WS-RM compliant implementation _must_ support the full unsigned long range for the message number. That likely requires conformance terminology not presently in the specification; this issue is not intended to broach the even-more-general subject of conformance clauses. My proposal therefore comes down to "close, no action". Made on Jul 28th TC call The answer to the question asked in the title is "yes"; an implementation supporting less than 18 quintillion as the maximum message number is valid. With regard to the specification at this time, no change seems necessary. Any clarification necessary to make this lack of an implementation requirement clear is likely to come from resolutions to i013: Max message number in policy and / or Issue i019: Sequence termination on Fault. Second proposal accepted on Jul 28th TC call , no objections. i013 i019 The RM Destination imperatively terminates a sequence due to one of these unrecoverable errors: - wsrm:SequenceTerminated - wsrm:MessageNumberRollover - wsrm:LastMessageNumberExceeded The semantics of sequence termination due to a fault occurrence are not clearly specified. This uses the reworded issue core design Jacques Durand Jacques Durand Unless an accurate and final acknowledgement status was sent back at the time the sequence is closed, the Source will not know if some non-acknowledged messages were actually received before the termination occurs. This gives the source two unpleasant options: (a) resend all non-acknowledged message in a new sequence, with the risk of causing undetectable duplicates, (b) not resend any, and these will be lost. Link Two options need be discussed: Option (1): At the time a Destination-controlled termination gets into effect, a final and accurate Acknowledgement for the entire sequence is sent back. Option (2): After the fault was notified to Source, simply rely on regular termination procedure (either expiration-based, or under Source control, so that the Source can complete its resending of pending messages and get the final acks), meanwhile reject any message for this sequence that exceeds the ending number in case of MessageNumberRollover or LastMessageNumberExceeded. As outlined in message number 76 Proposal 2 accepted on Sept. 15th TC call. Completed in CD 01 The semantics of the "at most once" delivery assurance are not clear. One interpretation is that at most once implies that the sender is not required to retransmit mesages which are not acked. all design Tom Rutt Tom Rutt It is important to clarify whether the sender must retransmit unacknowledged messages when the "at most once" delivery assurance is in use. Link Clarify the semantics. There are at least three possible semantics associated with "at most once" At most once means that the sender will never retransmit a message, regardless of whether it is acknolweged by the destination. The sender may retransmis messages, but is not required to to so, however the destination will not deliver duplicates The sender must retransmit messages, however the destination may drop messages in times of resource saturation, but will never deliver a duplicate. At line 162 of the WS-ReliableMessaging spec, delete the following paragraph: WS-ReliableMessaging provides an interoperable protocol that a Reliable Messaging (RM) Source and Reliable Messaging (RM) Destination use to provide Application Source and Destination a guarantee that a message that is sent will be delivered. The guarantee is specified as a delivery assurance. The protocol supports the endpoints in providing these delivery assurances. It is the responsibility of the RM Source and RM Destination to fulfill the delivery assurances, or raise an error. The protocol defined here allows endpoints to meet this guarantee for the delivery assurances defined below. and replace it with the following text: The WS-ReliableMessaging specification defines an interoperable protocol that requires a Reliable Messaging (RM) Source and Reliable Messaging (RM) Destination to ensure that each message transmitted by the RM Source is successfully received by an RM Destination, or barring successful receipt, that an RM Source can, except in the most extreem circumstances, accurately determine the disposition of each message transmitted as perceived by the RM Destination, so as to resolve any in-doubt status. In addition, The protocol allows the RM Source and RM Destination to provide their respective Application Source and Application Destination a guarantee that a message that is sent by an Application Source will be delivered to the Application Destination. This guarantee is specified as a delivery assurance. It is the responsibility of the RM Source and RM Destination to fulfill the delivery assurances on behalf of their respective Application counterparts, or raise an error. The protocol defined here allows endpoints to meet this guarantee for the delivery assurances defined below. Note that the underlying protocol defined in this specification remains the same regardless of the delivery assurance. However, the means by which these delivery assurances are manifested by either the RM Source or RM Destination roles is an implementation concern, and is out of scope of this specification. Note that the underlying protocol defined in this specification remains the same regardless of the delivery assurance. Proposal 2 accepted at Sept. 21 F2F Completed in CD 01 i009 Refurbished: Last sentence of Section 2 in RM-Policy spec says that an RM policy MUST apply to all messages in a binding (when associated to binding). That means applying equally (same timing parameters, etc.) to both in and out messages of an operation of type request-response. However, clearly the DA requirements are different for each endpoint (Client and WS), and so are the performance requirements and capabilities regarding the protocol. For example, a WS may need ExactlyOnce for incoming messages, and consequently implement the protocol along with its receiving functions (sending Acks), but not willing to implement the RM sending functions (resending mechanism...) - or at least not with the same parameter values - if the responses need not be reliable. In addition, when deployed in a WS-I-compliant (Basic Profile) environment, a reliable Response has to be sent over an HTTP response. The RMS behavior (which is now the sender of the Response) would need to implement a much more constrained and context-dependent resending mechanism, as response messages can only be resent as responses to request resendings. policy design Jacques Durand Jacques Durand Enforcing same protocol policies for inbound and outbound messages may create unnecessary burden to a WS endpoint for which RMD-only functions are sufficient. In addition, the resending behavior for synchronous responses being more constrained, cannot obey the same parameters. Link Even if the scope of an RM Policy remains at port level there could be an additional scoping attribute stating inbound vs outbound. Yet a cleaner way seems to make use of finer granularity in the attachment (as allowed by WS-PolicyAttachment). From Doug Davis - reduce the RM policy assertion to mean that RM is supported <wsrmp:RMAssertion [wsp:Optional="true|false"]?/> No Optional attribute implies RM is supported but optional. - this assertion applies _just_ to incoming messages - when optional its up to the RMS to decide whether or not RM is used - when not optional then RM is required for all messages to this endpoint - define a new RMRequired Fault to return when an endpoint gets a message that wasn't RM-enabled but requires it to be. - Define this new fault in the RM spec. - Add text to the wsrm spec saying that when a message is sent to an EPR that contains the <wsrmp:RMAssertion> element in the <wsa:Metadata> section then the sender of the message should use this information to know whether or not RM is supported/required. When sending replies it may not be possible for the wsa:ReplyTo endpoint to always expose WSDL to let the RMD know whether or not it is RM-enabled. To satisfy this the RMS can include the <wsrmp:RMAssertion> element in the wsa:ReplyTo EPR's <wsa:Metadata> element. As to the current parameters (e.g. MaxMessage#), those are removed and will either be placed in the CreateSeqResponse (based on Paul's issues) or dropped entirely from the spec. This assertion is not extensible. From Gilbert Pilz This proposal addresses the issue by splitting the current <wsrmp:RMAssertion> into two separate assertions: <wsrmp:RMInbound [wsp:Optional="true"]? ... > <wsrmp:AcknowledgementInterval Milliseconds="xs:unsignedLong" ... /> ? <wsrmp:MaxMessageNumber Number="xs:unsignedLong" ... /> ? ... </wsrm:RMInbound> And: <wsrmp:RMOutbound [wsp:Optional="true"]? ...> ... </wsrmp:RMOutbound> Note that <wsrmp:RMInbound> preserves the configuration parameters currently contained in <wsrmp:RMAssertion>. To indicate that RM is required for inbound messages only you might use something like the following policy (note: same as current example in WS-RM Policy) <wsp:Policy wsu:Id="MyPolicy" > <wsp:ExactlyOne> <wsrmp:RMInbound> <wsrmp:AcknowledgementInterval Milliseconds="200" /> </wsrmp:RMInbound> </wsp:ExactlyOne> </wsp:Policy> Note this proposal does not change the current specification with regards to supported policy attachment options (Endpoint Policy Subject; wsdl:binding or wsdl:port). To indicate that RM is required for both inbound and outbound messages you might use something like the following policy: <wsp:Policy wsu:Id="MyPolicy" > <wsp:ExactlyOne> <wsrmp:RMInbound> <wsrmp:AcknowledgementInterval Milliseconds="200" /> </wsrmp:RMInbound> <wsrmp:RMOutbound /> </wsp:ExactlyOne> </wsp:Policy> Obviously you can use combinations of these assertions and the wsp:Optional attribute to indicate many different policy combinations such as: an endpoint requires RM for inbound messages and supports the optional use of RM for outbound messages an endpoint does not support RM for inbound messages but requires the use of RM for outbound messages etc. Proposal regarding issue 021. I'm not quite sure this is right yet, so I would appreciate feedback from the Policy experts. Based on CDII Delete 142-154 section 2.3 and replace with. 2.3 Assertion Attachment The RM assertion can have Service, Endpoint, Operation or Message Endpoint Policy Subjects [WS-PolicyAttachment]. WS-PolicyAttachment [WS-PolicyAttachment] defines both abstract and concrete attachment points in WSDL [WSDL1.1]. Because the RM policy assertion specifies a concrete behaviour, it MUST NOT be attached to abstract constructs: wsdl:portType wsdl:portType/wsdl:operation wsdl:portType/wsdl:operation/wsdl:input wsdl:portType/wsdl:operation/wsdl:output wsdl:portType/wsdl:operation/wsdl:fault wsdl:message The RM policy assertion MAY be attached to the following constructs wsdl:service wsdl:port wsdl:binding. wsdl:binding/wsdl:operation wsdl:binding/wsdl:operation/wsdl:input wsdl:binding/wsdl:operation/wsdl:output wsdl:binding/wsdl:operation/wsdl:fault If the RM assertion is attached to the wsdl:service construct, it MUST be considered to apply to all the wsdl:port's referenced in the binding. If the RM assertion is attached to the wsdl:port construct, it MUST be considered to apply to all the wsdl:binding's referenced in the port. If the RM assertion is attached to the wsdl:binding construct, it MUST be considered to apply to all the wsdl:operation's referenced in the binding.If the RM assertion is attached to the wsdl:operation construct, it MUST be considered to apply to all the wsdl:input's, wsdl:output's and wsdl:fault's referenced in the operation. WS-Addressing allows for policy assertions to be included within an EndpointReference. Per section 2.2 above, the presence of this policy assertion in an EPR specifies the level of support for WS-ReliableMessaging offered by that endpoint. (In addition to proposal 4) If an RM policy assertion is attached to any of: wsdl:binding/wsdl:operation/wsdl:input wsdl:binding/wsdl:operation/wsdl:output wsdl:binding/wsdl:operation/wsdl:fault then an RM policy assertion, specifying wsp:Optional=true MUST be attached to the corresponding wsdl:binding or wsdl:port, indicating that the endpoint supports WS-RM. Any messages, regardless of whether they have an attached Message Policy Subject RM policy assertion, MAY be sent to that endpoint using WS-RM. Additionally, the receiving endpoint MUST NOT reject any message belonging to a Sequence, simply because there was no Message Policy Subject RM policy assertion attached to that message. Proposal 7 accepted with ammendment to add text "In the case where an optional RM Assertion applies to an output message, there is no requirement on the client to support an RMD implementation." at the March 22nd TC F2F. The RM policy assertions, specifically, InActivityTimeout, BaseRetransmissionInterval and ExponentialBackoff parameters need to be more finely specified. The following are the areas which need finer specification a) Default Value for InActivityTimeout, BaseRetransmissionInterval and ExponentialBackoff: There needs to be a default set for these parameters. Currently the specification says "If omitted, there is no implied value." Since these parameters dictate the delivery of the message, an implementation is going to assume a default anyways. Not specifying this will make implementations assume a different default value and cause unwanted timeouts. b) Definition of InActivity There needs to be a discussion of definition of inactivity. If RMS sends a sequence to RMD and is waiting for the response which is delayed for whatever reason, is that inactivity on the link between RMS and RMD counted towards InActivityTimeout? If yes, then it is entirely possible that while waiting for a sequence response, RMS could timeout due to InActivity. c) Applicability of InActivityTimeout: It needs to be specified to which end this parameter is applicable. It seems like sequence creator starts the timer for InActivityTimeout. If the intention is that this timer exists on both ends of a sender and receiver engaged in a RM sequence, we need to define a method for synchronization of the timer value of this parameter between them. For example an KeepAlive message would need to be defined for keeping sequence alive. d) Corner Case Handling: There needs to be a discussion of the corner case when the BaseRetransmissionInterval exceeds InActivityTimeout. This can happen when the RMD is indisposed and ExponentialBackoff drives up the value of BaseRetransmissionInterval. In this case my retransmission is schedule later than the timeout that I need to abide to. What state does the RMS enter in this situation? e) BaseRetransmissionInterval Needs an Upper Bound: If an RMD is offline for extended period of time, one can expect the BaseRetransmissionInterval to be exponentially backed off i.e. become large enough to be not meaningful anymore. Having an upper bound on this parameter will enable the RMS to stop retransmitting and report a fault. This is the revised description policy design Vikas Deolaliker Vikas Deolaliker There is no obvious case mentioned in the spec that requires two timers for retransmission upon timeout. Original proposal in raised issue , this is the text of the revised proposal 1) InActivityTimeout and BaseRetransmissionInterval can be merged into one i.e. BaseRetransmissionTimeout. Having just one counter on the RMS and RMD will reduce the run-time resources (much simpler state machine) required to implement RM-Assertions and avoid confusion (unknown states in state machine) caused by two timeouts. Having a separate timeout for sequence and retransmission may not be necessary as activity on the RM link is transmission/retransmission. I believe one timeout i.e. BaseRetransmissionTimeout does not change the behavior of the system. Once this timeout occurs the sequence has to timeout as the implication of the timeout is the destination is either congested or offline. 2) If InActivityTimeout has to be there as a parameter, we need to fully specify it with mechanisms for synchronization and keepalive. In addition, we need to discuss how the corner cases and other conflicts that occur when one has two timeout (as discussed in a-e above) are handled. See message Delete all re-transmission parameters as described in the WS-RM Policy specification since they are unnecessary and unhelpful should the implementer use an algorithm with a different set of controls. Specific modification to documents See message SAP favors removing two of the parameters that are part of the wsrmp specification[1] as a step to resolve Issue i022 [2]: BaseRetransmissionInterval and ExponentialBackoff. We agree with Bob's argument that these are more dynamic in nature and should not be specified in the wsrmp document. However, we disagree to remove InactivityTimeout (and Acknowledgement Interval) from the specification. Acknowledgement Interval is important from RMS's point of view to determine the duration to wait for an ack, hence necessary for RMD to specify. Inactivity Timeout is important for reclaiming resources. It is important for RMS to know when RMD may recover resources and hence adjust its rate of transmission accordingly. We propose to remove BTI and EB. See message remove lines 137-138, 156-163, 205-206, 282, 389-402 of WS-RMP and the schema components represented by lines 389-402 in the appendix from the wsrmp XSD (where are the xsd's hiding?) Proposal 4 accepted at Nov 3rd TC call Completed in CD 2 In situations where the RMD is running low on resources, it may want to provide hints to the RMS of its situation with the expectation that the RMS pauses or slows down the (re)transmittal of messages and avoid further straining of RMD resources until recovery. The current solution of statically associating an ExponentialBackoff policy assertion may not be timely and sufficient in all the cases and a more dynamic solution for throttling the message flow may be needed. core design Sanjay Patil Marc Goodner In a low-resource situation, it is likely that the RMD would discard any incoming messages and stop sending any Acks. Since the current protocol design does not provide for the RMS to become cognizant of the situation on the RMD side, RMS may simply keep on (re)transmitting messages resulting into further resource utilization (network bandwidth, processing power on both ends, etc.) and possibly making the situation worse. It seems that a better option may be for the RMD to push back on the RMS in the event of low-resource like situations and request the RMS for pausing or slowing down any (re)transmissions. Link RM Protocol to support RMD pushing back on the RMS for slowing down or stopping (re)transmission of messages. See message Close with no action. See message Proposal 2 accepted at Nov 3rd TC call Issue i009 asks whether WS-RX should define policy assertions to define various kinds of QoS properties for a message sequence. This certainly seems like a good subject for discussion. What worries is something related. There is a tacit assumption that WS-RX policies will follow WS-Policy (latest public version Sept. 2004). This specification does not state explicitly how to tell whether a message conforms to a particular policy. The assumption is that one can examine the headers in the message and tell what policy is being followed. Thus, the effect of policies is manifested on the wire. But neither the suggested QoS assertions nor the existing WS-RX assertion that declares the retry-interval etc. will appear as message headers. So, how do we tell what policy is being followed? Clearly, some other mechanism is needed. One way is for messages to carry the URI of the policy they adhere to. Another is to define headers in the start-sequence and sequence-started messages that indicate policy information. I'm sure folks can come up with other good suggestions. policy design Ashok Malhotra Ashok Malhotra See description Close with clarification of meaning of observed to be added to spec. Proposal 1 accepted at Sept. 21 F2F Pending text agreed on Oct. 20 TC call: Change text using email message 144 proposal from Marc Goodner to change "observe" to "in effect". Amended to add the words "rm assertion parameters do not affect the messages which are sent on the wire" Completed in CD 2 i009 i013 Consider the following scenario: an RMS establishes a Sequence with CreateSequence and transmits a single message that is NOT received by the RMD. It then follows that with an AckRequested message. What is the correct form of the SequenceAcknowledgement expected? Should one be sent? core design Chris Ferris Chris Ferris The specification and schema require that a SequenceAcknowledgement element have at least one AcknowledgementRange child element (or a Nack) Yet, MessageNumber values start at 1 and increment monotonically by 1 for each successive message in a Sequence. Zero (0) is not a valid MessageNumber. From raised issue Recommend that an RMD be required to respond with a SequenceAcknowledgement element containing exactly one AcknowledgementRange child element that has both the @Upper and @Lower attributes each carry a value of "0" to signify that no messages have been received for a given Sequence. e.g. <wsrm:SequenceAcknowledgement xmlns:wsrm="http://docs.oasis-open.org/whatever"> <wsrm:Identifier>http://example.org/mysequence/1234</wsrm:Identifier> <wsrm:AcknowledgementRange Upper="0" Lower="0"> </wsrm:SequenceAcknowledgement> 1) Amend the schema to add a third <xs:choice> element, <wsrm:None/> in parallel with Nack and AcknowledgementRange. 2) Explain the meaning of this element in the text, i.e. "/wsrm:SequenceAcknowledgement/wsrm:None -- no messages were received". 3) Editors to clean up the text around AcknowledgementRange (i.e. is it really optional, etc...) Proposal 2 accepted at Sept. 22 F2F Completed in CD 01 In case an RM destination expects a large number of concurrent sequences, it may find itself in a position where maintaining the state of existing sequences takes too much resources. As a consequence, existing sequences may need to be terminated by the RM Destination, or new CreateSequence requests may be turned down, and denial of service occurs. COnsider a rate of message loss (and not RM-recovered) of about one for each million in average, over a sequence 1 trillion long (about 18,000, 000 times smaller than allowed maximum). Representing the state of such a sequence would require 1M intervals, with about 12 bytes to code an interval of (long) integers (long starting number + length on 4bytes) about 12Mb is used for the sequence state. For am RM Destination with tens of thousands of concurrent long-lasting sequences, it means that potentially terabytes of persistent space will be needed to store the state of these sequences. Also, the SequenceAcknowledgement element for such sequences may become extremely bulky (with such a rate loss above, could reach several Gb once the sequence gets big.) core design Jacques Durand Jacques Durand Space needs over time for sequences states is something unpredictable but manageable, (somehow like cache management). If one wants to ensure the scalability of the RM mechanism, such dynamic policies as: (1) deciding to arbitrarily end some existing sequence (e.g. LFU) (2) dynamically adjust the maximum sequence length of new sequences at creation time should be supported (though their specification should remain out of scope). For example, in many cases it is preferable to preventively limit the size of requested new sequences, and to decide that below a threshold of available memory, the maximum length of new sequences would get smaller. The RM specification is currently not open to such policies, mandating a fixed maximum to all sequences created regardless of resource status. From raised issue (a) create another fault like "ResourceExhaustion" more explicit than "SequenceTerminated" fault, that allows the RM Source to understand the reason of such an arbitrary termination by the RM Destination. (b) In addition, if a smaller maximum has been dynamically decided by the RM Destination, communicate it to the RM Source via the CreateSequenceResponse. Closed with no action at Sept. 21 F2F The InOrder delivery assurance can only be enforced for messages within one sequence. If a new sequence has to be created, for example due to a MessageNumber rollover, the ordering of the messages can not be enforced unless there is a way to link the sequences together. If this is the intention it should be clarified in the spec. core design Andreas Bjärlestam Andreas Bjärlestam InOrder is one of the supported delivery assurances. The scope of the ordering should be clear. Original message: InOrder Messages will be delivered in the order that they were sent. This delivery assurance may be combined with any of the above delivery assurances. It requires that the messages within a Sequence will be delivered in an order so that the message numbers are monotonically increasing. Note that this assurance says nothing about duplications or omissions. Note also that it is only applicable to messages in the same Sequence. Cross Sequence ordering of messages is not in the scope of this specification. Proposal 1 accepted on Sept. 15th TC call. Completed in CD 01 When a Source decides to stop using a sequence, there is no way the RMS can get a sequence ack that it knows will accurately reflect the final state of the sequence, i.e. the state the sequence will have at actual termination time. No matter how long an RMS waits after its last sending and before requesting its last Ack, some past message that was previously sent and never acknowledged (for which RM Source had stop any resending effort) could be received late by RMD (e.g. after being stuck in a router), i.e. after the sending of the last SequenceAcknowledgement and before the sequence is actually terminated so that the RMD can reclaim resources. This is the twin sister of issue i019 which deals with a similar problem but in case of sequence fault (which gives no chance to RMS to get this final seq ack.) core design Jacques Durand Jacques Durand An RMS (or SA) may decide to stop using a sequence even though some messages were not received (not acked). But in all cases, it is important that the RMS gets a final accurate account of which messages have been received and which have not for this sequence. The RMS may have to raise an error for those not received. Also if the SA decides to take remedial action for these (e.g. some resending on its own) it must be given some means to avoid treating messages that it did not know were already received in a previous sequence (e.g. avoid resending them later in a new sequence as they would become undetectable duplicates.) From Jacques Durand at issue origin TBD. Outline of a solution: (a) give an RMS a way to trigger a SeqAck that will be associated with the "closing" of the sequence i.e. no more message will be accepted by the RMD after this Ack is generated. (b) give an RMS a way to reiterate this trigger in case it is lost, so that it can get this last SeqAck. As outlined in message number 76 Proposal 2 accepted on Sept. 15th TC call. Completed in CD 01 The current draft of the WS-ReliableMessaging specification includes elements that are defined in WS-Security. This dependency is unnecessary and creates a number of problems for WS-RM implementations and the organizations that provide such implementations. It should therefore be removed. core design Gilbert Pilz Gilbert Pilz Lines 502-508 of WS-ReliableMessaging-v1.0-wd-01 describes the inclusion of a <wsse:SecurityTokenReference> as a sub-element of the <wsrm:CreateSequence> element. The reason for including a SecurityTokenReference in the sequence creation request is to provide the information necessary to perform authorization checks upon the messages within the sequence. Such authorization checks are unnecessary as they only serve to defend against a denial-of-service attack (spoofed sequence identifiers) that can be better defended against by proper protection of the sequence identifier. In addition to this there are a large number of denial of service attacks that are not blocked by these authorization checks. If vendors that provide implementations of WS-RM are required to support the use of the SecurityTokenReference during sequence creation in order to be deemed compliant (as the current interopability scenarios indicate), then such vendors must supply an implementation of WS-Security along with their implementation of WS-ReliableMessaging. This despite the fact that 99% of their customers may not be interested in using anything more complicated than SSL/TLS to protect their web services traffic. Although the use of the SecurityTokenReference element is described as optional, the decision on whether or not to use this option lies with the RM Source. Since there is no RM-Policy Assertion that indicates whether or not the RM Destination can accept the use of this option, negotiating the use of this option requires manual, out of band communications between the operators of the two systems. This impacts the usability of the systems that use WS-RM. Delete lines 458-461 of WS-ReliableMessaging-v1.0-wd-01 Delete lines 502-508 of WS-ReliableMessaging-v1.0-wd-01 Remove lines 450-452 and 494-500 Proposal 2 accepted at Sept. 22 F2F Completed in CD 01 i007 When an RMD accepts an offer of a bilateral Sequence, is it Obligated to use that Sequence for response messages to the endpoint that requested creation of the Sequence in which the offer was made? core design Chris Ferris Chris Ferris The text in section 3.4 makes no mention of the obligations, if any that the RMD has in accepting a CreateSequence with an Offer. The text at 480(pdf) reads: /wsrm:CreateSequence/wsrm:Offer This element, if present, enables an RM Source to offer a corresponding Sequence for the reliable exchange of messages transmitted from RM Destination to RM Source. As the wsrm:Offer is intended as an optimization, I believe that the RMD should be under no obligation to actually use the offered Sequence. Similarly, I believe that it should be made clear in the spec that the RMS MUST NOT presume that the offered Sequence will actually be used to ensure that there are no interop issues that might arise from one implementation making such an assumption and another that chooses not to use the offered Sequence (for what ever reason). I suppose that we *could* devise a wsrm:Decline child of wsrm:CreateSequence as a courtesy to the RMS that made the offer so that it could reclaim the associated resources rather than having to wait until the offered (but unused) Sequence expired. That would make it abundantly clear that there was no association. If we pursued the wsrm:Decline, then the text around lines 536-566 will need to be fixed accordingly. Remove lines 545-546 of WS-RM spec (pdf) [3] so as to not require that the RMD send a wsrm:Accept in a CSR for a CS with a wsrm:Offer. Absence of a wsrm:Accept in a CSR for a corresponding CS with wsrm:Offer enables the RMS to safely reclaim the resources associated with the offered sequence. It isn't clear to me that the spec need to say anything about that, but if some would prefer it did, I offer this addendum to my proposal to be inserted immediatly following the deleted lines above: Note: If a wsrm:CreateSequenceResponse is returned without a child wsrm:Accept in response to a wsrm:CreateSequence that did contain a child wsrm:Offer, then the RM Source MAY immediately reclaim any resources associated with the unused offered Sequence. [1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14682/ReliableMessagingIssues.xml#i030 [2] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14682/ReliableMessagingIssues.xml#i001 [3] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14603/wsrm-1.1-spec-wd-03.pdf Proposal 2 accepted Completed in CD 2 i001 i030 There is an inconsistency between the spec and the schema for the child element of the <AckRequested> directive. Is the child element wsrm:MaxMessageNumberUsed (as per the schema) or is it wsrm:MessageNumber as per the spec? Here's the prose from line 427 (pdf) of the wsrm spec: /wsrm:AckRequested/wsrm:MessageNumber This optional element, if present, MUST contain an xs:unsignedLong representing the highest <MessageNumber> sent by the RM Source within a Sequence. If present, it MAY be treated as a hint to the RM Destination as an optimization to the process of preparing to transmit a <SequenceAcknowledgement>. Here's the relevant fragment from the schema: <xs:complexType name="AckRequestedType"> <xs:sequence> <xs:element ref="wsrm:Identifier"/> <xs:element name="MaxMessageNumberUsed" type="xs:unsignedLong" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> schema editorial Chris Ferris Chris Ferris There is a clear discrepancy between the spec and the schema I believe the intent was to have the element named as per the schema. Change the text at line 427 as follows: /wsrm:AckRequested/wsrm:MaxMessageNumberUsed This optional element, if present, MUST contain an xs:unsignedLong representing the highest <MessageNumber> sent by the RM Source within a Sequence. If present, it MAY be treated as a hint to the RM Destination as an optimization to the process of preparing to transmit a <SequenceAcknowledgement>. Change the ws-rx schema AckRequestedType complexType from: <xs:complexType name="AckRequestedType"> <xs:sequence> <xs:element ref="wsrm:Identifier"/> <xs:element name="MaxMessageNumberUsed" type="xs:unsignedLong" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> to: <xs:complexType name="AckRequestedType"> <xs:sequence> <xs:element ref="wsrm:Identifier"/> <xs:element name="MessageNumber" type="xs:unsignedLong" minOccurs= "0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> to bring it into alignment with the specification prose. Proposal 2 accepted at Sept. 22 F2F Completed in CD 01 I've been thinking a bit about how we might optimize the serialization of the elements in the protocol; doing so without actually changing the abstract properties of the protocol itself. Here's what we have today: <wsrm:Sequence xmlns:wsrm="http://docs.oasis-open.org/wsrx/@@@";> <wsrm:Identifier>http://example.org/mysequence/1234</wsrm:Identifier> <wsrm:MessageNumber>1</wsrm:MessageNumber> <wsrm:LastMessage/> </wsrm:Sequence> I think that if the properties were serialized as attributes, we would have a much more compact serialization: <wsrm:Sequence xmlns:wsrm="http://docs.oasis-open.org/wsrx/@@@" seqID="http://example.org/mysequence/1234"; msgNum="1" last="true"/> The serilaization savings for a Sequence element is 91 bytes per message. For the SequenceAcknowledgement, we could collapse the acknowledgement range elements into a single attribute value that was a sequence of integers. e.g in the simplest case, here would be an example SeqAck: <wsrm:SequenceAcknowledgement xmlns:wsrm="http://docs.oasis-open.org/wsrx/@@@" seqID="http://example.org/mysequence/1234"; ranges="1 1 3 10"> where the @ranges attribute is a list of unsignedLongs. e.g. <xs:simpleType name='rangeType'> <xs:list itemType='xs:unsignedLong'/> </xs:simpleType> The ranges are expressed as "low hi low hi low hi ..." In the example above, message #2, 3 and 4 are missing. Here's an example of a nack: <wsrm:SequenceAcknowledgement xmlns:wsrm="http://docs.oasis-open.org/wsrx/@@@" seqID="http://example.org/mysequence/1234"; nack="2 3 4"> The savings on the SequenceAcknowledgement are 99 bytes/message using the optimized serialization for a SequenceAcknowledgement with no gaps, 148 bytes for one with one gap, 195 bytes for one with two gaps, and 242 for one with three. Basically, it boils down to an additional 47 bytes per gap (in this case using namespace prefix of wsrm) or 42 bytes using the default namespace. core design Chris Ferris Chris Ferris The point of this proposal is not limited to byte savings of serialization. Rather, it has more to do with the efficiency with which the protocol properties can be serialized and deserialized. Especially with the @range attribute, there are far fewer nodes involved. In terms of creation/serialization performance, I found an average savings in serialization (using java) of: Sequence - .0478 ms SequenceAcknowledgement (with 2 gaps) - .19765 ms I haven't had a chance to assess parsing performance benefits yet, but I have to imagine that there would be some benefit. Sure, scoff if you will, but in the context of an server implementation processing a gazillion messages, the performance savings are non-trivial. Think about providing RM support for a customer such as a Ford or FedEx. The sheer volume of messages that they expect to be able to process daily is mind-boggling. Of course, in the context of a message with a WS-Security header, the RM performance and bandwidth overhead pales in comparison for the processing of the overall message, but IMO, there's no reason that RM should exacerbate the issue. If there is a performance and bandwidth optimization that we could effect without actually changing the protocol, I think we should give it serious consideration. As for extensibility, we could still have the Sequence and SequenceAcknowledgement elements extensible via both attributes and elements. There's no reason to change that. This isn't fully fleshed out in terms of line numbers and prose, etc. However, the gist would be to have the protocol elements be as follows: <wsrm:Sequence seqID="[xs:anyURI]" msgNum="[xs:unsignedLong]" last="[xs:boolean]"? .../> <xs:simpleType name='rangeType'> <xs:list itemType='xs:unsignedLong'/> </xs:simpleType> <!-- The ranges are expressed as "low hi low hi low hi ..." --> <wsrm:SequenceAcknowledgement seqID="[xs:anyURI]" [ranges="[wsrm:rangeType]"|nack="[wsrm:rangeType]"] .../> <wsrm:AckRequested seqID="[xs:anyURI]" msgNum="[xs:unsignedLong]"? .../> Close with no action Proposal 2 accepted on Nov 10 TC call Although it is assumed that a NACK will trigger retransmission of a given message from the source to the destination there is no wording in the current version of the spec that describes this feature adequately. core design Steve Winkler Steve Winkler This will clarify to implementers the spirit of the spec by spelling out in more concrete terms what is currently only implied. Add the following to the spec directly before the text that is incorporated as a resolution to i005: Upon the receipt of a Nack, an RM Source SHOULD retransmit the message identified by the Nack as soon as possible. Add the following to the spec directly before the text that is incorporated as a resolution to i005: Upon the receipt of a Nack, an RM Source SHOULD retransmit the message identified by the Nack. Proposal 2 accepted at Sept. 22nd F2F Completed in CD 01 In Section 3.2 of the spec, it states that 'The <SequenceAcknowledgment> header block MAY be transmitted independently, or included on return messages'. A similar statement is made in Section 3.3, 'The RM Source endpoint requests this Acknowledgment by including an <AckRequested> header block in the message'. In both cases, the header can be piggy-backed on a message going to the relevant endpoint. If during the processing of this header, a fault occurs, the spec does not state what should happen. Consider the case where an AckRequested is piggy-backed on a non WS-RM message that happens to be going to the correct endpoint. If the AckRequested turns out to be for an UnknownSequence, the spec states that the fault processing should be as per WS-Addressing, however any EPRs defined in the message are potentially application EPRs and not WS-RM EPRs, so sending a fault to the applications FaultTo EPR may not be the correct thing to do. core design Daniel Millwood Daniel Millwood The piggy-backing of headers is an optimization and as such, it is questionable whether their processing should affect the processing of the original message. The spec should be clear on the expected behaviour of the RM Source and the RM Destination in these cases. Change the wording of the spec to be along the lines of "If a fault occurs when processing an RM Header that was piggy-backed on another message, a fault MUST be generated, but the processing of the original message MUST NOT be affected. If a non-mustUnderstand fault occurs when processing an RM Header that was piggy-backed on another message, a fault MUST be generated, but the processing of the original message MUST NOT be affected. Proposal 2 accepted at Sept. 22nd F2F Completed in CD 01 WS-Addressing Core [1], section 2.1 says the following about 'anon': "Some endpoints cannot be located with a meaningful IRI; this URI is used to allow such endpoints to send and receive messages. The precise meaning of this URI is defined by the binding of Addressing to a specific protocol." WS-Addressing SOAP binding [2] defines what the 'anon' address means when used with ReplyTo and FaultTo in SOAP and SOAP/HTTP binding. It does not say anything about what it means when used in other headers such as AcksTo. core design Anish Karmarkar Umit Yalcinalp WSRM defines AcksTo element of type EndpointReferenceType and allows 'anon' URI for the address. But the meaning of such an anon address is not defined anywhere. This can be resolved by: a) Adding a stmt similar to WS-Addressing SOAP binding. Something like: "When "http://www.w3.org/2005/08/addressing/anonymous"; is specified as the address of the wsrm:AcksTo EPR, the underlying SOAP protocol binding provides a channel to the specified endpoint. Any underlying protocol binding supporting the SOAP request-response message exchange pattern provides such a channel. For instance, the SOAP 1.2 HTTP binding[SOAP 1.2 Part 2: Adjuncts] puts the reply message in the HTTP response." OR b) we could ask the WS-Addressing WG to fix their SOAP binding to include not just ReplyTo and FaultTo EPRs but any EPR when used in the context of SOAP/HTTP binding. I prefer that we do (b). If they refuse, we can do (a) On the Dec. 8 TC call we determined that option b of proposal 1 has been done. Umit's message for details. i012 wsrm:CreateSequence messages can be duplicated, delayed a/o resent by the RMS (for lack of response or lost CreateSequenceResponse). Therefore it is possible that one RMS create Sequence request message may result in creation of multiple (spurious) Sequences at the RMD. Each Sequence at an RMD may require resource reservation resulting in excessive resource utilization or unnecessary refusal from RMD to create new (legitimate) Sequences. core design Anish Karmarkar Anish Karmarkar WSRM spec is created to reliably deliver messages in an unreliable environment, where message may be lost, duplicated, delayed or received out-of-order. This unreliable environment applies not only to payload message but also to protocol signal messages such as wsrm:CreateSequence/wsrm:CreateSequenceResponse messages. Typically on receiving a wsrm:CreateSequence message, the RMD reserves resources for the sequence (when it does not generate a fault) and responds with a wsrm:CreateSequenceResponse. It is possible that the underlying network duplicates/delays/loses the wsrm:CreateSequence message OR it is possible that the RMS resends wsrm:CreateSequence message for a lack of response (or because the wsrm:CreateSequenceResponse message was delayed or lost). In such a scenario the RMD may end up unnecessarily reserving resources (till the expiration time/inactivity Timeout of the Sequence) for Sequences that were never requested. This may result excessive resource utilization or refusal of legitimate Sequence request because of spurious requests taking up all the RMS resources. Require that the RMS include the wsrm:Identifier in the wsrm:CreateSequence request. I.e RMS decides on the identifier for the Sequence rather than the RMD. RMD merely echos the wsrm:Identifier in the wsrm:CreateSequenceResponse that was present in the wsrm:CreateSequence message (or faults). If it is essential that the RMD generate the wsrm:Identifier for the Sequence (and I would like to understand why that is so -- I have some idea of why that may be the case, but not sure if that is the reason why it is so), then a different approach will have to be taken. Something along the lines of: -- require the RMS to specify a suggested wsrm:Identifier in the CS and allow the RMD to ok that or override it in the CSR message. Motion to close with no action passed at 9/22 F2F. Section 2.1 defines the term 'Endpoint'. This is the same definition used by WS-Addressing [1] in section 1. Instead of defining this term again in WSRM, just point to the ws-addr document. core editorial Anish Karmarkar Anish Karmarkar In the spirit of composability and defining something once and reusing it, it makes sense to just refer to the WS-Addressing definition. This also protects us from minor changes in definition in the ws-addr spec (which is not final yet). Replace the current definition by a reference to the WS-Addr spec. Insert the current text from ws addressing with "as defined in ws addressing" as a prefix phrase. Proposal 2 made and accepted on Oct. 13 TC call Completed in CD 2 There are several reference to RFC 2396. This RFC is obsoleted by RFC 3986. core editorial Anish Karmarkar Anish Karmarkar RFC 2396 is obsoleted by RFC 3986. Either replace 2396 with 3986 OR like WS-Addressing, move to IRIs (RFC 3987). Replace reference to RFC2396 with RFC3986,. and to Open AI to open issue to explore which of the uses of the term URI need to be replaced with IRI. Proposal 2 made and accepted on Oct. 13 TC call Completed in CD 2 Lines 270-272 talk about wsrm:Sequence having a mustUnderstand attribute to ensure that the RMD understands it. What it really should say is: have a mU attribute with a value of '1/true'. core editorial Anish Karmarkar Anish Karmarkar Lines 270-272 in [1] say: "... The <wsrm:Sequence> element MUST have a mustUnderstand attribute from the namespace corresponding to the version of SOAP to which the <wsrm:Sequence> SOAP header block is bound." Having a mU attribute does not ensure that the RMD will understand the SOAP header, since the value of the attribute can be '0/false'. Change it to say: "... mustUnderstand attribute with a value of 1/true ..." Proposal 1 accepted at 9/22 F2F. See proposed-04. Completed in CD 01 Section 3 uses 'optional' and 'required' to mean the same thing as 'optional' and 'required' in RFC 2119. To keep the style consistent, these should be capitalized. core editorial Anish Karmarkar Anish Karmarkar Section 3 uses 'optional' and 'required' to mean the same thing as 'optional' and 'required' in RFC 2119. To keep the style consistent, these should be capitalized. Change all occurrences of 'required' to 'REQUIRED' and 'optional' to 'OPTIONAL' in section 3. Proposal 1 accepted at 9/22 F2F. See proposed-05. Completed in CD 01 Page 15, lines 344-345 say : "This element MUST NOT be present if <wsrm:Nack> is also present as a child of <wsrm:SequenceAcknowledgement>." Given that there can be multiple SeqAck headers in a message, this is true only for the same header and not across headers. core editorial Anish Karmarkar Anish Karmarkar WSRM allows multiple SeqAck headers, therefore one can Nack sequence "A" in one header and Ack Sequence "B" in another header in the same message. Replace the sentence in question with "... MUST NOT be present if a sibling <wsrm:Nack> element is also present ..." Proposal 1 accepted on Oct. 13 TC call Completed in CD 2 Page 25, lines 664-665 at [1] says: "WS-ReliableMessaging faults MUST include as the [action] property the default fault action URI defined in the version of WS-Addressing used in the message." This can be interpreted as any version of WS-Addressing is allowed with WSRM. WSRM spec should specify which version of WS-Addressing is used by the spec. A related issue is that: On page 25, lines 664-666 talk about the default "http://schemas.xmlsoap.org/ws/2004/08/addressing/fault"; as the Fault [action] property. This default is defined only for the SOAP binding and is meant to be used with WS-Addr faults not WSRM faults. core design Anish Karmarkar Anish Karmarkar Without clearly indicating which version of WS-Addressing is required/used by the spec, independent implementation will not interoperate. WS-Addressing specification has changed substantially (in certain sections/artifacts of the WS-Addressing spec) over the years. Use the CR version of the spec [2] (in this paragraph as well as the normative reference for the spec) for now and make changes as the addressing spec transitions through the process of becoming a REC. Based on the WS-Addr schedule and WSRM schedule, WS-Addr is slated to become a REC before WSRM is final. For the related issue: change line 664 from -- "WS-ReliableMessaging faults MUST include as the [action] property the default fault" to -- "WS-ReliableMessaging faults MUST include as the [action] property as defined by WS-Addressing [ref]." and delete lines 665-667 Defer updating references to WS-A at this time. We should reopen this issue after WS-A progresses to Proposed Recommendation with the intention of updating the reference when WS-A reaches REC status. Given the importance of the version of WS-Addressing for interop, in deferring this issue I would like to record the sense of the TC (if TC agrees to do so) that for the Implementation SC and interop events/efforts, the TC will be cognizant of the changes that have been made to the WS-Addressing spec by the WS-Addressing WG. For example, Reference Properties have been removed, the syntactic structure of an EPR has changed, the default Action value for faults, default Action algorithm for WSDL, defaulting of wsa:To has changed. Wherever possible the interop effort will adopt the recent changes that have been made to WS-Addressing. Proposal 2 accepted on Oct. 27th TC call , issue is deferred. Edits applied in RM WD 12 and RM Policy WD 8. On page 49, lines 156-1358 in [1], there is a schema import of the wsa namespace in the wsdl:types section. Why is this needed? wsdl editorial Anish Karmarkar Anish Karmarkar The wsa element/types are not used by the schema (embedded in the WSDL) or used in the definition of any of the message constructs. The only place it is used is for wsa:Action (as a WSDL 1.1 extensible attribute). To do that, it is not necessary to schema import the namespace. Remove the xs:import that imports wsa namespace. Proposal 1 accepted on Oct. 13 TC call Completed in CD 2 On page 27, line 745 at