To:
ietf-provreg@cafax.se
From:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date:
Mon, 24 Sep 2001 15:33:42 -0400
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: <check> Response Attribute
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
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.
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.
Eric