If we think that it is preferable
for the Sequence to expire on the RMS before it expires on the RMD could
we/should we recommend that the RMS should "shave some time off of the
/wsrm:CreateSequenceResponse/wsrm:Expires value" and/or that the RMD should "pad
the /wsrm:CreateSequenceResponse/wsrm:Expires a bit"?
- gp
From: Bob Freund-Hitachi
[mailto:]
Sent: Thursday, July 20,
2006 12:43 PM
To: Marc Goodner; Doug Davis; Bob Freund-Hitachi;
Subject: [ws-rx] RE: i145 - Current
proposal
The state table moved
from the none state to the created state when the CSR was successfully
processed.
If that marks the
start of the sequence lifetime, then fine, but it is hard to determine where
in the normative spec that is made clear.
For durations less
than non-expiring, if csr successful processing marks the beginning of the
sequence lifetime and the time of this event is only known to the RMS, and if
both RMD and RMS are using the same duration, then it seems to me that since
there is positive non zero finite time between the sending of csr by the rmd
and the conclusion of its processing by the rms, then it follows that the
sequence will expire at the rmd at or before the time it expires at the rms
since it could also be said relatively, that the sequence begins at the rmd
(as far as it is concerned), when the csr is
sent.
Unless there is some
other timing mechanism imposed, that is what just will occur based on the
operation of the protocol without any specific desire for one to outlast the
other.
I would be happy for
text to be inserted somewhere clearly that simply said
that.
All sequence state
can be deleted upon the expiration of the duration defined in expiry time by
either RMS or RMD. That will make it clear that there is no terminating
protocol to be employed when sequences expire.
The question is,
where do you want it?
The text I proposed
could be grafted on to the section on sequences to prevent the creation of a
new spec section if you would prefer.
Thanks
-bob
From: Marc
Goodner [mailto:]
Sent: Thursday, July 20, 2006 2:14
PM
To: Doug Davis;
Bob
Freund-Hitachi;
Subject: i145 - Current
proposal?
Guys, following
up from my post earlier today on current proposals I realize the proposal
1 for i145 is not current. Reading the below
thread to see where this issue is the discussion seems to have stopped here.
Is there any agreement on this issue? Is there a proposal available we could
consider on today’s call?
From:
Doug Davis [mailto:]
Sent: Thursday, July 06, 2006 6:26
AM
To:
Subject: RE: [ws-rx] i145 - design:
Implications of Sequence Expiration not
specified
The timer started
when the sequence is created - or in state table terms, when we move from
"none" state to "created" state. Why would we need any finer granulatity
than that?
Its interesting that you think the
lifetime of the Sequence should be longer on the RMS than the RMD. I
would think it would be the other way around. It seems like it would
worse for the RMS to think that a sequence lived longer than it really did.
Stopping early (for the RMS) wouldn't cause too much pain (at least its
in control over why it stopped using the sequence) but sending a message and
finding out that the sequence it wanted to use is no longer there seems a bit
scarier. Did it go away because it expired or because of some internal
error that now required some kind of admin help? It (the RMS) just
doesn't know and it would worry me if it made some kind of assumption.
It would be much safer to have the RMS expire before the RMD and let the
RMS have control over when to stop using a sequence.
re:MakeConnection - I'm no so sure
it belongs in the state table at all. Its more of a transport level
thing and doesn't really have 'state' per say. Either there are messages
waiting to be delivered or not - just 2 possible states. Not very
exciting :-)
thanks,
-Doug
"Bob
Freund-Hitachi"
<>
07/05/2006 12:57
PM
To
Doug
Davis/Raleigh/IBM@IBMUS, <>
cc
Subject
RE: [ws-rx] i145 -
design: Implications of Sequence Expiration not
specified
Doug,
The state table
relies on definitions of events to advance from state to state.
It looks pretty bad
to say in the RMD state table that the sequence comes to life at some
implementation defined time and that it stays in the none state until that
time occurs. The state transitions are all very black and
white
I know of a community
of potential users who are more than a bit concerned about the security of the
protocol. I believe that their opinion would be to define expires to be
fairly tight compared with the expected time for sequence transmission.
Others might feel fine leaving it at PT0S
One aspect of the
text I proposed that I like is defining expiry that way ensures that the
Sequence will expire at the RMS at the same time or later than at the RMD (no
fair discussing clock granularity at this juncture). This provides at
least known behavior and supports silent termination. The RMS can be
reasonably assured that it need not be concerned about what is going on at the
RMD.
As for
MakeConnection, I have been thinking a bit about its
representation.
I am drifting in the
direction of defining an underlying “transfer engine” that would deal with it
independently of the sequence state tables. I think that this also might
take care of re-transmissions as well as the handling of responses which are
hard to find in the spec J.
Thanks
-bob
From: Doug
Davis [mailto:]
Sent: Wednesday, July 05,
2006 12:29 PM
To:
Subject: RE:
[ws-rx] i145 - design: Implications of Sequence Expiration not
specified
I had forgotten that I did
have a version that fixed the start of the duration, how about:
This element, if
present, of type xs:duration specifies the duration of time until the Sequence
SHOULD be terminated, relative to its creation time.
The
termination should probably be silent since we don't have a message for it.
Its not a fault, per say, so I'm not sure SeqTerminated Fault makes
sense.
My concern with the text
you've proposed is that it mandates that the sequences are created at a
certain time and I'm not sure we can mandate that. For example, you say
the sequence starts (on the RMD) when the CSR is transmitted. Is that
before or after the MakeConnection is received? I would prefer before,
but the 'transmit' in there may imply something else to others. I think
leaving it as a generic "creation time" is best - leaves it up to the impl to
decide when that time is.
Likewise, as you asked,
whether the Offered sequence is 'created' during the generation of CS or
during the processing of the CSR is an RMS detail that we should not get
into.
Overall, I'm not that
concerned about the timing of this, and am ok with leaving it a bit loose,
because I don't think this timing is that critical. If this timing were
critical and every millisecond counted then I would agree with you that we
would need to be very precise and need more work in this area, but I just
don't think the expiry/lifetime of a sequence is mission critical - it just
needs to remain available 'as long as' the requested Expires time - note it
doesn't have to commit suicide at that time at all, it just can't do it before
that time.
thanks
-Doug
"Bob
Freund-Hitachi"
<>
07/05/2006 11:57
AM
To
Doug
Davis/Raleigh/IBM@IBMUS, <>
cc
Subject
RE: [ws-rx] i145 -
design: Implications of Sequence Expiration not
specified
Doug,
Is that
termination silent?
I think that you
are correct, a new section is not really necessary.
Do we care what
signals the start of that xs:duration?
I think that this
may be tied to definition of the sequence lifetime which may be better defined
in Section 3.4 “Sequences”
My suggestion
would be to insert in the first paragraph of 3.4, perhaps at the end,
something along the lines of:
“A Sequence
exists at the RM Source from the processing of the wsrm:CreateSequenceResponse
until the earlier of the transmission of wsrm:TerminateSequence or the
Sequence expires (see section 3.1). A Sequence exists at the RM
Destination from the transmission of a wsrm:CreateSequenceResponse until the
earlier of the successful processing of a wsrm:TerminateSequence or the
Sequence expires (see Section 3.1).”
Once that is
done, then in Section 3.3 “Sequence Termination” expiration behavior could be
stated as something like:
At
the end of the first paragraph of 3.3
“Sequence are
also implicitly terminated without further exchange of protocol messages upon
the expiration of the Sequence (see Section 3.1)”
Then in Section
3.1 something along the lines of:
Following the
paragraph headed by the line: /wsrm:CreateSequenceResponse/wsrm:Expires the
following refining language:
“The Sequence is
said to expire when wsrm:CreateSequenceResponse/wsrm:Expires elapses from
either the perspective of the sender or the receiver of this
element”
I am still a bit
vague about the usage of the Expires within an Offer.
What does it mean
to you?
Thanks
-non
From: Doug
Davis [mailto:]
Sent: Wednesday, July 05,
2006 10:38 AM
To:
Subject: [ws-rx]
i145 - design: Implications of Sequence Expiration not specified
http://lists.oasis-open.org/archives/ws-rx/200606/msg00216.html
Bob,
I
think we can resolve this issue with a much smaller change - instead of
creating an entire new section why not just modify the description of the
Expires element like this:
This element, if present, of
type xs:duration specified the duration of time until the Sequence SHOULD be
terminated.
It will need to be modified slightly based on the exact usage
but you get the idea.
thanks
-Doug
