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