Re: Layer 2 and "idn identities" (was: Re: [idn] what are the IDN identifiers?)

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

0. Citing the IDN working group as a reference that defines "[t]he client
   side of IDN" is unclear. Is this a reference to the charter?

1. The document cited, "Requirements of Internationalized Domain Names",
   draft-ietf-idn-requirements, Zita Wenzel and James Seng, editors, is
   technically inconsnstent. Cited for nameprep, which could have been
   cited directly.

2. Concerning language tags, the subject of rfc1766, and its sequelae, for a
   work in progress, I've the following fragment to share:

   X. IANA Language Tags
   .in 3
   .sp
   RFC 1766 created a boutique for language tags of obscure utility.      
   For several years the IANA's "consideration" was limited to some
   variations of Norwegian, and relevent here, a tag for Dine', and
   for Mingo.
   .sp
   The tag for Dine' ("i-navajo") was submitted by Sean Burke on
   19 September 1997.
   It cited an "academic" source (non-indian, non-Dine') as the authority
   for Dine'. The Navajo Nation Agency Network Project registered "navajo.org"
   on 5 May 1997, and teaching Dine' langauge and culture in Navajo schools
   has been Navajo Nation policy since 1984, and the Navajo Nation produces
   K-12 and adult-learner langauge materials.
   .sp
   ...

   The point I'll eventually get around to making is that the "i-navajo" tag
   is bogus, and modernly, the repository and IANA consideration created by
   1766 is chock-a-block with tags for sign languages. Now I do think that it
   is possible to have useful repositories of somethings at IANA, just that
   this isn't it, at least not presently.

   You may also want to contemplate Appendix B of [Alphabet] (your cite) and
   the current set of i-tags in the IANA repository, for ... consistency.

3. Concerning language codes, the subject of iso639, and its sequelae, for a
   work in progress, I've the following fragment to share:

   ...
   .sp
   Modernly, the United States Library of Congress is the
   ISO 639-2 Registration Authority, and retains the general "one language
   per reservation" rule, indifferent to the Oklahoma and larger Pan-Indian
   experiences, the Termination Period, and the Coastal and Boarder Treaty
   problem populations.
   No American public institution, the LOC included, has systematically
   published indian language K-12 or adult-lerner literacy materials in the
   19th or 20th century.
   The practice of private evangelical institutional contributions
   to systemic indigenous literacy ended in the early 20th century.
   .sp
   ...

   The point I'll eventually get around to making is that the iso639 codes
   that pertain to National Languages in the Americas are also bogus, and
   modernly, the LOC allocation table is chock-a-block with codes that no
   First Nations or Indian Nations government has approved (or in fact been
   substantively consulted upon).

4. Author's Disclaimer is unnecessary in any working group document, as the
   editor will remove any encumberences. Should your document be adopted by
   any group operating under 2026 process, you may want to consider providing
   more explicit guidance to your editor.

   You may want to discuss http://www.imc.org/idn/mail-archive/msg02517.html

5. Compatibility with ASCII. Please note that SJIS and ASCII "collide" on two
   code points. This property is not restricted to SJIS, and exists in several
   "local standards".

   Personally, I prefer "National Standards", as the ASCII we refer to is the
   product of a US national body, originally the ASA (American Standards
   Association), subsequently ANSI (American National Standards Institute).

   Note: code point allocations for characters used for Spanish, and also for
   Dine' (Navajo), as well as other American Indian scripts that acquired
   their modern form prior to 1940 are not present in any ASA/ANSI product.
   Compare, UCAS [1] proposed by the CSA (Canadian Standards Association).

   However, if you wish to use an agency-less language, and refer to these
   as author-less "local standards", that is a matter of taste.

6. Symbols.

   There is no more use for "Symbols" in the DNS, than for cymbals.

7. The cite for "Alphabet" is either incorrect, or the http reference is
   obsoleted, or both.

There is a heck of a lot of unnecessary stuff to parse through to get to
what may be a locale model of character encoding.

Having created a "code-set independent" architecture at Sun, contemporanious
with Gary Miller's CSI work at IBM, in which a UTF-8 locale provides a base
from which to provide code-set dependent services, I'd like to see your basic
proposal unencumbered by all the pseudo-formal-esse.

> Since nobody disbute with me, I take it as we are agree to
> the above discussion.   I'd like to refer to my  I-D 
> draft-liana-idn-map-00.txt  for more discussion in this direction. 

Nope and See Above.

Eric

[1] Report on the Native Language Communications Survey, Government of Canada,
    DOC 1989".