RE: <check> Response Attribute

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

> -----Original Message-----
> From: Jordyn A. Buchanan [mailto:jordyn@register.com]
> Sent: Tuesday, September 25, 2001 5:36 PM
> To: Rick H Wesson
> Cc: Edward Lewis; ietf-provreg@cafax.se
> Subject: RE: <check> Response Attribute
> 
> 
> At 2:24 PM -0700 9/25/01, Rick H Wesson wrote:
> >Jordyn,
> >
> >If the name is available then yes is the only answer, if the 
> domains is
> >not available or MAYBE availabe then no is the appropiate answer.
> 
> Hmm?  From a registrar perspective, if the registry says a name is 
> *not* available, then I am not going to try to register a name.  If 
> it might be available or might not be, I would probably try.  "Maybe" 
> seems closer to "available" than "not available" in my mind.

I don't see how a registry can be undecided about object availability.  At
any given moment in time, an object is either available or it isn't.  It
might be available with conditions, but it's available, and the purpose of
the <check> isn't to explain the preconditions that might have to be met for
a <create> to be accepted.  It's supposed to be a light-weight, fast
operation that helps a client decide if a <create> might or might not work.

> I'm open to suggestions that we could supplement the "available" or 
> "not available" responses with codes to indicate uncertainty, but it 
> seems like an indeterminate state is a possible one that we should 
> get a grip on before deciding that <check> is only going to boolean.
>
> Ed R. raised the point of asynchrony, which I alluded to earlier. 
> What if the EPP implementation is just a frontend to a non-realtime 
> process?  Is it desirable to try and accomodate such a situation?  I 
> think probably yes, which means we need to be able to deal with 
> indeterminate responses.

I think the whole idea of indeterminate responses is BAD for both client and
server.  It implies client and server state management responsibilities for
the duration of pending transactions, adding a layer of complexity of
questionable utility.  Things are far simpler to implement and manage given
real-time interactions with unambiguous responses, even if some of the
responses ultimately mean something akin to the "pendingVerification" domain
status.

BTW, we have covered this topic before.  See section 3.6 of the requirements
draft.

<Scott/>