Re: <check> Response Attribute

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

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

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

Eric