Message-Id: <6.2.1.2.2.20050502162405.040e9c50@mail.jefsey.com>
Date: Mon, 02 May 2005 16:24:38 +0200
To: ltru@ietf.org
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: Re: [Ltru] Last registry for now
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: 
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

Dear Doug,
thank you for this effort. You only face the usual problem of a 
decentralised network. When someone starts doing something of common use 
there are two normal reactions:

1. he is the csar (centralized/dominance network syndrom)
2. why does he do it this way (decentralized/democratic network syndrom).

This is because he creates something abnormal in a decentralized network: a 
single point of possible unreliability/dependance. In a distributed network 
it works by subsidiarity. Each is caring for his own destiny and freely 
decides who he trusts and how he organises his own security. When someone 
interferes in the best interest of someone else (as you do) it is not to 
stay/block/stop, it is to transfer and remove oneselve once he has 
permitted others to behave by their own.

What I need (and this is the problem of the whole IANA), is a copy of the 
software generator and a reference to your sources. To be able to run it. 
To verify that I reach the same file as yours in making a diff. There are 
two solutions:

- either the registry is entrusted to the IEFT and maintained/published as 
an RFC and your tool is used to produced the RFC and the check is made by 
the members of the WG who want. The Internet being the adherence to the 
RFC/BPC/STD one can presume most will be satisfied by the IESG final check.

- either the registry is entrusted to the IANA - in a way similar to the 
DNS files. Then there is an urgent need for the description of a stable 
noh-IANA process of verification, maintenance, cross-checks, as the one I 
run for the DNS on a daily basis reaching a real life situation which (for 
a reference file) quite different from the DNS NTI/ICANN root 
(http://nicso.org) I documented several time. CENTR and ccNSO members are 
just now starting anew a review process of the IANA deliverables. When you 
see the dispute over the "CS" case ... I suppose you would be puzzled about 
the IANA management of the ccTLD tables. To do that, we need the stable, 
clear, scalable description (requested by the Charter) about the way the 
Internet addresses the ISO and non-ISO tables variations. This should lead 
to one or several documented codes (practice and codes are the basis for 
IESG approvals) generating the same registry information from the same 
sources. For that your sources must be quoted in your file header (also to 
acknowledge the true authors).

Please provide the trusted URL of the source files you used and the source 
code or the code logic you followed. We inspect them, build our own code 
and generate a copy. We will check it with yours to verify that we both/all 
are right and to understand and correct the possible discrepancies. 
Otherwise we will run it by our own, and if there is a discrepancy we start 
with another unnecessary dispute on sources and concepts.

jfc




On 07:42 02/05/2005, Doug Ewell said:
>When I first mocked up a sample of the proposed Language Subtag Registry
>back in July 2004, based on the description in
>draft-phillips-langtags-04, my intent was to show list members on
>ietf-languages what the registry would look like, and how it would be
>updated to reflect any changes in the core ISO standards or IETF
>registrations.  I hoped it would encourage any necessary questions about
>the format of the registry, the update process, and the subtag mechanism
>itself.  To a great extent, this has been successful.
>
>Unfortunately, it seems that to an even greater extent, the continual
>updating of the sample registry has become a distraction from the
>overall process of evaluating the draft, and moving it toward the Last
>Call that is scheduled for this month.  This has become especially true
>in regard to discussions that focus on the exact contents of the
>registry and on decisions to exclude (or include) certain "useless" or
>"stupid" subtags, usually region subtags.
>
>It seems that by updating the contents of the registry so frequently --
>about 30 times since July -- I have been a major contributor to this
>distraction.
>
>Additionally, my role in trying to maintain a draft registry has become
>badly misunderstood.  I am not some kind of Registry Czar who imposes
>his personal will on which subtags "should" and "should not" be valid.
>I make only those changes that seem to have consensus within the group
>or seem uncontroversial.  I have never tried to effect changes in the
>draft by going through the "back door" of the registry.  Unfortunately,
>some recent posts to the effect that "maybe Doug can do this or that"
>imply that the draft is (or should be) controlled by the registry, not
>the other way around.  This is not good.
>
>It would be perfectly possible for WG members to visualize how the
>"live" registry will look and behave, and use that information to
>evaluate the draft, without constant and distracting changes in the
>content of the sample registry.
>
>Section 3.7 of draft-01 explains how the initial registry will be
>constructed from the core ISO standards and the existing Language Tag
>Registry, and how it will be updated.  In particular, it states that the
>initial registry will be submitted for a Last Call of its own.  That is
>the time when group members should focus on fine-tuning the registry,
>not now.
>
>Consequently, I have uploaded a new sample registry, dated 2005-04-30,
>to the usual URL:
>
>http://users.adelphia.net/~dewell/lstreg.txt
>
>Barring any further architectural changes to the registry, this will be
>the LAST registry update I will make until the draft passes Last Call.
>"Architectural changes" would include things like new fields, changes in
>field names, or a change in the overall format of the registry.  To
>demonstrate this, the current version makes *only* the following changes
>over the previous version, dated 2005-04-19:
>
>1.  The "%%" lines at the start and end of the file are dropped.
>
>2.  Underscores in field names are replaced by hyphens.  For example,
>"File_Date" is changed to "File-Date".
>
>3.  Descriptions are copied exactly from the ISO standards, including
>any non-Latin-1 characters.
>
>Note that none of the content changes we have been discussing lately
>(e.g. tweaks to Suppress-Script entries and UN macrogeographical codes)
>are incorporated.  This is intentional, because including these changes
>would only start another round of registry fine-tuning threads and would
>push the draft document even farther away from completion.  If any list
>members feel (as I do) that some or all of these content changes should
>be incorporated in the initial registry, the time to discuss this is
>after the draft is approved, during the registry Last Call.
>
>In the meantime, let's focus on getting any remaining issues resolved in
>draft-01, and moving it toward Last Call, because if that doesn't
>happen, the registry won't matter one bit.
>
>--
>Doug Ewell
>Fullerton, California
>http://users.adelphia.net/~dewell/
>
>
>
>_______________________________________________
>Ltru mailing list
>Ltru@lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru