Re: new ECML v 2 requirements from Nokia

[Eric Brunner <brunner@world.std.com>]

David,

An escape mechanism from a iso3166-constrained interpretation of a series of
two or more octets is fine, assuming that iso3166 was a manditory referent.

When Donald, Bill and I (but mostly Donald and I) went over the equivalent
problem in Domain Name System (DNS) IANA Considerations (BCP 0042), we found
that we could reserve the two-octet label-space without having to cite 3166.

There we were forced to consider the problem of unique identifiers and the
legacy code base that knew the identifiers consisted of 16 contiguous bits,
interpreted as octet-aligned data, and letters-digits-or-hyphen, in ASCII.
We still don't have any basis to judge whether or not the management of the
DNS root was effected one way or another by not citing 3166. We don't appear
to have caused an instance of non-interoperability.

Here we are just attempting to create an identifer with no compactness
properties that force us to use binary labels, or anything less compact
than strings -- the requirement of two octet (ASCII) strings seems to be
foreign to the problem at hand.

The degree of implementation complexity that seperates a two-octet lookup
table with sparce (240) values, and shell-completion isn't compelling.

If the 3166 reference is optional (which is how we solved this problem in
the XML stream for provisioning DNS TLD registries in PROVREG [1]), then
the problem is solved.

Eric

[1]  EPP Contact mapping, Sec. 2.4.1 Street, City, and State or Province
     draft-ietf-provreg-epp-contact-04.txt