RE: Poll response data

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

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

>-----Original Message-----
>From: Daniel Manley [mailto:dmanley@tucows.com]
>Sent: Monday, June 18, 2001 3:08 PM
>To: 'ietf-provreg@cafax.se'
>Subject: Poll response data
>
>
>Hi Scott,
>
>Perhaps this is answered in your latest documents.  If so, please
>forgive me -- I'll take a look soon.
>
>In the drafts I've seen so far, the specification for the poll response
>data is pretty lite.  Is it the spec's responsibility to define all the
>possible resData bits than can be returned in a Poll.  I've seen an XML
>sample that showed domain:transfer.  Would there also be
>contact:transfer?  How about domain:renew if the registry has
>automatically renewed a domain that was about to expired.  How about
>domain:delete, if the domain is not being auto-renewed and will be
>deleted.  Would a domain:delete response be accompanied by a sequence of
>host:delete's where the action is cascaded to children objects?
>
>Dan
>