Message-Id: <6.1.2.0.2.20050128115946.0413e290@mail.jefsey.com>
Date: Fri, 28 Jan 2005 13:54:53 +0100
To: "Doug Ewell" <dewell@adelphia.net>,
	<ietf-languages@alvestrand.no>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
In-Reply-To: <00b301c50507$020c5600$030aa8c0@DEWELL>
References: <20050128001251.06C3F62250@eikenes.alvestrand.no>
	<00b301c50507$020c5600$030aa8c0@DEWELL>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-56F13C93
Cc: iesg@iesg.org
Subject: IANA registration issues not covered by the "RFC 3066bis" draft
Precedence: list
Sender: ietf-languages-bounces@alvestrand.no
Errors-To: ietf-languages-bounces@alvestrand.no

Dear Doug,
thank you for your detailed responses.

At 08:00 28/01/2005, Doug Ewell wrote:
>JFC (Jefsey) Morfin <jefsey at jefsey dot com> wrote:
> >> Read RFC 3066.
> >
> > I found nothing about Registrar (word does not exist there). I found
> > nothing about his designation process. The duration of his term. His
> > duties. The procedure of appeal, etc. A Registrar is a IANA/ICANN
> > function to manage a Registry, ie with the capacity to register. What
> > is documented in the RFC 3066 is a "reviewer" with a capacity to not
> > register. That Reviewer is also not documented, except as designated
> > by the Applications Area Director what rise many problems since there
> > are two of them.
>
>Oh, I see.  Your original question was intended to expose the fact that
>a person called a Reviewer actually performs registration functions.
>You could have just come out and said so.

No. I did not want to expose, just asking how these functions are de 
facto/contractually organized. As you know ICANN is a no member Californian 
corporation set-up by Jon Postel, Joe Sims and others to replace Jon Postel 
personal involvement (in a similar way IETF is organizing the IASA to 
replace Bob Khan). This organization has contracted the management of the 
IANA functions with the US Government 
http://www.icann.org/general/iana-contract-09feb00.htm . There are two well 
known constraints on this contract:

- this contract is uncertain http://www.gao.gov/new.items/og00033r.pdf 
according to the US GAO (General Accounting Office) as the only rights of 
the USG comes from its interest in developing the US domestic and foreign 
communications and commerce, not in governing the world digital system.
- the US Government has published its intent not to renew this contract. 
For a certain time ICANN (in opposition to the RFC 2860 which defines the 
technical work expected from ICANN by the IETF) presents the IANA as an 
ICANN integrated function.

In addition, the work I personally carry for several years (in accordance 
with the ICANN ICP-3 document) shows that the evolution of the market 
understanding of the Internet architecture comes back to a digital space 
user centric vision, shadowed by the OSI/Internet episode and. This 
evolution is also demanded for risk containment reasons by businesses and 
States and can be summarized into a transition from an Internet under ICANN 
dominance (with a single IANA occurrence) towards a totally open Internet: 
this is what ICP-3 called experimentation about, the IETF has not 
considered yet. Our own work show that we can avoid a balkanization of the 
Internet through a third solution (neither an ICANN dominance, nor ITU 
supported fragmentation) through the intergovernance of an authoritative 
set of matrices, organized by a granularity of reference centers managed in 
subsidiarity.

These contractual, uncertain future and architectural evolution, calls for 
the IANA functions to be kept independent and extremely clear as per RFC 
2860, ftp://ftp.rfc-editor.org/in-notes/rfc2860.txt, that is under the 
control of IESG and not under the control of the ICANN BoD (except the IP 
addresses and Domain Names as agreed in RFC 2860 4.3).

RFC 3066 creates the function of Reviewer but does not defines properly its 
designation, removal, appeal process. The ICANN management of IANA makes 
the ICANN procedures to apply in terms of IANA Manager, Registrars, 
appeals, etc. However long terms IANA organization. (it seems we both agree 
on the definition of the Registrar and Reviewer roles).

>Probably there was an understanding that the business of reviewing and
>registering language tags was a non-controversial one.  It certainly has
>been for the last ten years, with a handful of exceptions.

True. As I noted it, the registration was "for information" and carried by 
a non IETF list. This would be changed by the Draft-Phillips- etc. This 
aspect has not been covered. The Reviewer function should be better defined 
and the IANA's role, rights, appeal procedures  etc. should be described.

>Remember that the positions of ISO 15924 Registrar (which Mark Davis was
>referring to) and RFC 3066 Language Tag Reviewer are not the same
>position.  It happens that they are both filled by the same individual.

True. But Michael Everson is actually carrying three tasks:
- Reviewer on behalf or IETF as designated by one Application AD (as per 
RFC 3066) or both? Assisted by a non-IETF list?
- Registrar of ISO 15924 - what is out of IETF scope
- Registrar for IANA - as per a IANA page I do not find back right now 
(sorry, but the IANA is a mess not a menu)

This last function falls into the RFC 2860 field and should be discussed 
and defined in the Draft.

> > This function was of low importance as long as registrationswere not
> > mandatory. It will be a key or even "the" key IANA function, as
> > appeals and conflicts will most probably rise on language
> > regsitrations with powerful and decided interest being at stake (cf.
> > .PL/MINC issue), should the Draft be accepted as a BCP. My question is
> > therefore very important.
>
>The Language Subtag Reviewer in RFC 3066bis has three jobs related to
>language subtags:
>
>1.  When ISO 639 adds a new language code, add the corresponding
>language subtag to the Registry.  This is clerical and
>non-controversial.
>
>2.  When ISO 639 changes the code for a language, add the new code as an
>alias for the old code.  This is also clerical and non-controversial, so
>long as ISO 639/RA doesn't reuse codes.
>
>3.  When someone submits a request to register a language tag (4 to 8
>letters), that request must be scrutinized carefully before
>registration.  Unlike (1) and (2) above, this requires a lot of thought
>and discussion and may be highly controversial.  The draft makes it
>clear that such registrations are discouraged.

I am not referring to this. I am referring to the registration of the 
documentation of a language tag through a single document, book or authority.

>The ".PL/MINC issue" has nothing whatsoever to do with whether 'ar' is a
>valid language code or whether 'PL' is a valid country code.  Neither
>the draft, nor RFC 3066 nor RFC 1766 before it, makes any judgment about
>whether "ar-PL" is an appropriate language tag.  Anything else related
>to the ".PL/MINC issue" is out of the scope of language tags.  This has
>been explained to you before.

I am afraid you will never understand this as a tag designer while I am a 
tag user. In missing the style and authority fields your tag does not 
permit the real needs of the words to be documented, leading to conflicts. 
Your tag does not scale and is therefore inadequate to real life and 
violating RFC 1958.

But this is another issue. Thank you for the input. I will use it to 
document the problems ahead and the ways to solve them in good consistency 
with the other problems created by the quick coming user centric 3rd 
generation.

jfc


>-Doug Ewell
>  Fullerton, California
>  http://users.adelphia.net/~dewell/
>
>
>_______________________________________________
>Ietf-languages mailing list
>Ietf-languages@alvestrand.no
>http://www.alvestrand.no/mailman/listinfo/ietf-languages

_______________________________________________
Ietf-languages mailing list
Ietf-languages@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages