OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: draft issue list 45


Sorry for not getting the issue list updated, here is an interim copy until after today’s call. I will get an update posted today. (Note: This does not reflect the editors work on the pending issues from last week, I’ll catch those and other updates after the call today.)

Title: WS Reliable Messaging Working Issues List


WS Reliable Messaging Working Issues List

Date: 2006/07/06

Revision: 45

Statistics

core soap wsdl policy schema all total
unassigned 0 0 0 0 0 0 0
active 12 0 0 0 0 0 12
pending 15 0 0 0 0 0 15
done 31 0 0 2 0 0 33
deferred 0 0 0 0 0 0 0
resolved 0 0 0 0 0 0 0
closed 57 0 1 6 4 3 72
dropped 14 1 0 3 0 0 18
total 129 1 1 11 4 3 150

Open Issues Summary

id owner title target type
i113 Jacques Durand Tightening up the state tables core design *
i121 Gilbert Pilz security threats and requirements core design *
i122 Gilbert Pilz security profiles core design *
i123 Gilbert Pilz security profile agreement core design *
i124 Gilbert Pilz security composition policy core design *
i134 Update acknowledgements core editorial
i139 Inappropriate Fault destination core design *
i140 Bob Freund add sub-headings to fault descriptions core editorial *
i143 Bob Freund messages have to be received for them to be examined core editorial *
i144 Bob Freund RMS MessageNumberRollover behavior unclear core editorial *
i145 Bob Freund Implications of Sequence Expiration not specified core editorial *
i147 Matthew Lovett Extensibility (or not) of the Protocol Elements core editorial *

Pending Issues Summary

id owner title target type
i125 Paul Fremantle Protocol precondition requires knowledge of policies core design
i126 Chris Ferris unclear text regarding wsa:Action core design
i127 Doug Davis Make Accept/AcksTo consistent core design
i129 Doug Davis Define "discard" core design
i130 Doug Davis what does ack interval refer to core design
i133 Marc Goodner Duplicate text in fault section core editorial
i135 Editors Consistent use of wsrm: in normative text core editorial
i136 Editors RM SeqID Globally Unique core editorial
i137 Anish Karmarkar No mechanisms to convey that messages should be polled. core design
i138 Editors Offer/Accept elements are incomplete core editorial
i141 Bob Freund Sec 3.3 fault response to TerminateSequenceRequest is not specified. core editorial
i142 Bob Freund Sec 3.5 Request Acknowledgement text assumesSequence is known core editorial
i148 Matthew Lovett Reword the Abstract core editorial
i149 Peter Niblett Define the syntax used to refer to elements and attributes core editorial
i150 Umit Yalcinalp Define the syntax used to refer to elements and attributes core editorial

Done Issues Summary

id owner title target type
i007 Marc Goodner WSS 1.0/1.1 token support core design
i021 Jacques Durand An RM Policy applies two-way policy design
i042 Anish Karmarkar Which version of WS-Addressing spec? core design
i061 Doug Davis Anonymous AcksTo core design
i089 Doug Davis suggest the restricted use of anonymous URI core design
i090 Daniel Millwood Use of offered sequences unclear in current spec core design
i091 Bob Freund-Hitachi Unexpected UnknownSequenceFault or SequenceTerminatedFault core design
i092 Anish Karmarkar Where is the SequenceAcknowledgement sent on receipt of AckRequested header? core design
i093 Doug Bunting 2119 terms apply to implementations, not message (document) instances core editorial
i096 Bob Freund Complete the state tables core design
i097 Marc Goodner Extensibility of RM assertion needs to be defined policy editorial
i098 clarify difference between "sequence" and "non-sequence" faults core editorial
i099 Correlating faults to Sequences using SOAP 1.1 core design
i100 Matthew Lovett Language for faultstring elements core editorial
i101 Paul Fremantle Recommend RMD Close rather than Terminate core design
i103 Paul Fremantle Remove the Partial Answer Mode (PAM) core design
i104 Paul Fremantle Mixing SOAP versions core design
i105 Paul Fremantle Sequence Acks on all messages after close core editorial
i106 Bob Freund SequenceAcknowledgement:Final assumption of deliverability core design
i107 Bob Freund Nacks ack as well as Nack core design
i108 Chris Ferris misplaced guidance on fault handling core editorial
i109 Chris Ferris The description of the <Sequence/> element could use some wordsmithing core editorial
i110 Chris Ferris Chris' Rants (on RM) part 1 core editorial
i111 Paul Fremantle Sequence state in event of MessageNumberRollover core design
i112 Chris Ferris dangling reference to RMAssertion acknowledgement timing params core design
i114 Christopher B Ferris Figure 2 (cd3) is out of date with the changes to the potocol core design
i116 Doug Davis Add Max Msg Num to Message Number Rollover Fault core design
i117 Anish Karmarkar Issue 21 resolution text contains language about 'parameters' which don't exist core design
i118 Chris Ferris misuse of request term core editorial
i119 Doug Davis When to piggy-back RM headers core editorial
i120 Gilbert Pilz misplaced paragraph on action IRI's core editorial
i131 Remove sections 1.1 and 1.1.1 core editorial
i132 Change default value of fault uri core design

Resolved Issues Summary

id owner title target type

Deferred Issues Summary

id owner title target type

Closed Issues Summary

id owner title target type
i001 Lei Jin Bilateral sequence negotiation core design
i002 Anish Karmarkar AckTo EPR and seq lifetime core design
i003 Anish Karmarkar EPRs and sequence scope core design
i004 Marc Goodner wsa:messageID uniqueness requirments for retransmission core design
i005 Steve Winkler Source resend of nacks messages when ack already received core design
i006 Tom Rutt Source based delivery QoS policy assertion core design
i008 Tom Rutt Policy assertions granularity policy design
i009 Chris Ferris Declaration of QoS policies core design
i010 Doug Davis Sequence port spanning core design
i011 Doug Davis Typo in expires P0S core editorial
i012 Lei Jin Anonymous acksTo soap design
i013 Doug Davis Max message number in policy core design
i014 Gilbert Pilz Document Names core editorial
i015 Gilbert Pilz Required Artifact Metadata core editorial
i016 Gilbert Pilz Document Identifiers core editorial
i017 Gilbert Pilz XML Namespace URIs schema editorial
i018 Doug Bunting Is an implementation supporting a smaller max message number valid? core design
i019 Jacques Durand Sequence termination on Fault core design
i020 Tom Rutt Semantics of "At most once" Delivery assurance all design
i022 Vikas Deolaliker RM Policy Assertion Model's Base Retransmission Interval Clarification Needed policy design
i023 Marc Goodner Robust recovery from low-resource conditions core design
i024 Ashok Malhotra WS-RX policies not manifested on the wire policy design
i025 Chris Ferris What is the correct form of SeqAck when RMD has received no messages core design
i026 Jacques Durand better support in handling space-greedy sequences core design
i027 Andreas Bjärlestam InOrder delivery assurance spanning multiple sequences core design
i028 Jacques Durand Accurate final acknowledgement of a Sequence with gaps when RMS decides to stop using it core design
i029 Gilbert Pilz Remove dependency on WS-Security core design
i030 Chris Ferris What are the obligations on RMD for use (or not) of Offered Sequence? core design
i031 Chris Ferris Inconsistency between spec and schema (AckRequested) schema editorial
i032 Chris Ferris Protocol serialization optimization proposal core design
i033 Steve Winkler Processing model of NACKs core design
i034 Daniel Millwood If a fault is generated whilst processing a piggy-backed AckRequested or SequenceAcknowledgement header, should this stop processing of the entire message? core design
i035 Umit Yalcinalp What does 'anon' URI mean when used in AcksTo EPR? core design
i036 Anish Karmarkar Duplicate detection of wsrm:CreateSequence messages core design
i037 Anish Karmarkar WS-Addressing Endpoint redefined in WSRM core editorial
i038 Anish Karmarkar 2396 is obsoleted by 3986 core editorial
i039 Anish Karmarkar What does 'have a mustUnderstand attribute' mean? core editorial
i040 Anish Karmarkar Change 'optional' and 'required' in section 3 to RFC 2119 OPTIONAL and REQUIRED core editorial
i041 Anish Karmarkar Presence of NACK and ACK range in the same message core editorial
i043 Anish Karmarkar Why is wsa imported in the WSDL? wsdl editorial
i044 Anish Karmarkar SequenceFault element refers to fault code rather than fault [Subcode] core editorial
i045 Anish Karmarkar Why is SecureConversation a normative reference? core editorial
i046 Anish Karmarkar Schema type of wsrm:FaultCode element can be changed from xs:QName to wsrm:FaultCodes schema editorial
i047 Doug Davis Reorder spec sections core editorial
i048 Doug Davis CloseSequenceResponse and Acks core design
i049 Tom Rutt Allignment and refinement of defintions for DA core design
i050 Marc Goodner spec talks about delivery assurances but does not clearly relate them to the protocol core design
i051 Chris Ferris Presence of multiple <SequenceAcknowledgement> headers for same Sequence in the same message core editorial
i052 Umit Yalcinalp Should DA be separate assertion or parameter policy design
i053 Umit Yalcinalp Which occurances within the specs, if any, of the term "URI" need to be replaced with "IRI"? core editorial
i054 Umit Yalcinalp Target of RM Assertion parameters are confusing with respect to how they are specified and attached policy design
i055 Marc Goodner Whose Inactivity Timeout is it anyway? policy design
i056 Chris Feris How can RMS communicate the Base Retransmission Interval, Exponential Backoff and Inactivity Timeout values? policy design
i057 Umit Yalcinalp Classification of References (normative vs. non-normative) is needed core design
i058 Tom Rutt State Transition Table core editorial
i059 Bob Freund Retransmission behavior core design
i060 Jacques Durand Definition for "Reliable Message" core editorial
i062 Doug Davis None AcksTo core design
i063 Doug Davis SeqAck - None and Final schema editorial
i064 Umit Yalcinalp Create Sequence Refused Fault is too restrictive core design
i065 Matthew Lovett Reword "Closing a Sequence" section core editorial
i066 Doug Davis Remove LastMessage core design
i067 Doug Davis Replace 'response' core editorial
i068 Doug Davis Remove 'correlation' text core editorial
i069 Doug Davis MessageNumber on AckReq core design
i070 Marc Goodner Receive is defined twice in wsrm-1.1-spec-cd-01 core editorial
i071 Marc Goodner Editorial nits for wsrm-1.1-spec-cd-01 core editorial
i072 Marc Goodner Editorial nits for wsrmp-1.1-spec-cd-01 policy editorial
i073 Marc Goodner Descriptive text of removed parameters also needs to be removed policy editorial
i074 Sanjay Patil Use of [tcShortName] in artifact locations namespaces, etc all editorial
i075 Umit Yalcinalp Case of multiple RM Policies and DAs within an RMD scope core design
i076 Matt Lovett Semantics of offered Sequences core design
i077 Matt Lovett How does a RM Destination reject an offered Sequence? core design
i078 Bob Freund Lost TerminateSequence core design
i079 Bob Freund SequenceClosed fault and SequenceAcknowledgement(Final) core editorial
i080 Anish Karmarkar Remove ambiguity about the protocol being at least once on the wire core editorial
i081 Jacques Durand RMS lacks support for InOrder core design
i082 Jacques Durand Level of "response message" unclear, for SequenceResponse core design
i083 Tom Rutt Fault Messages for Terminated Sequence core editorial
i084 Matthew Lovett RMS state table and SequenceClosedFault core editorial
i085 Matthew Lovett CloseSequence element is inconsistent core design
i086 Paul Fremantle Alternative approach for MaxMessage core design
i087 Paul Fremantle Acknowledgement Interval in CreateSequenceResponse core design
i088 Chris Ferris Versioning policy all design
i094 Doug Davis New WSRMRequired Fault core design
i095 Anish Karmarkar CloseSequenceResponse and TerminateSequenceResponse messages are inconsistent wrt presence of wsrm:Identifier spec design
i102 Jacques Durand consistency in controlling the binding of SequenceAcknowledgement and of seq management responses core design
i115 Gilbert Pilz "must understand" attribute for extensions to RM components core design
i128 define unspecified IncompleteSequenceBehavior core design
i146 Bob Freund Editorial Examples in Apx C lack CloseSequence core editorial

Detailed Listing

i001 Bilateral sequence negotiation core - design - closed
Description
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.

Justification
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.
Related Issues
i021
Origin
F2F - Lei Jin
Owner
Lei Jin
Proposal 12005-08-25
From restated issue

Delete lines 221-226 of WSRX-ReliableMessagingPolicy document.

Resolution2006-09-01
Proposal 1 accepted on Sept. 1 call.
Resolution2005-10-27
Completed in CD 01
i002 AckTo EPR and seq lifetime core - design - dropped
Description
Should the AckTo EPR be allowed to change during the lifetime of a sequence?
Justification
Raised at F2F
Related Issues
Origin
F2F - Anish Karmarkar
Owner
Anish Karmarkar
Proposal 12005-10-22

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

Proposal 22005-11-03

See message

Close with no action.

Resolution2005-11-10
Proposal 2 accepted on Nov 10 TC call
i003 EPRs and sequence scope core - design - dropped
Description
Which pair of EPRs define the scope of a sequence?
Justification
Raised at F2F
Related Issues
Origin
F2F - Anish Karmarkar
Owner
Anish Karmarkar
Proposal 12005-09-22
Close with no action
Resolution2005-09-22
Proposal 1 accepted at Sept. 22 F2F
i004 wsa:messageID uniqueness requirments for retransmission core - design - dropped
Description
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?
Justification
Raised at F2F
Related Issues
Origin
F2F - Steve Winkler
Owner
Marc Goodner
Proposal 12005-09-01
Close with no change required
Resolution2005-09-01
Proposal 1 accepted
i005 Source resend of nacks messages when ack already received core - design - closed
Description
Is the sender required to resend a message identified in a Nack, if it has already received an ack for that same messageNumber?
Justification
Raised at F2F
Related Issues
Origin
F2F - Steve Winkler
Owner
Steve Winkler
Proposal 12005-09-08
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>.
Resolution2006-09-08
Proposal 1 made and accepted on Sept. 8th TC call.
Resolution2005-10-27
Completed in CD 01
i006 Source based delivery QoS policy assertion core - design - dropped
Description
Is there a requirement that the sender can assert that the receiver must deliver a particular reliability assurance on a given sequence?
Justification
Raised at F2F. Also raised on list by Tom Rutt.
Related Issues
Origin
F2F - Tom Rutt
Owner
Tom Rutt
Proposal 12005-10-11
See mail: close issue with no changes to specfication.
Proposal 22005-10-26

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.

Resolution2005-12-14
Closed with no action at December 14th F2F meeting
i007 WSS 1.0/1.1 token support core - design - done
Description
Must the ws-reliable messaging spec support tokens produced for both ws-security 1.0 and ws-security 1.1?
Justification
Raised at F2F
Related Issues
Origin
F2F - Paul Cotton
Owner
Marc Goodner
Proposal 12005-08-04
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 2006-03-22
Resolution 2006-03-22
Proposal 2 accepted at March 22nd F2F.
i008 Policy assertions granularity policy - design - dropped
Description
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".
Justification
Raised at F2F Also raised on list by Tom Rutt.
Related Issues
Origin
F2F - Tom Rutt
Owner
Tom Rutt
Proposal 12005-10-11

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.

Resolution 2006-03-22
Closed with no action at the March 22nd F2F as it was addressed by resolution to i021.
i009 Declaration of QoS policies core - design - closed
Description
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.
Justification
"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."
Related Issues
Origin
Chris Ferris
Owner
Chris Ferris
Proposal 12005-09-21

<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'.

Resolution2005-09-21
Proposal 1 accepted at Sept. 22 F2F, new issue to be opened to define whether the above is an assertion or a parameter.
Resolution2005-10-27
Completed in CD 01
i010 Sequence port spanning core - design - closed
Description
Is there a need to allow a single sequence to span multiple ports?
Justification
"Having a single sequence span multiple ports (much like an MQ queue does) could be needed as well."
Related Issues
Origin
Doug Davis
Owner
Doug Davis
Proposal 12005-10-09
See this email and attachment
Proposal 2
See attachment in this message
Resolution2005-10-27
Proposal 2 accepted on Oct. 27th TC call
Resolution2006-01-05
Completed in CD 2
i011 Typo in expires P0S core - editorial - closed
Description
Per the schema spec a zero second duration needs to have the "T" designator - so it should be PT0S not P0S.
Justification
align with schema spec ( http://www.w3.org/TR/xmlschema-2/#duration )
Related Issues
Origin
Doug Davis
Owner
Doug Davis
Proposal 12005-07-14
simple search and replace of P0S with PT0S
Resolution2006-07-21
Proposal accepted at July 21st TC meeting , no objections.
Resolution2005-10-27
Completed in CD 01
i012 Anonymous acksTo soap - design - dropped
Description
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.
Justification
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).
Related Issues
Origin
Lei Jin
Owner
Lei Jin
Proposal 12005-07-11
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.

Proposal 22005-07-11
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.

Proposal 32005-07-11
Response to each proposal above from Chris Ferris, proposal 1 out of scope and proposal 2 not an issue.
Proposal 42005-09-08
Close issue without change to spec.
Resolution2006-09-08
Proposal 4 made and accepted on Sept. 8 TC call.
i013 Max message number in policy core - design - closed
Description
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.
Justification
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.
Related Issues
Origin
Doug Davis
Owner
Doug Davis
Proposal 12005-08-08
Original proposal from raised issue , revised proposal

In the WS-RM Policy doc:

After line 173, add to the normative outline: <wsrm:MaxMessageNumber Number="xs:unsignedLong" ... /> ?

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:

        <xs:element name="MaxMessageNumber" minOccurs="0" > 
    <xs:complexType> 
    <xs:attribute name="Number" 
                    type="xs:unsignedLong" use="required" /> 
    <xs:anyAttribute namespace="##any" processContents="lax" /> 
    </xs:complexType> 
</xs:element>
      

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.

Resolution2005-08-11
Proposal 1 accepted at August 11 TC call.
Resolution2005-10-27
Completed in CD 01
i014 Document Names core - editorial - closed
Description
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.
Justification
The name of a document effects a number of things such as the document identifier, URIs etc.
Related Issues
Origin
Gilbert Pilz
Owner
Gilbert Pilz
Proposal 12005-07-13
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).

Resolution2005-08-04
First proposal accepted on Aug. 4th conf call , no objections
i015 Required Artifact Metadata core - editorial - closed
Description
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.
Justification
OASIS requirement.
Related Issues
i074
Origin
Gilbert Pilz
Owner
Gilbert Pilz
Proposal 12005-07-13
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.

Proposal 22005-08-18
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

Resolution2005-08-18
Proposal 2 accepted on TC call on Aug. 18th
i016 Document Identifiers core - editorial - closed
Description
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
Justification
Self-evident
Related Issues
i074
Origin
Gilbert Pilz
Owner
Gilbert Pilz
Proposal 12005-07-13
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).

Proposal 22005-08-18
Link

wsrm-1.1-spec-wd-01.*

wsrmp-1.1-spec-wd-01.*

