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:dug@us.ibm.com]
Sent: Wednesday, July 05, 2006
12:29 PM
To: ws-rx@lists.oasis-open.org
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"
<bob.freund@hitachisoftware.com>
07/05/2006 11:57 AM
|
To
|
Doug Davis/Raleigh/IBM@IBMUS,
<ws-rx@lists.oasis-open.org>
|
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:dug@us.ibm.com]
Sent: Wednesday, July 05, 2006 10:38 AM
To: ws-rx@lists.oasis-open.org
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