RE: Poll response data

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

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
>