Steve,
Thanks for taking the time to review the document! Comments inline
below:
On Friday, Oct 17, 2003, at 18:17 US/Eastern, Steve Anderson wrote:
> Some comments on the use case/requirement document ... Better late
> than never, I suppose ...
>
> I propose changing the definition of "Idle Time-out" from
>
> A period of time, after which, if there is no activity by the user
> associated
> with a session, the session may be considered invalid
>
> to
>
> A period of time, during which, if there is no activity by the user
> associated
> with a session, the session may be considered suspended.
>
> The wording change at the beginning is just clarification, and I don't
> expect it to be controversial.
Not controversial perhaps, but important. I can say that what I meant
by "timeout" was actually "timeout value" - ie. a timeout value of 2
hours would imply that a session was considered timed-out after a
period of exactly 2 hours. Changing "after" to "during" changes the
meaning of timeout - I like your definition better, but it may well
reflect some changes I need to make to the rest of the document ;)
> The wording change at the end may generate a little discussion. I
> prefer the notion of suspending the session here, because if the user
> re-authenticates successfully, the data associated with the session
> before the timeout should still be available. Under the previous
> wording, there was no distinction between disposition of the session
> during timeout and during logout.
I'm certainly open to this... anyone else have something to add?
> I would also like to echo some of Mike Beach's comments. I view the
> SP as the top of the food chain, as it relates to idle timeout
> thresholds. Other links in that 'chain' can shorten the threshold,
> but not widen.
Can you expand on that view? I'll just say the same thing I said about
Mike's earlier comment. I think that for a *local* resource, the SP
*is* the SA, but that they may be conceptually separate, implying that
at the least the SA and the SP will "agree" on timeout values. For a
*shared* session, the SA is almost certain to NOT be physically
connected to the SP, but still may be, and the SA will have ultimate
responsibility for the timeout values set - an individual SP shouldn't
be able to affect the timeout value for a session that is shared with
other SPs - one would imagine the SA would have to take responsibility
to setting the global session timeout, no?
Thanks again,
- JohnK