Resolution2005-08-18
Link

Proposal 2 accepted on Aug 18th TC call

i017 XML Namespace URIs schema - editorial - closed
Description
We need to decide upon the normative XML namespace URIs that must be used by implementations of these specifications
Justification
Self-evident
Related Issues
i074
Origin
Gilbert Pilz
Owner
Gilbert Pilz
Proposal 12005-07-13
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).

Proposal 22005-07-13
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

Proposal 3
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

Proposal 42005-08-18
Link

http://docs.oasis-open.org/wsrm/yyyymm/

http://docs.oasis-open.org/wsrmp/yyyymm/

Resolution2005-08-18
Link

Proposal 4 made and accepted on Aug 18th TC call.

i018 Is an implementation supporting a smaller max message number valid? core - design - closed
Description
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?
Justification
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".
Related Issues
i013 i019
Origin
Doug Bunting
Owner
Doug Bunting
Proposal 12005-07-14
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".

Proposal 22005-07-28
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.

Resolution2005-07-28
Second proposal accepted on Jul 28th TC call , no objections.
i019 Sequence termination on Fault core - design - closed
Description
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

Justification
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.
Related Issues
Origin
Jacques Durand
Owner
Jacques Durand
Proposal 12005-07-15
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.

Proposal 2
As outlined in message number 76
Resolution2005-09-15
Proposal 2 accepted on Sept. 15th TC call.
Resolution2005-10-27
Completed in CD 01
i020 Semantics of "At most once" Delivery assurance all - design - closed
Description

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.

Justification
It is important to clarify whether the sender must retransmit unacknowledged messages when the "at most once" delivery assurance is in use.
Related Issues
i009
Origin
Tom Rutt
Owner
Tom Rutt
Proposal 12005-07-21
Link

Clarify the semantics. There are at least three possible semantics associated with "at most once"

  1. At most once means that the sender will never retransmit a message, regardless of whether it is acknolweged by the destination.
  2. The sender may retransmis messages, but is not required to to so, however the destination will not deliver duplicates
  3. The sender must retransmit messages, however the destination may drop messages in times of resource saturation, but will never deliver a duplicate.
Proposal 22005-09-21

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.

Resolution2005-09-21
Proposal 2 accepted at Sept. 21 F2F
Resolution2005-10-27
Completed in CD 01
i021 An RM Policy applies two-way policy - design - done
Description
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.
Justification
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.
Related Issues
Origin
Jacques Durand
Owner
Jacques Durand
Proposal 12005-07-21
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).
Proposal 22006-01-13

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.

Proposal 32005-12-15

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 4 2006-02-09

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.

Proposal 5 2006-03-01

(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 6 2006-03-07
Proposal 7 2006-03-22
Resolution 2006-03-22
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.
i022 RM Policy Assertion Model's Base Retransmission Interval Clarification Needed policy - design - closed
Description

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

Justification
There is no obvious case mentioned in the spec that requires two timers for retransmission upon timeout.
Related Issues
Origin
Vikas Deolaliker
Owner
Vikas Deolaliker
Proposal 12005-08-04
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.

Proposal 22005-10-21

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

Proposal 32005-11-02

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.

Proposal 42005-11-03

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?)

Resolution2005-11-03
Proposal 4 accepted at Nov 3rd TC call
Resolution2006-01-05
Completed in CD 2
i023 Robust recovery from low-resource conditions core - design - dropped
Description
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.
Justification
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.
Related Issues
Origin
Sanjay Patil
Owner
Marc Goodner
Proposal 12005-07-26
Link RM Protocol to support RMD pushing back on the RMS for slowing down or stopping (re)transmission of messages.
Proposal 22005-10-12

See message

Close with no action.

Proposal 32005-11-02

See message

Resolution2005-11-03
Proposal 2 accepted at Nov 3rd TC call
i024 WS-RX policies not manifested on the wire policy - design - closed
Description

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.

Justification
See description
Related Issues
i009 i013
Origin
Ashok Malhotra
Owner
Ashok Malhotra
Proposal 12005-09-21
Close with clarification of meaning of observed to be added to spec.
Resolution2005-09-21
Proposal 1 accepted at Sept. 21 F2F
Resolution2005-10-20

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"

Resolution2006-01-05
Completed in CD 2
i025 What is the correct form of SeqAck when RMD has received no messages core - design - closed
Description

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?

Justification

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.

Related Issues
Origin
Chris Ferris
Owner
Chris Ferris
Proposal 12005-07-20

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>

Proposal 22005-09-22

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...)

Resolution2005-09-22
Proposal 2 accepted at Sept. 22 F2F
Resolution2005-10-27
Completed in CD 01
i026 better support in handling space-greedy sequences core - design - dropped
Description
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.)
Justification
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.
Related Issues
Origin
Jacques Durand
Owner
Jacques Durand
Proposal 12005-08-09
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.
Resolution2005-09-21
Closed with no action at Sept. 21 F2F
i027 InOrder delivery assurance spanning multiple sequences core - design - closed
Description
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.
Justification
InOrder is one of the supported delivery assurances. The scope of the ordering should be clear.
Related Issues
Origin
Andreas Bjärlestam
Owner
Andreas Bjärlestam
Proposal 12005-09-14
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.
Resolution2005-09-15
Proposal 1 accepted on Sept. 15th TC call.
Resolution2005-10-27
Completed in CD 01
i028 Accurate final acknowledgement of a Sequence with gaps when RMS decides to stop using it core - design - closed
Description

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.)

Justification

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.)

Related Issues
Origin
Jacques Durand
Owner
Jacques Durand
Proposal 12005-08-11
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.
Proposal 2
As outlined in message number 76
Resolution2005-09-15
Proposal 2 accepted on Sept. 15th TC call.
Resolution2005-10-27
Completed in CD 01
i029 Remove dependency on WS-Security core - design - closed
Description
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.
Justification

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.

Related Issues
i007
Origin
Gilbert Pilz
Owner
Gilbert Pilz
Proposal 12005-08-17
  • Delete lines 458-461 of WS-ReliableMessaging-v1.0-wd-01

  • Delete lines 502-508 of WS-ReliableMessaging-v1.0-wd-01

Proposal 22005-09-22
Remove lines 450-452 and 494-500
Resolution2005-09-22
Proposal 2 accepted at Sept. 22 F2F
Resolution2005-10-27
Completed in CD 01
i030 What are the obligations on RMD for use (or not) of Offered Sequence? core - design - closed
Description
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?
Justification

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.

Related Issues
i001 i030
Origin
Chris Ferris
Owner
Chris Ferris
Proposal 12005-08-25
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.
Proposal 22005-09-27

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

Resolution2005-10-06
Proposal 2 accepted
Resolution2006-01-05
Completed in CD 2
i031 Inconsistency between spec and schema (AckRequested) schema - editorial - closed
Description

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>
      
Justification
There is a clear discrepancy between the spec and the schema
Related Issues
Origin
Chris Ferris
Owner
Chris Ferris
Proposal 12005-08-29

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>.

Proposal 22005-09-14

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.

Resolution2005-09-22
Proposal 2 accepted at Sept. 22 F2F
Resolution2005-10-27
Completed in CD 01
i032 Protocol serialization optimization proposal core - design - dropped
Description

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.

Justification

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.

Related Issues
Origin
Chris Ferris
Owner
Chris Ferris
Proposal 12005-08-30
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]"? .../>
      
Proposal 22005-11-10
Close with no action
Resolution2005-11-10
Proposal 2 accepted on Nov 10 TC call
i033 Processing model of NACKs core - design - closed
Description
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.
Justification
This will clarify to implementers the spirit of the spec by spelling out in more concrete terms what is currently only implied.
Related Issues
Origin
Steve Winkler
Owner
Steve Winkler
Proposal 12005-09-08
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.
Proposal 22005-09-22
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.
Resolution2005-09-22
Proposal 2 accepted at Sept. 22nd F2F
Resolution2005-10-27
Completed in CD 01
i034 If a fault is generated whilst processing a piggy-backed AckRequested or SequenceAcknowledgement header, should this stop processing of the entire message? core - design - closed
Description
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.
Justification
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.
Related Issues
Origin
Daniel Millwood
Owner
Daniel Millwood
Proposal 12005-09-08
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.
Proposal 22005-09-22
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.
Resolution2005-09-22
Proposal 2 accepted at Sept. 22nd F2F
Resolution2005-10-27
Completed in CD 01
i035 What does 'anon' URI mean when used in AcksTo EPR? core - design - closed
Description

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.

Justification
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.
Related Issues
i012
Origin
Anish Karmarkar
Owner
Umit Yalcinalp
Proposal 12005-09-08

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)

Resolution2005-12-08
On the Dec. 8 TC call we determined that option b of proposal 1 has been done. Umit's message for details.
i036 Duplicate detection of wsrm:CreateSequence messages core - design - dropped
Description
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.
Justification
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.
Related Issues
Origin
Anish Karmarkar
Owner
Anish Karmarkar
Proposal 12005-09-21
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.
Resolution2005-09-22
Motion to close with no action passed at 9/22 F2F.
i037 WS-Addressing Endpoint redefined in WSRM core - editorial - closed
Description
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.
Justification
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).
Related Issues
Origin
Anish Karmarkar
Owner
Anish Karmarkar
Proposal 12005-09-21
Replace the current definition by a reference to the WS-Addr spec.
Proposal 22005-10-13
Insert the current text from ws addressing with "as defined in ws addressing" as a prefix phrase.
Resolution2005-10-13
Proposal 2 made and accepted on Oct. 13 TC call
Resolution2006-01-05
Completed in CD 2
i038 2396 is obsoleted by 3986 core - editorial - closed
Description
There are several reference to RFC 2396. This RFC is obsoleted by RFC 3986.
Justification
RFC 2396 is obsoleted by RFC 3986.
Related Issues
Origin
Anish Karmarkar
Owner
Anish Karmarkar
Proposal 12005-09-21
Either replace 2396 with 3986 OR like WS-Addressing, move to IRIs (RFC 3987).
Proposal 22005-10-13
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.
Resolution2005-10-13
Proposal 2 made and accepted on Oct. 13 TC call
Resolution2006-01-05
Completed in CD 2
i039 What does 'have a mustUnderstand attribute' mean? core - editorial - closed
Description
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'.
Justification

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'.

Related Issues
Origin
Anish Karmarkar
Owner
Anish Karmarkar
Proposal 12005-09-21
Change it to say: "... mustUnderstand attribute with a value of 1/true ..."
Resolution2005-09-22
Proposal 1 accepted at 9/22 F2F. See proposed-04.
Resolution2005-10-27
Completed in CD 01
i040 Change 'optional' and 'required' in section 3 to RFC 2119 OPTIONAL and REQUIRED core - editorial - closed
Description
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.
Justification
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.
Related Issues
Origin
Anish Karmarkar
Owner
Anish Karmarkar
Proposal 12005-09-21
Change all occurrences of 'required' to 'REQUIRED' and 'optional' to 'OPTIONAL' in section 3.
Resolution2005-09-22
Proposal 1 accepted at 9/22 F2F. See proposed-05.
Resolution2005-10-27
Completed in CD 01
i041 Presence of NACK and ACK range in the same message core - editorial - closed
Description

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.

Justification
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.
Related Issues
Origin
Anish Karmarkar
Owner
Anish Karmarkar
Proposal 12005-09-21
Replace the sentence in question with "... MUST NOT be present if a sibling <wsrm:Nack> element is also present ..."
Resolution2005-10-13
Proposal 1 accepted on Oct. 13 TC call
Resolution2006-01-05
Completed in CD 2
i042 Which version of WS-Addressing spec? core - design - done
Description

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.

Justification
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.
Related Issues
Origin
Anish Karmarkar
Owner
Anish Karmarkar
Proposal 12005-09-21

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

Proposal 2

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.

Resolution2005-10-27
Proposal 2 accepted on Oct. 27th TC call , issue is deferred.
Resolution 2006-04-27
Edits applied in RM WD 12 and RM Policy WD 8.
i043 Why is wsa imported in the WSDL? wsdl - editorial - closed
Description
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?
Justification
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.
Related Issues
Origin
Anish Karmarkar
Owner
Anish Karmarkar
Proposal 12005-09-21
Remove the xs:import that imports wsa namespace.
Resolution2005-10-13
Proposal 1 accepted on Oct. 13 TC call
Resolution2006-01-05
Completed in CD 2
i044 SequenceFault element refers to fault code rather than fault [Subcode] core - editorial - closed
Description
On page 27, line 745 at [1] refers to fault code rather than fault [Subcode].
Justification
Fault codes are either Sender or Receiver which map to S11:Client or S11:Server for SOAP 1.1. The text in question is actually talking about the fault [Subcode]s that are defined subsequently.
Related Issues
Origin
Anish Karmarkar
Owner
Anish Karmarkar
Proposal 12005-09-21

Either:

1) refer to fault [Subcode] instead of fault code

Or:

2) refer to fault [Subcode] instead of fault code and change the element from wsrm:SequenceFault/wsrm:FaultCode to wsrm:SequenceFault/wsrm:FaultSubcode to match the abstract property that is being conveyed.

I prefer (2).

Proposal 22005-10-13
change sentence line 745 and 746 of WD 03 (9/19) to refer to fault [Subcode] instead of fault code
Resolution2005-10-13
Proposal 2 made and accepted on Oct. 13 TC call
Resolution2006-01-05
Completed in CD 2
i045 Why is SecureConversation a normative reference? core - editorial - closed
Description
SecureConversation is listed as a normative reference, but it is never referenced from anywhere (which needs to be fixed). More importantly, only the security considerations section talks about SecureConversation but in a non-normative way.
Justification
A non-normative reference is listed under normative reference.
Related Issues
Origin
Anish Karmarkar
Owner
Anish Karmarkar
Proposal 12005-09-21
Include the [SecureConversation] reference wherever the Security Consideration section talks about it and move it to the non-normative reference section.
Resolution2005-09-22
Proposal 1 accepted at 9/22 F2F. See proposed-11.
Resolution2005-10-27
Completed in CD 01
i046 Schema type of wsrm:FaultCode element can be changed from xs:QName to wsrm:FaultCodes schema - editorial - closed
Description

Page 37, line 1027 of [1] makes the type of wsrm:FaultCode as xs:QName. This element is already restricted to the QNames listed in the schema type wsrm:FaultCodes.

Related issues:

Editorial issue about changing wsrm:FaultCodes to wsrm:FaultCodeType, raised in the email at [2]

Justification
Although the schema is correct, it would be more appropriate and narrowly/tightly scoped by using the type wsrm:FaultCodes instead of xs:QName
Related Issues
Origin
Anish Karmarkar
Owner
Anish Karmarkar
Proposal 12005-09-21

Replace line 1027 from -

<xs:element name="FaultCode" type="xs:QName"/>

to -

<xs:element name="FaultCode" type="wsrm:FaultCodes"/>

Resolution2005-09-22
Proposal 1 accepted at 9/22 F2F. See proposed-12.
Resolution2005-10-27
Completed in CD 01
i047 Reorder spec sections core - editorial - closed
Description
The current order in which the RM spec talks about the protocol elements is:         Sequence header       SeqAck header         ReqAck header         CreateSequence         TerminateSequence         CloseSequence I'd like to reorder them based on how we actually expect people to use them.
Justification
Helps in understanding the spec.
Related Issues
Origin
Doug Davis
Owner
Doug Davis
Proposal 12005-09-21

Change the order to be:

CreateSequence

Sequence header

ReqAck header

SeqAck header

CloseSequence

TerminateSequence

Proposal 22005-09-22

Postpone incorporation until after the first CD

Change the order to be:

CreateSequence

CloseSequence

TerminateSequence

Sequence header

ReqAck header

SeqAck header

Resolution2005-09-22
Proposal 2 accepted at Sept. 22 F2F, see proposed-13
Resolution2006-01-05
Completed in CD 2
i048 CloseSequenceResponse and Acks core - design - closed
Description
Using the CloseSequence operation a RMS will be able to get the true final accounting of the ACKs for a sequence - sort of.  There is one case that could be problematic.  Let's say that the CreateSequence operation is given a bad AcksTo EPR.  In this case no Acks will ever be received by the RMS - and this could be the reason for it closing the sequence.  However, if all ACKs are always sent to the AcksTo EPR then the RMS will have no choice but to eventually Terminate the sequence (or wait for it to timeout) without ever getting the true final accounting of Acks.  This would leave the RMS and RMD with a very different view of the state of the sequence.
Justification
See description.
Related Issues
Origin
Doug Davis
Owner
Doug Davis
Proposal 12005-09-21

To solve this I'd like to require that the CloseSequenceResponse message include the "final" Ack.

So, using [1]:

Replace the text on line 608:

Upon receipt of this message the RM Destination MUST send a SequenceAcknowledgement to the RM Source.

With:

Upon receipt of this message the RM Destination MUST send a   SequenceAcknowledgement to the RM Source in the   CloseSequenceResponse message.

Resolution2005-10-06
Proposal 1 accepted and further described here.
Resolution2006-01-05
Completed in CD 2
i049 Allignment and refinement of defintions for DA core - design - dropped
Description
I took an action Item to align the Delivery Assurance definition text in the body document with the resolution of Issue 009.
Justification

The resolution of Issue 009 is documented here:

It is best if the Delivery assurances are defined in only one place in the document.

There is a discrepancy with the current text in secton 2 and the resolution of issue 009, regarding the necessity for raising an error on at least one endpoint.

The definition in the current text of DA in Section 2 :

There are four basic delivery assurances that endpoints can provide:

- AtMostOnce Messages will be delivered at most once without duplication or an error will be raised on at least one endpoint. It is possible that some messages in a sequence may not be delivered.

- AtLeastOnce Every message sent will be delivered or an error will be raised on at least one endpoint. Some messages may be delivered more than once.

- ExactlyOnce Every message sent will be delivered without duplication or an error will be raised on at least one endpoint. This delivery assurance is the logical "and" of the two prior delivery assurances.

- 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 sequence observed by the ultimate receiver be non-decreasing. It says nothing about duplications or omissions.

while the current text for resolution of issue 009 adds the following for DA policy assertion:

<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'.

Related Issues
Origin
Tom Rutt
Owner
Tom Rutt
Proposal 12005-10-06

The proposal to resolve this ISSUE is presented in Three Steps.

Step 1) of Proposed Resoluton: Change the use of in line definitions in the proposal for Issue 009 to references to the definitions in section

Resulting text for Proposal for Issue 009:

<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 which delivery assurance is asserted.

A value of 'AtMostOnce' means that the Delivery Assurance “at Most Once, defined in section xxx, is asserted.

A value of 'AtLeastOnce' means that the Delivery Assurance “At Least Once”, defined in section xxx, is asserted..

A value of 'ExactlyOnce' means that the Delivery Assurance “Exactly Once”, defined in section xxx, is asserted.

/wsrm:DeliveryAssertion/@ordered

This attribute, of type xs:boolean, specifies whether, or not, the “in order” reliability function defined in section xxx is asserted. . A value of 'true' asserts that the “in order” reliability function is required. A value of 'false' asserts that the “in order” reliability function is not required. If omitted, the default implied value is 'false'.

