[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WS-RX issue list - revision 16
|
I’ve added this to Kavi but did not notify the TC due
to the confusion this week. Let me know when it’s live. |
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="IssuesToHtml.xsl" title="Generate Issue List"?>
<issues
xmlns="http://docs.oasis-open.org/ws-rx/issues/IssuesDoc.xsd";
xmlns:h="http://docs.oasis-open.org/ws-rx/issues/Markup.xsd";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://docs.oasis-open.org/ws-rx/issues/IssuesDoc.xsd http://docs.oasis-open.org/ws-rx/issues/IssuesDoc.xsd";
>
<head>
<uri>http://docs.oasis-open.org/ws-rx/issues/</uri>
<title>WS Reliable Messaging Working Issues List</title>
<date>Date: 2005/11/04</date>
<revision>Revision: 16</revision>
<targets>
<target>core</target>
<target>soap</target>
<target>wsdl</target>
<target>policy</target>
<target>schema</target>
<target>all</target>
</targets>
<states>
<state type="Open">unassigned</state>
<state type="Open">active</state>
<!--<state type="Editor">ToDo</state>-->
<state type="Pending">pending</state>
<state type="Done">done</state>
<state type="Deferred">deferred</state>
<state type="Resolved" color="#ccc">resolved</state>
<state type="Closed" color="#ccc">closed</state>
<state type="Closed" color="#ccc">dropped</state>
</states>
<!--<search base="http://lists.oasis-open.org/apps/org/workgroup/ws-rx/messages.php";>
-->
<!-- type 'issueID' is bound to the issue id --><!--
<i:queryArg name="p" value="1"/>
<i:queryArg name="lang" value="en"/>
<i:queryArg name="penalty" value="0"/>
<i:queryArg name="q" type="issueID"/>
--><!--<i:queryArg name="hdr-1-name" value="subject"/>
<i:queryArg name="hdr-1-query" type="issueID"/>
<i:queryArg name="resultsperpage" value="50"/>
<i:queryArg name="sortby" value="date"/>
<i:queryArg name="index-type" value="l"/>
<i:queryArg name="index" value="public-ws-addressing"/>--><!--
</search>-->
</head>
<issue id="i001" status="done" edstatus="unassigned">
<title>Bilateral sequence negotiation</title>
<description>
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200508/msg00231.html";>Restated issue</h:a>
<h:p>
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.
</h:p>
<h:p>
However, WSRX-ReliableMessagingPolicy document, lines 221-226, states
that an offer element must be present if and only if the endpoint
declares output messages.
</h:p>
<h:p>
"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."
</h:p>
<h:p>
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.
</h:p>
</description>
<relid>i021</relid>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13388/MinutesWSRXFormation.htm";>
F2F - Lei Jin
</origin>
<owner href="mailto:ljin@bea.com";>Lei Jin</owner>
<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.
</justification>
<proposal date="2005-08-25">
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200508/msg00231.html";>From restated issue</h:a>
<h:p>
Delete lines 221-226 of WSRX-ReliableMessagingPolicy document.
</h:p>
</proposal>
<resolution date="2006-09-01">
Proposal 1 accepted on <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14309/Minutes-wsrx-090105.htm";>Sept. 1 call</h:a>.
</resolution>
</issue>
<issue id="i002" status="active" edstatus="unassigned">
<title>AckTo EPR and seq lifetime</title>
<description>
Should the AckTo EPR be allowed to change during the lifetime of a sequence?
</description>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13388/MinutesWSRXFormation.htm";>
F2F - Anish Karmarkar
</origin>
<owner href="mailto:Anish.Karmarkar@oracle.com";>Anish Karmarkar</owner>
<justification>Raised at F2F</justification>
<proposal date="2005-10-22">
<h:p>
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.
</h:p>
<h:p>
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.
</h:p>
<h:p>
Here is the outline of a proposed solution:
</h:p>
<h:p>
<h:a href="http://www.oasis-open.org/archives/ws-rx/200509/msg00256.html";>See message</h:a>
</h:p>
</proposal>
<proposal date="2005-11-03">
<h:p>
<h:a href="http://www.oasis-open.org/archives/ws-rx/200511/msg00082.html";>See message</h:a>
</h:p>
<h:p>
Close with no action.
</h:p>
</proposal>
<!--<resolution date="2006-06-15">[markup]</resolution>-->
</issue>
<issue id="i003" status="dropped" edstatus="unassigned">
<title>EPRs and sequence scope</title>
<description>
Which pair of EPRs define the scope of a sequence?
</description>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13388/MinutesWSRXFormation.htm";>
F2F - Anish Karmarkar
</origin>
<owner href="mailto:Anish.Karmarkar@oracle.com";>Anish Karmarkar</owner>
<justification>Raised at F2F</justification>
<proposal date="2005-09-22">Close with no action</proposal>
<resolution date="2005-09-22">
Proposal 1 accepted at <h:a href="http://lists.oasis-open.org/archives/ws-rx/200509/msg00260.html";>Sept. 22 F2F</h:a>
</resolution>
</issue>
<issue id="i004" status="closed" edstatus="unassigned">
<title>wsa:messageID uniqueness requirments for retransmission</title>
<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?
</description>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13388/MinutesWSRXFormation.htm";>
F2F - Steve Winkler</origin>
<owner href="mailto:mgoodner@microsoft.com";>Marc Goodner</owner>
<justification>Raised at F2F</justification>
<proposal date="2005-09-01">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14309/Minutes-wsrx-090105.htm";>
Close with no change required</h:a>
</proposal>
<resolution date="2005-09-01">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14309/Minutes-wsrx-090105.htm";>Proposal 1 accepted</h:a>
</resolution>
</issue>
<issue id="i005" status="done" edstatus="unassigned">
<title>Source resend of nacks messages when ack already received</title>
<description>
Is the sender required to resend a message identified in a Nack, if it has
already received an ack for that same messageNumber?
</description>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13388/MinutesWSRXFormation.htm";>
F2F - Steve Winkler</origin>
<owner href="mailto:steve.winkler@sap.com";>Steve Winkler</owner>
<justification>Raised at F2F</justification>
<proposal date="2005-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>.
</proposal>
<resolution date="2006-09-08">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14420/Minutes-wsrx-090805.htm";>Proposal 1 made and accepted on Sept. 8th TC call.</h:a>
</resolution>
</issue>
<issue id="i006" status="active" edstatus="unassigned">
<title>Source based delivery QoS policy assertion</title>
<description>
Is there a requirement that the sender can assert that the receiver must
deliver a particular reliability assurance on a given sequence?
</description>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13388/MinutesWSRXFormation.htm";>
F2F - Tom Rutt</origin>
<owner href="mailto:tom@coastin.com";>Tom Rutt</owner>
<justification>
Raised at F2F.
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200506/msg00055.html";>Also raised on list by Tom Rutt.</h:a>
</justification>
<proposal date="2005-10-11">
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200510/msg00050.html";>See mail</h:a>: close issue with no changes to specfication.
</proposal>
<proposal date="2005-10-26">
<h:p>
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200510/msg00263.html";>see message</h:a>
</h:p>
<h:p>
Use the wsrmp:DeliveryAssurance element (as defined in the resolution of i009) in the CS message as follows:
</h:p>
<h:p>
<wsrm:CreateSequence ...="">
</h:p>
<h:p>
<wsrm:AcksTo ...=""> wsa:EndpointReferenceType </wsrm:AcksTo>
</h:p>
<h:p>
<wsrm:Expires ...=""> xs:duration </wsrm:Expires> ?
</h:p>
<h:p>
<wsrm:Offer ...="">
</h:p>
<h:p>
<wsrm:Identifier ...=""> xs:anyURI </wsrm:Identifier>
</h:p>
<h:p>
<wsrm:Expires ...=""> xs:duration </wsrm:Expires> ?
</h:p>
<h:p>
...
</h:p>
<h:p>
</wsrm:Offer> ?
</h:p>
<h:p>
<wsrmp:DeliveryAssurrance ...=""/>?
</h:p>
<h:p>
...
</h:p>
<h:p>
</wsrm:CreateSequence>
</h:p>
<h:p>
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.
</h:p>
</proposal>
<!--<resolution date="2006-06-15">[markup]</resolution>-->
</issue>
<issue id="i007" status="deferred" edstatus="unassigned">
<title>WSS 1.0/1.1 token support</title>
<description>
Must the ws-reliable messaging spec support tokens produced for both
ws-security 1.0 and ws-security 1.1?
</description>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13388/MinutesWSRXFormation.htm";>
F2F - Paul Cotton</origin>
<owner href="mailto:mgoodner@microsoft.com";>Marc Goodner</owner>
<justification>Raised at F2F</justification>
<proposal date="2005-08-04">
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200508/msg00036.html";>From Marc Goodner</h:a>
<h:p>
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.
</h:p>
<h:p>
WS-ReliableMessaging
</h:p>
<h:p>
Add prefix and namespace for WSS 1.1 to table at line 142:
</h:p>
<h:p>
wsse11 http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-wssecurity-secext-1.1.xsd
</h:p>
<h:p>
Add reference to WSS 1.1 after [WSSecurity] (lines 844-847):
</h:p>
<h:p>
[WSSecurity11]
</h:p>
<h:p>
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
</h:p>
<h:p>
WS-ReliableMessagingPolicy
</h:p>
<h:p>
Add reference to WSS 1.1 after [WSS] (lines 306-308):
</h:p>
<h:p>
[WSSecurity11]
</h:p>
<h:p>
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
</h:p>
</proposal>
<!--<resolution date="2006-06-15">[markup]</resolution>-->
</issue>
<issue id="i008" status="active" edstatus="unassigned">
<title>Policy assertions granularity</title>
<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".
</description>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13388/MinutesWSRXFormation.htm";>
F2F - Tom Rutt</origin>
<owner href="mailto:tom@coastin.com";>Tom Rutt</owner>
<justification>
Raised at F2F
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200506/msg00055.html";>Also raised on list by Tom Rutt.</h:a>
</justification>
<proposal date="2005-10-11">
<h:p>
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200510/msg00048.html";>From Tom Rutt:</h:a>
</h:p>
<h:p>
Add the following text after the text added for resolution of Issue 021:
</h:p>
<h:p>
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.
</h:p>
</proposal>
<!--<resolution date="2006-06-15">[markup]</resolution>-->
</issue>
<issue id="i009" status="done" edstatus="unassigned">
<title>Declaration of QoS policies</title>
<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.
</description>
<target>core</target>
<type>design</type>
<origin href="http://lists.oasis-open.org/archives/ws-rx/200506/msg00046.html";>
Chris Ferris
</origin>
<owner href="mailto:chrisfer@us.ibm.com";>Chris Ferris</owner>
<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."
</justification>
<proposal date="2005-09-21">
<h:p>
<wsrm:DeliveryAssertion mode="[AtLeastOnce|AtMostOnce|ExactlyOnce]" ordered="[xs:boolean]"? ...="" >
</h:p>
<h:p>
/wsrm:DeliveryAssertion
A policy assertion that makes a claim as to the delivery assurance policy
observed by the destination endpoint.
</h:p>
<h:p>
/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.
</h:p>
<h:p>
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.
</h:p>
<h:p>
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.
</h:p>
<h:p>
A value of 'ExactlyOnce' means that every message received by the RM
Destination will be delivered to the Application Destination without
duplication.
</h:p>
<h:p>
/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'.
</h:p>
</proposal>
<resolution date="2005-09-21">
Proposal 1 accepted at <h:a href="http://lists.oasis-open.org/archives/ws-rx/200509/msg00244.html";>Sept. 22 F2F</h:a>,
new issue to be opened to define whether the above is an assertion or a parameter.
</resolution>
</issue>
<issue id="i010" status="active" edstatus="unassigned">
<title>
Sequence port spanning
</title>
<description>
Is there a need to allow a single sequence to span multiple ports?
</description>
<target>core</target>
<type>design</type>
<origin href="http://lists.oasis-open.org/archives/ws-rx/200506/msg00059.html";>Doug Davis</origin>
<owner href="mailto:dug@us.ibm.com";>Doug Davis</owner>
<justification>
"Having a single sequence span multiple ports (much like an MQ queue does)
could be needed as well."
</justification>
<proposal date="2005-10-09">
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200510/msg00035.html";>
See this email and attachment
</h:a>
</proposal>
<proposal>
See attachment in <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/msg00266.html";>this message</h:a>
</proposal>
<resolution date="2005-10-27">
Proposal 2 accepted on <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15110/MinutesWSRX-102705.htm";>Oct. 27th TC call</h:a>
</resolution>
</issue>
<issue id="i011" status="done" edstatus="unassigned">
<title>Typo in expires P0S</title>
<description>
Per the schema spec a zero second duration needs to have the "T" designator - so it should be PT0S not P0S.
</description>
<target>core</target>
<type>editorial</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00046.html";>Doug Davis</origin>
<owner href="mailto:dug@us.ibm.com";>Doug Davis</owner>
<justification>
align with schema spec ( http://www.w3.org/TR/xmlschema-2/#duration )
</justification>
<proposal date="2005-07-14">simple search and replace of P0S with PT0S</proposal>
<resolution date="2006-07-21">
Proposal accepted at <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13746/MinutesWSRX072105-b.htm";>
July 21st TC meeting</h:a>, no objections.
</resolution>
</issue>
<issue id="i012" status="closed" edstatus="unassigned">
<title>
Anonymous acksTo
</title>
<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.
</description>
<target>soap</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00066.html";>Lei Jin</origin>
<owner href="mailto:ljin@bea.com";>Lei Jin</owner>
<justification>
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00066.html";>From new issue post.</h:a>
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).
</justification>
<proposal date="2005-07-11">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00066.html";>From new issue post.</h:a>
<h:p>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.</h:p>
</proposal>
<proposal date="2005-07-11">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00066.html";>From new issue post.</h:a>
<h:p>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.</h:p>
</proposal>
<proposal date="2005-07-11">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00069.html";>Response to each proposal above from Chris Ferris</h:a>, proposal 1 out of scope and proposal 2 not an issue.
</proposal>
<proposal date="2005-09-08">
Close issue without change to spec.
</proposal>
<resolution date="2006-09-08">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14420/Minutes-wsrx-090805.htm";>
Proposal 4 made and accepted on Sept. 8 TC call.
</h:a>
</resolution>
</issue>
<issue id="i013" status="done" edstatus="active">
<title>Max message number in policy</title>
<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.
</description>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00073.html";>Doug Davis</origin>
<owner href="mailto:dug@us.ibm.com";>Doug Davis</owner>
<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.
</justification>
<proposal date="2005-08-08">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00073.html";>
Original proposal from raised issue</h:a>, <h:a href="http://lists.oasis-open.org/archives/ws-rx/200508/msg00051.html";>revised proposal</h:a>
<h:p>
In the WS-RM Policy doc:
</h:p>
<h:p>
After line 173, add to the normative outline:
<![CDATA[<wsrm:MaxMessageNumber Number="xs:unsignedLong" ... /> ?]]>
</h:p>
<h:p>
After line 202, add to the more verbose section of the normative outline:
</h:p>
<h:p>
/wsrm:RMAssertion/wsrm:MaxMessageNumber
</h:p>
<h:p>
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.
</h:p>
<h:p>
/wsrm:RMAssertion/wsrm:MaxMessageNumber/@Number
</h:p>
<h:p>
The maximum message number.
</h:p>
<h:p>
After line 434, add to the schema:
</h:p>
<h:pre>
<![CDATA[<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>]]>
</h:pre>
<h:p>
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200508/msg00074.html";>Friendly
ammendment</h:a>, in the WS-RM Policy doc, after line 155:
</h:p>
<h:p>
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.
</h:p>
</proposal>
<resolution date="2005-08-11">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14014/wsrxminutes11aug2005.txt";>
Proposal 1 accepted at August 11 TC call.
</h:a>
</resolution>
</issue>
<issue id="i014" status="closed" edstatus="unassigned">
<title>
Document Names
</title>
<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.
</description>
<target>core</target>
<type>editorial</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00090.html";>Gilbert Pilz</origin>
<owner href="mailto:Gilbert.Pilz@bea.com";>Gilbert Pilz</owner>
<justification>
The name of a document effects a number of things such as
the document identifier, URIs etc.
</justification>
<proposal date="2005-07-13">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00090.html";>Link</h:a>
<h:p>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).</h:p>
</proposal>
<resolution date="2005-08-04">First proposal accepted on <h:a href="http://lists.oasis-open.org/archives/ws-rx/200508/msg00048.html";>
Aug. 4th conf call</h:a>, no objections
</resolution>
</issue>
<issue id="i015" status="done" edstatus="unassigned">
<title>
Required Artifact Metadata
</title>
<description>
<h:a href="http://www.oasis-open.org/committees/download.php/13344/ArtifactIdentificationRequirements-v1.0-wd-15.pdf";>
OASIS guidelines</h:a> require that the artifacts (documents, schemas, etc.)
produced by a TC should have a minimum set of of metadata that describes these artifacts.
</description>
<target>core</target>
<type>editorial</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00091.html";>Gilbert Pilz</origin>
<owner href="mailto:Gilbert.Pilz@bea.com";>Gilbert Pilz</owner>
<justification>
OASIS requirement.
</justification>
<proposal date="2005-07-13">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00091.html";>Link</h:a>
<h:p>
We propose the following values for each specification:
</h:p>
<h:p>
WS-ReliableMessaging:</h:p><h:p>
artifactName: TBD</h:p><h:p>
tc: TBD</h:p><h:p>
product: wsreliablemessaging</h:p><h:p>
productVersion: 01</h:p><h:p>
artifactType: spec</h:p><h:p>
stage: wd</h:p><h:p>
descriptiveName: Web Services Reliable Messaging Protocol Specification
</h:p>
<h:p>
WS-RM Policy:</h:p><h:p>
artifactName: TBD</h:p><h:p>
tc: TBD</h:p><h:p>
product: wsrmpolicy</h:p><h:p>
productVersion: 01</h:p><h:p>
artifactType: spec</h:p><h:p>
stage: wd</h:p><h:p>
descriptiveName: Web Services Reliable Messaging Policy Assertion Specification
</h:p>
<h:p>
Note that the product names of these two artifacts differ.
</h:p>
</proposal>
<proposal date="2005-08-18">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200508/msg00159.html";>Link</h:a>
<h:p>
WS-ReliableMessaging:
</h:p>
<h:p>
tc: wsrx
</h:p>
<h:p>
product: wsrm
</h:p>
<h:p>
productVersion: 1.1
</h:p>
<h:p>
artifactType: spec
</h:p>
<h:p>
stage: wd
</h:p>
<h:p>
descriptiveName: Web Services Reliable Messaging Protocol Specification
</h:p>
<h:p>
WS-RM Policy:
</h:p>
<h:p>
tc: wsrx
</h:p>
<h:p>
product: wsrmp
</h:p>
<h:p>
productVersion: 1.1
</h:p>
<h:p>
artifactType: spec
</h:p>
<h:p>
stage: wd
</h:p>
<h:p>
descriptiveName: Web Services Reliable Messaging Policy Assertion Specification
</h:p>
</proposal>
<resolution date="2005-08-18">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14148/Minutes%20Teleconf%2008-18-2005.html";>
Proposal 2 accepted on TC call on Aug. 18th
</h:a>
</resolution>
</issue>
<issue id="i016" status="done" edstatus="unassigned">
<title>Document Identifiers</title>
<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
</description>
<target>core</target>
<type>editorial</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00092.html";>Gilbert Pilz</origin>
<owner href="mailto:Gilbert.Pilz@bea.com";>Gilbert Pilz</owner>
<justification>Self-evident</justification>
<proposal date="2005-07-13">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00092.html";>Link</h:a>
<h:p>According to the OASIS guidelines and in light of the proposed artifact metadata,
the documents should currently be identified as:</h:p>
<h:p>
wsreliablemessaging-01-spec-wd-01.*
</h:p>
<h:p>
wsrmpolicy-01-spec-wd-01.*
</h:p>
<h:p>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).</h:p>
</proposal>
<proposal date="2005-08-18">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200508/msg00159.html";>Link</h:a>
<h:p>
wsrm-1.1-spec-wd-01.*
</h:p>
<h:p>
wsrmp-1.1-spec-wd-01.*
</h:p>
</proposal>
<resolution date="2005-08-18">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200508/msg00159.html";>Link</h:a>
<h:p>
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14148/Minutes%20Teleconf%2008-18-2005.html";>
Proposal 2 accepted on Aug 18th TC call
</h:a>
</h:p>
</resolution>
</issue>
<issue id="i017" status="done" edstatus="unassigned">
<title>XML Namespace URIs</title>
<description>
We need to decide upon the normative XML namespace URIs that must be used by implementations of these specifications
</description>
<target>schema</target>
<type>editorial</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00093.html";>Gilbert Pilz</origin>
<owner href="mailto:Gilbert.Pilz@bea.com";>Gilbert Pilz</owner>
<justification>Self-evident</justification>
<proposal date="2005-07-13">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00093.html";>Link</h:a>
<h:p>
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:
</h:p>
<h:p>
xmlns:wsrm="http://www.oasis-open.org/committees/ws-rx/wsreliablemessaging-200507.html";
</h:p>
<h:p>
xmlns:wsrmp="http://www.oasis-open.org/committees/ws-rx/wsrmpolicy-200507.html";
</h:p>
<h:p>Note that the 200507 in the URL is represents the schema version as a date (July, 2005).</h:p>
</proposal>
<proposal date="2005-07-13">
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200508/msg00018.html";>From Chris Ferris</h:a>
<h:p>
I propose that we resolve issue i017 [1] as follows:
</h:p>
<h:p>
The namespace URI used for our specs should follow the draft AIR
guidelines. e.g.
</h:p>
<h:p>
http://docs.oasis-open.org/[productname]1
</h:p>
<h:p>
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!)
</h:p>
<h:p>
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.
</h:p>
<h:p>
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).
</h:p>
<h:p>
[1]
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13809/ReliableMessagingIssues.xml#i017
</h:p>
<h:p>
[2]
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13809/ReliableMessagingIssues.xml#i015
</h:p>
</proposal>
<proposal>
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200508/msg00037.html";>From Marc Goodner</h:a>
<h:p>
The namespace URI used for our specs should follow the draft AIR Guidelines as follows:
</h:p>
<h:p>
http://docs.oasis-open.org/yyyy/mm/[productname]
</h:p>
<h:p>
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.
</h:p>
<h:p>
[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13809/ReliableMessagingIssues.xml#i017
</h:p>
<h:p>
[2] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13809/ReliableMessagingIssues.xml#i015
</h:p>
</proposal>
<proposal date="2005-08-18">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200508/msg00159.html";>Link</h:a>
<h:p>
http://docs.oasis-open.org/wsrm/yyyymm/
</h:p>
<h:p>
http://docs.oasis-open.org/wsrmp/yyyymm/
</h:p>
</proposal>
<resolution date="2005-08-18">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200508/msg00159.html";>Link</h:a>
<h:p>
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14148/Minutes%20Teleconf%2008-18-2005.html";>
Proposal 4 made and accepted on Aug 18th TC call.
</h:a>
</h:p>
</resolution>
</issue>
<issue id="i018" status="dropped" edstatus="unassigned">
<title>Is an implementation supporting a smaller max message number valid?</title>
<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?
</description>
<relid>i013</relid>
<relid>i019</relid>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00128.html";>
Doug Bunting
</origin>
<owner href="mailto:Doug.Bunting@Sun.COM";>Doug Bunting</owner>
<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".
</justification>
<proposal date="2005-07-14">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00128.html";>Link</h:a>
<h:p>
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".</h:p>
</proposal>
<proposal date="2005-07-28">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00294.html";>
Made on Jul 28th TC call
</h:a>
<h:p>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.</h:p>
</proposal>
<resolution date="2005-07-28">
Second proposal accepted on <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00294.html";>
Jul 28th TC call</h:a>, no objections.
</resolution>
</issue>
<issue id="i019" status="done" edstatus="unassigned">
<title>Sequence termination on Fault</title>
<description>
The RM Destination imperatively terminates a sequence due to one of these unrecoverable errors:
<h:p>
- wsrm:SequenceTerminated
</h:p>
<h:p>
- wsrm:MessageNumberRollover
</h:p>
<h:p>
- wsrm:LastMessageNumberExceeded
</h:p>
The semantics of sequence termination due to a fault occurrence are not clearly specified.
<h:p>
This uses the <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00171.html";>
reworded issue
</h:a>
</h:p>
</description>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00145.html";>
Jacques Durand
</origin>
<owner href="mailto:JDurand@us.fujitsu.com";>Jacques Durand</owner>
<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.
</justification>
<proposal date="2005-07-15">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00145.html";>Link</h:a>
<h:p>
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.</h:p>
</proposal>
<proposal>
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00076.html";>As outlined in message number 76</h:a>
</proposal>
<resolution date="2005-09-15">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14692/MinutesWSRXSept15th.htm";>
Proposal 2 accepted on Sept. 15th TC call.
</h:a>
</resolution>
</issue>
<issue id="i020" status="done" edstatus="unassigned">
<title>Semantics of "At most once" Delivery assurance</title>
<description>
<h:p>
The semantics of the "at most once" delivery assurance are not clear.
</h:p>
<h:p>
One interpretation is that at most once implies that the sender is not
required to retransmit mesages which are not acked.
</h:p>
</description>
<relid>i009</relid>
<target>all</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00204.html";>
Tom Rutt
</origin>
<owner href="mailto:tom@coastin.com";>Tom Rutt</owner>
<justification>
It is important to clarify whether the sender must retransmit unacknowledged
messages when the "at most once" delivery assurance is in use.
</justification>
<proposal date="2005-07-21">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00204.html";>Link</h:a>
<h:p>
Clarify the semantics. There are at least three possible semantics
associated with "at most once"
</h:p>
<h:ol>
<h:li>
At most once means that the sender will never retransmit a message,
regardless of whether it is acknolweged by the destination.
</h:li>
<h:li>
The sender may retransmis messages, but is not required to to so,
however the destination will not deliver duplicates
</h:li>
<h:li>
The sender must retransmit messages, however the destination may
drop messages in times of resource saturation, but will never deliver a duplicate.
</h:li>
</h:ol>
</proposal>
<proposal date="2005-09-21">
<h:p>
At line 162 of the WS-ReliableMessaging spec, delete the following
paragraph:
</h:p>
<h:p>
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.
</h:p>
<h:p>
and replace it with the following text:
</h:p>
<h:p>
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.
</h:p>
<h:p>
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.
</h:p>
<h:p>
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.
</h:p>
<h:p>
Note that the underlying protocol defined in this specification remains the same regardless of the delivery assurance.
</h:p>
</proposal>
<resolution date="2005-09-21">
Proposal 2 accepted at <h:a href="http://lists.oasis-open.org/archives/ws-rx/200509/msg00243.html";>Sept. 21 F2F</h:a>
</resolution>
</issue>
<issue id="i021" status="active" edstatus="unassigned">
<title>An RM Policy applies two-way</title>
<description>
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200509/msg00264.html";>Refurbished</h:a>:
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.
</description>
<target>policy</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00208.html";>
Jacques Durand
</origin>
<owner href="mailto:JDurand@us.fujitsu.com";>Jacques Durand</owner>
<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.
</justification>
<proposal date="2005-07-21">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00208.html";>Link</h:a>
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>
<!--<resolution date="">[markup]</resolution>-->
</issue>
<issue id="i022" status="pending" edstatus="unassigned">
<title>RM Policy Assertion Model's Base Retransmission Interval Clarification Needed</title>
<description>
<h:p>
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
</h:p>
<h:ul>
<h:li>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.
</h:li>
<h:li>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.
</h:li>
<h:li>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.
</h:li>
<h:li>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?
</h:li>
<h:li>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.
</h:li>
</h:ul>
<h:p>
This is the <h:a href="http://lists.oasis-open.org/archives/ws-rx/200508/msg00033.html";>
revised description</h:a>
</h:p>
</description>
<target>policy</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00210.html";>
Vikas Deolaliker
</origin>
<owner href="mailto:vikas@sonoasystems.com";>Vikas Deolaliker</owner>
<justification>
There is no obvious case mentioned in the spec that requires two timers for retransmission
upon timeout.
</justification>
<proposal date="2005-08-04">
Original proposal in <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00210.html";>
raised issue</h:a>, this is the text of the <h:a href="http://lists.oasis-open.org/archives/ws-rx/200508/msg00033.html";>
revised proposal</h:a>
<h:p>
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.
</h:p>
<h:p>
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.
</h:p>
</proposal>
<proposal date="2005-10-21">
<h:p>
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/msg00207.html";>See message</h:a>
</h:p>
<h:p>
Delete all re-transmission parameters as described in the WS-RM Policy <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14986/wsrmp-1.1-spec-wd-01.pdf";>specification</h:a> since they are
unnecessary and unhelpful should the implementer use an algorithm with a different set of controls. <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/bin00004.bin";>Specific modification to documents</h:a>
</h:p>
</proposal>
<proposal date="2005-11-02">
<h:p>
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200511/msg00021.html";>See message</h:a>
</h:p>
<h:p>
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.
</h:p>
</proposal>
<proposal date="2005-11-03">
<h:p>
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200511/msg00060.html";>See message</h:a>
</h:p>
<h:p>
remove lines 137-138, 156-163, 205-206, 282, 389-402 of <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14986/wsrmp-1.1-spec-wd-01.pdf";>WS-RMP</h:a> and the schema
components represented by lines 389-402 in the appendix from the wsrmp XSD (where
are the xsd's hiding?)
</h:p>
</proposal>
<resolution date="2005-11-03">
Proposal 4 accepted at <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200511/msg00099.html";>Nov 3rd TC call</h:a>
</resolution>
</issue>
<issue id="i023" status="closed" edstatus="unassigned">
<title>Robust recovery from low-resource conditions</title>
<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.
</description>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00252.html";>
Sanjay Patil
</origin>
<owner href="mailto:mgoodner@microsoft.com";>Marc Goodner</owner>
<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.
</justification>
<proposal date="2005-07-26">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00252.html";>Link</h:a>
RM Protocol to support RMD pushing back on the RMS for slowing down or
stopping (re)transmission of messages.
</proposal>
<proposal date="2005-10-12">
<h:p>
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200510/msg00062.html";>See message</h:a>
</h:p>
<h:p>
Close with no action.
</h:p>
</proposal>
<proposal date="2005-11-02">
<h:p>
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200511/msg00041.html";>See message</h:a>
</h:p>
</proposal>
<resolution date="2005-11-03">
Proposal 2 accepted at <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200511/msg00099.html";>Nov 3rd TC call</h:a>
</resolution>
</issue>
<issue id="i024" status="pending" edstatus="unassigned">
<title>WS-RX policies not manifested on the wire</title>
<description>
<h:p>
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.
</h:p>
<h:p>
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.
</h:p>
<h:p>
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.
</h:p>
</description>
<relid>i009</relid>
<relid>i013</relid>
<target>policy</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200508/msg00003.html";>
Ashok Malhotra
</origin>
<owner href="mailto:ashok.malhotra@oracle.com";>
Ashok Malhotra
</owner>
<justification>See description</justification>
<proposal date="2005-09-21">Close with clarification of meaning of observed to be added to spec. </proposal>
<resolution date="2005-09-21">
Proposal 1 accepted at <h:a href="http://lists.oasis-open.org/archives/ws-rx/200509/msg00244.html";>Sept. 21 F2F</h:a>
</resolution>
<resolution date="2005-10-20">
<h:p>Pending text agreed on <h:a href="http://lists.oasis-open.org/archives/ws-rx/200510/msg00200.html";>Oct. 20 TC call</h:a>:</h:p>
<h:p>Change text using <h:a href="http://lists.oasis-open.org/archives/ws-rx/200510/msg00144.html";>email message 144
proposal from Marc Goodner</h:a> to change "observe" to "in effect".</h:p>
<h:p>Amended to add the words "rm assertion parameters do not affect the messages which are sent on the wire"</h:p>
</resolution>
</issue>
<issue id="i025" status="done" edstatus="unassigned">
<title>What is the correct form of SeqAck when RMD has received no messages</title>
<description>
<h:p>
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?
</h:p>
</description>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200508/msg00017.html";>
Chris Ferris
</origin>
<owner href="mailto:chrisfer@us.ibm.com";>Chris Ferris</owner>
<justification>
<h:p>
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.
</h:p>
</justification>
<proposal date="2005-07-20">
<h:p>
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200508/msg00017.html";>From raised issue</h:a>
</h:p>
<h:p>
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.
</h:p>
<h:p>
<wsrm:SequenceAcknowledgement xmlns:wsrm="http://docs.oasis-open.org/whatever">
</h:p>
<h:p>
<wsrm:Identifier>http://example.org/mysequence/1234</wsrm:Identifier>
</h:p>
<h:p>
<wsrm:AcknowledgementRange Upper="0" Lower="0">
</h:p>
<h:p>
</wsrm:SequenceAcknowledgement>
</h:p>
</proposal>
<proposal date="2005-09-22">
<h:p>
1) Amend the schema to add a third <xs:choice>
element, <wsrm:None/> in
parallel with Nack and AcknowledgementRange.
</h:p>
<h:p>
2) Explain the meaning of this element in the text, i.e.
"/wsrm:SequenceAcknowledgement/wsrm:None -- no messages were received".
</h:p>
<h:p>
3) Editors to clean up the text around AcknowledgementRange (i.e. is it
really optional, etc...)
</h:p>
</proposal>
<resolution date="2005-09-22">
Proposal 2 accepted at <h:a href="http://lists.oasis-open.org/archives/ws-rx/200509/msg00260.html";>Sept. 22 F2F</h:a>
</resolution>
</issue>
<issue id="i026" status="dropped" edstatus="unassigned">
<title>better support in handling space-greedy sequences</title>
<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.)
</description>
<target>core</target>
<type>design</type>
<origin href="http://lists.oasis-open.org/archives/ws-rx/200508/msg00061.html";>Jacques Durand</origin>
<owner href="JDurand@us.fujitsu.com">Jacques Durand</owner>
<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:
<h:ul>
<h:li>(1) deciding to arbitrarily end some existing sequence (e.g. LFU)</h:li>
<h:li>(2) dynamically adjust the maximum sequence length of new sequences at creation time</h:li>
</h:ul>
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.
</justification>
<proposal date="2005-08-09">
From <h:a href="http://lists.oasis-open.org/archives/ws-rx/200508/msg00061.html";>raised issue</h:a>
<h:ul>
<h:li>
(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.
</h:li>
<h:li>
(b) In addition, if a smaller maximum has been dynamically decided by the RM Destination,
communicate it to the RM Source via the CreateSequenceResponse.
</h:li>
</h:ul>
</proposal>
<resolution date="2005-09-21">
Closed with no action at <h:a href="http://lists.oasis-open.org/archives/ws-rx/200509/msg00244.html";>Sept. 21 F2F</h:a>
</resolution>
</issue>
<issue id="i027" status="done" edstatus="unassigned">
<title>
InOrder delivery assurance spanning multiple sequences
</title>
<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.
</description>
<target>core</target>
<type>design</type>
<origin href="http://lists.oasis-open.org/archives/ws-rx/200508/msg00062.html";>Andreas Bjärlestam</origin>
<owner href="andreas.bjarlestam@ericsson.com">
Andreas Bjärlestam
</owner>
<justification>
InOrder is one of the supported delivery assurances. The scope of the ordering should be clear.
</justification>
<proposal date="2005-09-14">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00126.html";>Original message:</h:a> InOrder Messages will be delivered in the order that they were sent. This delivery assurance may be combined with any of the above delivery assurances. It requires that the messages within a Sequence will be delivered in an order so that the message numbers are monotonically increasing. Note that this assurance says nothing about duplications or omissions. Note also that it is only applicable to messages in the same Sequence. Cross Sequence ordering of messages is not in the scope of this specification.
</proposal>
<resolution date="2005-09-15">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14692/MinutesWSRXSept15th.htm";>
Proposal 1 accepted on Sept. 15th TC call.
</h:a>
</resolution>
</issue>
<issue id="i028" status="done" edstatus="unassigned">
<title>Accurate final acknowledgement of a Sequence with gaps when RMS decides to stop using it</title>
<description>
<h:p>
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.)
</h:p>
</description>
<target>core</target>
<type>design</type>
<origin href="http://lists.oasis-open.org/archives/ws-rx/200508/msg00084.html";>Jacques Durand</origin>
<owner href="JDurand@us.fujitsu.com">Jacques Durand</owner>
<justification>
<h:p>
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.)
</h:p>
</justification>
<proposal date="2005-08-11">
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200508/msg00084.html";>From Jacques Durand at issue origin</h:a>
<h:p>
TBD. Outline of a solution:
</h:p>
<h:ul>
<h:li>(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.</h:li>
<h:li>(b) give an RMS a way to reiterate this trigger in case it is lost, so that it can get this last SeqAck.</h:li>
</h:ul>
</proposal>
<proposal>
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00076.html";>As outlined in message number 76</h:a>
</proposal>
<resolution date="2005-09-15">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14692/MinutesWSRXSept15th.htm";>
Proposal 2 accepted on Sept. 15th TC call.
</h:a>
</resolution>
</issue>
<issue id="i029" status="done" edstatus="unassigned">
<title>Remove dependency on WS-Security</title>
<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.</description>
<target>core</target>
<type>design</type>
<relid>i007</relid>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200508/msg00121.html";>Gilbert Pilz</origin>
<owner href="mailto:gilbert.pilz@bea.com";>Gilbert Pilz</owner>
<justification>
<h:p>
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.
</h:p>
<h:p>
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.
</h:p>
<h:p>
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.
</h:p>
</justification>
<proposal date="2005-08-17">
<h:ul>
<h:li>
<h:p>Delete lines 458-461 of WS-ReliableMessaging-v1.0-wd-01</h:p>
</h:li>
<h:li>
<h:p>Delete lines 502-508 of WS-ReliableMessaging-v1.0-wd-01</h:p>
</h:li>
</h:ul>
</proposal>
<proposal date="2005-09-22">
Remove lines 450-452 and 494-500
</proposal>
<resolution date="2005-09-22">
Proposal 2 accepted at <h:a href="http://lists.oasis-open.org/archives/ws-rx/200509/msg00260.html";>Sept. 22 F2F</h:a>
</resolution>
</issue>
<issue id="i030" status="pending" edstatus="unassigned">
<title>What are the obligations on RMD for use (or not) of Offered Sequence?</title>
<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?
</description>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200508/msg00251.html";>
Chris Ferris
</origin>
<owner href="mailto:chrisfer@us.ibm.com";>Chris Ferris</owner>
<justification>
<h:p>
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:
</h:p>
<h:p>
/wsrm:CreateSequence/wsrm:Offer
</h:p>
<h:p>
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.
</h:p>
</justification>
<proposal date="2005-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>
<proposal date="2005-09-27">
<h:p>
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.
</h:p>
<h:p>
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:
</h:p>
<h:p>
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.
</h:p>
<h:p>
[1]
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14682/ReliableMessagingIssues.xml#i030
</h:p>
<h:p>
[2]
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14682/ReliableMessagingIssues.xml#i001
</h:p>
<h:p>
[3]
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14603/wsrm-1.1-spec-wd-03.pdf
</h:p>
</proposal>
<resolution date="2005-10-06">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14845/MinutesWSRX-100605.htm";>Proposal 2 accepted</h:a>
</resolution>
</issue>
<issue id="i031" status="done" edstatus="unassigned">
<title>Inconsistency between spec and schema (AckRequested)</title>
<description>
<h:p>
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?
</h:p>
<h:p>
Here's the prose from line 427 (pdf) of the wsrm spec:
</h:p>
<h:p>
/wsrm:AckRequested/wsrm:MessageNumber
</h:p>
<h:p>
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>.
</h:p>
<h:p>
Here's the relevant fragment from the schema:
</h:p>
<h:pre>
<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>
</h:pre>
</description>
<target>schema</target>
<type>editorial</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200508/msg00285.html";>
Chris Ferris
</origin>
<owner href="mailto:chrisfer@us.ibm.com";>Chris Ferris</owner>
<justification>There is a clear discrepancy between the spec and the schema</justification>
<proposal date="2005-08-29">
<h:p>
I believe the intent was to have the element named as per the schema. Change the text at
line 427 as follows:
</h:p>
<h:p>
/wsrm:AckRequested/wsrm:MaxMessageNumberUsed
</h:p>
<h:p>
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>.
</h:p>
</proposal>
<proposal date="2005-09-14">
<h:p>Change the ws-rx schema AckRequestedType complexType from:</h:p>
<h:pre>
<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>
</h:pre>
<h:p>to:</h:p>
<h:pre>
<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>
</h:pre>
<h:p>to bring it into alignment with the specification prose.</h:p>
</proposal>
<resolution date="2005-09-22">
Proposal 2 accepted at <h:a href="http://lists.oasis-open.org/archives/ws-rx/200509/msg00260.html";>Sept. 22 F2F</h:a>
</resolution>
</issue>
<issue id="i032" status="active" edstatus="unassigned">
<title>Protocol serialization optimization proposal</title>
<description>
<h:p>
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.
</h:p>
<h:p>
Here's what we have today:
</h:p>
<h:pre>
<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>
</h:pre>
<h:p>
I think that if the properties were serialized as attributes, we would have a much more compact serialization:
</h:p>
<h:pre>
<wsrm:Sequence
xmlns:wsrm="http://docs.oasis-open.org/wsrx/@@@"
seqID="http://example.org/mysequence/1234"; msgNum="1"
last="true"/>
</h:pre>
<h:p>
The serilaization savings for a Sequence element is 91 bytes per message.
</h:p>
<h:p>
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:
</h:p>
<h:pre>
<wsrm:SequenceAcknowledgement
xmlns:wsrm="http://docs.oasis-open.org/wsrx/@@@"
seqID="http://example.org/mysequence/1234"; ranges="1 1 3 10">
</h:pre>
<h:p>
where the @ranges attribute is a list of unsignedLongs. e.g.
</h:p>
<h:pre>
<xs:simpleType name='rangeType'>
<xs:list itemType='xs:unsignedLong'/>
</xs:simpleType>
</h:pre>
<h:p>
The ranges are expressed as "low hi low hi low hi ..."
</h:p>
<h:p>
In the example above, message #2, 3 and 4 are missing. Here's an example of a nack:
</h:p>
<h:pre>
<wsrm:SequenceAcknowledgement
xmlns:wsrm="http://docs.oasis-open.org/wsrx/@@@"
seqID="http://example.org/mysequence/1234"; nack="2 3 4">
</h:pre>
<h:p>
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.
</h:p>
</description>
<target>core</target>
<type>design</type>
<origin href="">Chris Ferris</origin>
<owner href="mailto:chrisfer@us.ibm.com";>Chris Ferris</owner>
<justification>
<h:p>
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.
</h:p>
<h:p>
In terms of creation/serialization performance, I found an average savings in serialization
(using java) of:
</h:p>
<h:p>
Sequence - .0478 ms
</h:p>
<h:p>
SequenceAcknowledgement (with 2 gaps) - .19765 ms
</h:p>
<h:p>
I haven't had a chance to assess parsing performance benefits yet, but I have to imagine that
there would be some benefit.
</h:p>
<h:p>
Sure, scoff if you will, but in the context of an server implementation processing a
gazillion messages, the performance savings are non-trivial.
</h:p>
<h:p>
Think about providing RM support for a customer such as a Ford or FedEx.
</h:p>
<h:p>
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.
</h:p>
<h:p>
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.
</h:p>
</justification>
<proposal date="2005-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:
<h:pre>
<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]"? .../>
</h:pre>
</proposal>
<!--<resolution date="">[markup]</resolution>-->
</issue>
<issue id="i033" status="done" edstatus="unassigned">
<title>Processing model of NACKs </title>
<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.
</description>
<target>core</target>
<type>design</type>
<origin href="mailto:steve.winkler@sap.com";>Steve Winkler</origin>
<owner href="mailto:steve.winkler@sap.com";>Steve Winkler</owner>
<justification>
This will clarify to implementers the spirit of the spec
by spelling out in more concrete terms what is currently only implied.
</justification>
<proposal date="2005-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>
<proposal date="2005-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.
</proposal>
<resolution date="2005-09-22">
Proposal 2 accepted at <h:a href="http://lists.oasis-open.org/archives/ws-rx/200509/msg00262.html";>Sept. 22nd F2F</h:a>
</resolution>
</issue>
<issue id="i034" status="done" edstatus="unassigned">
<title>
If a fault is generated whilst processing a piggy-backed
AckRequested or SequenceAcknowledgement header, should this stop
processing of the entire message?
</title>
<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.
</description>
<target>core</target>
<type>design</type>
<origin href="mailto:MILLWOOD@uk.ibm.com";>Daniel Millwood</origin>
<owner href="mailto:MILLWOOD@uk.ibm.com";>Daniel Millwood</owner>
<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.
</justification>
<proposal date="2005-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>
<proposal date="2005-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.
</proposal>
<resolution date="2005-09-22">
Proposal 2 accepted at <h:a href="http://lists.oasis-open.org/archives/ws-rx/200509/msg00262.html";>Sept. 22nd F2F</h:a>
</resolution>
</issue>
<issue id="i035" status="active" edstatus="unassigned">
<title>
What does 'anon' URI mean when used in AcksTo EPR?
</title>
<description>
<h:p>
WS-Addressing Core [1], section 2.1 says the following about 'anon':
</h:p>
<h:p>
"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."
</h:p>
<h:p>
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.
</h:p>
</description>
<relid>i012</relid>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00090.html";>Anish Karmarkar</origin>
<owner href="mailto:umit.yalcinalp@sap.com";>Umit Yalcinalp</owner>
<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.
</justification>
<proposal date="2005-09-08">
<h:p>
This can be resolved by:
</h:p>
<h:p>
a) Adding a stmt similar to WS-Addressing SOAP binding. Something like:
</h:p>
<h:p>
"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."
</h:p>
<h:p>
OR
</h:p>
<h:p>
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.
</h:p>
<h:p>
I prefer that we do (b). If they refuse, we can do (a)
</h:p>
</proposal>
<!--<resolution date="">[markup]</resolution>-->
</issue>
<!-- i036 -->
<issue id="i036" status="dropped" edstatus="unassigned">
<title>Duplicate detection of wsrm:CreateSequence messages</title>
<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.
</description>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00190.html";>
Anish Karmarkar
</origin>
<owner href="mailto:Anish.Karmarkar@oracle.com";>Anish Karmarkar</owner>
<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.
</justification>
<proposal date="2005-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.
</proposal>
<resolution date="2005-09-22">
Motion to close with no action passed at <h:a href="http://lists.oasis-open.org/archives/ws-rx/200509/msg00262.html";>9/22 F2F</h:a>.
</resolution>
</issue>
<issue id="i037" status="pending" edstatus="unassigned">
<title>WS-Addressing Endpoint redefined in WSRM</title>
<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.
</description>
<target>core</target>
<type>editorial</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00194.html";>
Anish Karmarkar
</origin>
<owner href="mailto:Anish.Karmarkar@oracle.com";>Anish Karmarkar</owner>
<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).
</justification>
<proposal date="2005-09-21">Replace the current definition by a reference to the WS-Addr spec.</proposal>
<proposal date="2005-10-13">Insert the current text from ws addressing with "as defined in ws addressing" as a prefix phrase.</proposal>
<resolution date="2005-10-13">
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200510/msg00109.html";>Proposal 2 made and accepted on Oct. 13 TC call</h:a>
</resolution>
</issue>
<issue id="i038" status="pending" edstatus="unassigned">
<title>2396 is obsoleted by 3986</title>
<description>
There are several reference to RFC 2396. This RFC is obsoleted by RFC 3986.
</description>
<target>core</target>
<type>editorial</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00195.html";>
Anish Karmarkar
</origin>
<owner href="mailto:Anish.Karmarkar@oracle.com";>Anish Karmarkar</owner>
<justification>RFC 2396 is obsoleted by RFC 3986.</justification>
<proposal date="2005-09-21">Either replace 2396 with 3986 OR like WS-Addressing, move to IRIs (RFC 3987).</proposal>
<proposal date="2005-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.
</proposal>
<resolution date="2005-10-13">
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200510/msg00109.html";>Proposal 2 made and accepted on Oct. 13 TC call</h:a>
</resolution>
</issue>
<issue id="i039" status="done" edstatus="unassigned">
<title>What does 'have a mustUnderstand attribute' mean?</title>
<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'.
</description>
<target>core</target>
<type>editorial</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00204.html";>
Anish Karmarkar
</origin>
<owner href="mailto:Anish.Karmarkar@oracle.com";>Anish Karmarkar</owner>
<justification>
<h:p>
Lines 270-272 in <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14548/wsrm-1.1-spec-wd-03.pdf";>[1]</h:a>
say:
</h:p>
<h:p>
"... The <wsrm:Sequence>
</h:p>
<h:p>
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."
</h:p>
<h:p>
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'.
</h:p>
</justification>
<proposal date="2005-09-21">Change it to say: "... mustUnderstand attribute with a value of 1/true ..."</proposal>
<resolution date="2005-09-22">
Proposal 1 accepted at
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200509/msg00262.html";>9/22 F2F</h:a>.
See proposed-04.
</resolution>
</issue>
<issue id="i040" status="done" edstatus="unassigned">
<title>Change 'optional' and 'required' in section 3 to RFC 2119 OPTIONAL and REQUIRED</title>
<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.
</description>
<target>core</target>
<type>editorial</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00205.html";>
Anish Karmarkar
</origin>
<owner href="mailto:Anish.Karmarkar@oracle.com";>Anish Karmarkar</owner>
<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.
</justification>
<proposal date="2005-09-21">
Change all occurrences of 'required' to 'REQUIRED' and 'optional' to 'OPTIONAL' in section 3.
</proposal>
<resolution date="2005-09-22">
Proposal 1 accepted at
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200509/msg00262.html";>9/22 F2F</h:a>.
See proposed-05.
</resolution>
</issue>
<issue id="i041" status="pending" edstatus="unassigned">
<title>Presence of NACK and ACK range in the same message</title>
<description>
<h:p>
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14548/wsrm-1.1-spec-wd-03.pdf";>
Page 15, lines 344-345 say
</h:a>:
</h:p>
"This element MUST NOT be present if <wsrm:Nack>
is also present as a child of <wsrm:SequenceAcknowledgement>."
<h:p>
Given that there can be multiple SeqAck headers in a message, this is true only for the same header and not across headers.
</h:p>
</description>
<target>core</target>
<type>editorial</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00208.html";>
Anish Karmarkar
</origin>
<owner href="mailto:Anish.Karmarkar@oracle.com";>Anish Karmarkar</owner>
<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.
</justification>
<proposal date="2005-09-21">
Replace the sentence in question with "... MUST NOT be present if a sibling <wsrm:Nack> element is also present ..."
</proposal>
<resolution date="2005-10-13">
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200510/msg00109.html";>Proposal 1 accepted on Oct. 13 TC call</h:a>
</resolution>
</issue>
<issue id="i042" status="deferred" edstatus="unassigned">
<title>Which version of WS-Addressing spec?</title>
<description>
<h:p>
Page 25, lines 664-665 at <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14548/wsrm-1.1-spec-wd-03.pdf";>[1]</h:a>
says:
</h:p>
<h:p>
"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."
</h:p>
<h:p>
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:
</h:p>
<h:p>
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.
</h:p>
</description>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00209.html";>
Anish Karmarkar
</origin>
<owner href="mailto:Anish.Karmarkar@oracle.com";>Anish Karmarkar</owner>
<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.
</justification>
<proposal date="2005-09-21">
<h:p>
Use the CR version of the spec <h:a href="http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/";>[2]</h:a>
(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.
</h:p>
<h:p>
For the related issue:
</h:p>
<h:p>
change line 664 from --
</h:p>
<h:p>
"WS-ReliableMessaging faults MUST include as the [action] property the default fault"
</h:p>
<h:p>
to --
</h:p>
<h:p>
"WS-ReliableMessaging faults MUST include as the [action] property as defined by WS-Addressing [ref]."
</h:p>
<h:p>
and delete lines 665-667
</h:p>
</proposal>
<proposal>
<h:p>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.
</h:p>
<h:p>
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.
</h:p>
</proposal>
<resolution date="2005-10-27">
Proposal 2 accepted on <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15110/MinutesWSRX-102705.htm";>Oct. 27th TC call</h:a>
, issue is deferred.
</resolution>
</issue>
<issue id="i043" status="pending" edstatus="unassigned">
<title>Why is wsa imported in the WSDL?</title>
<description>
On page 49, lines 156-1358 in <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14548/wsrm-1.1-spec-wd-03.pdf";>[1]</h:a>,
there is a schema import of the wsa namespace in the wsdl:types section. Why is this needed?
</description>
<target>wsdl</target>
<type>editorial</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00210.html";>
Anish Karmarkar
</origin>
<owner href="mailto:Anish.Karmarkar@oracle.com";>Anish Karmarkar</owner>
<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.
</justification>
<proposal date="2005-09-21">
Remove the xs:import that imports wsa namespace.
</proposal>
<resolution date="2005-10-13">
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200510/msg00109.html";>Proposal 1 accepted on Oct. 13 TC call</h:a>
</resolution>
</issue>
<issue id="i044" status="pending" edstatus="unassigned">
<title>SequenceFault element refers to fault code rather than fault [Subcode]</title>
<description>
On page 27, line 745 at <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14548/wsrm-1.1-spec-wd-03.pdf";>[1]</h:a>
refers to fault code rather than fault [Subcode].
</description>
<target>core</target>
<type>editorial</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00213.html";>
Anish Karmarkar
</origin>
<owner href="mailto:Anish.Karmarkar@oracle.com";>Anish Karmarkar</owner>
<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.
</justification>
<proposal date="2005-09-21">
<h:p>Either:</h:p>
<h:p>1) refer to fault [Subcode] instead of fault code</h:p>
<h:p>Or:</h:p>
<h:p>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.</h:p>
<h:p>I prefer (2).</h:p>
</proposal>
<proposal date="2005-10-13">change sentence line 745 and 746 of WD 03 (9/19) to refer to fault [Subcode] instead of fault code</proposal>
<resolution date="2005-10-13">
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200510/msg00109.html";>Proposal 2 made and accepted on Oct. 13 TC call</h:a>
</resolution>
</issue>
<issue id="i045" status="done" edstatus="unassigned">
<title>Why is SecureConversation a normative reference?</title>
<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.
</description>
<target>core</target>
<type>editorial</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00214.html";>
Anish Karmarkar
</origin>
<owner href="mailto:Anish.Karmarkar@oracle.com";>Anish Karmarkar</owner>
<justification>
A non-normative reference is listed under normative reference.
</justification>
<proposal date="2005-09-21">
Include the [SecureConversation] reference wherever the Security Consideration section talks about it
and move it to the non-normative reference section.
</proposal>
<resolution date="2005-09-22">
Proposal 1 accepted at
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200509/msg00262.html";>9/22 F2F</h:a>.
See proposed-11.
</resolution>
</issue>
<issue id="i046" status="done" edstatus="unassigned">
<title>Schema type of wsrm:FaultCode element can be changed from xs:QName to wsrm:FaultCodes</title>
<description>
<h:p>Page 37, line 1027 of <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14548/wsrm-1.1-spec-wd-03.pdf";>[1]</h:a>
makes the type of wsrm:FaultCode as xs:QName.
This element is already restricted to the QNames listed in the schema type wsrm:FaultCodes.</h:p>
<h:p>Related issues:</h:p>
<h:p>Editorial issue about changing wsrm:FaultCodes to wsrm:FaultCodeType, raised in the email at <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00193.html";>[2]</h:a></h:p>
</description>
<target>schema</target>
<type>editorial</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00215.html";>
Anish Karmarkar
</origin>
<owner href="mailto:Anish.Karmarkar@oracle.com";>Anish Karmarkar</owner>
<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
</justification>
<proposal date="2005-09-21">
<h:p>Replace line 1027 from -</h:p>
<h:p><xs:element name="FaultCode" type="xs:QName"/> </h:p>
<h:p>to -</h:p>
<h:p><xs:element name="FaultCode" type="wsrm:FaultCodes"/></h:p>
</proposal>
<resolution date="2005-09-22">
Proposal 1 accepted at
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200509/msg00262.html";>9/22 F2F</h:a>.
See proposed-12.
</resolution>
</issue>
<issue id="i047" status="pending" edstatus="unassigned">
<title>Reorder spec sections</title>
<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.
</description>
<target>core</target>
<type>editorial</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00217.html";>
Doug Davis
</origin>
<owner href="mailto:dug@us.ibm.com";>Doug Davis</owner>
<justification>
Helps in understanding the spec.
</justification>
<proposal date="2005-09-21">
<h:p>Change the order to be:</h:p>
<h:p>CreateSequence</h:p>
<h:p>Sequence header</h:p>
<h:p>ReqAck header</h:p>
<h:p>SeqAck header</h:p>
<h:p>CloseSequence</h:p>
<h:p>TerminateSequence</h:p>
</proposal>
<proposal date="2005-09-22">
<h:p>Postpone incorporation until after the first CD</h:p>
<h:p>Change the order to be:</h:p>
<h:p>CreateSequence</h:p>
<h:p>CloseSequence</h:p>
<h:p>TerminateSequence</h:p>
<h:p>Sequence header</h:p>
<h:p>ReqAck header</h:p>
<h:p>SeqAck header</h:p>
</proposal>
<resolution date="2005-09-22">
Proposal 2 accepted at <h:a href="http://lists.oasis-open.org/archives/ws-rx/200509/msg00262.html";>Sept. 22 F2F,
see proposed-13</h:a>
</resolution>
</issue>
<issue id="i048" status="pending" edstatus="unassigned">
<title>
CloseSequenceResponse and Acks
</title>
<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.
</description>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00218.html";>
Doug Davis
</origin>
<owner href="mailto:dug@us.ibm.com";>Doug Davis</owner>
<justification>
See description.
</justification>
<proposal date="2005-09-21">
<h:p>To solve this I'd like to require that the CloseSequenceResponse message include the "final" Ack.</h:p>
<h:p>So, using <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14548/wsrm-1.1-spec-wd-03.pdf";>[1]</h:a>:</h:p>
<h:p>Replace the text on line 608:</h:p>
<h:p>
Upon receipt of this message the RM Destination MUST send a
SequenceAcknowledgement to the RM Source.
</h:p>
<h:p>With:</h:p>
<h:p>Upon receipt of this message the RM Destination MUST send a
SequenceAcknowledgement to the RM Source in the
CloseSequenceResponse message.</h:p>
</proposal>
<resolution date="2005-10-06">
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14845/MinutesWSRX-100605.htm";>Proposal 1 accepted</h:a> and <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/msg00034.html";>further described here</h:a>.
</resolution>
</issue>
<issue id="i049" status="active" edstatus="unassigned">
<title>Allignment and refinement of defintions for DA</title>
<description>
I took an action Item to align the Delivery Assurance definition text in
the body document with the resolution of Issue 009.
</description>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/msg00015.html ">
Tom Rutt
</origin>
<owner href="mailto:tom@coastin.com";>Tom Rutt</owner>
<justification>
<h:p>
The resolution of Issue 009 is documented <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14682/ReliableMessagingIssues.xml#i009";>here</h:a>:
</h:p>
<h:p>
It is best if the Delivery assurances are defined in only one place in
the document.
</h:p>
<h:p>
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.
</h:p>
<h:p>
The definition in the current text of DA in Section 2 :
</h:p>
<h:p>
There are four basic delivery assurances that endpoints can provide:
</h:p>
<h:p>
- 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.
</h:p>
<h:p>
- 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.
</h:p>
<h:p>
- 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.
</h:p>
<h:p>
- 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.
</h:p>
<h:p>
while the current text for resolution of issue 009 adds the following
for DA policy assertion:
</h:p>
<h:p>
<wsrm:DeliveryAssertion mode="[AtLeastOnce|AtMostOnce|ExactlyOnce]"
ordered="[xs:boolean]"? ...="" >
</h:p>
<h:p>
/wsrm:DeliveryAssertion
</h:p>
<h:p>
A policy assertion that makes a claim as to the delivery assurance policy
observed by the destination endpoint.
</h:p>
<h:p>
/wsrm:DeliveryAssertion/@mode
</h:p>
<h:p>
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.
</h:p>
<h:p>
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.
</h:p>
<h:p>
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.
</h:p>
<h:p>
A value of 'ExactlyOnce' means that every message received by the RM
Destination will be delivered to the Application Destination without
duplication.
</h:p>
<h:p>
/wsrm:DeliveryAssertion/@ordered
</h:p>
<h:p>
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.
</h:p>
<h:p>
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'.
</h:p>
</justification>
<proposal date="2005-10-06">
<h:p>
The proposal to resolve this ISSUE is presented in Three Steps.
</h:p>
<h:p>
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
</h:p>
<h:p>
Resulting text for Proposal for Issue 009:
</h:p>
<h:p>
<wsrm:DeliveryAssertion mode="[AtLeastOnce|AtMostOnce|ExactlyOnce]"
ordered="[xs:boolean]"? ...="" >
</h:p>
<h:p>
/wsrm:DeliveryAssertion
</h:p>
<h:p>
A policy assertion that makes a claim as to the delivery assurance policy
observed by the destination endpoint.
</h:p>
<h:p>
/wsrm:DeliveryAssertion/@mode
</h:p>
<h:p>
This required attribute specifies which delivery assurance is asserted.
</h:p>
<h:p>
A value of 'AtMostOnce' means that the Delivery Assurance “at Most Once,
defined in section xxx, is asserted.
</h:p>
<h:p>
A value of 'AtLeastOnce' means that the Delivery Assurance “At Least Once”,
defined in section xxx, is asserted..
</h:p>
<h:p>
A value of 'ExactlyOnce' means that the Delivery Assurance “Exactly Once”,
defined in section xxx, is asserted.
</h:p>
<h:p>
/wsrm:DeliveryAssertion/@ordered
</h:p>
<h:p>
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'.
</h:p>
<h:p>
Step 2) of Proposed Resolution: Clarify Definitions of Delivery
assurances, including the requirment for error indication.
</h:p>
<h:p>
We need to align the two definitions and put the resulting agreed text
in section 2:
</h:p>
<h:p>
- 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..
</h:p>
<h:p>
- 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.
</h:p>
</proposal>
<!--<resolution date="">[markup]</resolution>-->
</issue>
<issue id="i050" status="active" edstatus="unassigned">
<title>spec talks about delivery assurances but does not clearly relate them to the protocol</title>
<description>
The WS-ReliableMessaging specification talks about delivery assurances but does not clearly relate them to the protocol.
</description>
<target>core</target>
<type>editorial</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00269.html";>
Stefan Batres
</origin>
<owner href="mailto:mgoodner@microsoft.com";>Marc Goodner</owner>
<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.</justification>
<proposal date="2005-09-26">
<h:p>
One proposal that has been kicked around by the TC consists of:
</h:p>
<h:p>
a) Remove all references to delivery assurances from the WS-RM spec.
</h:p>
<h:p>
b) Describe, in detail, DA's in the policy spec (since we're adding an Assurances element to that document anyway).
</h:p>
<h:p>
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.
</h:p>
<h:p>
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.
</h:p>
</proposal>
<!--<resolution date="">[markup]</resolution>-->
</issue>
<issue id="i051" status="pending" edstatus="unassigned">
<title>
Presence of multiple <SequenceAcknowledgement> headers for same Sequence in the same message
</title>
<description>
<h:p>
Anish has a proposal<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00208.html";>[2]</h:a>
for resolving i041<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14682/Re#i041";>[1]</h:a>.
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.
</h:p>
<h:p>
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.
</h:p>
</description>
<target>core</target>
<type>editorial</type>
<relid>i041</relid>
<origin href="http://lists.oasis-open.org/archives/ws-rx/200510/msg00046.html";>Chris Ferris</origin>
<owner href="mailto:chrisfer@us.ibm.com";>Chris Ferris</owner>
<justification>
I don't believe that it was never intended to permit multiple <SequenceAcknowledgement>
elements belonging to the same sequence in a given message.
</justification>
<proposal date="2005-10-11">
<h:p>
Add the following language to the spec after line 340 (pdf wd 03)<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14548/wsrm-1.1-wd-03.pdf";>[3]</h:a>:
</h:p>
<h:p>
A message MUST NOT contain multiple <SequenceAcknowledgement>
header blocks that share the same value for <Identifier>.
</h:p>
</proposal>
<resolution date="2005-10-13">
<h:a href="http://lists.oasis-open.org/archives/ws-rx/200510/msg00109.html";>Accepted proposal 1 on Oct. 13 TC call</h:a>
</resolution>
</issue>
<issue id="i052" status="active" edstatus="unassigned">
<title>Should DA be separate assertion or parameter</title>
<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.
</description>
<target>policy</target>
<relid>i009</relid>
<type>design</type>
<origin href="http://lists.oasis-open.org/archives/ws-rx/200510/msg00107.html";>Chris Ferris</origin>
<owner href="mailto:umit.yalcinalp@sap.com";>Umit Yalcinalp</owner>
<justification>We need to make a decision</justification>
<!--<proposal date="2005-06-29">[markup]</proposal>-->
<!--<resolution date="">[markup]</resolution>-->
</issue>
<issue id="i053" status="active" edstatus="unassigned">
<title>
Which occurances within the specs, if any, of the term "URI" need to be replaced with "IRI"?
</title>
<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.
</description>
<target>core</target>
<relid>i038</relid>
<type>editorial</type>
<origin href="http://lists.oasis-open.org/archives/ws-rx/200510/msg00108.html";>Chris Ferris</origin>
<owner href="mailto:umit.yalcinalp@sap.com";>Umit Yalcinalp</owner>
<justification>Ensure correct use of the terminology within the spec wherever a URI could be an IRI.</justification>
<proposal date="2005-10-24">
<h:p>
Here are the references to URI that should and should not be updated to IRI... <h:a href="http://www.oasis-open.org/archives/ws-rx/200510/msg00216.html ">see message</h:a>
</h:p>
</proposal>
<proposal date="2005-11-03">
<h:p>
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.
</h:p>
<h:p>
It is not necessary to change the sequence identifier to IRI as we previously proposed. Therefore we propose the
following changes to satisfy i053...
</h:p>
<h:p>
<h:a href="http://www.oasis-open.org/archives/ws-rx/200511/msg00102.html";>See message</h:a> for line number details of changes
</h:p>
</proposal>
<!--<resolution date="">[markup]</resolution>-->
</issue>
<issue id="i054" status="active" edstatus="unassigned">
<title>Target of RM Assertion parameters are confusing with respect to how they are specified
and attached</title>
<description>
<h:p>
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14793/wsrmp-1.1-spec-wd-01.pdf";>
Currently the WS-RM Policy Assertion
</h:a> 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:
</h:p>
<h:p>RMS:</h:p>
<h:p>-- Base Retransmission Interval (BRI)</h:p>
<h:p>-- Exponential Backoff (EB)</h:p>
<h:p>-- Inactivity Timeout (IT)</h:p>
<h:p>RMD:</h:p>
<h:p>-- Inactivity Timeout (IT)</h:p>
<h:p>-- Acknowledgement Interval (AI)</h:p>
<h:p>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.</h:p>
<h:p>There are two possible interpretations:</h:p>
<h:p>(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.</h:p>
<h:p>(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.</h:p>
<h:p>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.</h:p>
</description>
<target>policy</target>
<type>design</type>
<relid>i021</relid>
<relid>i006</relid>
<origin href="http://lists.oasis-open.org/archives/ws-rx/200510/msg00155.html";>Umit Yalcinalp</origin>
<owner href="mailto:umit.yalcinalp@sap.com";>Umit Yalcinalp</owner>
<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.</justification>
<proposal date="2005-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>
<proposal date="2005-11-02">
<h:p>
<h:a href="http://www.oasis-open.org/archives/ws-rx/200511/msg00023.html";>See message</h:a>
</h:p>
<h:p>
As indicated for the proposal for resolving i022 [1], we favor retaining InactivityTimeout and AcknowledgementInterval in the WS-RM Policy specification.
</h:p>
<h:p>
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.
</h:p>
<h:p>
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 <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200511/msg00021.html";>original issue posting</h:a>.
</h:p>
</proposal>
<!--<resolution date="">[markup]</resolution>-->
</issue>
<issue id="i055" status="active" edstatus="unassigned">
<title>Whose Inactivity Timeout is it anyway?</title>
<description>
<h:p><h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14793/wsrmp-1.1-spec-wd-01.pdf";>
Currently the WS-RM Policy Assertion</h:a> 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:</h:p>
<h:p>RMS:</h:p>
<h:p>-- Base Retransmission Interval (BRI)</h:p>
<h:p>-- Exponential Backoff (EB)</h:p>
<h:p>-- Inactivity Timeout (IT)</h:p>
<h:p>RMD:</h:p>
<h:p>-- Inactivity Timeout (IT)</h:p>
<h:p>-- Acknowledgement Interval (AI)</h:p>
<h:p>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?</h:p>
<h:p>Currently the specification indicates the following in Lines 108-111:</h:p>
<h:p>{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?</h:p>
</description>
<target>policy</target>
<type>design</type>
<relid>i054</relid>
<origin href="http://lists.oasis-open.org/archives/ws-rx/200510/msg00157.html";>Umit Yalcinalp</origin>
<owner href="mailto:mgoodner@microsoft.com";>Marc Goodner</owner>
<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.</justification>
<proposal date="2005-11-02">
<h:p>
<h:a href="http://www.oasis-open.org/archives/ws-rx/200511/msg00037.html";>See message</h:a> for full description of proposal rationale
</h:p>
<h:p>
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:
</h:p>
<h:p>
Remove the lines 154-155 [4]
</h:p>
<h:p>
/wsrmp:RMAssertion/wsrm:InactivityTimeout/@Milliseconds
The inactivity timeout duration, specified in milliseconds.
</h:p>
<h:p>
Replace the lines 151-153 with
</h:p>
<h:p>
/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.
</h:p>
<h:p>
Add the lines:
</h:p>
<h:p>
/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.
</h:p>
</proposal>
<!--<resolution date="">[markup]</resolution>-->
</issue>
<issue id="i056" status="active" edstatus="unassigned">
<title>
How can RMS communicate the Base Retransmission Interval, Exponential Backoff and
Inactivity Timeout values?
</title>
<description>
<h:p>
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14793/wsrmp-1.1-spec-wd-01.pdf";>
Currently the WS-RM Policy Assertion
</h:a> 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:</h:p>
<h:p>RMS:</h:p>
<h:p>-- Base Retransmission Interval (BRI)</h:p>
<h:p>-- Exponential Backoff (EB)</h:p>
<h:p>-- Inactivity Timeout (IT)</h:p>
<h:p>RMD:</h:p>
<h:p>-- Inactivity Timeout (IT)</h:p>
<h:p>-- Acknowledgement Interval (AI)</h:p>
<h:p>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.</h:p>
</description>
<target>policy</target>
<type>design</type>
<origin href="http://lists.oasis-open.org/archives/ws-rx/200510/msg00159.html";>Umit Yalcinalp</origin>
<owner href="mailto:chrisfer@us.ibm.com";>Chris Feris</owner>
<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.
</justification>
<proposal date="2005-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>
<proposal date="2005-11-02">
<h:p>
<h:a href="http://www.oasis-open.org/archives/ws-rx/200511/msg00040.html";>See message</h:a> for complete proposal rationale
</h:p>
<h:p>
Add the following section to the wsrmp specification (which may be subject to further editorial modification)
</h:p>
<h:p>
Section XX: Optimization for specifying parameters within WS-RM Protocol
</h:p>
<h:p>
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.
</h:p>
<h:p>
<wsrm:CreateSequence ...="">
</h:p>
<h:p>
<wsrm:AcksTo ...=""> wsa:EndpointReferenceType </wsrm:AcksTo>
</h:p>
<h:p>
<wsrm:Expires ...=""> xs:duration </wsrm:Expires> ?
</h:p>
<h:p>
…
</h:p>
<h:p>
<wsrmp:InactivityTimeout>600000</wsrmp:InactivityTimeout>
</h:p>
<h:p>
</wsrm:CreateSequence>
</h:p>
<h:p>
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.
</h:p>
</proposal>
<!--<resolution date="">[markup]</resolution>-->
</issue>
<issue id="i057" status="unassigned" edstatus="unassigned">
<title>Classification of References (normative vs. non-normative) is needed</title>
<description>
<h:p>Currently our working draft references are all over the map.</h:p>
<h:p>-- <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14785/wsrm-1.1-spec-wd-05.pdf";>
WS-RM
</h:a>: Lists most references as Normative, except those that are related to WS-Policy.</h:p>
<h:p>-- <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14793/wsrmp-1.1-spec-wd-01.pdf";>
WS-RM Policy Assertion
</h:a>: 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.</h:p>
</description>
<target>core</target>
<type>design</type>
<origin href="http://lists.oasis-open.org/archives/ws-rx/200510/msg00165.html";>Umit Yalcinalp</origin>
<!--<owner href=""></owner>-->
<justification>Obvious :-). We need normative and non-normative references clearly delineated.</justification>
<proposal date="2005-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>
<!--<resolution date="">[markup]</resolution>-->
</issue>
<issue id="i058" status="active" edstatus="unassigned">
<title>State Transition Table</title>
<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.
</description>
<target>core</target>
<type>editorial</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/msg00258.html";>
Abbie Barbir
</origin>
<owner href="mailto:tom@coastin.com";>Tom Rutt</owner>
<justification>
A full state transition table is needed in order to ensure proper design of the reliable protocol.
</justification>
<!--<proposal date="2005-06-29">[markup]</proposal>-->
<!--<resolution date="">[markup]</resolution>-->
</issue>
<issue id="i059" status="active" edstatus="unassigned">
<title>Retransmission behavior</title>
<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.
</description>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/msg00258.html";>
Bob Freund
</origin>
<owner href="mailto:bob.freund@hitachisoftware.com";>Bob Freund</owner>
<justification>
See description.
</justification>
<!--<proposal date="2005-06-29">[markup]</proposal>-->
<!--<resolution date="">[markup]</resolution>-->
</issue>
<issue id="i060" status="active" edstatus="unassigned">
<title>
Definition for "Reliable Message"
</title>
<description>
There are several references to "reliable message" (section 1, 2 intro, 2.1, 2.3) that are not backed
by a clear definition.
</description>
<target>core</target>
<type>editorial</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/msg00258.html";>
Jacques Durand
</origin>
<owner href="mailto:JDurand@us.fujitsu.com";>
Jacques Durand
</owner>
<justification>
A full state transition table is needed in order to ensure proper design of the reliable protocol.
</justification>
<proposal date="2005-10-25">
<h:p>
1- Add a terminology entry. It could be:
</h:p>
<h:p>
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.
</h:p>
<h:p>
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:
</h:p>
<h:p>
Replace:
</h:p>
<h:p>
"Messages for which the delivery assurance applies MUST contain a <wsrm:Sequence> header block."
</h:p>
<h:p>
With:
</h:p>
<h:p>
"Reliable Messages MUST contain a <wsrm:Sequence> header block."
</h:p>
<h:p>
(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.)
</h:p>
</proposal>
<!--<resolution date="">[markup]</resolution>-->
</issue>
<issue id="i061" status="active" edstatus="unassigned">
<title>Anonymous AcksTo</title>
<description>
Add text, similar to above, to the spec. It should be placed in the Sequence Ack section.
</description>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/msg00267.html";>Doug Davis</origin>
<owner href="mailto:dug@us.ibm.com";>Doug Davis</owner>
<justification>See description.</justification>
<proposal date="2005-10-27">
<h:p>
After the first paragraph in the SeqAck section (currently section 3.2) add something like:
</h:p>
<h:p>
Sending Sequence Acknowledgement Header blocks back to the AcksTo EPR could have an impact on current
SOAP implementations. While this specification discusses the ability to add, or piggy-back, a Sequence
Acknowledgement Header block to a message that is targetted to the AcksTo EPR, the precise mechanism
for determining when any particular message is targetted, or not, to the AcksTo EPR is out of scope
for this specification. However, WS-Addressing does give some guidance on EPR comparision.
</h:p>
<h:p>
Using the WS-Addressing's anonymous IRI in the AcksTo EPR may further impact implementations. When
the AcksTo EPR uses 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 to 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.
</h:p>
<h:p>
Maybe we should say that they should compare EPRs per WSA's rules? thoughts?
</h:p>
<h:p>
Another option for the anon AcksTo is to encourage people to use ref-p's to disamiguate anonymous
EPRs - but I still like the idea of restricting back-channel flows.
</h:p>
</proposal>
<!--<resolution date="">[markup]</resolution>-->
</issue>
<issue id="i062" status="active" edstatus="unassigned">
<title>None AcksTo</title>
<description>
Disallow the use of the 'none' IRI
</description>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/msg00268.html";>Doug Davis</origin>
<owner href="mailto:dug@us.ibm.com";>Doug Davis</owner>
<justification>W/o disallowing it Acks can not be sent back to the RM Source</justification>
<proposal date="2005-10-27">
<h:p>
After the first paragraph in the SeqAck section (currently section 3.2) add something like:
</h:p>
<h:p>
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.
</h:p>
</proposal>
<!--<resolution date="">[markup]</resolution>-->
</issue>
<issue id="i063" status="active" edstatus="unassigned">
<title>SeqAck - None and Final</title>
<description>
In <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15001/wsrm-1.1-spec-wd-05.pdf";>[1]</h:a>
current schema and pseudo schema doesn't allow None and Final on the same SeqAck - and they should be.
</description>
<target>core</target>
<type>editorial</type>
<origin href="http://lists.oasis-open.org/archives/ws-rx/200511/msg00057.html";>Doug Davis</origin>
<owner href="mailto:dug@us.ibm.com";>Doug Davis</owner>
<justification>Its possible that a sequence could be closed w/o any Acks.</justification>
<proposal date="2005-10-30">
<h:p>
Make schema and pseudo schema support None and Final - like this:
</h:p>
<h:p>
<wsrm:SequenceAcknowledgement ...="">
</h:p>
<h:p>
<wsrm:Identifier ...=""< xs:anyURI </wsrm:Identifier<
</h:p>
<h:p>
[ [ <wsrm:AcknowledgementRange ...=""
</h:p>
<h:p>
Upper="xs:unsignedLong"
</h:p>
<h:p>
Lower="xs:unsignedLong"/< *
</h:p>
<h:p>
| <wsrm:None/< ]
</h:p>
<h:p>
<wsrm:Final/< ?
</h:p>
<h:p>
| <wsrm:Nack> xs:unsignedLong </wsrm:Nack< + ]
</h:p>
<h:p>
...
</h:p>
<h:p>
</wsrm:SequenceAcknowledgement<
</h:p>
<h:p>
Note: changed the + to a * on the AckRange element. since Final can appear w/o any AckRanges.
</h:p>
</proposal>
<!--<resolution date="">[markup]</resolution>-->
</issue>
<issue id="i064" status="active" edstatus="unassigned">
<title>
Create Sequence Refused Fault is too restrictive
</title>
<description>
<h:p>
In <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15001/wsrm-1.1-spec-wd-05.pdf";>WS-RM specification</h:a>
, the Create Sequence Refused fault requires [Detail] to be empty (lines 836-842) as follows:
</h:p>
<h:p>
4.7 Create Sequence Refused
</h:p>
<h:p>
This fault is sent in response to a create sequence request that cannot be satisfied.
</h:p>
<h:p>
Properties:
</h:p>
<h:p>
[Code] Sender
</h:p>
<h:p>
[Subcode] wsrm:CreateSequenceRefused
</h:p>
<h:p>
[Reason] The create sequence request has been refused by the RM Destination.
</h:p>
<h:p>
[Detail] empty
</h:p>
<h:p>
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.
</h:p>
</description>
<target>core</target>
<type>design</type>
<origin href="http://lists.oasis-open.org/archives/ws-rx/200511/msg00057.html";>Umit Yalcinalp</origin>
<owner href="mailto:umit.yalcinalp@sap.com";>Umit Yalcinalp</owner>
<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.
</justification>
<proposal date="2005-11-01">Allow [Detail] to contain any content, instead of requiring it to be empty.</proposal>
<!--<resolution date="">[markup]</resolution>-->
</issue>
<issue id="i065" status="active" edstatus="unassigned">
<title>Reword "Closing a Sequence" section</title>
<description>
<h:p>
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:
</h:p>
<h:p>
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.
</h:p>
<h:p>
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.
</h:p>
<h:p>
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.
</h:p>
<h:p>
Upon receipt of this message the RM Destination MUST send aSequenceAcknowledgement to the RM Source. Note, this
SequenceAcknowledgement MUST include the <wsrm:Final>
element.
</h:p>
<h:p>
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.
</h:p>
<h:p>
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
</h:p>
</description>
<target>core</target>
<type>editorial</type>
<origin href="http://lists.oasis-open.org/archives/ws-rx/200511/msg00057.html";>Matthew Lovett</origin>
<owner href="mailto:MLOVETT@uk.ibm.com";>Matthew Lovett</owner>
<justification>The above text could be clearer.</justification>
<proposal date="2005-11-02">
<h:p>
Replace the above text (lines 625 - 648) with the following:
</h:p>
<h:p>
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.
</h:p>
<h:p>
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.
</h:p>
<h:p>
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.
</h:p>
<h:p>
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.
</h:p>
</proposal>
<!--<resolution date="">[markup]</resolution>-->
</issue>
<issue id="i066" status="active" edstatus="unassigned">
<title>Remove LastMessage</title>
<description>
<h:p>
The LastMessage element, as part of a Sequence header element, appears superfluous. It seems to serve 2 purposes:
</h:p>
<h:p>
1 - force a SeqAck to be sent back from the RMD
</h:p>
<h:p>
2 - force the RMD to reject any messages with a higher message #
</h:p>
<h:p>
#1 can be done with an AckReq header. We should avoid having multiple ways to do the same thing.
</h:p>
<h:p>
#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.
</h:p>
<h:p>
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.
</h:p>
</description>
<target>core</target>
<type>design</type>
<origin href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200511/msg00019.html";>Doug Davis</origin>
<owner href="mailto:dug@us.ibm.com";>Doug Davis</owner>
<justification>See above</justification>
<proposal date="2005-11-02">
Remove all references to LastMessage (and related Fault) from the <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15001/wsrm-1.1-spec-wd-05.pdf";>spec</h:a>. See attached diff/pdf file for the
specific changes.
</proposal>
<!--<resolution date="">[markup]</resolution>-->
</issue>
<issue id="i067" status="active" edstatus="unassigned">
<title>
Replace 'response'
</title>
<description>
<h:p>
<h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15001/wsrm-1.1-spec-wd-05.pdf";>under figure 2</h:a>, for step 7 replace:
</h:p>
<h:p>
7.The RM Destination acknowledges receipt of message numbers 1 and 3 in response to the RM Source's <wsrm:LastMessage>
token.
</h:p>
<h:p>
with
</h:p>
<h:p>
7.The RM Destination acknowledges receipt of message numbers 1 and 3 as a result of receiving the RM Source's <wsrm:LastMessage>
token.
</h:p>
</description>
<target>core</target>
<type>editorial</type>
<origin href="http://lists.oasis-open.org/archives/ws-rx/200511/msg00057.html";>Doug Davis</origin>
<owner href="mailto:dug@us.ibm.com";>Doug Davis</owner>
<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 :-)
</justification>
<proposal date="2005-11-02">see above</proposal>
<!--<resolution date="">[markup]</resolution>-->
</issue>
<issue id="i068" status="active" edstatus="unassigned">
<title>Remove 'correlation' text</title>
<description>
<h:p>
In section 2.2 the <h:a href="http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15001/wsrm-1.1-spec-wd-05.pdf";>spec</h:a> says:
</h:p>
<h:p>
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.
</h:p>
<h:p>
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.
</h:p>
</description>
<target>core</target>
<type>editorial</type>
<origin href="http://lists.oasis-open.org/archives/ws-rx/200511/msg00057.html";>Doug Davis</origin>
<owner href="mailto:dug@us.ibm.com";>Doug Davis</owner>
<justification>Leads to confusion</justification>
<proposal date="2005-11-02">Remove the text after the semi-colon</proposal>
<!--<resolution date="">[markup]</resolution>-->
</issue>
<!--<issue id="i000" status="unassigned" edstatus="unassigned">
<title>My Issue</title>
<description>
This is my issue. There are many like it, but this one is mine.
</description>
<target>core</target>
<type>editorial</type>
<origin href=""></origin>
<owner href="mailto:";></owner>
<justification>[markup]</justification>
<proposal date="2005-11-03">[markup]</proposal>
<resolution date="">[markup]</resolution>
</issue>-->
</issues>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]