Re: <check> Response Attribute

[Ed Rahn <ed@ItsYourDomain.Com>]

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

> The proposal of 9/21 by the editor of draft-provreg-epp, to make a specific
> modification of a schema, is discussed.
> 
> There are three related issues. One is the data type returned by an operator.
> Another is registry state for the operator's (object) operands. A third is
> the extensibility of the first and second.
> 
> 1. Discussion of types.
> 
> The present schema, from draft-ietf-provreg-epp-04.txt (line numbers added),
> is:
> 
>    2954   <!--
>    2955   <check> result type.
>    2956   -->
>    2957     <simpleType name="checkType">
>    2958       <restriction base="token">
>    2959         <enumeration value="+"/>
>    2960         <enumeration value="-"/>
>    2961       </restriction>
>    2962     </simpleType>
>  
> The base type for "token" [t] is "normalizedString" [n], which in turn has
> a base type of "string" [s], a primitive datatype. "boolean" [b] is also a
> primitive datatype.
> 
> Definitional texts:
> 
> [Definition:] token represents tokenized strings. The value space of token
> is the set of strings that do not contain the line feed (#xA) nor tab (#x9)
> characters, that have no leading or trailing spaces (#x20) and that have no
> internal sequences of two or more spaces. The lexical space of token is the
> set of strings that do not contain the line feed (#xA) nor tab (#x9)
> characters, that have no leading or trailing spaces (#x20) and that have no
> internal sequences of two or more spaces.
> 
> [Definition:]  boolean has the value space required to support
> the mathematical concept of binary-valued logic: {true, false}. 
> 
> Considered as a question of types, the proposal is to change the tuple used,
> the primitive datatype, restricting the value space to the {true,false,1,0}
> set, restricting the lexical space, and restricting the set of facets, from
> those of "token" to those of "boolean".
> 
> [t] http://www.w3.org/TR/xmlschema-2/#token
> [n] http://www.w3.org/TR/xmlschema-2/#normalizedString
> [s] http://www.w3.org/TR/xmlschema-2/#string
> [b] http://www.w3.org/TR/xmlschema-2/#boolean

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.

> 
> 2. Discussion of registry state.
> 
> Known registry states for objects which may be the operands for the <check>
> operator include:
> 
> 	"+"	found or existant
> 	"-"	not found or non-existant
> 	" "	unknown (NeuStar/NeuLevel)
> 	"tbd"	reserved (ICANN)
> 	"tbd"	mechanism lock present (failure diagnostic, pendingDelete, etc)
> 	"tbd"	policy lock present, e.g., "pending" (DRP, etc)
> 	"foo"	defensive registraion (.name specific)
> 	"no"	other issue, tbd, e.g., charter scope (.coop)
> 	"tbd"	unavailable
> 
> It appears that independent of registry-specific policy, more than two values
> are required to express the actual state of objects in the object repository.
> A simplified view might mask all object states to a two-valued representation.
> 

Registrar specific information should not be in the standards draft. 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. 

> 3. Extensibility within type and of state.
> 
> Assume a datatype has an N-valued value-space, and for some M < N, N - M of
> the values are allocated. Only N - M values in the value-space are available
> to be reserved for future specification, or reserved for unspecified use, or
> defined to be "undefined".
> 
> In the special case of a boolean type with two values of its value-space
> allocated, N == M == 2, and no extension within the type is possible.
> 
> A similar observation applies to the internal state-space of an object
> repository, and its external representation(s), which may differ, e.g.,
> a common registry for distinct policy-defined or delegated name-spaces.

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. 

> 
> Eric
> 

Ed Rahn
ItsYourDomain.com