RE: <check> Response Attribute

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

> -----Original Message-----
> From: Ed Rahn [mailto:ed@ItsYourDomain.Com]
> Sent: Tuesday, September 25, 2001 5:28 PM
> To: Edward Lewis
> Cc: Jordyn A. Buchanan; ietf-provreg@cafax.se; jaap@sidn.nl
> Subject: RE: <check> Response Attribute
> 
> 
> How would a <create> command deal with an object that returned a <check>
> of "maybe". It would either need to create the object, or not create it.

Exactly.  At any given point in time an object is either available, or it
isn't.  The <check> is supposed to be nothing more than a fast, light-weight
hint that helps a client decide if a <create> could work.  <create> then
returns an unambiguous success or failure response, not something like
"might have been created".

> Addressing Jordyn's comments. Could EPP be used in some type of
> asynchronous fashion? I searched through the "Generic Registry-Registrar
> Protocol Requirements" draft quickly and did not see anything concerning
> realtime or delayed actions. If EPP could be used in a delayed environment
> a "maybe" responce might be needed. In this case "yes" would be not be
> used, and we would still be using a two responce system.

Think email transport as one option, and yes, EPP can be used that way.  I
don't see how a "maybe" comes up even here, though, because at the moment in
time that the command gets executed there shouldn't be any ambiguity.  That
may change before a <create> is attempted, but that situation exists even in
a real-time environment.  That's why <check> is a _hint_, and not a
guarantee of success or failure.

> Addressing Edward's comments. Would we want to make <check>
> conditional? This could not only be necessary for domains but any other
> object that would require some type of prerequesits, such as secure
> certificates. I'm under the opinion that  a <check> would return a
> "no" and then set some type of reason, an <info> command could be used to
> obtain the necessary prerequesits.

No, I don't think it makes sense to make <check> conditional.  It's utility
comes in providing a fast, unambiguous pre-<create> hint.  <info> is
designed to return information for a single registered object, not general
server-specific policy information that is better documented outside the
protocol.

We already have a provision in the domain mapping document to deal with a
situation where offline processing is needed to completely confirm object
creation.  The <create> returns an unambiguous response, and (if needed) the
status of the object gets initially set to "pendingVerification".  After the
offline verification process is completed, the object either gets set to
"active", or maybe the server deletes the object and sends the client a
notice, or it does whatever it needs to do, but there's never any doubt
about the success or failure of any particular command.

<Scott/>