Step 2) of Proposed Resolution: Clarify Definitions of Delivery assurances, including the requirment for error indication.

We need to align the two definitions and put the resulting agreed text in section 2:

- the definitions of AtLeastOnce and of ExactlyOnce from Issue 009 do not mention the possibility of an error (delivery failure) while they do in the current core spec definition. Is that intentional, or a lapse? It seems the the same reasons that may lead an RMD to drop received messages under AtMostOnce, may also apply under AtLeastOnce (e.g. some resource shortage). The difference seems to be about proper error raising/notification when a received message is not delivered..

- Similarly, AtMostOnce as defined in the resolution to issue 009 assumes that duplicates are never delivered - that seems stronger than the original requirement in the core spec that says "... or else an error will be raised". These need to be aligned one way or the other.

Resolution2005-12-14
Issue dropped as misaligned text no longer exists due to resolution of i050 December 14th F2F meeting
i050 spec talks about delivery assurances but does not clearly relate them to the protocol core - design - closed
Description
The WS-ReliableMessaging specification talks about delivery assurances but does not clearly relate them to the protocol.
Justification
This vague definition of the relationship between delivery assurances and the protocol has caused (extreme) confusion and does not clearly describe how the protocol is intended to be used.
Related Issues
Origin
Stefan Batres
Owner
Marc Goodner
Proposal 12005-09-26

One proposal that has been kicked around by the TC consists of:

a) Remove all references to delivery assurances from the WS-RM spec.

b) Describe, in detail, DA's in the policy spec (since we're adding an Assurances element to that document anyway).

c) Create a new deliverable for the TC; a profiles document. The profiles would describe how the protocol should be used to implement the various delivery assurances.

Other variants on this have been proposed as well. The point is to make it more obvious that DA's are a contract between RMS/RMD and apps whereas the protocol is about guaranteed transfer between RMS and RMD and enables the implementation of DA's between RMS/RMD and apps.

Proposal 22005-12-14

Remove DA assertions from policy spec.

Replace lines 135 to 159 with the text "The protocol supports reliability features which include ordered delivery, duplicate elimination, and guaranteed receipt for the RMD. It is expected that the AD and RMD will implement as many of these or as few of these characteristics as necessary to implement the AD. In any case the wire protocol does not change."

Remove DA from the glossary on lines 176 to 177

Resolution2005-12-14
Proposal 2 accepted at December 14th F2F meeting
Resolution2006-01-05
Completed in CD 2
i051 Presence of multiple <SequenceAcknowledgement> headers for same Sequence in the same message core - editorial - closed
Description

Anish has a proposal[2] for resolving i041[1]. I think that his proposed resolution clears up the ambiguity of the co-occurance of a <Nack/> and an <AckRange> in the same <SeqAck>, and that makes the prose consistent with the schema which uses an xs:choice.

However, reading the issue itself lead me to consider that the spec says nothing about the presence of multiple <SeqAck> header blocks that might share the same <Identifier> in a given message.

Justification
I don't believe that it was never intended to permit multiple <SequenceAcknowledgement> elements belonging to the same sequence in a given message.
Related Issues
i041
Origin
Chris Ferris
Owner
Chris Ferris
Proposal 12005-10-11

Add the following language to the spec after line 340 (pdf wd 03)[3]:

A message MUST NOT contain multiple <SequenceAcknowledgement> header blocks that share the same value for <Identifier>.

Resolution2005-10-13
Accepted proposal 1 on Oct. 13 TC call
Resolution2006-01-05
Completed in CD 2
i052 Should DA be separate assertion or parameter policy - design - dropped
Description
The resolution to issue i009, created an element for DeliveryAssurance: <wsrm:DeliveryAssertion mode="[AtLeastOnce|AtMostOnce|ExactlyOnce]" ordered="[xs:boolean]"? ...="" > The question that was not resolved as part of that discussion is whether the element should be a child of <wsrm:RMAssrtion> or whether it should be a separate assertion.
Justification
We need to make a decision
Related Issues
i009
Origin
Chris Ferris
Owner
Umit Yalcinalp
Resolution2005-12-14
Issue dropped as DA no longer exists in policy spec due to resolution of i050 December 14th F2F meeting
i053 Which occurances within the specs, if any, of the term "URI" need to be replaced with "IRI"? core - editorial - closed
Description
In closing i038, we determined that it would be necessary to review each use of the term URI to determine whether it needed to be replaced with "IRI" and thus require the addition of a reference to RFC3987.
Justification
Ensure correct use of the terminology within the spec wherever a URI could be an IRI.
Related Issues
i038
Origin
Chris Ferris
Owner
Umit Yalcinalp
Proposal 12005-10-24

Here are the references to URI that should and should not be updated to IRI... see message

Proposal 22005-11-03

After reviewing our previous proposal for i053 we have come to the conclusion that the only URI references that need to be updated to IRI are those that are inherited from WS-Addressing. There are three of these changes from URI to IRI are all around WS-A Action, two are in the same paragraph saying that unless there is a value (a IRI) for Action derived from WS-A rules it is a value defined in WS-RM (a URI). The other is about using the default value for Fault (a IRI) from WS-A in Action.

It is not necessary to change the sequence identifier to IRI as we previously proposed. Therefore we propose the following changes to satisfy i053...

See message for line number details of changes

Resolution2005-11-10
Proposal 2 accepted with amendment that line 321 be IRI so that WSA action is consistently IRI on Nov 10 TC call
Resolution2006-01-05
Completed in CD 2
i054 Target of RM Assertion parameters are confusing with respect to how they are specified and attached policy - design - closed
Description

Currently the WS-RM Policy Assertion describes four distinctive parameters in Section 2.1: Base Retransmission Interval, Exponential Backoff, Inactivity Timeout and Acknowledgement Interval. Further, these parameters are scoped with respect to two distinct roles as summarized below:

RMS:

-- Base Retransmission Interval (BRI)

-- Exponential Backoff (EB)

-- Inactivity Timeout (IT)

RMD:

-- Inactivity Timeout (IT)

-- Acknowledgement Interval (AI)

Clearly there is a separation between which roles these assertions would apply in the specification. However, the definition of the RM assertion includes ALL of the parameters regardless of the role. This causes a problem in interpreting what is being intended in Section 2.3 [1] which describes attachment of the policy. From the perspective of WSDL, the service is always described from the perspective of the provider and lists the requirements of the provider. Hence the WS-Policy attachment of RM Assertion will appear to apply to RMD alone. If we were to take this assumption into consideration, semantics of supplying all the 4 parameters in a RM Assertion is not very clear.

There are two possible interpretations:

(1) Although, there are two separate roles of RMS and RMD, it is the RMD who owns the WSDL and dictates all these parameters. This means the BRI, EB although are defined for RMS, are not really defined by RMS. RMS in essence has no control over these parameters. Note that this interpretation appears to contradict the Lines 112-113 and 117-119.

(2) All the parameters appearing in a WSDL for RMD are applicable for the RMD only. However each parameter is scoped to request and/or response. For example, the BRI, EB and IT will apply when the RMD acts in a sender role (for a response message), and only the IT and AI apply in the RMD's receiver role (for a request message). RMS is free to use its own parameters. Note that this interpretation appears to conflict with the example provided in Section 2.3, lines 225-227 where RMS is mentioned, but it is not stated that the RMD will be in the role of sender when these parameters apply.

It is not clear which of the above interpretations is correct. Further, different sections of the specification are in conflict with each other regardless of the interpretation assumed as illustrated above.

Justification
It should be clear in the specification where the assertion parameters apply and how. Currently, there are two distinct and possible interpretations leading to confusion. Further, not making the clarification affects resolution of issues that pertain to attachment of policy in general since it is not obvious how the RM Assertion parameters apply with respect to the roles that are acknowledged in the specification.
Related Issues
i021 i006
Origin
Umit Yalcinalp
Owner
Umit Yalcinalp
Proposal 12005-10-18
Clarify and explicitly state in the specification that each role manages its own parameters. Update the example to include in the WSDL only the parameters that are applicable to RMD: IT and AI. In addition, clarify whether the parameters that apply to RMS may be used within the content of RM Assertions and when.
Proposal 22005-11-02

See message

As indicated for the proposal for resolving i022 [1], we favor retaining InactivityTimeout and AcknowledgementInterval in the WS-RM Policy specification.

If we retain these two parameters, we think that the values that are specified in the policy document are applied to RMD only to resolve i054[2]. The attachment of values apply to the endpoint/binding hence they should pertain to RMD.

Note that we acknowledge that RMS may also have an InactivityTimeout which may be internal to the RMS, but it is not specified in the policy document. As far as the Policy Attachment is concerned, we would like to see Inactivity Timeout (as well as Acknowledgement Interval) to apply to RMD configuration. This is basically a variation of proposal 1 in the original issue posting.

Proposal 32005-11-08

See message, line numbers refer to wsrmp-1.1-spec-cd-01.

Change lines 148-149 from:

"The assertion defines an inactivity timeout parameter that either the RM Source or RM Destination MAY include."

To:

"The assertion defines an inactivity timeout parameter that the RM Destination MAY include."

Resolution2005-11-17
Proposal 3 accepted on Nov. 17th TC call
Resolution2006-01-05
Completed in CD 2
i055 Whose Inactivity Timeout is it anyway? policy - design - closed
Description

Currently the WS-RM Policy Assertion describes four distinctive parameters in Section 2.1: Base Retransmission Interval, Exponential Backoff, Inactivity Timeout and Acknowledgement Interval. Further, these parameters are scoped with respect to two distinct roles as summarized below:

RMS:

-- Base Retransmission Interval (BRI)

-- Exponential Backoff (EB)

-- Inactivity Timeout (IT)

RMD:

-- Inactivity Timeout (IT)

-- Acknowledgement Interval (AI)

The current WS-RM Policy Specification allows the specification of the Inactivity Timeout, however it is not clear who actually "owns" this value. Is it the RMS or the RMD that specifies the value of the Inactivity Timeout?

Currently the specification indicates the following in Lines 108-111:

{The assertion defines an inactivity timeout parameter that either the RM Source or RM Destination MAY include. If during this duration, an endpoint has received no application or control messages, the endpoint MAY consider the RM Sequence to have been terminated due to inactivity.} If either of the parties can include this value, which party does the WS-RM Policy Attachment refer to? If it applies to, say RMD, shouldn't the RMS be able to specify this in some fashion?

Justification
Simply, it is not clear from the specification which party it applies to. This must be clarified. Further, if either of the parties can include this value, it should be stated when RMS or RMD may specify this value.
Related Issues
i054
Origin
Umit Yalcinalp
Owner
Marc Goodner
Proposal 12005-11-02

See message for full description of proposal rationale

We propose to add the following two attributes to the definition of InactivityTimeout at Line 158 [4] and move the specified value as the content value of the element as follows:

Remove the lines 154-155 [4]

/wsrmp:RMAssertion/wsrm:InactivityTimeout/@Milliseconds The inactivity timeout duration, specified in milliseconds.

Replace the lines 151-153 with

/wsrmp:RMAssertion/wsrm:InactivityTimeout A parameter that specifies a period of inactivity for a Sequence. If omitted, there is no implied value. The value of the element indicates the default inactivity timeout duration in milliseconds.

Add the lines:

/wsrmp:RMAssertion/wsrm:InactivityTimeout/@minValue A parameter that specifies a minimum value of inactivity for a Sequence. If omitted, there is no implied value. This attribute is only present when the @maxValue is present. /wsrmp:RMAssertion/wsrm:InactivityTimeout/@maxValue A parameter that specifies a maximum value of inactivity for a Sequence. If omitted, there is no implied value.

Proposal 22005-11-08
Close with no action (based on proposal 3 for i054)
Proposal 32005-11-17
Delete inactivity timeout.
Resolution2005-11-17
Proposal 3 accepted on Nov. 17th TC call
Resolution2006-01-05
Completed in CD 2
i056 How can RMS communicate the Base Retransmission Interval, Exponential Backoff and Inactivity Timeout values? policy - design - dropped
Description

Currently the WS-RM Policy Assertion specification describes four distinctive assertion parameters in Section 2.1: Base Retransmission Interval, Exponential Backoff, Inactivity Timeout and Acknowledgement Interval. Further, these parameters are scoped with respect to two distinct roles as summarized below:

RMS:

-- Base Retransmission Interval (BRI)

-- Exponential Backoff (EB)

-- Inactivity Timeout (IT)

RMD:

-- Inactivity Timeout (IT)

-- Acknowledgement Interval (AI)

The specification makes the above distinction and allows both the RMS and the RMD to include their respective parameters. However, it is not clear "where" these parameters would be included and "how" they would be communicated between the RMS and RMD. Specifically, the current RM Assertion element appears to apply only to a WSDL which enables the RMD to communicate it assertions. However, it is not clear how the RMS can express and communicate its RM Assertion parameters.

Justification
Although the specification defines certain parameters with respect to a role, namely the RMS, it is not clear how they would be expressed and communicated. This makes the specification incomplete and unusable from the perspective of RMS. For example, it is impossible for an RMS to configure its system once with parameters that suits its own needs and allow these parameters to be negotiated with the RMD.
Related Issues
Origin
Umit Yalcinalp
Owner
Chris Feris
Proposal 12005-10-18
Scope the RM Assertion parameters on a per Sequence basis and utilize the CreateSequence message exchange for communicating RM Assertion parameters between the RMS and the RMD.
Proposal 22005-11-02

See message for complete proposal rationale

Add the following section to the wsrmp specification (which may be subject to further editorial modification)

Section XX: Optimization for specifying parameters within WS-RM Protocol

When RMS needs to specify the InactivityTimeout value for a sequence, the selection of the inactivity timeout may be part of the create sequence protocol as specified in Section 3.4 of [WS-RM]. RMS MAY include the wsrmp:InactivityTimeout element as a child of wsrm:CreateSequence element to designate the Inactivity Timeout value. When specified as such, the maxValue and minValue attributes MUST not be present.

<wsrm:CreateSequence ...="">

<wsrm:AcksTo ...=""> wsa:EndpointReferenceType </wsrm:AcksTo>

<wsrm:Expires ...=""> xs:duration </wsrm:Expires> ?

<wsrmp:InactivityTimeout>600000</wsrmp:InactivityTimeout>

</wsrm:CreateSequence>

This specific optimization may be rejected by the RMD and the RMD MUST use the CreateSequenceResponse Fault as the response to the Create Sequence request. In this case, the RMD MAY include the specified InactivityTimeout element as part of the [Detail] to indicate that the inactivity timeout value specified by RMS is not valid.

Proposal 32005-11-03
Close with no action
Resolution2005-11-17
Proposal 3 accepted on Nov. 17th TC call
i057 Classification of References (normative vs. non-normative) is needed core - design - closed
Description

Currently our working draft references are all over the map.

-- WS-RM : Lists most references as Normative, except those that are related to WS-Policy.

-- WS-RM Policy Assertion : All references are non-normative. As one of the editors of this spec, to put all references as non-normative was deliberate on my part. IMO, the tc should make the decision about the references and which bucket they belong to. This is not an editorial decision and other TCs, such as WS-RF, went through each reference and determined where they belong to.

Justification
Obvious :-). We need normative and non-normative references clearly delineated.
Related Issues
Origin
Umit Yalcinalp
Owner
Umit Yalcinalp
Proposal 12005-10-18
Review each reference by the tc and determine whether the reference is normative. This must be done before we go to public draft (PD). I think we can live with this issue right now and should not affect our first CD. For the first CD, I propose we leave everything as is and put a note stating that the decision on classifying references is pending.
Proposal 22005-12-14

Proposal in email 109 with RTTM reference as non-normative, refinements from Paul Cotton and to use XML second edition rather than third.

Resolution2005-12-14
Proposal 2 accepted at December 14th F2F meeting
Resolution2006-01-05
Completed in CD 2
i058 State Transition Table core - editorial - closed
Description
The current specification has an example of message exchange between two ends. The example represents a subset of possible states that the protocol can transition to. It is left to the reader/implementor to verify all the possible states of the protocol.
Justification
A full state transition table is needed in order to ensure proper design of the reliable protocol.
Related Issues
Origin
Abbie Barbir
Owner
Tom Rutt
Proposal 1
the state table be incorporated as a new appendix, to be formatted by the editors, to be maintained as part of the core document.
Resolution2006-01-26
Proposal 1 accepted on Jan 26th TC call
Resolution2006-03-02
Completed in CD 3
i059 Retransmission behavior core - design - closed
Description
The Core specification depends on message retransmission by the RMS of unacknowledged messages in order for a reliable exchange to be accomplished, yet does not describe this behavior in any way. Discuss and conclude the manner and the location for such an exposition in the core specification.
Justification
See description.
Related Issues
Origin
Bob Freund
Owner
Bob Freund
Proposal 12005-11-07

See mail, this proposal is relative to Web Services Reliable Messaging Committee Draft 01

Insert after line 265:

The RM Source will expect to receive acknowledgements from the RM Destination during the course of a message exchange at occasions described in Section 3 below. Should the acknowledgement not be received timely, the RM Source MUST re-transmit the request since either the request or the associated acknowledgement may have been lost. Since the nature and dynamic characteristics of the underlying transport and potential intermediaries are unknown in the general case, the timing of re-transmissions cannot be specified. Additionally, over-aggressive re-transmissions have been demonstrated to cause transport or intermediary flooding which are counterproductive to the intention of providing a reliable message exchange. Consequently, implementers are encouraged to utilize adaptive mechanisms that dynamically adjust re-transmission time and the back-off intervals that are appropriate to the nature of the transports and intermediaries envisioned. For the case of TCP/IP transports, a mechanism similar to that described as RTTM in RFC 1323 [RTTM] should be considered.

Delete lines 951-952 reason: reference is not used; besides it is a book that may not remain in print

Insert before line 953:

[RTTM]

V Jacobson et alia, “RFC 1323 TCP/IP High Performance Extensions” 1992

Resolution2005-11-10
Proposal 1 acepted on Nov 10 TC call
Resolution2006-01-05
Completed in CD 2
i060 Definition for "Reliable Message" core - editorial - closed
Description
There are several references to "reliable message" (section 1, 2 intro, 2.1, 2.3) that are not backed by a clear definition.
Justification
A full state transition table is needed in order to ensure proper design of the reliable protocol.
Related Issues
Origin
Jacques Durand
Owner
Jacques Durand
Proposal 12005-10-25

1- Add a terminology entry. It could be:

Reliable message: a message submitted by the Application Source to an RM Source via the "Send" operation, for transmission over the protocol defined in this specification.

2- In 3.1: associate the main protocol requirement (Sequence element) with the definition of "reliable message" instead of with a vague requirement of being subject to some DA:

Replace:

"Messages for which the delivery assurance applies MUST contain a <wsrm:Sequence> header block."

With:

"Reliable Messages MUST contain a <wsrm:Sequence> header block."

(DA and protocol being in fact separately defined, DA should now more abstractly mandate the use of "reliable messages" if we still want to pre-req one to the other.)

Proposal 22005-12-01

See message:

Replace the first bullet in section 2.3 Invariants on line 207 of wd06

