On 11/16/10 11:16 AM, David Conrad wrote:
Tony,
On Nov 16, 2010, at 6:06 AM, Tony Finch wrote:
Note that .4u is still simply not allowed by RFC 1123 or by this
draft.
According to my reading of RFC 1123 it is allowed,
1123 says:
"... However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be alphabetic."
Note that it says 'will be alphabetic' not ...
Were one to stop at the policy statement: "a valid host name can never
have the dotted-decimal form #.#.#.#", rather than the implementation
detail "since at least the highest-level component label will be
alphabetic", then one could consider whether labels consisting of at
least one instance of a label consisting of a character string
representing a digit in excess of 256 within the first four or fewer
labels meets the rule.
I'm not suggesting that there is a compelling need for a TLD "257", or
for a TLD "255" with a registration restriction that any sub-domain
must contain a non-digit or have a value as a digit string greater
than 256 within one of the first three lables, but that does seem to
be consistent with the narrowest reading of the policy, and the least
change needed to correct the associated error in the implementation
detail.
Also, just speaking of current policy, 2-letter TLDs are restricted to ...
This is the other leg of the test. The iso3166/MA has an allocation
model, and a use model. The allocation model appears to be sparse in
the 676 code element space available through an alpha-2 code
mechanism, and the following property of the model is generally
overlooked:
"ISO 3166-1 specifies a series of code elements for user purposes
which the ISO 3166/MA will never use in the updating process of the
standard. To quote from ISO 3166-1:2006, clause 8.1.3 User-assigned
code elements:
If users need code elements to represent country names not included in
this part of ISO 3166, the series of letters AA, QM to QZ, XA to XZ,
and ZZ, and the series AAA to AAZ, QMA to QZZ, XAA to XZZ, and ZZA to
ZZZ respectively and the series of numbers 900 to 999 are available.
These code elements are at the disposal of users who need to add
further names of countries, territories or other geographical entities
to their in-house application of ISO 3166-1."
Source: http://www.iso.org/iso/customizing_iso_3166-1.htm,
linked to from
http://www.iso.org/iso/support/country_codes/iso_3166_code_lists/iso-3166-1_decoding_table.htm
When ICANN proposed "two characters", terrain the authors of rfc2929
went over in 2000, I wrote pointing out that it was proposing to
expand the number of reserved code points from 676 code elements to
1296 code elements. While some prudence concerning the scale
limitations of the current iso3166/MA's allocation model and the size
of jurisdictionally, geographically, or economically distinct entities
and regional intellectual property associations provided allocations
is reasonable, the history of changes by the iso3166/MA does not
suggest that it needs to be protectively anticipated by a step-change
doubling of its allocatable values.
"ICANN predicts breakups of most major countries" or "ICANN to
recognize Indian Nations", and I'm particularly fond of the latter and
look forward to the film at 11, could explain this sudden solicitude
towards an apparently insufficiently future-aware iso3166/MA, but I
suspect that is not the actual motivation.
To preclude the AA, QM to QZ, XA to XZ, and ZZ, and the series AAA to
AAZ, QMA to QZZ, XAA to XZZ, and ZZA to ZZZ respectively and the
series of numbers 900 to 999 range, from their intended use as user
defined (and here "user" is the applications which are aware of the
use made of an identifier, hence, applications which use the content
of the IANA root zone) code points, unique within an application
domain (the IANA root zone), is a peculiar kind of clarification.
I'm fine with ICANN Board deciding that "xxx" is not a valid gTLD
label, or that "4u" is not a valid gTLD label, or whatever. However,
the claims of technical necessity can be independent of the policy
goals of such bodies, and probably should be.
Personally I'm as indifferent to the "will break" claim for inet_* as
I was to the claim of brokenness for sizeof(tld) > 4, and for "can't
work in China" for various bits of the IDN/IDNA chain of deliverables.
The resolution, external to authorized users, of mappings in the .mil
and subordinate zones, is optional, not mandatory. The resolution of
mappings in the .中国 zone, from November 2001 to the very recent
present, by resolvers external to the region, was optional, not
mandatory. The resolution of stupid-domain-name.257 is as optional,
and the continued operation of IDN-unaware operating system product,
or IMP-aware operating system product, decades after their technical
obsolescence, as door stops and space heaters and print servers is
appropriate use.
I don't see the compelling rational for this draft by a standards
body, and I'm unmoved by the non-standards representations of utility
and necessity.
I'm also unmoved by the representations of utility and necessity for
v6 and DNSSEC as a mandatory to implement features of new gTLD
operators, and no others.
My two beads worth,
Eric
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
