[dnsext] How DNAME solves the aliasing problem in Unicode for ITU-T/ISO OIDs

[Alfred Hönes <[e-mail]>]

Folks,
I eventually was able to follow up to an ITU-T liaison
statement [1] that Patrick has brought to the attention of
the apps-discuss list [2] shortly before IETF in Maastricht.

You might know that a joint ITU-T / ISO effort has created a new
hierarchical OID system based on Unicode / UTF-8 labels:
ITU-T X.660 | ISO/IEC 9834.  They also have filed with IANA
a provisional 'oid' URI Scheme registration for this system, based
on an I-D [3] not (yet) accepted by the IESG for publication [4].

In the liaison statement, a draft version of ITU-T X.672 has been
provided for comment to the IETF -- it is available from [1].

The draft X.672 specifies a DNS/NAPTR based basic resolution system
("ORS") for OIDs with an extensible set of services, operating in the
".oid-res.org" DNS tree in a similar manner as the reverse DNS trees
for IPv4 and IPv6 are organized.
For the benefit of users (and the cash flow of OID registration
authorities?), the 'new' OID system allows unlimited registering
of aliases at each level of the tree (not even restricted to
'sibling' OIDs in the OID tree).

Therefore, it is interesting to observe how the ITU-T and ISO/IEC
deal with the aliasing problem in the OID system and in the ORS.

Please refer to the above draft recommendation and the references
listed therein for details.

In essence:
The ITU-T recognizes the necessity of primary (canonical) OIDs and
OID labels (and hence, if you want to use these terms, the existence
of "first-class" and "second-class" citizens / OIDs), and they
specify the use of DNAME in the delegating zone and simply prohibit
the necessity for non-structural RRs at such delegation points by
requiring an additional, service-specific label for all
'information-carrying' RRs (NAPTRs, so far, but new ORS applications
might involve other RR types).
(Translated to the HTTP world, the equivalent method would be to
mandate (e.g.) "www." in front of zone names with A/AAAA RRs for
web servers.)
This way, the ITU-T has no need for CNAME+DNAME, BNAME, etc.,
and no provisioning issues!  The resolution system always returns
the RRset at the canonical name.

Transfering this solution to the IDNA TLD and sub-TLD alias
registration problem, the solution would be to perform "delegation"
of all IDNA aliases via DNAME RRs in the 'registrating' zone
(e.g., root zone for TLD aliases) and to mandate the non-use of other,
information-carrying RR types at these "alias delegation points".
Registrants would be recommended to use simple, universal sub-domain
names for such aliased domains, which would not be subject to I18N
and the alias problem; the canonical names' DNS nodes of course would
be allowed to hold any information-carrying RRs.

Observing that ISO/IEC and ITU-T apparently can 'live' with this
method (and do that without an outstanding controversy!), I'm asking
myself why ICANN and the TLD registries would not be able do operate
with such methods.


Kind regards,
  Alfred Hönes.


BTW: I have filed comments on the draft [5], partly DNS related.
     Thus, you don't need to complain about the same issues again.

[1]
 https://datatracker.ietf.org/liaison/903/
[2]
 http://www.IETF.ORG/mail-archive/web/apps-discuss/current/msg01613.html
[3]
 http://tools.IETF.ORG/html/draft-larmouth-oid-iri-04
[4]
 https://datatracker.IETF.ORG/doc/draft-larmouth-oid-iri/
[5]
 http://www.IETF.ORG/mail-archive/web/apps-discuss/current/msg01782.html

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+