The RM Source MUST assign each message to be delivered reliably a message number (defined below) beginning at 1 and increasing by exactly 1 for each subsequent message to be delivered reliably.

Proposal 32005-12-14

Accept Chris' changes with the two changes noted by Jacques .

For each occurance of the term, I have listed the line number as per wd-07 and the current text and proposed alternate text.

line 76-77: The primary goal of this specification is to create a modular mechanism for reliable message delivery.

The primary goal of this specification is to create a modular mechanism for reliable delivery of messages.

line 114-116: If an action IRI is used, and one is not already defined per the rules of the WS-Addressing specification [WS-Addressing], then the action IRI MUST consist of the reliable messaging namespace URI concatenated with a '/', followed by the message element name.

If an action IRI is used, and one is not already defined per the rules of the WS-Addressing specification [WS-Addressing], then the action IRI MUST consist of the WS-RM namespace URI concatenated with a '/', followed by the message element name.

line 125: Reliable Messaging Model

no change

line 128-130: 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,

no change

line 160: Figure 1 below illustrates the entities and events in a simple reliable message exchange.

Figure 1 below illustrates the entities and events in a simple reliable exchange of messages.

line 161-162: The Reliable Messaging (RM) Source accepts the message and Transmits it one or more times.

no change

line 167: Figure 1: Reliable Messaging Model

no change

line 198-199: The RM Source MUST assign each reliable message a sequence number (defined below) beginning at 1 and increasing by exactly 1 for each subsequent reliable message.

The RM Source MUST assign each message within a Sequence a message number (defined below) beginning at 1 and increasing by exactly 1 for each subsequent message.

line 204: Figure 2 illustrates a possible message exchange between two reliable messaging endpoints A and B.

no change

line 234-236: Additionally, over-aggressive re-transmissions have been demonstrated to cause transport or intermediary flooding which are counterproductive to the intention of providing a reliable message exchange.

Additionally, over-aggressive re-transmissions have been demonstrated to cause transport or intermediary flooding which are counterproductive to the intention of providing a reliable exchange of messages.

line 693-694: The purpose of the <wsrm:SequenceFault> element is to carry the specific details of a fault generated during the reliable messaging specific processing of a message belonging to a Sequence.

no change

line 779-780: However, it is recommended that the security context be established first.Security contexts are independent of reliable messaging Sequences.

no change

line 796-803: That is, one aspect of security is to prevent message replay and the core tenet of reliable messaging is to replay messages until they are acknowledged.Consequently, if the security subsystem processes a message but a failure occurs before the reliable messaging sub-system records the message (or the message is considered "processed"), then it is possible (and likely) that the security subsystem will treat subsequent copies as replays and discard them.At the same time, the reliable messaging sub-system will likely continue to expect and even solicit the missing message(s).Care should be taken to avoid and prevent this rare condition.

no change

line 816: Availability – All reliable messaging services are subject to a variety of availability attacks.

no change

line 448 (section 3.4) : "Messages for which the delivery assurance applies MUST contain a <wsrm:Sequence> header block." Reword as: "Messages for which a reliable delivery is required MUST contain a <wsrm:Sequence> header block."

In wsrmp specification (0.2) line 95: "..to ensure reliable message delivery." --> "..to ensure reliable delivery of messages."

Resolution2005-12-14
Proposal 3 accepted at December 14th F2F meeting
Resolution2006-01-05
Completed in CD 2
i061 Anonymous AcksTo core - design - done
Description
Add text, similar to above, to the spec. It should be placed in the Sequence Ack section.
Justification
See description.
Related Issues
Origin
Doug Davis
Owner
Doug Davis
Proposal 12006-02-08

Reflects updated proposal

After the first paragraph in the SeqAck section (currently section 3.6) add:

While this specification discusses the ability to add, or piggy-back, a Sequence Acknowledgement Header block to a message that is targeted to the AcksTo EPR, the precise mechanism for determining when any particular message is targeted, or not, to the AcksTo EPR is out of scope for this specification.

Using the WS-Addressing anonymous IRI in the AcksTo EPR may impact implementations. When the AcksTo EPR contains the anonymous IRI, Sequence Acknowledgements MUST be sent on the appropriate protocol binding-specific channel. For example, in the HTTP case, Sequence Acknowledgements would be expected to flow on the HTTP response flow. It is worth noting that this may result in new SOAP messages being generated and sent in certain situations. For example, if on an HTTP request flow the SOAP message contained a wsa:ReplyTo that didn't use the anonymous IRI, then it is possible that a new SOAP message may need to flow back on the HTTP response flow for the sole purpose of carrying a Sequence Acknowledgement. Because the anonymous IRI is a general purpose IRI that can be used by many concurrent RM Sequences, Sequence Acknowledgements that are sent to the AcksTo EPR using these protocol binding-specific channels SHOULD only be sent when it can be determined that the channel is related to the RM Sequence. For example, Sequence Acknowledgements should only be piggy-backed on HTTP response flows where the message that was sent on the HTTP request flow referenced the Sequence in question through the use of a Sequence or AckRequested Header block.

Proposal 2 2006-01-26

At the end of the explanation of AcksTo in section 3.1 "Sequence Creation" (line 264 in wsrm-1.1-spec-cd-02):

Additionally use of the WS-Addressing defined "http://www.w3.org/2005/03/addressing/role/anonymous" (the anonymous IRI) may, under some circumstances, make it impossible for either the RM Destination to send or the RM Source to receive Sequence Acknowledgments.

After the first paragraph in section 3.6 "Sequence Acknowledgement" (line 521 in wsrm-1.1-spec-cd-02):

While this specification discusses the ability to add, or piggy-back, a Sequence Acknowledgment Header block to a message that is targeted to the AcksTo EPR, the precise mechanism for determining when any particular message is targeted, or not, to the AcksTo EPR is out of scope for this specification.

Using the WS-Addressing anonymous IRI in the AcksTo EPR may impact some implementations. When the AcksTo EPR contains the anonymous IRI, Sequence Acknowledgments MUST be sent on the appropriate protocol binding-specific channel. For example, in the HTTP case, Sequence Acknowledgments would be expected to flow on the HTTP response flow. It is worth noting that there are message interactions, such as WSDL 1.1 one-way operations, for which there may be no HTTP response flow (see section 4.7.9 of the WS-I Basic Profile 1.1 [WS-I Basic Profile 1.1] for details on why this might be the case). For this reason it is RECOMMENDED that the RM Source avoid the use of the anonymous IRI in the AcksTo EPR unless there exists a clear indication (from either the Application Source, via configuration, or by some other mechanism) that Sequence Acknowledgments will be able to flow across the protocol binding-specific back channel.

The successful use of the anonymous IRI in the AcksTo EPR in conjunction with one-way messages may result in new SOAP messages being generated and returned. With asynchronous, one-way usage it is possible that a new SOAP message may need to flow back on the HTTP response flow for the sole purpose of carrying a Sequence Acknowledgment. Because the anonymous IRI is a general purpose IRI that can be used by many concurrent RM Sequences, Sequence Acknowledgments that are returned to the AcksTo EPR using these protocol binding-specific channels SHOULD only be returned when it can be determined that the channel is related to the RM Sequence. For example, Sequence Acknowledgments should only be piggy-backed on HTTP response flows when the message that was sent on the HTTP request flow referenced the Sequence in question through the use of a Sequence or AckRequested Header block.

Add the following reference to section 6.2 (Non-Normative References):

[WS-I Basic Profile 1.1] (+ appropriate stuff)

Proposal 32006-02-16
Close with no action. Made at Feb 16th TC call
Proposal 42006-02-16
Defer (until WS-A is "done" at W3C). Made at Feb 16th TC call
Proposal 52006-02-16

Chris' proposal with empty body. Made at Feb 16th TC call

When a CreateSequence contains a <wsrm:AcksTo> EPR that specifies the WS-Addressing anonymous URI, the RM Destination of a Web service provider MUST send the <wsrm:SequenceAcknowledgement> in a SOAP envelope with an empty <soap:Body> in the context of a WSDL operation that contains only a <wsdl:input> message that uses the SOAP over HTTP binding.

Proposal 6 2006-02-23

In the Requested Ack section, change:

The RM Source may request an acknowledgement message from the RM Destination at any time by including an <wsrm:AckRequested> header block in the message.

to

The RM Source may request an acknowledgement message from the RM Destination at any time by including an <wsrm:AckRequested> header block in any message targeted to the RM Destination.

In the Seq Ack section, change:

The <wsrm:SequenceAcknowledgement> header block MAY be transmitted independently or included on return messages.

to

The <wsrm:SequenceAcknowledgement> header block MAY be transmitted independently or included on any message targeted to the AcksTo EPR.

And in the Seq Ack section, after the first para add:

A RMD MAY include a wsrm:SequenceAcknowledgement header block on any SOAP envelope targetted to the endpoint referenced by the wsrm:AcksTo EPR.

A wsrm:AcksTo EPR MAY specify the WS-Addressing anonymous URI as its address. When the wsrm:AcksTo EPR specifies the WS-Addressing anonymous URI as its address, the RMD MUST transmit any wsrm:SequenceAcknowledgement headers for the created Sequence in a SOAP envelope to be transmitted on the protocol binding-specific channel provided by the context of a received message containing a SOAP envelope that contains a wsrm:Sequence header block and/or a wsrm:AckRequested header block for that same Sequence identifier.

Note that this practice MAY require that the RMD endpoint return a SOAP envelope specifically for the purpose of transmitting the wsrm:SequenceAcknowledgement in certain cases where there would not normally be a SOAP envelope carried in the response message, such as a WSDL oneway operation or in the case where a wsrm:AckRequested header block is sent independently of any application-level message content

Resolution2006-02-23

Proposal six ammended as follows and acepted on Feb. 23rd TC call.

A wsrm:AcksTo EPR MAY specify the WS-Addressing anonymous URI as its address. When the wsrm:AcksTo EPR specifies the WS-Addressing anonymous URI as its address, the RMD MUST transmit any wsrm:SequenceAcknowledgement headers for the created Sequence in a SOAP envelope to be transmitted on the protocol binding-specific channel provided by the context of a received message containing a SOAP envelope that contains a wsrm:Sequence header block and/or a wsrm:AckRequested header block for that same Sequence identifier.

To

A wsrm:AcksTo EPR MAY specify the WS-Addressing anonymous URI as its address. When the wsrm:AcksTo EPR specifies the WS-Addressing anonymous URI as its address, the RMD MUST transmit any wsrm:SequenceAcknowledgement headers for the created Sequence in a SOAP envelope to be transmitted on the protocol binding-specific channel. Such a channel is provided by the context of a received message containing a SOAP envelope that contains a wsrm:Sequence header block and/or a wsrm:AckRequested header block for that same Sequence identifier.

i062 None AcksTo core - design - closed
Description
Disallow the use of the 'none' IRI
Justification
W/o disallowing it Acks can not be sent back to the RM Source
Related Issues
Origin
Doug Davis
Owner
Doug Davis
Proposal 12005-10-27

After the first paragraph in the SeqAck section (currently section 3.2) add something like:

Implementations MUST NOT use an IRI in the AcksTo EPR that would prevent the sending of Sequence Acknowledgements back to the RM Source. For example, using the WS-Addressing "none" IRI would make it impossible for the RM Destination to ever send Sequence Acknowledgements.

Resolution2005-11-10
Proposal 1 accepted on Nov 10 TC call
Resolution2006-01-05
Completed in CD 2
i063 SeqAck - None and Final schema - editorial - closed
Description
In [1] current schema and pseudo schema doesn't allow None and Final on the same SeqAck - and they should be.
Justification
Its possible that a sequence could be closed w/o any Acks.
Related Issues
Origin
Doug Davis
Owner
Doug Davis
Proposal 12005-10-30

Make schema and pseudo schema support None and Final - like this:

<wsrm:SequenceAcknowledgement ...="">

<wsrm:Identifier ...=""> xs:anyURI </wsrm:Identifier>

[ [ <wsrm:AcknowledgementRange ...=""

Upper="xs:unsignedLong"

Lower="xs:unsignedLong"/> *

| <wsrm:None/> ]

<wsrm:Final/> ?

| <wsrm:Nack> xs:unsignedLong </wsrm:Nack> + ]

...

</wsrm:SequenceAcknowledgement>

Note: changed the + to a * on the AckRange element. since Final can appear w/o any AckRanges.

Proposal 22005-10-11

See message for complete details

2. disallow Final without either None or an AcknowledgementRange sequence; I do not know what Final alone means, could you point me to the defining text in the specification:

<wsrm:SequenceAcknowledgement ...="">

<wsrm:Identifier ...=""> xs:anyURI </wsrm:Identifier>

[ [ <wsrm:AcknowledgementRange ...=""

Upper="xs:unsignedLong"

Lower="xs:unsignedLong"/> +

| <wsrm:None/> ]

<wsrm:Final/> ?

| <wsrm:Nack> xs:unsignedLong </wsrm:Nack> + ]

...

</wsrm:SequenceAcknowledgement>

In either case, line 385[1] must change from "when sending AcknowledgementRanges" to "when sending AcknowledgementRange sequences or None".

Resolution2005-11-10
Proposal 1 amended with point 2 from Proposal 2 on Nov 10 TC call
Resolution2006-01-05
Completed in CD 2
i064 Create Sequence Refused Fault is too restrictive core - design - closed
Description

In WS-RM specification , the Create Sequence Refused fault requires [Detail] to be empty (lines 836-842) as follows:

4.7 Create Sequence Refused

This fault is sent in response to a create sequence request that cannot be satisfied.

Properties:

[Code] Sender

[Subcode] wsrm:CreateSequenceRefused

[Reason] The create sequence request has been refused by the RM Destination.

[Detail] empty

We think that this is too restrictive and should allow any content to be part of [Detail]. The specification should not dictate interpretation of content of the [Detail], but should not restrict its contents.

Justification
There may be many reasons to indicate why Create Sequence may be refused by RMD. Further, sequence creation may be composed by security or other extensibility as CreateSequence element allows today. Disallowing [Detail] to contain any element, we are restricting extensibility and ways for tools to interpret the reasons for create sequence to fail. We think that the [Detail] element content may be used for including additional information which may be specific to a platform, composition or extension.
Related Issues
Origin
Umit Yalcinalp
Owner
Umit Yalcinalp
Proposal 12005-11-01
Allow [Detail] to contain any content, instead of requiring it to be empty.
Resolution2005-12-01
Proposal 1 acepted on the Dec 1st, 2005 call
Resolution2006-01-05
Completed in CD 2
i065 Reword "Closing a Sequence" section core - editorial - closed
Description

Section 3.6 "Closing a Sequence" contains in introduction to the close operation, and its justification. I think that the current text would benefit from a rework. Lines 625 - 648 of working draft 05 say:

There may be times during the use of an RM Sequence that the RM Source or RM Destination will wish to discontinue using a Sequence even if some of the messages have not been successfully delivered to the RM Destination.

In the case where the RM Source wishes to discontinue use of a sequence, while it can send a TerminateSequence to the RM Destination, since this is a one-way message and due to the possibility of late arriving (or lost) messages and A cknowledgements, this would leave the RM Source unsure of the final ranges of messages that were successfully delivered to the RM Destination.

To alleviate this, the RM Source can send a <wsrm:CloseSequence> element, in the body of a message, to the RM Destination to indicate that RM Destination MUST NOT receive any new messages for the specified sequence, other than those already received at the time the <wsrm:CloseSequence> element is interpreted by the RMD.

Upon receipt of this message the RM Destination MUST send aSequenceAcknowledgement to the RM Source. Note, this SequenceAcknowledgement MUST include the <wsrm:Final> element.

While the RM Destination MUST NOT receive any new messages for the specified sequence it MUST still process RM protocol messages. For example, it MUST respond to AckRequested, TerminateSequence as well as CloseSequence messages. Note, subsequent CloseSequence messages have no effect on the state of the sequence.

In the case where the RM Destination wishes to discontinue use of a sequence it may 'close' the sequence itself. Please see wsrm:Final above and the SequenceClosed fault below. Note, the SequenceClosed Fault SHOULD be used in place of the SequenceTerminated Fault, whenever possible, to allow the RM Source to still receive Acknowledgements

Justification
The above text could be clearer.
Related Issues
Origin
Matthew Lovett
Owner
Matthew Lovett
Proposal 12005-11-02

Replace the above text (lines 625 - 648) with the following:

There may be times during the use of an RM Sequence that the RM Source or RM Destination will wish to discontinue using a Sequence. Simply terminating the Sequence discards the state managed by the RM Destination, leaving the RM Source unaware of the final ranges of messages that were successfully delivered to the RM Destination. To ensure that the Sequence ends with a known final state both the RM Source and RM Destination may choose to 'close' the Sequence before terminating it.

If the RM Source wishes to close the Sequence then it sends a <wsrm:CloseSequence> element, in the body of a message, to the RM Destination. This message indicates that the RM Destination MUST NOT receive any new messages for the specified sequence, other than those already received at the time the <wsrm:CloseSequence> element is interpreted by the RMD. Upon receipt of this message the RM Destination MUST send a SequenceAcknowledgement to the RM Source. Note, this SequenceAcknowledgement MUST include the <wsrm:Final> element.

While the RM Destination MUST NOT receive any new messages for the specified sequence it MUST still process RM protocol messages. For example, it MUST respond to AckRequested, TerminateSequence as well as CloseSequence messages. Note, subsequent CloseSequence messages have no effect on the state of the sequence.

In the case where the RM Destination wishes to discontinue use of a sequence it may close the sequence itself. Please see wsrm:Final above and the SequenceClosed fault below. Note, the SequenceClosed Fault SHOULD be used in place of the SequenceTerminated Fault, whenever possible, to allow the RM Source to still receive Acknowledgements.

Resolution2005-11-17
Proposal 1 accepted on Nov. 17th TC call
Resolution2006-01-05
Completed in CD 2
i066 Remove LastMessage core - design - closed
Description

The LastMessage element, as part of a Sequence header element, appears superfluous. It seems to serve 2 purposes:

1 - force a SeqAck to be sent back from the RMD

2 - force the RMD to reject any messages with a higher message #

#1 can be done with an AckReq header. We should avoid having multiple ways to do the same thing.

#2 is really only an issue if someone tries to hijack the sequence - and to protect against that we should be using a real security mechanism like WS-SC/Trust, not the LastMessage element.

When an RMS is done with a sequence it is free to simply Close or Terminate it (whether or not it has all of the Acks it wants - but normally it will wait) - having an additional message exchange to send a LastMessage is unnecessary.

Justification
See above
Related Issues
Origin
Doug Davis
Owner
Doug Davis
Proposal 12005-11-02
Remove all references to LastMessage (and related Fault) from the spec. See attached diff/pdf file for the specific changes.
Resolution2005-12-01
Proposal 1 acepted on the Dec 1st, 2005 call
Resolution2006-01-05
Completed in CD 2
i067 Replace 'response' core - editorial - closed
Description

under figure 2, for step 7 replace:

7.The RM Destination acknowledges receipt of message numbers 1 and 3 in response to the RM Source's <wsrm:LastMessage> token.

with

7.The RM Destination acknowledges receipt of message numbers 1 and 3 as a result of receiving the RM Source's <wsrm:LastMessage> token.

Justification
"response" could be misleading since some may think of it as a request/response thing. Basically just a minor editoral change. We need easy ones for our conf calls :-)
Related Issues
Origin
Doug Davis
Owner
Doug Davis
Proposal 12005-11-02
see above
Resolution2005-11-10
Proposal 1 accepted on Nov 10 TC call
Resolution2006-01-05
Completed in CD 2
i068 Remove 'correlation' text core - editorial - closed
Description

In section 2.2 the spec says:

The RM Source MUST have an endpoint reference that uniquely identifies the RM Destination endpoint; correlations across messages addressed to the unique endpoint MUST be meaningful.

Does anyone know what correlations its talking about? If not this text seems pretty useless and should be moved as it could be misleading for some people to think we're talking about WS-Addressing correlation or something.

Justification
Leads to confusion
Related Issues
Origin
Doug Davis
Owner
Doug Davis
Proposal 12005-11-02
Remove the text after the semi-colon
Resolution2005-11-10
Proposal 1 accepted on Nov 10 TC call
Resolution2006-01-05
Completed in CD 2
i069 MessageNumber on AckReq core - design - closed
Description

The spec says:

This OPTIONAL element, if present, MUST contain an xs:unsignedLong representing the highest <wsrm:MessageNumber> sent by the RM Source within the 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 <wsrm:SequenceAcknowledgement>.

This additional element seems to provide no real value. I'd like to understand the motivation behind it. What kind of optimizations are we talking about? If the optimization is related to "when" to send back the Ack then we have a problem since the spec says that the RMD MUST respond with a SeqAck - and while not explicitly stated I think its implied that it should return it as soon as possible. So, what additional value is this providing? I fear that, like LastMessage, people may read more into this than intended and make assumption about its purpose that are not true. If it provides no additional value, that we can specify in the spec, we should remove it.

Justification
See description
Related Issues
Origin
Doug Davis
Owner
Doug Davis
Proposal 12005-11-03
Remove MessageNumber from AckRequested element
Resolution2005-11-10
Proposal 1 accepted on Nov 10 TC call
Resolution2006-01-05
Completed in CD 2
i070 Receive is defined twice in wsrm-1.1-spec-cd-01 core - editorial - closed
Description
Receive is defined twice and differently each time on lines 206-207 and 215. Line 215 is from the original spec. Lines 206 and 207 are new. I can not find the issue/resolution that resulted in this new text.
Justification
It's wrong to define the same term twice, especially differently each time.
Related Issues
Origin
Marc Goodner
Owner
Marc Goodner
Proposal 12005-11-30
See message: "It appears it was added by accident as part of issue 019. Jacques offered a new definition which was adopted but for some reason the new text wasn't used to replace the old definition, instead a new entry in the glossary was added."
Resolution2005-12-01
Proposal 1 acepted on the Dec 1st, 2005 call
Resolution2006-01-05
Completed in CD 2
i071 Editorial nits for wsrm-1.1-spec-cd-01 core - editorial - closed
Description
There are a number of editorial issues with the CD document wsrm-1.1-spec-cd-01. These are described fully in the proposal below.
Justification
Self evident
Related Issues
Origin
Marc Goodner
Owner
Marc Goodner
Proposal 12005-11-08

Please see original message for complete list of nits.

Resolution2005-11-10
Proposal 1 accepted on Nov 10 TC call
Resolution2006-01-05
Completed in CD 2
i072 Editorial nits for wsrmp-1.1-spec-cd-01 policy - editorial - closed
Description
There are a number of editorial issues with the CD document wsrmp-1.1-spec-cd-01. These are described fully in the proposal below.
Justification
Self evident
Related Issues
Origin
Marc Goodner
Owner
Marc Goodner
Proposal 12005-11-08

Please see original message for complete list of nits.

Resolution2005-11-10
Proposal 1 accepted on Nov 10 TC call
Resolution2006-01-05
Completed in CD 2
i073 Descriptive text of removed parameters also needs to be removed policy - editorial - closed
Description
In the resolution to i022 the line numbers specified neglected to include the descriptive text on the parameters (BaseRetransmission and ExponentialBackoff) that were removed.
Justification
No need to describe things that aren’t there.
Related Issues
i022
Origin
Marc Goodner
Owner
Marc Goodner
Proposal 12005-11-08
Delete the descriptive text on BaseRetransmission and ExponentialBackoff, lines 112 -119 of wsrmp-1.1-spec-wd-01
Resolution2005-11-10
Proposal 1 accepted on Nov 10 TC call
Resolution2006-01-05
Completed in CD 2
i074 Use of [tcShortName] in artifact locations namespaces, etc all - editorial - closed
Description
The TC Administrator advised the TC to ensure use of [tcShortName] as the first token after domain name as part of the various artifact location, namespace, etc, strings pertaining to this TC.
Justification
Use of [tcShortName] as the first token after domain name allows each TC to create their own artifact locations, namespaces, etc, that would not collide with similar strings owned by other TCs.
Related Issues
i015 i016 i017
Origin
Sanjay Patil
Owner
Sanjay Patil
Proposal 12005-11-10
See attachment
Resolution2005-11-10
Proposal 1 accepted on Nov 10 TC call
Resolution2006-01-05
Completed in CD 2
i075 Case of multiple RM Policies and DAs within an RMD scope core - design - closed
Description
As the 1-1 relationnship between RMD and port (or RMD-WSDL) is no longer required (i010 allows RMS and RMD to span several endpoints) the specification needs be clearer on how RM Policies apply, as an RMD will handle messages and sequences that are subject to different RM policies - meaning protocol parameters as well as DAs.
Justification
RM policy parameters are so far attached to the endpoint, while they actually concern the RMD behavior, and this may cause an issue if one RMD serves several ports with different policy parameters. Regarding DAs, same 1-n issue: an RMD must be able to handle messages according to different DAs. While the DA to be enforced on a message can be resolved separately from protocol concerns (e.g. based on endpoint info), that would require looking at extra headers if this RMD is deployed as an intermediary. Also that would not work if DAs are to be attached at a finer granularity than endpoint (e.g. message or operation).
Related Issues
Origin
Jacques Durand
Owner
Umit Yalcinalp
Proposal 12005-11-14
Associate more explicitly policies (and DAs) with sequences, e.g. either in CreateSequence, or CreateSequenceResponse, so that an RMD can apply different policies to different sequences just based on sequence ID.
Proposal 22005-12-15

From Matt, PaulF, Jacques based on F2F discussions.

Section 2.1 add new text to follow line 109: "When a RM Destination provides RM services for more than one endpoint it is RECOMMENDED that all the endpoints should have the same values for RM Policy parameters. If the RM Policies are not the same then the RM Policy parameters in effect for each Sequence is governed by the endpoint that was used for the <wsrm:CreateSequence> message."

We also propose a new issue, to aid the RMS/RMD/AS/AD in cases where policies/WSDL are not advertised, or the RMS is not WSDL/policy aware. The advantage of this would be that now we have a mechanism for RMD to specify the RM assertion for the Sequence as opposed to per port/endpoint.

New issue (see message, not tracked in proposal for issue list).

Proposal 32006-01-10

From Doug Davis

After line 485 in [1]:

The RM Policy parameters in effect for each Sequence is governed by the endpoint that was used for the <wsrm:CreateSequence>message.

Proposal 4

Add the following text at the end of section 2.3 in WSRMP [1].

An RM policy assertion allows for extensibility as defined in Section 2.2 [ref]. Because the WSRM [ref to section 2 of WSRM spec] specification allows an RM Sequence to span multiple WSDL ports and/or endpoints, implementations or specifications that make use of these extensibility points should be aware that doing so may create situations in which multiple policies containing extended RM policy assertions may apply to the same RM Sequence. The means and mechanisms for collating and resolving conflicts between RM policy assertions attached to multiple wsdl:bindings and/or wsdl:ports that participate in a single RM Sequence is not defined by this specification. Users/creators of extended RM policy assertions are encouraged to consider and address any possible conflicts in the content and semantics of the RM policy assertion extensions.

Resolution2006-02-02

Proposal 4 accepted on Feb. 2 TC call with ammendment to change "these extensibility points" to "this capability" thus:

An RM policy assertion allows for extensibility as defined in Section 2.2 [ref]. Because the WSRM [ref to section 2 of WSRM spec] specification allows an RM Sequence to span multiple WSDL ports and/or endpoints, implementations or specifications that make use of this capability should be aware that doing so may create situations in which multiple policies containing extended RM policy assertions may apply to the same RM Sequence. The means and mechanisms for collating and resolving conflicts between RM policy assertions attached to multiple wsdl:bindings and/or wsdl:ports that participate in a single RM Sequence is not defined by this specification. Users/creators of extended RM policy assertions are encouraged to consider and address any possible conflicts in the content and semantics of the RM policy assertion extensions.

Resolution2006-03-02
Completed in CD 3
i076 Semantics of offered Sequences core - design - closed
Description

The current specification explains how a RM Source may offer a Sequence to the RM Destination, but does not explain what this really means. It can be read as a protocol optimization, with no deeper semantics. It could alternatively be assumed that the 2 sequences are linked in some way - perhaps application replies are expected to travel back on this sequence (and no other); perhaps the offered Sequence is supposed to close/terminate when the other Sequence closes/terminates. Someone might even assume that offers will only be made for request-reply applications, wheras the absence of an offer implies fire-and-forget messaging. (I am not advocating this interpretation!)

We should clarify the specification, so that the reader is fully aware of the semantic import of offering (or accepting the offer of) a Sequence.

Justification
The capabilities in the spec should have clear semantics
Related Issues
Origin
Matt Lovett
Owner
Matt Lovett
Proposal 12005-11-23

I think that we should clearly state that there is no deep semantic to offering a Sequence, it is merely a protocol optimization. I think that the right way to explain that is to add a note into the text that introduces offer, saying that the use of offer is semantically identical to not using offer, and then initiating another Sequence between the two endpoints. Describing this is a little tricky, as we don't want to talk about creating a Sequence from RM Destination to RM Source.... and we don't have a term in the spec for the middleware layer that implements RM in either direction. Here is a concrete proposal:

Add the following as a continuation of line 256 (using line numbers from wsrm-1.1-spec-wd-06.pdf): Note, offering a Sequence within the <wsrm:CreateSequence> element is simply a protocol optimization. There is no semantic difference between offering a Sequence, and choosing not to offer one and subsequently creating a Sequence to carry messages from the Ultimate Receiver to the Initial Sender.

Proposal 22005-12-08
Add the following as a continuation of line 256 (using line numbers from wsrm-1.1-spec-wd-06.pdf): Note, offering a Sequence within the <wsrm:CreateSequence> element is simply a protocol optimization. There is no semantic difference between offering a Sequence, and choosing not to offer one and subsequently creating a Sequence to carry messages from the RMD to the RMS.
Resolution2005-12-08
Proposal 2 accepted on the Dec. 8 TC call with the advice to the editors that RMD should be qualified with "a new sequence with the response messages"
Resolution2006-01-05
Completed in CD 2
i077 How does a RM Destination reject an offered Sequence? core - design - dropped
Description

Section 3.1 lines 254 - 256 in wsrm-1.1-spec-wd-06.pdf says: <wsrm:CreateSequence> MAY carry an offer to create an inbound sequence which is either accepted or rejected in the <wsrm:CreateSequenceResponse>.

However, there is no way to reject the offered sequence without faulting the entire CreateSequence message, as lines 348 - 352 also say: /wsrm:CreateSequenceResponse/wsrm:Accept This element, if present, enables an RM Destination to accept the offer of a corresponding Sequence for the reliable exchange of messages transmitted from RM Destination to RM Source. This element MUST be present if the corresponding <wsrm:CreateSequence> message contained an <wsrm:Offer> element.

I believe this is inconsistent. We should either define how a RM Destination can accept an inbound Sequence while rejecting the offer, or adjust the text in lines 254 - 256 to say that it is not possible.

Justification
The specification should be consistent.
Related Issues
Origin
Matt Lovett
Owner
Matt Lovett
Proposal 12005-11-23

As noted above, I can see 2 alternatives. I believe the way to go is to say that it is not possible to reject an offered Sequence without rejecting the entire CreateSequence message.

Reword lines 254 - 256 to read: <wsrm:CreateSequence> MAY carry an offer to create an inbound sequence which is then accepted in the <wsrm:CreateSequenceResponse>. If the RM Destination is unable to accept the offered Sequence then it MUST respond with a CreateSequenceRefused fault.

Proposal 22005-12-06
is a dupe
Resolution2005-12-08
Proposal 2 accepted on Dec. 8 TC call.
i078 Lost TerminateSequence core - design - closed
Description

It is not unreasonable to anticipate that from time to time TerminateSequence sent from the RMS may be lost.

Should TerminateSequence be lost, the only way for the RMD to reclaim resources is to wait for sequence expiry or to garbage collect based on implementation policy.

Justification

Retrying TerminateSequence is not a reasonable alternative since the RMS cannot determine if CloseSequence was successful, besides the RMS has no evidence of the loss of TerminateSequence.

Related Issues
Origin
Bob Freund
Owner
Bob Freund
Proposal 12005-11-30

To improve this situation, we propose to change oneway TerminateSequence to request-response TerminateSequence so that the RMS can on the same connection determine whether TerminateSequence was successful and thus can retry CloseSequence if necessary.

Proposal 22006-02-02

See complete proposal (lots of inline XML makes straight copy here difficult... sorry)

Resolution2006-02-02

Proposal 2 accepted on Feb. 2 TC call.

Resolution2006-03-02
Completed in CD 3
i079 SequenceClosed fault and SequenceAcknowledgement(Final) core - editorial - closed
Description

When the RMD autonomously closes a sequence while the RMS is sending messages, messages that the RMD has already received cause SeqAck(Final) but other messages cause SequenceClosed fault or SeqAck(Final). Which is to be returned is unclear.

The SequenceClosed fault is not useful for the RMS to determine the maximum message number that the RMD had accepted.

Justification

Provides the RMS correct ending status on autonomously closed sequences.

Related Issues
Origin
Bob Freund
Owner
Bob Freund
Proposal 12005-11-30

We propose that SeqAck(Final) be piggybacked on the SequenceClosed fault

Proposal 22005-12-15

line 375-377 replace: Upon receipt of this message the RM Destination MUST include a SequenceAcknowledgement header block in the CloseSequenceResponse message. Note, this SequenceAcknowledgement MUST include the <wsrm:Final> element.

with

Upon receipt of this message, or subsequent to the RM Destination closing the Sequence of its own volition, the RM Destination MUST include a final SequenceAcknowledgement (that MUST include the <wsrm:Final> element) header block on each message destined to the RM Source, including the CloseSequenceResponse message and on any Sequence Fault transmitted to the RMS.

Resolution2005-12-15
Proposal 2 accepted at December 15th F2F meeting
Resolution2006-01-05
Completed in CD 2
i080 Remove ambiguity about the protocol being at least once on the wire core - editorial - closed
Description

Some of the text in the spec is confusing wrt whether the protocol is at least once on the wire and that the DAs are implemented by the RMD and the AD.

Justification

see above

Related Issues
Origin
Anish Karmarkar
Owner
Anish Karmarkar
Proposal 12005-12-01

See message line numbers from wd-05.

1) Line 151-153 says: "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." This isn't quite right as the RMS is not involved in implementing the DAs.

I would like to propose that the above text be replaced with: "It is the responsibility of the RM Destination to fulfill the delivery assurances on behalf of the Application Source and Application Destination, or raise an error."

2) Line153-154 says: "The protocol defined here allows endpoints to meet this guarantee for the delivery assurances defined below."

To be more specific I propose that the above text be replaced with: "The protocol defined here allows the RM Destination to meet this guarantee for the delivery assurances defined below."

3) Line 158-159 says: "Note that the underlying protocol defined in this specification remains the same regardless of the delivery assurance."

This is text that was added recently. To be more clear, I propose that we change this to: "Note that the underlying protocol defined in this specification is independent of the delivery assurance. I.e., irrespective of the delivery assurance, this specification, for the non-error case, requires the RM Sender to resend a message until an acknowledgement is received from the RM Destination for every message that the RM Sender sends in the Sequence."

Proposal 22005-12-14

Accept parts 2 and 3 of email 85 with the following to replace part 1, "It is the responsibility of the RM Destination and Application Destination to fulfill the delivery assurances, or raise an error".

Complete text below, line numbers from wd-05.

1) Line 151-153 says: "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."

This isn't quite right as the RMS is not involved in implementing the DAs.

I would like to propose that the above text be replaced with: "It is the responsibility of the RM Destination and Application Destination to fulfill the delivery assurances, or raise an error."

2) Line153-154 says: "The protocol defined here allows endpoints to meet this guarantee for the delivery assurances defined below."

To be more specific I propose that the above text be replaced with: "The protocol defined here allows the RM Destination to meet this guarantee for the delivery assurances defined below."

3) Line 158-159 says: "Note that the underlying protocol defined in this specification remains the same regardless of the delivery assurance."

This is text that was added recently. To be more clear, I propose that we change this to: "Note that the underlying protocol defined in this specification is independent of the delivery assurance. I.e., irrespective of the delivery assurance, this specification, for the non-error case, requires the RM Sender to resend a message until an acknowledgement is received from the RM Destination for every message that the RM Sender sends in the Sequence."

Resolution2005-12-14
Proposal 2 accepted at December 14th F2F meeting
Resolution2006-01-05
Completed in CD 2
i081 RMS lacks support for InOrder core - design - closed
Description
InOrder (as defined) requires two conditions in addition to the use of the protocol: (a) messages are numbered by RMS in same order they are submitted ("sent"), (b) messages are delivered by RMD in same order as they are numbered. There is currently no requirement for (a).
Justification
RMD alone can't enforce InOrder. RMS must do its part. Either it has to be aware of which DA is required, or the required behavior must be an invariant of RMS regardless of DA.
Related Issues
Origin
Jacques Durand
Owner
Jacques Durand
Proposal 12005-12-07
Make it an invariant. Add a sentence at the end of 1st invariant (section 2.3): "During the lifetime of a Sequence, two invariants are REQUIRED for correctness: The RM Source MUST assign each message to be delivered reliably a message number (defined below) beginning at 1 and increasing by exactly 1 for each subsequent message to be delivered reliably. These numbers MUST be assigned in the same order in which messages are sent by the Application Source."
Resolution2005-12-14
Proposal 1 accepted at December 14th F2F meeting
Resolution2006-01-05
Completed in CD 2
i082 Level of "response message" unclear, for SequenceResponse core - design - closed
Description
The wsrm specification makes several mentions of carrying some operation messages (CreateSequenceResponse, CloseSequenceResponse) over "response messages". It is unclear whether these are underlying protocol responses if a 2-way protocol is used, or are SOAP responses (as in SOAP MEPs), or are just RM-level messages with "response" semantics.
Justification
In order to remain independent from underlying protocol bindings, and to not preclude future SOAP bindings to other protocols, (or even other HTTP bindings such as PAOS) the specification must not make any assumption about MEPs that take place below SOAP level. The current wording could be interpreted as: a request-response underlying protocol is in use and messages such as CreateSequenceResponse bind to a response.
Related Issues
Origin
Kazunori Iwasa, Jacques Durand
Owner
Jacques Durand
Proposal 12005-12-15
Reword "request message" and "response message" so that they become respectively SOAP request and SOAP response messages (either referring to SOAP responses as informally Defined in SOAP 1.1 or to SOAP Request-response MEP formally defined in 1.2). Replace the expression "request-response pattern" (Section 4) by SOAP request-response MEP.
Proposal 22006-01-19

