Re: <check> Response Attribute

[Daniel Manley <dmanley@tucows.com>]

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