Return-Path: Received: from eikenes.alvestrand.no ([unix socket]) by eikenes.alvestrand.no (Cyrus v2.1.11-Mandrake-RPM-2.1.11-1mdk) with LMTP; Fri, 18 Mar 2005 16:23:59 +0100 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B5E4961C0D for ; Fri, 18 Mar 2005 16:23:59 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25154-08 for ; Fri, 18 Mar 2005 16:23:56 +0100 (CET) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id BF63461BE5 for ; Fri, 18 Mar 2005 16:23:55 +0100 (CET) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCJIx-0007RI-86; Fri, 18 Mar 2005 10:22:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCJIv-0007RC-Hq for ltru@megatron.ietf.org; Fri, 18 Mar 2005 10:22:26 -0500 Received: from montage.altserver.com ([63.247.76.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16970 for ; Fri, 18 Mar 2005 10:22:20 -0500 (EST) Received: from lns-p19-19-idf-82-249-5-14.adsl.proxad.net ([82.249.5.14] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DCJIr-0000qd-BO for ltru@lists.ietf.org; Fri, 18 Mar 2005 07:22:22 -0800 Message-Id: <6.1.2.0.2.20050318162045.03657eb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 18 Mar 2005 16:22:19 +0100 To: "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Registry homepage (was: "Obsolete" region subtags) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - lists.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org X-Virus-Scanned: by amavisd-new at alvestrand.no 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 Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru