RE: Poll response data

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

>-----Original Message-----
>From: Rick H Wesson [mailto:wessorh@ar.com]
>Sent: Wednesday, June 20, 2001 12:50 PM
>To: Hollenbeck, Scott
>Cc: 'Klaus Malorny'; 'ietf-provreg@cafax.se'
>Subject: RE: Poll response data
>
>
>
>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?

All info will be correct as of the time a message was queued, though you're
right that things might change between the time a message gets queued and
the time it gets retrieved (in the case you mentioned, registrar-A's queued
messages will include a notice of B's ACK, so when viewed in aggregate all
of the info will be correct and current).  I suppose that the need or desire
to do a <transfer> query after receiving notice of a <transfer> action may
depend on the amount of time that has elapsed between message enqueuing and
message retrieval.  What I think is important, though, is that the client
will have all of the info it needs to determine if it _should_ do an
additional query -- it won't _have_ to.  Without more detail in the message,
the client _must_ do a query to obtain details.

<Scott/>