Re: <check> Response Attribute

[Ed Rahn <ed@ItsYourDomain.Com>]

Eric, 

On Mon, 24 Sep 2001, Eric Brunner-Williams in Portland Maine wrote:

> >> 1. Discussion of types.
> ...
> > I'm am under the opinion that this should be changed to a boolean type to
> > better represent what the check command is really suppose to do, and has
> > been documented to do.
> 
> You wrote to the same effect earlier today. I suppose that it is a nuance
> whether the schema is controlling, or the descriptive text, but I prefer
> the former, which as far as I'm concerned, is correct as to type, and as
> to mechanism to represent object state when <check> is the operand, and is
> extensible.
> 
> >> 2. Discussion of registry state.
> ...
> > Registrar specific information should not be in the standards draft.
> 
> The discussion is of registry state, or at least its external (protocol)
> representation.
> 
> >                                                                      That
> > would not be fesable, and is the reason another attribute should be
> > created, or possibly returning a value in the <msg> field as to why it is
> > not available. 
> 
> Assuming you wrote "registrar" when you ment "registry", would you be
> specific please?
> 

My fault, I did mean registry.

It had been suggested that instead of changing the x attribute of the
check responce to a boolean type, that this be extended to not only return
if the domain is available or not, but why it is not available. If instead
of returning available or not the server returned why, the client would
need to know about all possible responces, and all of the responces would
need to be documented. As more registry's adopt EPP, it will become more
and more difficult to update the documentation to reflect all the possible
return values.

Because of this the reason why the domain is not available or even why
it is, whould be stored in another field. 

> >> 3. Extensibility within type and of state.
> ...
> > Creating another attribute on the check responce would allow for responces
> > limited to the length of the field * the number of characters in the
> > applicable character set.
> 
> This appears to follow from your second point, above. 
> 
> If you haven't read rfc640 recently, I commend it to your attention.
> 

This could be another way to a return <check> responce, however I believe
that this way of thinking of things is a bit out dated. The same results
could be achieved from a boolean x attribute, and a text attribute
describing the reason x was given such a value.

> Eric
> 

Ed Rahn
itsyourdomain.com