RE: <check> Response Attribute

["Jordyn A. Buchanan" <jordyn@register.com>]

Here are some states that I can think of off the top of my head

- Not available because the domain is restricted due to registry 
policy (for example b.com)
- Not available because the domain is registered to someone else
- Not available because someone paid for it not to be available
- I don't know if it's available
- Available
- Not available because it's reserved
- Not available because it's been deleted, but hasn't been released yet
- Not available because it's a name that isn't registerable by you 
(for example, if only certain registrars have access to certain 
subdomains)
- Available, but the cost is different than you were expecting

I'm sure there are other variations on theme.

I'm not 100% convinced that anything other than a binary state is 
good for the check command, but as long as we're going to make it not 
binary, we should recognize that a) there are many states and b) we 
are not smart enough to predict them all.  So I think I'm with 
Asbjorn on this.

Jordyn


At 11:44 AM -0700 9/24/01, Rick H Wesson wrote:
>Asbjorn,
>
>If you could list more than 8 to 10 diferent reasons then I'd understand
>why we shouldn't enumerate them, thus far only two reasons have been
>listed.
>
>If we just have two cases the I feel we shuld enum,erate them in the
>protocol.
>
>-rick
>
>
>
>On 24 Sep 2001 asbjorn.rrp@theglobalname.org wrote:
>
>>  Scott,
>>
>>  as Petrick mentioned earlier, we (.NAME) will have socalled "Defensive
>>  Registrations"[1] meaning that we might want to tell the
>>  Registra[r/nt] that this is the reason why a domain is not available.
>>
>>  There might be other reasons for a domain not to be available - a
>>  Registry might for example not allow registrations if the domain name
>>  includes the F-word or other expletives, or other policy-depended
>>  reason.
>>
>>  Since it might be hard to catch all the reasons why a domain name is
>>  "not available" in an enumeration, maybe it should be a free-form
>>  field there after all?!
>>
>>
>>  Asbjorn
>>
>>  [1] 
>>http://www.icann.org/tlds/agreements/name/registry-agmt-appl-03jul01.htm#2
>>
>>  On Sat, 22 Sep 2001 19:33:49 -0400 "Hollenbeck, Scott" wrote:
>>  >> -----Original Message-----
>>  >> From: Patrick [mailto:patrick@gandi.net]
>>  >> Sent: Saturday, September 22, 2001 10:28 AM
>>  >> To: ietf-provreg@cafax.se
>>  >> Subject: Re: <check> Response Attribute
>>  >>
>>  >>
>>  >> So the information about why it can not be registered is still
>>  >> useful.
>>  >
>>  >I think Dan Manley suggested this as well.  OK, if multiple people feel it
>>  >would be helpful to provide both a yes/no response and some sort of
>>  >rationale if the answer is "no", should we attempt to enumerate the
>>  >reasons
>>  >for "no" or should we consider free-form (aka server-defined, with some
>>  >defined maximum length) text to describe the rationale?
>>  >
>>  ><Scott/>
>>  >
>>
>>
>>  --
>>   The information transmitted in this email is intended only for 
>>the person(s)
>>   or entity to which it is addressed and may contain proprietary, 
>>confidential
>>   and/or privileged material. If you have received this email in 
>>error, please
>>   contact the sender by replying and delete this email so that it is not
>>   recoverable. If you are not the intended recipient(s), any 
>>retention, review,
>>   disclosure, distribution, copying, printing, dissemination, or 
>>other use of,
>>   or taking of any action in reliance upon, this information is strictly
>>   prohibited and without liability on our part.
>>