Subject: Re: [Ltru] Registry homepage (was: "Obsolete" region subtags)

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 18 Mar 2005 16:22:19 +0100

On 07:13 18/03/2005, Randy Presuhn said:
>Hi -
> > JFC (Jefsey) Morfin wrote:
> > > why do you want to use the IANA?
> >
> > I'm not exactly sure why, but at the moment I trust that they
> > try to work for some common good.  I never had any problems
> > with ICANN, quite the contrary, I like their WDPRS among other
> > things.  That's all off topic here, let's stick to the facts,
> > at the moment IANA hosts all registries related to RfCs.
>
>There's a simpler answer.  Our charter says that this WG is to
>"describe the structure of the IANA registry."  Alternatives are
>outside the scope of this working group.
>
>Please, let's focus this energy on the work we were chartered to do.

Cool ...

Dont' you agree that our job is to discuss an answer to a charter which 
only assigns us to define the "structure of the IANA registry"? An 
XML/ASN.1 structure.

When IESG does that it is because they want to be very restrictive or not 
to limit the scope of the debate. My reading is the second one due to the 
charter last paragraph which implies that we have to revamp of the review 
process. Many other important questions are not listed. How to define the 
technical role of the IANA in area? Will it be a repository, a 
clearinghouse, a registry. Will it act as only a web pages, as a 
"whatidiom" web service, as an FTP server? How is it to be organized? What 
is the contingency plan if it changes (this has to do with the adressing of 
the bases which can be hard coded in millions of programs), the NIC changed 
a few time since it was created. etc.

The first question to consider is what is this structure in that registry 
going to do for who. There are three classes of people involved:

- those who manage the structure - IANA with an important backlog (if Frank 
is correct): question is why? How can our solution help? And there are many 
technical solutions to that I am surprised no one considers.

- those who fill the data into the structure (among who is Frank, with 
seemingly some feelings and misunderstandings). It is important to 
determine the procedure, the guidance, etc. soi they feel at ease and 
motivated. Some are voluntaries, some are employees of organizations with 
social, cultural, religious or commercial interests, some are civil 
servants. Some are linguists, some are network people. We need to keep a 
balance in the best common interest. Frank is in that sense a good 
representative of possible feelings (good or bad) we must take into 
account. Another aspect is the role of the ietf-language list and of its 
procedures which is depend on all of this.

- those who will use it. I represent some of them.

All together we need something which will work.

jfc

=====================================================
For your convenience:
Draft: 	http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-00.txt
Charter: http://ietf.org/html.charters/ltru-charter.html
gmane: http://dir.gmane.org/gmane.ietf.ltru
If you were Bcced for information and not familliar with the IETF process:
http://www.ietf.org/rfc/rfc2026.txt
http://www.ietf.org/rfc/rfc2418.txt
http://www.ietf.org/rfc/rfc3934.txt
http://www.ietf.org/rfc/rfc3669.txt
http://www.ietf.org/rfc/rfc3160.txt
http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt
=====================================================
Jon Postel (RFC 1591): "The IANA is not in the business of deciding
what is and what is not a country. The selection of the ISO 3166 list
  as a basis for country code top-level domain names was made with
  the knowledge that ISO has a procedure for determining which
entities should be and should not be on that list."
=====================================================
Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the
same thing, choose one. If a previous design, in the Internet context
or elsewhere, has successfully solved the same problem, choose the
same solution unless there is a good technical reason not to.
Duplication of the same protocol functionality should be avoided as far as
possible, without of course using this argument to reject improvements."
=====================================================
It seems that what works for countries and ISO 3166 since 1978 should
apply to languages and to ISO 693.
=====================================================

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru