RE: [ws-rx] List of Bob's NEW issues (really only six) well, ok seven

[Doug Davis <dug@us.ibm.com>]

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?

DUG: If you look at the process of creating
a sequence there are two expires - one in the CS and one in the CSR.  The
only one that matters is the one in the CSR since the one in the CS is
just a request - the one in the CSR is the definative value.  So,
in the case of Offer, the expires time is relative to something at the
RMS (the Offer is, in essence, the CSR) - it can't be related to the receipt
of the message at the RMD since the RMS has no idea when that will happen.
 This would also seem to imply that the RMD of any particular sequence
is the 'master' w.r.t. the expiry of the sequence. So, if you're looking
for some text that makes it clear that the expires times is relative to
something on the RMD then how about something like:
        This
element, if present, of type xs:duration specifies the duration of time
until the Sequence SHOULD be terminated, relative to its creation time.
I'm not sure we can be more precise
than that due to all of the various latency issues people may run into
- the other end of the sequence will just need to figure out what to do
with this value, +/- latency times, on its own.

thanks,
-Doug

"Bob Freund" <bob@freunds.com>

06/29/2006 12:05 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