Re: draft-ietf-impp-pres-01

Dave Crocker <[email protected]> writes:

> John> The use of durations instead of absolute times in subscription
> John> requests makes the most sense to me.
> 
> So, I want to monitor you availability for the next 5 minutes and it
> takes 2 minutes for my request to arrive at the server.  That's ok?
> 
> In any event, can you elaborate on the reasoning behind your
> preference?

Well, I guess my position on this subject was more controversial than
I had imagined.  Sorry about suggesting otherwise, Dave.

The reason I think durations are the right solution is that, from a
watcher's perspective, a subscription request is successful only when
the watcher receives a successful response.  Given the time at which
the subscription was requested, the time at which the response was
received, and the duration contained in the response, the watcher can
bound the time at which the lease on the subscription will terminate.

Let's take your example for the perspective of a watcher.  The watcher
cannot know how long it takes a request to arrive at a server, so
let's change the example to:

   I want to monitor you availability for the next 5 minutes and it
   takes 4 minutes for the response to my subscription request to
   arrive back to me.  Is that okay?

Sure, this is okay by me.  I know my lease on the subscription will
terminate between 5 and 9 minutes after I initiated the request.  If
do not care about your presence information after 5 minutes from the
initial request, I simply instruct my watcher to discard notifications
from you after 5 minutes.  Not a problem.

If one uses absolute times, one cannot make bounds on the length of a
subscription without knowing the clock skew between the server and the
watcher, and skew happens.  My laptop is an example of why one should
not rely on absolute time.  Most of the time I use Linux, and when I
connect to the corporate network, AFS can adjust my clock.  When I run
Windows 2000, and then Linux, AFS always seems to need to adjust my
clock.  I cannot seem to get the two operating systems on my local
machine to agree on an absolute time.

> John> In Section 3.4, as Dave pointed out for IM, the paragraph 
> 
> John>    Note that the transaction-identifier parameter used by the service
> John>    is potentially long-lived.  Accordingly, the values generated for
> John>    this parameter should be unique across a significant duration of
> John>    time.
> 
> John> is wrong because a transaction-identifier for a subscription request can be
> John> reused as soon as its matching response is received.
> 
> 1.  I missed that in the spec.  Can you point out where this is said
> in the specification.

The quoted material is in Section 3.4 of draft-ietf-impp-pres-01.txt.
The part after the quote was my understanding of how
transaction-identifiers work.  It could be flawed.

> 2.  Re-use of unique identifiers is a little more complicated that
> this model suggests.  For example, I send a request and you take a
> long time to respond.  I send it again, after you do respond but
> before I get the response.  Do you interpret this as a new request or
> an old one?  How do you know?

I assumed that if you resend a request, that request must use a new
transaction-identifier.  That is, for each request there is a unique
transaction-identifier.  In this model, you can reuse a
transaction-identifier whenever you receive a response with that
transaction-identifier.

> Or, I send a request and you take forever to respond. Do I ever get to
> re-use that unique identifier?  How can I know when?

As I understand the protocol, you cannot reuse a
transaction-identifier except when you receive a response with that
transaction-identifier.  I bet real implementations will not follow
this rule to the letter.



  [reminder: [email protected] for non-technical discussions, please]