From Jaqcues:

  • 1 - L237: replace: "...responds either with a <wsrm:CreateSequenceResponse> or a CreateSequenceRefused fault in the body of the response message." With : "...responds either with a message containing <wsrm:CreateSequenceResponse> or with a CreateSequenceRefused fault." (its being said enough elsewhere that either one should be in the body)
  • 2 - Everywhere else, replace "response message" with "message". (That would avoid such redundancy as "response message in response to...")
  • 3- Replace "request message" by "message" everywhere.
  • 4- L611: "Faults" section: remove the sentence: "Sequence creation uses a CreateSequence, CreateSequenceResponse request-response pattern." which has little meaning in this section anyway (the rest of the paragraph talks of errors incurred by the CreateSequence message only)
Resolution2006-01-19

Resolved on Jan 19th TC call to accept points 1 and 4 from proposal 2.

Resolution2006-03-02
Completed in CD 3
i083 Fault Messages for Terminated Sequence core - editorial - closed
Description
It is not clear whether "SequenceTerminated" Fault is allowed in response to a message with a terminated sequence ID.
Related Issues
Origin
Tom Rutt
Owner
Tom Rutt
Proposal 12006-01-02

Add the following clarification to the text regarding sequence Termination

Either a "SequenceTerminated" fault or an "UnknownSequence" fault may be returned by an RMD in response to a messaged containing a terminated Sequence ID.

Proposal 22006-01-18

From Tom:

Line 614 of Candidate CD II draft:

Change:

UnknownSequence is a fault generated by endpoints when messages carrying RM header blocks targeted at unrecognized sequences are detected, these faults are also treated as defined in WS-Addressing.

To

UnknownSequence is a fault generated by endpoints when messages carrying RM header blocks targeted at unrecognized or terminated sequences are detected, these faults are also treated as defined in WS-Addressing.

Line 719 of Canditate CD II draft

Change:

This fault is sent by either the RM Source or the RM Destination in response to a message containing an unknown sequence identifier.

To:

This fault is sent by either the RM Source or the RM Destination in response to a message containing an unknown or terminated sequence identifier.

Resolution2006-01-19

Resolved on Jan 19th TC call to accept proposal 2.

Resolution2006-03-02
Completed in CD 3
i084 RMS state table and SequenceClosedFault core - editorial - closed
Description
The RMS state table currently has many placeholders in Row 16, which describes the RMS state transitions when it receives a SequenceClosedFault. The author of the table considered the spec unclear, and so was unable to complete this row.
Justification
The spec should be complete, or explicitly declare some behaviour to be beyond the spec.
Related Issues
Origin
Matthew Lovett
Owner
Matthew Lovett
Proposal 12006-01-05

Taking the columns in turn:

e, f, g -> The RMS should move the Sequence into closed state. This is described (in working draft 07) by lines 759 - 761, and referenced from line 383. I believe that information is complete and clear, but welcome any suggestions to improve it.

h -> No change, the Sequence is still closed. This can easily occur, if the rate that the RMS sends messages is higher than the time it takes for a fault message to travel back from the RMD. In any case, I think that the information noted above covers this, but welcome editorial suggestions.

i -> With the spec as it stands there is no 'terminating' state for sequences, so we cannot hope to have a sensible answer here. If a terminating state is created then the RMS may choose to note the final ack state (as carried in the fault), but should remain in the terminating state.

j -> The question mark here is covered by another new issue "Fault Messages for Terminated Sequence", raised by Tom and recorded as Proposed 02 for the 5th Jan 2006 call.

Proposal 2 2006-02-16

Reference to wsrm-1.1-spec-cd-02

Replace lines 373-376 with the following:

Should the RM Destination wish to discontinue use of a sequence it may autonomously close the sequence. From that point in time until the sequence is terminated, the RM Destination shall behave as if it had received a <wsrm:CloseSequence> element from the RM Source and shall generate SequenceClosed Faults upon receipt of new messages directed at the closed sequence. The RM Source, upon receipt of a SequenceClosed Fault at any time, will behave as it had sent a <wsrm:CloseSequence>.

Modifications to the WSRM State Table V1.0 Based on WD07

RMS table, row 20 “receipt of SequenceClosedFault from RMD” columns e through h, change next state from ? to Closed; column I change next state to Ignore

Proposal 32006-02-16

Reference to wsrm-1.1-spec-cd-02

Replace lines 373-376 with the following:

Should the RM Destination wish to discontinue use of a sequence it MAY autonomously close the sequence. From that point in time until the sequence is terminated, the RM Destination MUST behave as if it had received a <wsrm:CloseSequence> element from the RM Source and MUST generate SequenceClosed Faults upon receipt of new messages directed at the closed sequence. The RM Source, upon receipt of a SequenceClosed Fault at any time, MUST behave as it had sent a <wsrm:CloseSequence>.

Modifications to the WSRM State Table V1.0 Based on WD07

RMS table, row 20 “receipt of SequenceClosedFault from RMD” columns e through h, change next state from ? to Closed; column I change next state to Ignore

Resolution2006-02-16
Proposal 3 arrived at and accepted on Feb 16th TC call.
Resolution2006-03-02
Completed in CD 3
i085 CloseSequence element is inconsistent core - design - closed
Description
All other references to Sequence identifiers is by an element, using a reference to the global wsrm:Identifier element. The CreateSequence element uses an attribute, and defines it inline.
Justification
While not a critical problem, the schema should be consistent.
Related Issues
Origin
Matthew Lovett
Owner
Matthew Lovett
Proposal 12006-01-10

Replace the attribute with a reference to the wsrm:Identifier element within the CreateSequence element:

Update the CloseSequence on line 372 (in wd 08), and the following description. The new example should be:

<wsrm:CloseSequence ...="">

<wsrm:Identifier ...=""> xs:anyURI </wsrm:Identifier>

...

</wsrm:CloseSequence>

and the description need to be changed to include the new element and the extensibility points.

Resolution2006-01-12
The TC accept this new Issue and close with its proposal, and along with new text for lines 379 thru 381, using lines 455 to 460 as a basis.
Resolution2006-03-02
Completed in CD 3
i086 Alternative approach for MaxMessage core - design - closed
Description
We solved the issue of some platforms not having a native unsigned long by adding a MaxMessageNumber to Policy. Another simpler approach would be to use max(signed long) as the limit, and ensure that all implementations can support this.
Justification
This is not a critical issue, but this is a simpler
Related Issues
Origin
Paul Fremantle
Owner
Paul Fremantle
Proposal 1

Policy:

Remove lines 97-100 plus editorial fixup of following para. Remove line 114 Remove line 130-134

Core:

Update line 465 to state new limit. Add a schema restriction on line 870

Resolution2006-01-19

Resolved on Jan 19th TC call to accept proposal 1 as amended by Anish's message.

Resolution2006-03-02
Completed in CD 2
i087 Acknowledgement Interval in CreateSequenceResponse core - design - closed
Description
Propose moving AI from Policy to the CreateSequenceResponse
Justification
AcknowledgementInterval is not constraint or feature of an endpoint, it is a protocol parameter of a given sequence. Moving it out of policy has a number of benefits. It reduces the reliance on Policy and WSDL for simple devices, allowing them to ascertain this value without supporting either of those standards. It makes it clear what the ack interval is for any sequence. Further it seems unrealistic that a service would be chosen on the basis of AckInterval.
Related Issues
Origin
Paul Fremantle
Owner
Paul Fremantle
Proposal 1

Modifications to the WSRM spec - Based on WD8

After line 302 insert:

<wsrm:AcknowledgementInterval Milliseconds="xs:unsignedLong" ...="" /> ?

After line 326 Insert:

/wsrm:CreateSequenceResponse/wsrm:AcknowledgementInterval

This element, if present, specifies the duration after which the RM Destination will transmit an acknowledgement. If omitted, there is no implied value.

/wsrm:CreateSequenceResponse/wsrm:AcknowledgementInterval/@Milliseconds

The acknowledgement interval, specified in milliseconds.

Changes to Policy document based on WD3.

Remove lines 101-108

Remove line 113

Remove lines 125-129

Remove line 164 (AI example)

At line 179 Remove text: "Line (13) indicates the RM Destination may buffer acknowledgements for up to two-tenths of a second."

Resolution2006-01-19

Resolved on Jan 19th TC call to accept proposal 1.

Resolution2006-03-02
Completed in CD 3
i088 Versioning policy all - design - closed
Description
Our specs need a formally adopted namespace versioning policy.
Related Issues
Origin
Chris Ferris
Owner
Chris Ferris
Proposal 12006-01-19

Namespace Versioning Policy

The following is the declared policy of this specification with regards to the namespace URI assignment for both the related XML Schema and WSDL definitions.

The pattern of the namespace URI shall be:

http://docs.oasis-open.org/ws-rx/[product]/yyyymm/

Where [product] is the short name of the specification as prescribed by OASIS followed by the century, year and month chosen by the TC.

It is the intent of the WS-RX TC members that the namespace URI will not change arbitrarily with each subsequent revision of the corresponding WSDL or XML Schema document, but rather change only when a subsequent revision, published in conjunction with a Committee Specification results in non-backwardly compatible changes from a previously published Committee Specification.

Under this policy, the following are examples of backwards compatible changes that would not result in assignment of a new namespace URI:

* addition of new global element, attribute, complexType and simpleType definitions

* addition of new operations within a WSDL portType or binding (along with the corresponding schema, message and part definitions)

* addition of new elements or attributes in locations covered by a previously specified wildcard

* modifications to the pattern facet of a type definition for which the value-space of the previous definition remains valid or for which the value-space of the preponderance of instance would remain valid

* modifications to the cardinality of elements for which the value-space of possible instance documents conformant to the previous revision of the schema would still be valid with regards to the revised cardinality rule

The policy for namesapce URI assignment between subsequent revisions of TC editors drafts shall be to retain the same namespace URI regardless of the nature of the changes. Prior to adoption of a new Committee Specification, the TC will assess the backwards-compatibility of the schema and WSDL documents with the prior Committee Specification (if any) and either retain the namespace URI or assign a new one in accordance with this policy.

An RDDL document shall be made available at the namespace URI location that will provide a link to the actual location of the relevant XML Schema or WSDL definitions documents. When appropriate, the RDDL will provide links to the deprecated revisions of the XML Schema and WSDL definitions documents that carry the same namespace URI.

Resolution2006-01-19

Accept proposed issue and proposal 1 as amended by Paul Cotton:

Change the following text:

"It is the intent of the WS-RX TC members that the namespace URI will not change arbitrarily with each subsequent revision of the corresponding WSDL or XML Schema document, but rather change only when a subsequent revision, published in conjunction with a Committee Specification results in non-backwardly compatible changes from a previously published Committee Specification."

to refer to "Committee Drafts/Specification" instead of "Committee Specification"

Resolved on Jan 19th TC call

Resolution2006-03-02
Completed in CD 3
i089 suggest the restricted use of anonymous URI core - design - done
Description
When an AS uses an RMS to reliably send messages to an RMD, the RMS will need to be able to resend the un-acked messages at will. If the AS uses a target URL or wsa:To value such that the RMS can not, at its own discretion, initiate the (re)sending of messages then the RMS would be severely limited in its ability to complete its job. To this end the RM spec should discourage the use of wsa:To values that would put the RMS in this situation, like the anonymous URI. Of course, there may be times that using the anonymous URI _and_ RM can work and so we shouldn't totally ban the use of anonymous URI but we should make people aware that w/o some other mechanism, a generic WSA+RM soap stack would not be able to support this. Note, that while this is phrased in the context of wsa:To, for replies the RMD becomes the RMS and the wsa:ReplyTo becomes the wsa:To - so it would mean that we'd, implicitly, be discouraging the use of the anonymous URI in wsa:ReplyTo when people would want responses sent reliably.
Related Issues
Origin
Doug Davis
Owner
Doug Davis
Proposal 12006-02-08

After line 441 of [1] add:

Messages sent using this protocol MUST NOT use a wsa:To value that would prohibit the RM Source from retransmitting unacknowledged messages. For example, using WS-Addressing's anonymous IRI, without any additional transmission mechanism, would restrict an RM Source's ability to re-establishing a new connection to the RM Destination when a re-transmission of a message is needed. Note, that this implicitly impacts possibles values used in other places - for example, in wsa:ReplyTo when responses are expected to be transmitted reliably.

Proposal 2 2006-02-23
Close with no action.
Proposal 3 2006-04-06
Proposal 4 2006-04-27
Revised from Apr 4 proposal
Proposal 5 2006-04-26
Proposal 6 2006-05-10
Proposal 7 2006-05-10
Proposal 8 2006-05-10
Proposal 9 2006-05-31
Resolution 2006-06-08
Proposal 9 accepted on June 8th TC call.
i090 Use of offered sequences unclear in current spec core - design - done
Description

When an RMS sends a CreateSequence that includes an offer, the offer is meant to be an optimisation for creating a sequence back from the RMD to the RMS. Closer inspection highlights issues with this approach.

The RMS knows the endpoint of the RMD and sends it the CreateSequence message with the Offer, but the RMD is not informed of the endpoint it should use to send protocol messages back to the RMS for the offered sequence, or which AD endpoints the sequence can be used for.

Now, the RMD could assume that

a) It should send protocol messages to the same endpoint that it sends the CreateSequenceResponse message to for the inbound sequence.

b) It should send protocol messages to the same endpoint that it sends Acks to for the inbound sequence

c) It should send protocol messages to the same endpoint that it would have done if it had created the outbound sequence itself, which could be a, or b, or another endpoint as yet unknown to it.

but assumptions break interoperability and the RMD still doesnt know which application messages can use the sequence.

As an optimisation, the offer should not change the behaviour that would be observed without the optimisation.

Lets take an example. Two applications A and B use reliable messaging to query addresses from an address book application at endpoint X. They both use the same RMS and share the same sequence, and the RMD at endpoint X passes the messages onto the address book app where addresses are queried and need to be sent back. Application A sets a wsa:ReplyTo of Endpoint A for its replies. Application B sets a wsa:ReplyTo of Endpoint B for its replies. Both these endpoints support WSRM. When the replies are sent back, two sequences are established. One to endpoint A and one to endpoint B.

Now try and do the same with offer. The RMS creates the outbound sequence and offers a sequence the other way. Its accepted by the RMD. Now the application messages arrive at the RMD, are processed by the address book app and the replies need to be sent back to Endpoint A and Endpoint B.

Which endpoint does the offered sequence service? None, A, B, or both?

Further more, since the spec doesn't limit the offered sequence to just replies (it can be used for any msg going from the RMD to the RMS) this problem is made even worse. Even before the first application message from the RMS to the RMD is sent, the RMD could have a message for the RMS. How does the RMD know whether or not the wsa:To EPR in this message matches one of the possibly many RMS EPRs that the offered sequence is for?

The result is the creation of an offered sequence where its not clear which application messages can use it, or where to send the protocol messages.

Related Issues
Origin
Daniel Millwood
Owner
Daniel Millwood
Proposal 12006-01-16

Whilst there may be a subset of WSRM usecases where offer could make sense, I believe it is too open to interpretation to be interoperable. For the benefit of interoperability, it should be removed from the spec.

Delete from <wsrm:CreateSequence> in line 274, through to 277 Delete lines 309 through to 330 Delete lines 369 through to 384 Delete line 1043 Delete line 1060 Delete lines 1090 through to 1106

Proposal 2 2006-02-23

Section 2.1

Line 240 after last sentence add, "When an offer is accepted all messages for the accepted sequence MUST be sent to the <wsa:ReplyTo> of the <wsrm:CreateSequence> message."

Line 274 change "to RM Source." to "to the RM Source at the address specified by the <wsa:ReplyTo> of this message."

Line 343 change "to RM Source." to "to the RM Source at the address specified by the <wsa:ReplyTo> of the <wsrm:CreateSequence> message."

Proposal 3 2006-03-09
Proposal 4 2006-03-16
Proposal 5 2006-03-16

Line 282 Insert

/wsrm:CreateSequence/wsrmffer/wsrm:Endpoint

This REQUIRED element, of type wsa:EndpointReferenceType as specified by WS-Addressing [WSAddressing] specifies the endpoint reference to which WS-RM protocol messages related to the offered Sequence are to be sent.

Line 238 strike starting at "Note that" to 241.

Resolution 2006-03-16
Proposal 5 arrived at and agreed to on March 16th TC call.
i091 Unexpected UnknownSequenceFault or SequenceTerminatedFault core - design - done
Description
State table indicates insufficient specification of these faults condition.
Related Issues
Origin
Bob Freund-Hitachi
Owner
Bob Freund-Hitachi
Proposal 1

Core:

Ref WD08

Insert after line 706:

Receipt of SequenceTerminated by either the RMD or the RMS shall terminate the sequence if it is not otherwise terminated.

Insert after line 715:

Receipt of UnknownSequence by either the RMD or the RMS shall terminate the sequence if it is not otherwise terminated.

State Table:

Ref 1.0:RMD

Change next state row 15, columns E-H to Terminated

Change next state row 16, columns E-H to Terminated

Ref 1.0 RMS

Change next state row 17 columns E-I to Terminated

Change next state row 18 columns D-H to Terminated

Resolution2006-02-09
Proposal 1 accepted on Feb. 9 TC call.
i092 Where is the SequenceAcknowledgement sent on receipt of AckRequested header? core - design - done
Description
The spec does not say where the SequenceAcknowledgement message is sent on receipt of the AckRequested header. There are two possibilities: to the AcksTo EPR or to the ReplyTo (as a response) of the message requesting the SequenceAcknowledgement.
Related Issues
Origin
Anish Karmarkar
Owner
Anish Karmarkar
Proposal 1 2006-02-15
Please see post from Anish (includes highlighting that can't be rendered here).
Resolution2006-02-16
Proposal 1 accepted on Feb 16th TC call.
i093 2119 terms apply to implementations, not message (document) instances core - editorial - done
Description
RFC 2119 assigns very specific meanings to the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". We say this RFC applies to our specification but do not consistently use the words as defined. RFC 2119 is about requirements of a specification (for implementations of said specification that is) and not about cardinality in or other constraints upon an XML message (or document in general) instance. Phrases in the RFC such as "particular behaviour is acceptable" and "implementation which does not include" make this distinction quite clear. We should use other terms to describe cardinality and constraints for the elements and attributes in our schema.
Related Issues
i040
Origin
Doug Bunting
Owner
Doug Bunting
Proposal 1

Editors run through the specifications and correct phrases such as (line numbers from CD 02)

  • "the action IRI MUST consist of the WS-RM namespace" (line 122)
  • "Additional children elements ... MUST NOT contradict the semantics" (lines 229-230)
  • "This element MUST NOT be sent as a header block" (line 255)
  • "This OPTIONAL element" (line 545)

and correct them to describe the constraints in terms of the implementation. In many cases, this change will have the additional benefit of changing the voice from passive to active.

Resolution2006-02-09
Proposal 1 accepted on Feb. 2 TC call (see proposed-01).
Resolution2006-05-25
Changes from editors with modifications accepted on Feb. 2 TC call (see proposed-01).
Resolution 2006-05-30
Resolution applied in WD 13
i094 New WSRMRequired Fault core - design - closed
Description
When an RMD requires its incoming messages to be delivered using RM we should define a standard fault that all endpoints can generate so we can consistently know what kind of error to expect.
Related Issues
Origin
Doug Davis
Owner
Doug Davis
Proposal 1

Using [1] add a section 4.8 that says:

4.8 WSRM Required

If RM Destination requires the use of WS-RM this fault is generated when it receives an incoming message that did not use this protocol. Properties:

[Code] Sender

[Subcode] wsrm:WSRMRequired

[Reason] RM Destination requires the use of WSRM.

[Detail]

xs:any

Resolution2006-02-09
Proposal 1 accepted on Feb. 9 TC call.
Resolution2006-03-02
Completed in CD 3
i095 CloseSequenceResponse and TerminateSequenceResponse messages are inconsistent wrt presence of wsrm:Identifier spec - design - closed
Description
Both the CloseSequenceResponse and TerminateSequenceResponse follow a similar pattern, but the CSR message does not contain the wsrm:Identifier whereas the TSR does.
Related Issues
Origin
Anish Karmarkar
Owner
Anish Karmarkar
Proposal 1

All changes are wrt CDII

1) After line 398 insert:

<wsrm:Identifier ...=""> xs:anyURI </wsrm:Identifier>

2) After line 404 insert:

/wsrm:CloseSequenceResponse/wsrm:Identifier

This REQUIRED element MUST contain an absolute URI conformant with RFC3986 that uniquely identifies the Sequence that is closed.

/wsrm:CloseSequenceResponse/wsrm:Identifier/@{any}

This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the element.

3) After line 1049 (in schema) insert:

<xs:element ref="wsrm:Identifier"/>

Resolution2006-02-09
Proposal 1 accepted on Feb. 9 TC call.
Resolution2006-03-02
Completed in CD 3
i096 Complete the state tables core - design - done
Description

The following are comments on the WSRM WD 10 Appendix 5 State Tables. FYI I believe the original state table proposal was here.

  1. There is no description in Appendix 5 of the meaning of the "N/A" "action to take".
  2. There is no explanation in Appendix 5 of what a cell means if there is a "?" (question mark) in the cell. Sometime the "?" appears alone and sometimes it appears affixed on an "action to take".
  3. There is no explanation in Appendix 5 of cells that do not contain an "action to take".
  4. There is no reference to Appendix D in the body of the specification. Can we provide a forward reference to Appendix D somewhere in the body of spec?
Related Issues
Origin
Doug Davis
Owner
Bob Freund
Proposal 1 2006-03-22
Proposal 2 2006-04-01
Resolution 2006-04-06
Proposal 2 acepted.
Resolution 2006-04-27
Edits applied in RM WD 12 and RM Policy WD 8.
Resolution 2006-05-30
Resolution applied in WD 13
i097 Extensibility of RM assertion needs to be defined policy - editorial - done
Description
The RM Policy Assertion defines the normative outline of the assertion to include extensibility for at the attribute and element level but not describe the extensibility.
Related Issues
Origin
Marc Goodner
Owner
Marc Goodner
Proposal 1 2006-02-23

Add after line 111 in section 2.2 (From current CD III candidate):

/wsrm:RMAssertion/{any}

This is an extensibility mechanism to allow different (extensible) types of information, based on a schema, to be passed.

/wsrm:RMAssertion/@{any}

This is an extensibility mechanism to allow different (extensible) types of information, based on a schema, to be passed.

