RE: [ws-rx] RE: i145 - Current proposal

Gil,

Given that we are using xs:durations and
not xs:daytime and given transit times from nanoseconds to weeks, than it is
impossible to ask what can be shaved off or padded.  I think that all we can do
is reference the duration relative to each endpoint’s clock at a point
near to when the respective endpoints become sensible of the duration.

Thanks

-bob

 

From: Gilbert Pilz
[mailto:] 

Sent: Thursday, July 27, 2006 3:11
PM

To: Bob Freund-Hitachi; Marc Goodner;
Doug Davis; 

Subject: RE: [ws-rx] RE: i145 -
Current proposal

 

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