Couple of comments below,
MG2.
From: Bob Freund
[mailto:bob@freunds.com]
Sent: Thursday, June 29, 2006 9:05 AM
To: Marc Goodner; 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
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.
MG2: There seems to be an easy solution if no one cares.
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?
MG2: I did not say I was opposed
to this, I just need more time to think about it. I will not be ready to make a
decision regarding this on today’s call.
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?
MG2: Why wouldn’t the RMS terminate the sequence with
the RMD before the situation arises? Certainly it should be aware that would be
about to happen.
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.
MG2: Bob, this is a rather substantial proposal to
reformat a whole section. I am having a hard time determining how I feel about
that in the absence of seeing the rewritten section. I am also not convinced
that this reformatting would add the amount of additional clarity you feel that
it would. Given where we are at in trying to complete the spec I am reticent at
taking this work on at this stage.
thanks
-Doug