Resolution 2006-03-02
Proposal 1 accepted on March 2nd TC call.
Resolution 2006-04-27
Edits applied in RM WD 12 and RM Policy WD 8.
i098 clarify difference between "sequence" and "non-sequence" faults core - editorial - done
Description
The second paragraph of Section 4 (lines 659-665 of http://www.oasis-open.org/committees/download.php/16851/wsrm-1.1-spec-wd-10.pdf) appears somewhat garbled. For example it states "CreateSequenceRefused is a possible fault reply for this operation" without any indication of what "this operation" refers to.
Justification
The difference between faults that are related to a specific sequence and those that are not is an important one that needs to be clarified.
Related Issues
Origin
Gilbert Pilz
Proposal 1
Resolution 2006-03-09
Proposal 1 accepted on March 9th TC call.
i099 Correlating faults to Sequences using SOAP 1.1 core - design - done
Description
The last sentence in the second paragraph of Section 4 (line 665 of http://www.oasis-open.org/committees/download.php/16851/wsrm-1.1-spec-wd-10.pdf) states that "These faults are correlated using the Sequence identifier carried in the detail" yet the description of the mapping of WS-RM faults to SOAP 1.1 seems to indicate that the [Detail] property is not carried in SOAP 1.1.
Justification
When an RMS or an RMD receives a fault such as <wsrm:SequenceTerminated> it is necessary to be able to figure out the Sequence to which the fault applies. The inability to do this when using SOAP 1.1 is seems to be a severe shortcoming.
Related Issues
Origin
Gilbert Pilz
Proposal 1
Resolution 2006-03-09
Proposal 1 accepted on March 9th TC call.
i100 Language for faultstring elements core - editorial - done
Description
The section of WSRM WD 10 that binds WS-RM faults to SOAP 1.1 is inconsistent in its use of the <faultstring> element. Line 718 does not constrain the language to be used, while line 728 restricts the language to English (xml:lang="en").
Justification
The specification should be consistent, and apply fairly to languages in use around the world.
Related Issues
Origin
Matthew Lovett
Owner
Matthew Lovett
Proposal 1 2006-03-02
Delete the xml:lang attribute from line 728.
Resolution 2006-03-02
Proposal 1 accepted on March 2nd TC call.
i101 Recommend RMD Close rather than Terminate core - design - done
Description
If the RMD terminates the sequence, the RMS cannot know which messages are acknowledged. That is why we added CloseSequence. We should recommend that RMD's use CloseSequence rather than TerminateSequence.
Justification
At the moment the spec says the RMD "may" close the sequence. However, unless there is a specific reason (e.g. resource issues, security issues etc), it is better if the RMD closes rather than terminates.
Related Issues
Origin
Paul Fremantle
Owner
Paul Fremantle
Proposal 1 2006-03-02

From WD-10:

At line 381: Replace:

"In the case where the RM Destination wishes to discontinue use of a sequence it may 'close' the sequence itself."

with

"In the case where the RM Destination wishes to discontinue use of a sequence it is RECOMMENDED that it 'close' the sequence."

Proposal 2 2006-03-07
Resolution 2006-03-09
Proposal 2 accepted on March 9th TC call.
i102 consistency in controlling the binding of SequenceAcknowledgement and of seq management responses core - design - dropped
Description
The protocol makes it possible to control how SequenceAcknowledgement can be returned to the RMS, w/r to the binding-specific channel of the underlying protocol, via the use of the WS-Addressing anonymous URI in the CreateSequence message (see i061 resolution). However the protocol does not offer any similar control on how the sequence management response messages (CSR, CloseSequenceResponse, and TSR) are making use of the underlying protocol binding-specific channel.
Justification
The deployment requirements that may lead to return SequenceAcknowledgement headers over the back-channel of an underlying 2-way protocol such as HTTP, will also require that sequence management response messages be also returned on the back-channel of the protocol. If not, it will not be possible to satisfy these requirements. For example, these requirements may be: an RMS may not be able to receive incoming requests due to security restrictions, or to addressing restrictions. It is not consistent - and potentially an interop issue - to address these for Seq-Acks and not for sequence management responses.
Related Issues
Origin
Jacques Durand
Owner
Jacques Durand
Proposal 1

After, or soon after the addition from i061:

[ When the wsrm:AcksTo EPR specifies the WS-Addressing anonymous URI as its address, the RMD MUST transmit any wsrm:SequenceAcknowledgement headers for the created Sequence in a SOAP envelope to be transmitted on the protocol binding-specific channel. ]

add:

"When the wsrm:AcksTo EPR specifies the WS-Addressing anonymous URI as its address, the CreateSequenceResponse MUST also be transmitted by the RMD on the protocol binding-specific channel provided by the context of the CreateSequence message. This MUST also be the case for any response message (CLoseSeqResponse, TerminateSeqResponse) to related sequence management messages that concern the same sequence. "

Resolution 2006-03-22
Closed with no action at March 22nd F2F.
i103 Remove the Partial Answer Mode (PAM) core - design - done
Description
When the RMS requests an acknowledgement, the RMD may either reply with a full sequence state, or a nack. It should be recommended that the RMD responds with the full state.
Justification

While getting a nack back (unprompted) is an efficient model for the RMD to point out "gaps" in the sequence, it does not give the RMS full information. If the RMS is asking what "messages did you get?", it is a little annoying to say "well.... you know, I *didn't* get message 3".

RECOMMEND that the RMD replies with a "full" ack.

Related Issues
Origin
Paul Fremantle
Owner
Paul Fremantle
Proposal 1

From CD-3.

At end of line 539 add:

It is RECOMMENDED that the RMD return a <wsrm:AcknowledgementRange> or <wsrm:None> element instead of a <wsrm:Nack> element (see below).

Resolution 2006-03-22
Proposal 1 accepted at March 22nd F2F.
i104 Mixing SOAP versions core - design - done
Description
You may end up with both SOAP 1.1 and SOAP 1.2 across a sequence. (Note WS-A concerd with resolution to i042)
Justification
Suppose the RMS starts a sequence in SOAP 1.2. The RMD may initiate messages (e.g. SequenceAcknowledgement). Those could be in SOAP 1.1. Should we allow mixing SOAP types? Probably not. We could recommend that the SOAP style in place for the CS should used for the rest of the sequence.
Related Issues
Origin
Paul Fremantle
Owner
Paul Fremantle
Proposal 1

From CD-3 between lines 241-2 insert new para:

The SOAP and WS-Addressing versions used for the CreateSequence message SHOULD remain in place for all future interactions between the RMS and RMD, including messages initiated by the RMD (e.g. <wsrm:SequenceAcknowledgement> and faults).

Proposal 2 2006-03-23

From CD-3 between lines 241-2 insert new para:

The SOAP version used for the CreateSequence message SHOULD be used for all subsequent messages in or for that Sequence, sent by either the RMS or the RMD.

Resolution 2006-03-23
Proposal 2 accepted at the March 23rd TC F2F.
i105 Sequence Acks on all messages after close core - editorial - done
Description
The current text is not clearly written. It says: "Upon receipt of this message, or subsequent to the RM Destination closing the Sequence of its own volition, the RM Destination MUST include a final SequenceAcknowledgement (that MUST include the <wsrm:Final> element) header block on each message destined to the RM Source, including the CloseSequenceResponse message and on any Sequence Fault transmitted to the RMS."
Justification

Obviously there may be messages (for example after the sequence has been terminated and the RMD no longer knows about this) that cannot include this element. The text needs tidying up.

Related Issues
Origin
Paul Fremantle
Owner
Paul Fremantle
Proposal 1

From CD-3. At lines 373-377 replace the above text with:

"Upon receipt of this message, or subsequent to the RM Destination closing the Sequence of its own volition, the RM Destination MUST include a final SequenceAcknowledgement (that MUST include the <wsrm:Final> element) header block on any messages *associated with the Sequence* destined to the RM Source, including the CloseSequenceResponse message *or* on any Sequence Fault transmitted to the RMS."

The added/modified text is within * *.

Resolution 2006-03-23
Proposal 1 accepted at the March 23rd TC F2F.
i106 SequenceAcknowledgement:Final assumption of deliverability core - design - done
Description
Modify definition of SequenceAcknowledgement:Final to reflect accurate ending delivery capability status
Justification
The protocol defines the SequenceAcknowledgement:Final element which contains the final summary of message acknowledgements at the closure of a sequence. It is assumed that the RMD has taken responsibility for all messages that have been acknowledged. Depending upon the operation of the RMD and its interface with the application, Messages that have been previously acknowledged as received by the RMD, may never be deliverable. One such case of note that comes to mind is the situation of a message sequence that is being delivered in-order to an application which is closed at the time when one or more gaps that may exist in the sequence. If this situation occurs, the RMS will have incorrect information concerning exactly which messages have been or will be deliverable at the conclusion of a sequence. Note that there is nothing in the spec that states what the RMS is to do with the information contained in SequenceAcknowledgement:Final. This proposal does not add any such statement, but it does permit the information to be potentially interpretable.
Related Issues
Origin
Bob Freund
Owner
Bob Freund
Proposal 1
Reference Core Spec CD03 insert after line 613: SequenceAcknowledgemnt:Final shall identify only those messages that have been delivered or which the RMD has taken responsibility for delivery without regard to the previous acknowledgement status of any message.
Proposal 2 2006-04-04
Proposal 3 2006-04-06
Proposal 4 2006-04-12
Resolution 2006-04-27
Proposal 4 accepted with addendum on Apr 27th TC call.
Resolution 2006-05-30
Resolution applied in WD 13
i107 Nacks ack as well as Nack core - design - done
Description
The description of Nack implies but does not clearly state that a Nack acknowledges messages received of a lower sequence number.
Related Issues
Origin
Bob Freund
Owner
Bob Freund
Proposal 1
Ref spec CD03 Insert in line 621 after “by the Nack.” Receipt of a NACK by the RMS implicitly acknowledges all messages of sequence numbers lower than the lowest sequence number contained in the Nack or Nacks.
Proposal 2 2006-03-23
Strike the sentance on line 616 starting at "This element permits..." through 618 of cd3
Resolution 2006-03-23
Proposal 2 accepted at March 23rd F2F.
i108 misplaced guidance on fault handling core - editorial - done
Description

Line 566 CD3 WS-RM spec (SeqAck section 3.6) reads:

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.

First point, this text isn't very clear. Second, it is IMO misplaced. It really should be called out separately as it applies to more than just SequenceAcks.

Justification
This guidance is in the SeqAck section and really deserves to stand on its own as it applies to any RM header block that is piggy-backed on a message unrelated to the Sequence.
Related Issues
Origin
Chris Ferris
Owner
Chris Ferris
Proposal 1

Strike sentence beginning on line 566, through line 568.

Insert, after line 232:

When processing of an RM protocol element generates a fault and that RM protocol element pertains to a Sequence that is otherwise unrelated to the message in which the protocol element is contained, (i.e. the RM protocol element is a SequenceAcknowledgement or AcksRequested element) the receiving endpoint MUST continue normal processing the message unless the generated fault is a SOAP MustUnderstand fault.

After matter:

Note that this says nothing about transmission of the generated fault. I personally believe that we should leave well enough alone, however, I recognize that this MAY present interoperability issues, especially in the case where both the [reply] endpoint and the [fault] endpoint are anonymous. I COULD see adding guidance that says that when the above criteria are met that the endpoint MUST NOT transmit the fault to the anon endpoint UNLESS there is no response message to be transmitted.

Proposal 2 2006-03-23
Proposal 3 2006-04-05
Resolution 2006-04-06
Proposal 3 accepted
i109 The description of the <Sequence/> element could use some wordsmithing core - editorial - done
Description
The description of the Sequence element could use some wordsmithing.
Justification
It currently says nothing of substantive meaning.
Related Issues
Origin
Chris Ferris
Owner
Chris Ferris
Proposal 1

Change line 504 from:

This is the element containing Sequence information for WS-ReliableMessaging.

to:

This protocol element associates the message in which it is contained with a previously established RM Sequence. It contains the Sequence's unique identifier and the containing message's ordinal position within that Sequence.

Resolution 2006-03-23
Proposal 1 accepted at March 23rd F2F.
i110 Chris' Rants (on RM) part 1 core - editorial - done
Description
suggested editorial tweaks
Related Issues
Origin
Chris Ferris
Owner
Chris Ferris
Proposal 1
Resolution 2006-03-23
Proposal 1 accepted at March 23rd F2F.
i111 Sequence state in event of MessageNumberRollover core - design - done
Description
The spec doesn't talk about what the continued state of a sequence is after MessageNumberRollover.
Related Issues
Origin
Paul Fremantle
Owner
Paul Fremantle
Proposal 1
Proposal 2
Resolution 2006-04-06
Proposal 2 accepted.
i112 dangling reference to RMAssertion acknowledgement timing params core - design - done
Description
From cd03[1] lines 564-566:

The timing of acknowledgements can be advertised using policy and acknowledgements can be explicitly requested using the <wsrm:AckRequested> directive (see Section Request Acknowledgement).

Justification
dangling reference
Related Issues
Origin
Chris Ferris
Owner
Chris Ferris
Proposal 1
Resolution 2006-04-06
Proposal 1 accepted
i113 Tightening up the state tables core - design - active
Description

(a)- RMD table: there is no way to transition from " none" to "connecting" state (event "CreateSequence receive" is missing)

(b)- RMD table: In the "event" entries: for events that concern "Faults", (e.g. Unknown Sequence Fault, Terminated Sequence Fault), and when either RMS or RMD could generate such Faults, it should be mentioned in table if the event is about receiving or generating such a Fault (assume it is "receive").

(c)- RMS table: mention that either the case of offered sequences is not handled, or add this case.

(d) "connected" state a bit ambiguous a name - too much transport related.

(e) these tables are more about sequences state than RMD/RMS states (as the same RMD/S can find itself in many states w/r to many sequences.

Related Issues
Origin
Jacques Durand
Owner
Jacques Durand
Proposal 1
i114 Figure 2 (cd3) is out of date with the changes to the potocol core - design - done
Description
Figure 2 (cd3) is out of date with the changes to the potocol
Related Issues
Origin
Christopher B Ferris
Owner
Christopher B Ferris
Proposal 1
Proposal 2
Resolution 2006-05-04
Proposal 2 acepted on May 4th TC call.
Resolution 2006-05-30
Resolution applied in WD 13
i115 "must understand" attribute for extensions to RM components core - design - dropped
Description
All of the Sequence Lifecycle Messages (<wsrm:CreateSequence>, <wsrm:CreateSequenceResponse>, <wsrm:CloseSequence>, <wsrm:CloseSequenceResponse>, <wsrm:TerminateSequence>, and <wsrm:TerminateSequenceResponse>) and RM Protocol Header Blocks (<wsrm:Sequence>, <wsrm:AckRequested>, and <wsrm:SequenceAcknowledgement>) define extension points for adding additional elements to the message, however, there is currently no mechanism for the sending party (e.g. the RMS in the case of a <wsrm:CreateSequence> message or the RMD in the case of a <wsrm:TerminateSequence> message) to indicate to the receiving party that it must understand the semantics implied by the extension element(s). The usefulness of these extension points is therefore imited by the fact that, in general, the sending party cannot be certain whether the receiving party understood the extension or is simply ignoring it.
Related Issues
Origin
Gilbert Pilz
Owner
Gilbert Pilz
Proposal 1
Revised from original.
Resolution 2006-06-01
Closed with no action on June 1st TC call.
i116 Add Max Msg Num to Message Number Rollover Fault core - design - done
Description
Since an RM impl may not support msg numbers up to the max of 9,223,372,036,854,775,807 it would be nice if the MsgNumRollover Fault included the max msg number in its details section so that the processor of the fault can know what value was exceeded.
Related Issues
Origin
Doug Davis
Owner
Doug Davis
Proposal 1
Resolution 2006-04-27
Proposal 1 accepted on Apr 27th TC call.
Resolution 2006-05-30
Resolution applied in WD 13
i117 Issue 21 resolution text contains language about 'parameters' which don't exist core - design - done
Description

Issue 21 resolution text contains the following text:

"If the RM policy assertion appears in a policy expression attached to a wsdl:binding as well as to the individual wsdl:binding level message definitions(wsdl:binding/wsdl:operation/wsdl:input, wsdl:binding/wsdl:operation/wsdl:output, wsdl:binding/wsdl:operation/wsdl:fault), the parameters in the former MUST be used and the latter ignored. If the RM policy assertion appears in a policy expression attached to a wsdl:port as well as to the other allowed WSDL/1.1 elements, the parameters in the former MUST be used and the latter ignored."

The WSRMP spec does not define any 'parameters', therefore these statements don't mean anything and are possibly misleading (may lead reader to believe something about policy merges that may or may not be true).

Related Issues
Origin
Anish Karmarkar
Owner
Anish Karmarkar
Proposal 1
Resolution 2006-04-27
Proposal 1 accepted on Apr 27th TC call.
Resolution 2006-05-30
Resolution applied in WD 9
i118 misuse of request term core - editorial - done
Description
Line 215 of CD03 reads: The RM Source will expect to receive acknowledgements from the RM Destination during the course of a message exchange at occasions described in Section 3 below. Should an acknowledgement not be received in a timely fashion, the RM Source MUST re-transmit the request since either the request or the associated acknowledgement may have been lost.
Related Issues
Origin
Chris Ferris
Owner
Chris Ferris
Proposal 1
Resolution 2006-05-04
Proposal 1 acepted on May 4th TC call.
Resolution 2006-05-30
Resolution applied in WD 13
i119 When to piggy-back RM headers core - editorial - done
Description

It is not clear when an implementation is allowed to piggy-back RM headers (acks, ackReq) in a message. I suspect that most implementations will simply compare the wsa:Address of the EPRs - however, since ref-p's are an integral part of EPRs they should really be included in the comparison.

The latest WSA spec says:

2.3 Endpoint Reference Comparison

This specification provides no concept of endpoint identity and therefore does not provide any mechanism to determine equality or inequality of EPRs and does not specify the consequences of their equality or inequality. However, note that it is possible for other specifications to provide a comparison function that is applicable within a limited scope.

This proposal does just that - it proposes a comparison function for use just by RM for a very specific purpose.

Related Issues
Origin
Doug Davis
Owner
Doug Davis
Proposal 1
Modified from original proposal
Proposal 2
Proposal 3
Resolution 2006-06-01
Proposal 3 accepted on June 1st TC call.
i120 misplaced paragraph on action IRI's core - editorial - done
Description
Lines 120-123 of discuss the use of action IRI's. This seems out of place at this point in the document. This paragpragh should be moved to the first paragraph of Section 3 where we discuss the RM Protocol Elements.
Related Issues
Origin
Gilbert Pilz
Owner
Gilbert Pilz
Proposal 1
Resolution 2006-05-11
Proposal 1 acepted on May 11th TC call.
Resolution 2006-05-30
Resolution applied in WD 13
i121 security threats and requirements core - design - active
Description
Chapter 5 of the WS-RM spec has a number of problems: It lacks information specific to WS-RM. What needs to be protected and why? It is overly general in parts; describing general security concepts that don't have anything specifically to do with WS-RM. It recommends specific solutions (WS-SecureConversation) in preference to other solutions (e.g. HTTPS). It lacks the detailed security requirements that are needed by implementers to build secure WS-RM implementations.
Related Issues
Origin
Gilbert Pilz
Owner
Gilbert Pilz
Proposal 1
i122 security profiles core - design - active
Description
The WS-RX TC Charter requires that WS-RM support the “efficient preservation of the integrity of reliable contexts by composition with WS-Security or other SOAP security mechanisms”. The charter also states that “While composition with other specifications is a goal of the TC, it is also a goal to leave the specifics of how that composition is achieved outside the scope of this TC.” This proposal attempts to satisfy these two requirements by defining a set of non-normative profiles for composing WS-RM with commonly used web services security mechanisms. The purpose is to aid in the implementation and deployment of interoperable services and applications that utilize secure, reliable SOAP messaging systems.
Related Issues
Origin
Gilbert Pilz
Owner
Gilbert Pilz
Proposal 1
i123 security profile agreement core - design - active
Description
In order for an RMD to perform the processing necessary to protect the Sequences for which it is responsible it must be aware of the particular security composition profile in effect for each Sequence. In order for the RMS to be certain that the RMD is actually protecting the Sequence in the desired manner the RMS must have a specific indication that the RMD understands and will conform to the particular security composition profile being used by the RMS for that Sequence. Both of these requirements mandate a mechanism by which the RMS and RMD can communicate the desired and effective security composition profile for a particular Sequence.
Related Issues
Origin
Gilbert Pilz
Owner
Gilbert Pilz
Proposal 1
i124 security composition policy core - design - active
Description
Although it may be possible for an RMS to determine at runtime what supported security composition profiles it may share with an RMD (through, for example, a series of <wsrm:CreateSequence> messages that are extended with the <wsrmsp:SecurityComposition> element) in general it is operationally more efficient if services can advertise which security composition profiles they support. This information can be used by development, configuration, and component assembly tools to decrease the amount of manual, out-of-band communication necessary to establish reliable, secure message exchanges between two endpoints.
Related Issues
Origin
Gilbert Pilz
Owner
Gilbert Pilz
Proposal 1
i125 Protocol precondition requires knowledge of policies core - design - pending
Description

The RM Source MUST have knowledge of the destination's policies, if any, and the RM Source MUST be capable of formulating messages that adhere to this policy.

Justification: Since the only assertion that we make currently is that RM is on, this seems extraneous. Furthermore the spec is more useful if it does not presuppose knowledge of policy to make it work.

Related Issues
Origin
Paul Fremantle
Owner
Paul Fremantle
Proposal 1
Proposal 2
Resolution 2006-06-15
Proposal 2 accepted on June 15th TC call.
i126 unclear text regarding wsa:Action core - design - pending
Description

Line 120 currently reads: If an action IRI is used, and one is not already defined per the rules of the WS-Addressing specification [WS-Addressing], then the action IRI MUST consist of the WS-RM namespace URI concatenated with a '/', followed by the message element name. For example: http://docs.oasis-open.org/ws-rx/wsrm/200602/SequenceAcknowledgement

This text is, IMO, ambiguous, if not confusing, at best. The intent was to define the pattern of defining a wsa:Action IRI value when the intent of a message is exclusive to RM, such as in the case of RM lifecycle messages (CreateSequence, TerminateSequence, etc.) or in the case where either an RM fault or SequenceAcknowledgement are sent standalone.

Even Gil's proposed revisions (for i093) don't resolve the ambiguity:

If an action IRI is used by a system that uses the elements defined within this specification, and one is not already defined per the rules of the WS-Addressing specification [WS-Addressing], then said system MUST use an the action IRI that MUST consists of the WS-RM namespace URI concatenated with a '/', followed by the message element name. For example: http://docs.oasis-open.org/ws-rx/wsrm/200604/SequenceAcknowledgement

What is needed is simply a clear prescription for the designation of the wsa:Action IRIs that are specific to the specification.

Related Issues
Origin
Chris Ferris
Owner
Chris Ferris
Proposal 1
Resolution 2006-06-15
Proposal 1 accepted on June 15th TC call.
i127 Make Accept/AcksTo consistent core - design - pending
Description

The definition of CS/AcksTo says:

... It specifies the endpoint reference to which messages containing <wsrm:SequenceAcknowledgement> header blocks and faults related to the created Sequence are to be sent, unless otherwise noted in this specification (for example, see Section 3.2).

However, the Accept/AcksTo says:

... The RM Source SHOULD send messages with <wsrm:SequenceAcknowledgement> header blocks related to the accepted Sequence to the referenced endpoint.

This is a bit inconsistent since the 2nd one doesn't say anything about sending faults the EPR. Since the Offered sequence should be no different from a sequence created using a CS we need to align these two definitions.

Related Issues
Origin
Doug Davis
Owner
Doug Davis
Proposal 1
Resolution 2006-06-15
Proposal 1 accepted on June 15th TC call.
i128 define unspecified IncompleteSequenceBehavior core - design - dropped
Description
When CSR/IncompleteSequenceBehavior is not present the spec is silent on what the default value might be. We should be clear that there is no default value.
Related Issues
Origin
Doug Davis
Proposal 1
Resolution 2006-06-08
Closed with no action, since line 317 covers what is missing on June 8th TC call.
i129 Define "discard" core - design - pending
Description
In WD13.pdf section 3 - line 308++ - should we define "discard" - its not clear to me that we mean the discarded messages will NEVER (and have never) be delivered to the AD, instead of just "from now on the RMD won't deliver them".
Related Issues
Origin
Doug Davis
Owner
Doug Davis
Proposal 1
Proposal 2
Proposal 3
Resolution 2006-06-22
Proposal 3 accepted on June 22nd TC call.
i130 what does ack interval refer to core - design - pending
Description

In WD13.pdf section 3 - line 301 - defines the AckInterval element as:

This element, if present, specifies the duration after which the RM Destination will transmit an acknowledgement. If omitted, there is no implied value.

'after' what? It isn't clear when this mystery timer is kicked off.

- "...specifies the duration after which the RM Destination will transmit..."

After what? It should say 'after receipt of a message' or something like that.

Related Issues
Origin
Doug Davis
Owner
Doug Davis
Proposal 1
Resolution 2006-06-22
Remove AI from spec, accepted on June 22nd TC call.
i131 Remove sections 1.1 and 1.1.1 core - editorial - done
Description
there's no text in there so there's no reason to keep 'em
Related Issues
Origin
Doug Davis
Proposal 1
Resolution 2006-06-08
Proposal 1 accepted on June 8th TC call.
i132 Change default value of fault uri core - design - done
Description
The default value for the fault uri is set to the default value of the WS-A faults. WS-A Rec says this value should only be used for WS-A faults. We need to define our own default uri for faults.
Related Issues
Origin
Marc Goodner
Proposal 1
Proposal 2
Entities that generate WS-ReliableMessaging faults MUST include as the [action] property the fault action IRI defined below: http://docs.oasis-open.org/ws-rx/wsrm/200604/fault
Resolution 2006-06-08
Proposal 2 accepted on June 8th TC call.
i133 Duplicate text in fault section core - editorial - pending
Description
In Section 4 of WS-RM the first two paragraphs of this section are practically duplicates of each other.
Related Issues
Origin
Marc Goodner
Owner
Marc Goodner
Proposal 1
Proposal 2
Resolution 2006-06-15
Proposal 2 accepted with ammendment, change bold sentence to "WSRMRequired is a fault generated an RM Destination that requires the use of WS-RM on a received message that did not use the protocol.", on June 15th TC call.
i134 Update acknowledgements core - editorial - active
Description
In the Acknowledgements, Section E of WS-RM and Section A of WS-RM Policy, the TBD needs to be updated to reflect the individuals who contributed to developing the spec in the TC.
Related Issues
Origin
Marc Goodner
i135 Consistent use of wsrm: in normative text core - editorial - pending
Description
we're inconsistent in the spec(s) when it comes to referencing RM elements. Sometimes we say "wsrm:SequenceAck" and sometimes we just say "SequenceAck". We need to be consistent in whether or not we use "wsrm:" - and also the font :-)
Related Issues
Origin
Doug Davis
Owner
Editors
Proposal 1
Resolution 2006-06-15
Proposal 1 accepted on June 15th TC call.
i136 RM SeqID Globally Unique core - editorial - pending
Description

in WD13.pdf, line 142 the spec says: The RM Destination creates a new Sequence and returns its globally unique identifier.

That's the only spot we talk about the seqID being globally unique. We do say that the Offered SeqID needs to be "unique" and we say that Sequence headers (acks...) MUST use unique seqID's but we never actually say that the seqID returned by the CS needs to be unique. To be explicit we should say that.

Related Issues
Origin
Doug Davis
Owner
Editors
Proposal 1
Resolution 2006-06-15
Proposal 1 accepted on June 15th TC call.
i137 No mechanisms to convey that messages should be polled. core - design - pending
Description

We have a polling mechanism that allows messages to be polled. This is quite helpful for RMDs that are behind the firewall. But there is no mechanism for the RMS to let the RMD know that there are messages that the RMD should poll for. I.e., unless the RMD polls for a message, it will not know whether it should have polled! Having a mechanism for the RMS to let the RMD know that there are pending messages is helpful in at least two scenarios:

1) RMD just polled for a message (perhaps because it periodically does that), and would like to know if it should poll again because there are additional pending messages. The RMD wants to minimize message delivery delays, but the only way to do that is to increase the polling period, which can result in unnecessary sending/receiving/processing of messages. Given that the RMD has already polled for a message, it is extremely convenient (with a minimal cost) to allow the RMS to inform the RMD that there are additional message waiting.

2) The RMD and RMS have ongoing communication (not necessarily a wsrm:MakeConnection), it is advantageous for the RMD to let the RMS know that there are pending messages by allowing the pending status to be piggy-backed on ongoing communication messages.

Related Issues
Origin
Anish Karmarkar
Owner
Anish Karmarkar
Proposal 1
Proposal 2
Resolution 2006-06-22
Proposal 2 accepted on June 22nd TC call.
i138 Offer/Accept elements are incomplete core - editorial - pending
Description

The use of Offer/Accept to create an inbound sequence should carry equivalent information as a CreateSequence/CreateSequenceResponse (in the other direction). A simple test for this is to look at the child elements of CreateSequenceResponse and compare them to Offer, and then apply the same test to Accept and CreateSequence. Currently there are differences: ...

Please see mail for complete description.

Related Issues
Origin
Matthew Lovett
Owner
Editors
Proposal 1
Resolution 2006-06-15
Proposal 1 accepted on June 15th TC call.
i139 Inappropriate Fault destination core - design - active
Description

- The paragraph beginning Section 4 (Faults) suggests that faults that relate to the processing of RM headers (and that relate to known sequences) SHOULD be sent to same destination as <wsrm:SequenceAcknowledgement> messages. But that does not make much sense for Faults of this type that originate in the RMS - such as InvalidAcknowledgement, and that clearly result from an unexpected behavior of the RMD. - The current text is not accurate in stating that “All other faults in the section Relate to the processing of RM header blocks targeted….” , as some faults may not need to originate in the processing of messages in order to be generated , e.g. due to resource shortage (e.g. SequenceTerminated).

Recommending that some RMS-originating faults such as InvalidAcknowledgement, UnknownSequence etc. go to the same destination as <wsrm:SequenceAcknowledgement> messages is simply not appropriate, while it is the RMD that would benefit from taking knowledge of these. In many cases, the destination of <wsrm:SequenceAcknowledgement> is the RMS itself. The destination of such faults should either be left to an external agreement / policy, or recommended to be the RM Destination.

Related Issues
Origin
Jacques Durand
Proposal 1
Proposal 2
From TC minutes of June 29th call, "RM Destinations that generate Sequence faults SHOULD send those faults to the same [destination] as <wsrm:SequenceAcknowledgement> messages."
i140 add sub-headings to fault descriptions core - editorial - active
Description
Add new sub-headings to each fault described in section 4. Faults are, in general, underspecified and do not have equivalent levels of informative content.
Related Issues
Origin
Bob Freund
Owner
Bob Freund
Proposal 1
i141 Sec 3.3 fault response to TerminateSequenceRequest is not specified. core - editorial - pending
Description
On receipt of a TerminateSequence message an RM Destination MUST respond with a corresponding TerminateSequenceResponse message or generate a fault. The fault that can be alternatively generated is not specified.
Related Issues
Origin
Bob Freund
Owner
Bob Freund
Proposal 1
Resolution 2006-06-29
Proposal 1 accepted on June 29th TC call.
i142 Sec 3.5 Request Acknowledgement text assumesSequence is known core - editorial - pending
Description
In WD 15 Section 3.5 “Request Acknowledgement” starting on line 600 states "An RM Destination that receives a message that contains an AckRequested header block MUST send a message containing a SequenceAcknowledgement header block to the AcksTo endpoint reference (see Section 3.1)." If the RM Destination is unaware of the Sequence, such a response is impossible.
Related Issues
Origin
Bob Freund
Owner
Bob Freund
Proposal 1
Proposal 2
Resolution 2006-06-29
Proposal 2 accepted on June 29th TC call.
i143 messages have to be received for them to be examined core - editorial - active
Description
Please see original message, it contains highlighting that will not come across here.
Related Issues
Origin
Bob Freund
Owner
Bob Freund
Proposal 1
i144 RMS MessageNumberRollover behavior unclear core - editorial - active
Description
Please see original message for complete description
Related Issues
Origin
Bob Freund
Owner
Bob Freund
Proposal 1
i145 Implications of Sequence Expiration not specified core - editorial - active
Description
Please see original message for complete description
Related Issues
Origin
Bob Freund
Owner
Bob Freund
Proposal 1
i146 Editorial Examples in Apx C lack CloseSequence core - editorial - dropped
Description
Please see original message for complete description
Related Issues
Origin
Bob Freund
Owner
Bob Freund
Proposal 1
Resolution 2006-06-29
Closed with no action on June 29th TC call.
i147 Extensibility (or not) of the Protocol Elements core - editorial - active
Description
Please see original message for complete description
Related Issues
Origin
Matthew Lovett
Owner
Matthew Lovett
Proposal 1
Proposal 2
i148 Reword the Abstract core - editorial - pending
Description
Please see original message for complete description
Related Issues
Origin
Matthew Lovett
Owner
Matthew Lovett
Proposal 1
Resolution 2006-06-29
Proposal 1 accepted on June 29th TC call.
i149 Define the syntax used to refer to elements and attributes core - editorial - pending
Description
Please see original message for complete description
Related Issues
Origin
Peter Niblett
Owner
Peter Niblett
Proposal 1
Resolution 2006-06-29
Proposal arrived at and accepted on June 29th TC call (see minutes under proposed-11).
i150 Define the syntax used to refer to elements and attributes core - editorial - pending
Description
Please see original message for complete description
Related Issues
Origin
Umit Yalcinalp
Owner
Umit Yalcinalp
Proposal 1
Resolution 2006-06-29
First alternative in proposal accepted on June 29th TC call (see minutes under proposed-12).


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]