RE: Poll response data

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

Klaus,

There _is_ a well defined mechanism to determine all of the transfer details
you've described.  Look at the definition of the <transfer> command's
"query" operation.  You're suggesting that this exact same info be described
and required for return via a polled message?

I don't have a problem with enhancing the description of the <poll> command
to note that the format of transfer notices as described in the current text
is a required feature (are there any others?), but I don't think it makes
any sense at all to push the transfer details in a polled message.  As
things are defined right now, a polled message goes away once received and
acknowledged by the client.  With a transfer query operation the details can
be retrieved at any time, including after the operation has been completed.

<Scott/>

>-----Original Message-----
>From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de]
>Sent: Tuesday, June 19, 2001 5:16 AM
>To: Hollenbeck, Scott
>Cc: 'ietf-provreg@cafax.se'
>Subject: Re: Poll response data
>
>
>"Hollenbeck, Scott" wrote:
>> 
>> Dan,
>> 
>> Echoing what Rick said, I believe that the types of 
>informational messages
>> that should be made available via a <poll> are a matter of 
>registry policy,
>> so that's why there isn't a detailed description of the 
>messages that may be
>> supported.  I also believe that some situations should be 
>relayed to a
>> client via messages that can be polled, and others should be 
>relayed to a
>> client via offline reporting.  Those situations that require 
>timely client
>> protocol action, such as any object transfer or upcoming 
>object expiration,
>> should be relayed to the client via the polling mechanism.  Purely
>> informational notices that don't have temporal factors may 
>be better left to
>> some kind of registry reporting service.
>> 
>> I'm sure I can make the text more clear to make this intent 
>more obvious.
>> 
>> <Scott/>
>
>
>Hi Scott,
>
>sorry, I have to disagree. Since the transfer of objects is an integral
part
>of your protocol, it is a kind of incompleteness if the mechanisms which
are
>used to notify the losing registrar are not described. You describe in
detail
>when the gaining or losing registrar may request/cancel/reject/approve a
>transfer, but not the exact way of the notification, although this is
similar
>essential to the transfer process as the other stuff. Since you already
>limited the freedom of a registry's policy* (e.g. the object model/fields,
the
>relation between hosts and domains, the way that objects are transferred),
I
>don't see any problems in defining a message returned on a poll that
contains
>at least the following information: the object which is requested to be
>transferred, the registrar who wants to gain the object, an expire date
that
>tells the losing registrar if/when a default action is taken and what this
>default action is (approval or rejection).