RE: Poll response data

["Bason, Chris" <cbason@verisign.com>]

Sheer,

The idea of putting the queue update time in the
response seems to make even less sense. The problem
I see here is that when you dequeue a message you
are updating the queue. Therefore every time you
retrieve a queued message all you are doing is 
sending the time you retrieved that particular message
in the response.

There is a count that is returned in the response
to a poll that indicates how many messages are in 
the queue. I think "overall freshness" is not what
a registrar needs to be concerned with. They should
dequeue each message and process it in the sequence
received. The idea that a registrar can determine
what needs to be done with a message or whether to
process a message based on "overall freshness" seems
to me to be problematic. 

Chris Bason


-----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.


Sheer


On Tue, 26 Jun 2001, Bason, Chris wrote:

> Sheer,
>
> The timestamp indicating when a message is queued
> is definitely relevant. Although, I don't see how a
> timestamp indicating when the "last" message is queued
> will help.
>
> You can't store the timestamp of the "last" message
> queued in the actual message being queued. The reason
> is that when you queue a message it IS the last message
> being queued and therefore the message queued timestamp
> and the "last" message queued timestamp would be the same.
> When the current message is dequeued from the queue, if
> you want to send in the message the "last" message queued
> timestamp, you would need to query the queue for the most
> recently queued message to determine when it was queued.
> You can't just send the message.
>
> Additionally, as soon as you send the message, the "last" message
> queued timestamp is obsolete. A message could be queued immediately
> after a message has been sent that obsoletes it and therefore
> makes the "last" message timestamp useless.
>
> Chris Bason
>
>
> -----Original Message-----
> From: Sheer El-Showk [mailto:sheer@saraf.com]
> Sent: Thursday, June 21, 2001 12:33 PM
> To: Klaus Malorny
> Cc: Rick H Wesson; Hollenbeck, Scott; 'ietf-provreg@cafax.se'
> Subject: Re: Poll response data
>
>
> Hi all,
>
> First off, I'm not all that concerned about the polling mecahism from an
> implementation perspective.  Depending on the registry architecture I
> think it would be possible to implement a notification system so that the
> queue is updated in near real time (the same way whois or zone file
> updates might eventually be implemented) upon transfer or other relevant
> events.
>
> That implementation detail aside, I think its still possible to address
> this concern within the protocol.  I may have missed it, but I didn't see
> any reference to a message timestamp in the EPP-03 discussion of <poll>.
> I think each poll resposne should include two new timestamps.  The first
> will be the time that the queue was most recently updated; the second will
> be the time that particular queued message was placed in the queue.  That
> way, the registrar has all the information it requires about the queued
> messages and can descide in a more informed manner whether or not it has
> to make further queries.
>
> Sheer
>
>
> On Thu, 21 Jun 2001, Klaus Malorny wrote:
>
> > Rick H Wesson wrote:
> > >
> > > Scott,
> > >
> > > On Wed, 20 Jun 2001, Hollenbeck, Scott wrote:
> > >
> > > > After thinking about this for a bit, I like Klaus' idea of returning
> more
> > > > transfer detail in the <poll> response.  Doing so will help reduce
the
> need
> > > > to do an immediate <transfer> query right after receiving a message
to
> > > > obtain the details of a pending transfer.
> > > >
> > >
> > > however the tradeoff is that the queue(s) wiill have to be larger and
> > > couldn't the information become out of sync with the rest of the
> registry?
> > >
> > >   Registrar-A submits a transfer request for foo.com from Registrar-B
> > >   <registry inserts stuff in queue>
> > >   Registrar-B does poll and ACK on foo.com
> > >   Registrar-A does a poll -> is the information correct?
> > >
> > > A better question is this situation ok?
> > >
> > > -rick
> >
> > Hi Rick,
> >
> > anywhere where you have multiple actions which are not executed
atomically
> in
> > a multitasking environment, there is a chance to get outdated
information.
> > E.g. you could query the registry about a transfer and it tells you that
> it is
> > pending, so you decide that you either accept or reject it. But before
you
> > submit your decision to the registry, the gaining registrar may have
> cancelled
> > the transfer, so you may get some kind of error message on your transfer
> > request despite the query reponse you got fractions of a second before.
> >
> > Therefore, the problem is not specific to the poll mechanism, although
the
> > effect may appear more often if you don't poll regularly.
> >
> > regards,
> >
> > Klaus Malorny
> >
> >
> >
>
___________________________________________________________________________
> >      |       |
> >      | knipp |                   Knipp  Medien und Kommunikation GmbH
> >       -------                           Technologiepark
> >                                         Martin-Schmeisser-Weg 9
> >      Dipl. Inf. Klaus Malorny           44227 Dortmund
> >      Klaus.Malorny@knipp.de             Tel. +49 231 9703 0
> >
>