Whatever, just that it should be said
somewhere and clearly
-bob
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Thursday, June 29, 2006 3:08
PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] List of Bob's
NEW issues (really only six) well, ok seven
Rollover by RM Source http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00212.html
on 1) that an impl detail, nothing on the wire from a spec perspective
on 2) an impl choice - it may not choose to close/terminate the sequence at all
I suggest: Close w/no action
MG: I haven’t thought deeply about this one, but that was my first inclination
as well.
BF: Well, if the RMD supports
sequences that are longer than the RMS (or an RMD acting as an RMS, we could
use some new names here) then rollover happens at the RMS it can’t
continue sending since it can’t represent the MessageNumber. What
does it do exactly?
DUG:
I'm a bit lost. If the RMS needs to end a sequence early (relative to the
RMD's max msg #) then that is its own concern. The RMD doesn't need to
know about it or do anything with that info. The RMS would need to decide
whether to raise some kind of fault back to the AS or create a new seq to
continue its work. Either way, that something internal to the RMS side of
things and the RMD doesn't need to know about it.
thanks,
-Doug
"Bob Freund-Hitachi" <bob.freund@hitachisoftware.com>
06/29/2006 12:50 PM
|
To
|
"Marc Goodner"
<mgoodner@microsoft.com>, "Bob Freund-Hitachi" <bob.freund@hitachisoftware.com>, Doug
Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>
|
cc
|
|
Subject
|
RE: [ws-rx] List of Bob's NEW issues (really
only six) well, ok seven
|
|
Most of these were created while working on the
state tables.
I attempted, to find the text in the specs that supported the
cells in the tables.
Since the tables are non-normative, I had a conceptual
problem adding behavior that I did not find in the normative parts of the
document.
I have added some additional comments below inline:
From: Marc Goodner
[mailto:mgoodner@microsoft.com]
Sent: Thursday, June 29, 2006 10:43 AM
To: Bob Freund-Hitachi;
Doug Davis; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] List of Bob's NEW issues (really only six)
well, ok seven
My
opinions inline.
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Thursday, June 29, 2006 6:45 AM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] List of Bob's NEW issues (really only six)
well, ok seven
Comments on Bob's issues:
Apx C examples http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00217.html
These sample message flows are tied to figure 2 - do we really want to update
that one too? I don't really care much except it does make more work for the
monkeys :-)
MG: I
don’t mind seeing these examples added, however I think the tie to figure
2 is a perfect excuse to avoid the work altogether. I’m fine with seeing
the message examples added with or without the update to figure 2. Someone will
have to produce them though.
BF:
Don’t care much either, but close is necessary to force seqAck/final and
encouraged, just seems odd that it is not in the examples.
Sequence Expiry http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00216.html
Do we really need an entire new section for this or can we just add a line of
text to where Expires is used saying something like:
This value indicates the time at which the Sequence
SHOULD be terminated.
Or just change sentences like:
This element, if present, of type xs:duration
specifies the duration for the offered Sequence.
To:
This element, if present, of type xs:duration
specified the duration of time until the Sequence SHOULD be terminated.
MG: I have not had enough time to think about this one. I am not going to be
ready to make a decision about this on today’s call.
BF: if we don’t say
anything in the spec about expiry, then what other than blank deserves to be in
the state table? I think that it is important to define precisely what
constitutes the lifetime of a sequence. The words I proposed were written
to ensure that the RM Destination would expire at the same time or earlier than
the RM Source.
Note
that in the case of an offered sequence, does expiry mean the duration from
receipt by the RMD of the offer, or is it the duration from the use of offer by
the RMD acting as an RMS when that RMD …. Hmm how does the RMD use the
offered sequence? Does the expires in the CSR that may be
“refined” by the RMD cover both the initial as well as the offered
sequence, Are the other CSR elements inherited by the accepted offered
sequence?. Where do we say that the acceptance of an offered sequence
causes the RMD to behave as an RMS plopped immediately into the connected
state?
Rollover by RM Source http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00212.html
on 1) that an impl detail, nothing on the wire from a spec perspective
on 2) an impl choice - it may not choose to close/terminate the sequence at all
I suggest: Close w/no action
MG: I haven’t thought deeply about this one, but that was my first
inclination as well.
BF: Well, if the RMD supports
sequences that are longer than the RMS (or an RMD acting as an RMS, we could
use some new names here) then rollover happens at the RMS it can’t
continue sending since it can’t represent the MessageNumber. What
does it do exactly?
What does not receive mean? http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00200.html
Just editoral, I'm ok with it.
MG: I’m not sure, I can try to be ready to decide on this one on the call
but no promises.
BF: glossary says that
Receive means to read a message from a network interface and to qualify it as
relevant to RM Destination functions. In order to confirm to the protocol
such that additional AckRequested that appear on its network interface
can be processed as required.
Can’t respond if Sequence not known http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00193.html
Editorial, not sure its needed since the definition of UnknownSeq fault says
its sent whenever we see an RM element referring to a Seq we don't know about,
so do we really need to say that for each and every RM element? Seems a
bit noisy but I'm not going to lay down in the road over it. My
preference would be to close w/no action since I think the Fault text already
covers this.
MG: Agree the fault text already covers it, but I’m fine with adding
this.
Terminate
sequence, fault not specified http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00192.html
See previous issue comment - this is getting a bit verbose.
MG: Agree, still I’m OK with it.
Add
detail and specificity to fault descriptions http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00190.html
I would like to see a specific proposal (actual proposed text) before I can
know for sure if I like the idea of this or not.
MG: I’m having a similar problem with this one.
BF: this is due to frustration trying to determine where to look for the
conditions that generate a particular fault and the precedence of faults.
Section 4 does not uniformly define fault generating conditions (see 4.5
for example) while spottily throughout the document fault generating conditions
are indeed described (see secs 3.1 and 3.2). In 4.5 it was not at all clear
to me whether the fault was to be transmitted or merely generated and by the
RMS or the RMD or both however in 3.4 it says that either may generate it, but
the RMS needs to receive a transmitted fault in order for its behavior to be
modified.
thanks
-Doug