RE: Poll response data

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

Sheer,

Now I'm getting confused.  If your suggestion is to note when the queue is
updated, that happens every time is message is either enqueued or dequeued.
So, pulling off a message would result in an update, and I'm not sure that
the date and time of that event is of any value at all because the client
already knows exactly when it happened because they caused the update.

When you wrote "updated", did you mean "had a message added to the end of
the queue"?  After thinking about that a bit, I'm not sure that this
provides any really useful information, either.  The protocol currently
provides a queue counter that tells the client how many message are queued
for delivery.  If a client gets an indication in a response that there are
"n" queued messages, I've thought (and I may be wrong) that clients will
typically want to retrieve all of the queued messages at once through a
series of "n" <poll> requests and acks without really worrying about when
the last message was added.

Could someone else with a client perspective provide any insights into ways
that a "last updated" or "last queued" time would be valuable or not?  I'm
OK with noting a date-time on each queued message, but I'm not so sure about
the utility of this second date-time.

<Scott/>

>-----Original Message-----
>From: Sheer El-Showk [mailto:sheer@saraf.com]
>Sent: Tuesday, June 26, 2001 2:05 PM
>To: Bason, Chris
>Cc: 'ietf-provreg@cafax.se'
>Subject: RE: Poll response data
>
>
>Hi Chris,
>
>I think this concept makes a lot more sent if you think of it as a "queue
>last updated" timestamp rather than a "last message queue time" (my
>careless wording initiall, I apologize).  The idea is that the queue
>structure (in memory or in a database or whatever) would maintain a
>timestamp indicating the last time it was updated.  It would then
>prepend/append this to any response to a <poll> request.  This wouldn't
>be part of the actually queue message, but status information about the
>overall queue.  In fact, if the queue is updated (by whatever batch or
>synchronus process updates it) without any messages being added then this
>time will be very different from a "last message queued" timestamp.
>
>The idea behind this is to give the polling registrar an idea of the
>freshness of the queue overall.  If I'm polling for the state of a
>transfer request and see only an "awaiting acknowledgement" message queued
>two days ago it makes a big difference to me whether the queue was last
>updated a few minutes ago or two days ago.  The idea is to allow automated
>registrar systems to determine if they need to actively query for more
>detailed information.  Of course, I think, if all these systems are kept
>near real time then a lot of this will be redundant, but that expectation
>can't be built into the protocol.