That works for me, as long as we have a
semi-formal protocol in consolidating and publishing the new submitted issues.
-Jacques
From: Marc Goodner
[mailto:mgoodner@microsoft.com]
Sent: Monday, July 25, 2005 7:08
PM
To: Jacques
Durand; wsrx
Subject: RE: [ws-rx] New proposed
issues 7/14 - 7/20
The summary does appear in the report on
the TC page for the accepted issues, the below was from a local
"submitted" file I've started working with.
For right now I think that for my own work
flow it makes more sense for me to capture the issues as they come in locally,
email the ones I have caught the day before the call (as below), and then
update the primary issue list with the accepted issues. I'd like to at
least keep it this way for a little while and then we can reevaluate what we
could do to improve it.
Regards,
Marc g
From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
Sent: Thursday, July 21, 2005
12:24 PM
To: Marc Goodner; wsrx
Subject: RE: [ws-rx] New proposed
issues 7/14 - 7/20
Marc and all:
In order to facilitate the review and the
access to issues:
-
I
propose that the state of the issue (assigned, resolved, etc.) also appears in
the Issue summary produced by the XSL,
-
I'll
move that we also add new proposed issues in the Issue list with a new state:
"submitted".
Regards,
jacques
From: Marc Goodner
[mailto:mgoodner@microsoft.com]
Sent: Thursday, July 21, 2005
12:16 AM
To: wsrx
Subject: [ws-rx] New proposed
issues 7/14 - 7/20
I have captured two new proposed issues since the last call
from the list. Please let me know if I have overlooked any. - Regards, Marc g
proposed-01
|
Is an implementation
supporting a smaller max message number valid?
|
core - design - unassigned
|
|
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? Related to i013.
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".
Origin
Doug
Bunting
Proposal
12005-07-14
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".
|
proposed-02
|
Sequence termination
on Fault
|
core - design - unassigned
|
|
Description
The
RM Destination imperatively terminates a sequence due to one of these
unrecoverable errors:
- wsrm:SequenceTerminated - wsrm:MessageNumberRollover - wsrm:LastMessageNumberExceeded
The semantics
of sequence termination due to a fault occurrence are not clearly specified.
This uses the reworded
issue
Justification
Unless
an accurate and final acknowledgement status was sent back at the time the
sequence is closed, the Source will not know if some non-acknowledged
messages were actually received before the termination occurs. This gives the
source two unpleasant options: (a) resend all non-acknowledged message in a
new sequence, with the risk of causing undetectable duplicates, (b) not
resend any, and these will be lost.
Origin
Jacques
Durand
Proposal
12005-07-15
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.
|