Re: <check> Response Attribute

[Mike Lampson <lampson@iaregistry.com>]

Maybe it's too late for this, but what us Registrars need to know is whether
the name is available for registration, not if it exists.  If a name cannot
be registered, I don't really care if it can't be registered because it
already exists or because it is reserved.

Regards,

Mike Lampson
The Registry at Info Avenue, LLC
(803) 802-6584

----- Original Message -----
From: "Daniel Manley" <dmanley@tucows.com>
To: "'ietf-provregcafaxse'" <ietf-provreg@cafax.se>
Sent: Friday, September 21, 2001 4:59 PM
Subject: Re: <check> Response Attribute


I tend to agree that "exists" is a black-and-white state that gets a
boolean setting.  Maybe you'd want an optional "status" or "why"
attribute that could contain the strings "reserved", "restricted", etc...

Dan

Hollenbeck, Scott wrote:

>>-----Original Message-----
>>From: Eric Brunner-Williams in Portland Maine
>>[mailto:brunner@nic-naa.net]
>>Sent: Friday, September 21, 2001 11:17 AM
>>To: Hollenbeck, Scott
>>Cc: 'ietf-provreg@cafax.se'; brunner@nic-naa.net
>>Subject: Re: <check> Response Attribute
>>
>>
>>Scott,
>>
>>You propose to restrict the type of <check> from an enumerated extensible
>>set (token) to a enumerated inextensible (boolean) set.
>>
>
>No, I've suggested that we replace what has been a kludge for a boolean
>response with a true boolean response.
>
>>How do you propose we handle requirements for "reserved" domain names?
>>
>
>The <check> command's purpose is to answer the question "does this object
>exist in the repository"; the answer to that question is binary.  If a name
>has been registered the answer should be "yes".
>
>I don't know which/whose requirements you're referring to.  If you're
>alluding to a specific server operator's need to return information beyond
a
>yes/no response I'd propose use of the extension mechanism.
>
><Scott/>
>