Message-Id: <6.2.3.4.2.20050910103755.03d13230@mail.afrac.org>
Date: Sun, 11 Sep 2005 02:34:19 +0200
To: "Randy Presuhn" <randy_presuhn@mindspring.com>, <ltru@ietf.org>
From: r&d afrac <rd@afrac.org>
Subject: Re: [Ltru] Re: Last call comments on LTRU registry and
	initialization documents (issue #878)
In-Reply-To: <005201c5b5c9$efe5dcc0$7f1afea9@oemcomputer>
References: <DE3D67514661E20ADB65F357@scan.jck.com>
	<tslu0gy101q.fsf@cz.mit.edu>
	<EFAFFC7D681AFA7F592E18AF@scan.jck.com>
	<tslll29c2nn.fsf@cz.mit.edu>
	<02BD58E66D8134A92F365882@scan.jck.com>
	<013101c5b550$313fc0c0$030aa8c0@DEWELL>
	<A15B4A4A37BA33067DEEC69C@scan.jck.com>
	<20050910021615.GK7608@NYCMJCOWA2>
	<005201c5b5c9$efe5dcc0$7f1afea9@oemcomputer>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: iesg@ietf.org, ietf@ietf.org
Precedence: list
Sender: ltru-bounces@ietf.org
Errors-To: ltru-bounces@ietf.org

We eventually reach the mission assigned by the Charter: the real 
IANA registry. And we considering some of the key points:

1. is the directory to be published as an RFC?
2. is it or not to document the subtags ISO aliases?
3. is it to respect the Charter and the IESG authority in being 
reviewed by ietf-languages@alvestrand.no and approved by its IESG 
designated reviewer?
4. what is its expected growth? Should it be contained in size? Is it 
informative or normative?
5. what is its practical purpose, in term of user applications? How 
is it expected to be used?
6. what is its dissemination system?
7. who is going to insure that this system is sure, secure, stable 
and who will bear the cost of it?

I am opposed that my approach is not in operations (cf. John): 
AFRAC's role is to consider the various propositions and to test the 
most appropriate ones for its own mission of a reference center. From 
this (a) we know the main Draft proposition is very limited and 
dangerous, (b) we know there are others possible propositions, with 
their own con and pros (Addison explained he had one), (c) we observe 
they should be correctly be supported by IRI-tags with  RFC 3066 bis 
as a default with no other change than to add one sentence: "0- 
introduces an URI/IRI tag which conforms RFC [URI-tags]"]).

Going further without first a consensus on the target of the WG 
(addressing user needs like ours vs. imposing on us an unique limited 
solution) would only create confusion. Competition, as begged from us 
by Addison, between standardisers and users is never good.

Now these simple, practical questions are put in front of the IESG. 
IESG will turn me right or wrong. If they can think of a way to 
deliver, with non limited and non constrained internationalisation 
options, along with the proposed registry: no one will be more happy 
than me. Otherwise the Internet standard process still gives chances 
to a thinking maturation process, through IETF/IAB and external appeals.

To help that thinking we may have to stabilise and deploy a 
grassroots project. But I am afraid then to trigger other projects by 
industry leaders and Govs. They will see there a way to block a 
Internet possible control and a way to obtain parts of it. But the 
constant disregard of our needs as a user of the deliverable may 
eventually push us to do that.

1. is it to be published as an RFC?

     As an RFC it is the same base for all the common reference 
centers, existing and to come, IANA or not. It preserves a point of 
consensus. It permits RFC "bis", "ter" etc. to accompany ISO, usage 
and RFC 3066nths evolution.

2. is it or not to document the subtags ISO aliases?

     No to do so would underline the motivation of exclusiveness. 
This would only add to confusion: users will see that registry as an 
hybrid registry, randomly (on their opinion) using variable format 
elements from ISO 639-1,2,3,5,6, from ISO 3166 and UN, from its own, 
with no documented relation with the ISO codes they use in their 
other applications. Search engines and Gov systems will align on ISO 
11179 works and on ISO 639-4 guidelines. In defending for ever the 
RFC 3066 errors, instead of correcting them progressively, what do we 
want to do?

    This is IETF, not a WTO arbitration.

3. is to respect the Charter and the IESG authority in being approved 
by ietf-languages@alvestrand.no and its reviewer

    I documented the need and the courtesy to have Michael Everson 
and ietf-languages@alvestrand.no to review and approve the soundness 
and the consistency of the proposed registry content. It also 
underline the script orientation of the Draft.

4. what is its expected growth? Should it be contained in size? Is it 
informative or normative?

    John documented the IETF/RFC's related difficulties if the 
parameter registry goes large (I do not know if there is another 
registry which can expand to 40.000 items?).

5. what is its practical purpose, in term of user applications? How 
is it expected to be used?

    This point is still pending.

6. what is its dissemination system?

    This point is still pending - it will result from the above.The 
only indication I got so far is "like Unicode". I indicated the 
system we advocate.

7. who is going to insure that this system is sustained and who will 
bear the cost if it?

    I know this is not a main IETF concern. I submit it is because 
the IANAI registries are usually not that size and do not risk to be 
accessed by the XML applications by billions?

jfc

At 07:38 10/09/2005, Randy Presuhn wrote:
>Hi -
>
> > From: "John.Cowan" <jcowan@reutershealth.com>
> > To: "John C Klensin" <john-ietf@jck.com>
> > Cc: <ltru@ietf.org>; <iesg@ietf.org>; <ietf@ietf.org>
> > Sent: Friday, September 09, 2005 7:16 PM
> > Subject: Re: [Ltru] Re: Last call comments on LTRU registry and 
> initializationdocuments
> >
> > John C Klensin scripsit:
> >
> > > So, all I was suggesting wrt the text of the "initial" document
> > > is that, when the IESG concluded that it had reached community
> > > consensus, two things should happen:
> > >
> > > (1) The IESG instructs IANA to create the registry,
> > > populating it with the elements as instructed in the
> > > Internet-Draft  and using the formats specified there
> > > and in the "registry" I-D.
> >
> > I think that's what we had in mind.
> >
> > > (2) The document is passed to the RFC Editor for
> > > publication,
> >
> > It's not clear to me what the point of publishing it as an RFC is,
> > and in fact if an explicit decision to that effect has been made,
> > it went past me entirely.
> >
> > IMHO after initial-registry has served its purpose, it should be
> > allowed to time out and die.
>...
>
>(As ltru co-chair)
>
>Those who follow the ltru WG mailing list closely will recall that
>there were two distinct issues recorded in the issue tracker:
>(at https://rt.psg.com/ user and password are "ietf")
>#875 should initial registry contents be made into an internet-draft?
>#878 should the initial registry contents i-d be published as an RFC?
>
>There was a rough consensus in support of #875, but the discussion
>of #878 was inconclusive.   We asked our AD whether he had any
>preference with respect to #878, and he indicated a preference for
>publication as an (informational) RFC.
>
>That is how we got to where we are today.
>
>The decision on #875 (initial registry as i-d) has in retrospect proven
>to be a good one, in my personal opinion.
>
>Regarding issue #878, I think we've all looked at it as just a matter of how
>to work the process to get the right stuff into the registry.  The working
>group has been quite clear in wanting to ensure that the initial registry
>is not mistaken for the registry itself, and was never enthusiastic about
>publishing it as an RFC.
>
>Consequently, I do not think that it would be a big problem if the
>IESG were to tell the ltru WG that we don't need to publish the initial
>registry i-d as an RFC, or if the WG, reconsidering issue #878 as a
>result of the IETF last call comments were to reach a consensus to
>withdraw the publication request, as long as we have some assurance
>that the registry will be end up with the right stuff.
>
>Sure, we would have wasted a lot of energy getting the initial registry i-d
>RFC-ready, but the important thing is to initialize the registry.  Process
>is a tool, not an end in itself, and the result we are interested in is
>getting the updated registry going, not publishing a history of its
>initialization, as interesting as that might be.
>
>The only problem I see is that the registry draft,
>http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt,
>currently references the initial registry i-d in multiple places; we'd need
>someone to provide the correct incantation to make the right thing
>happen.  I can hardly imagine that a document (whether BCP
>or some kind of Standard-to-be) would be permitted to reference
>(even informatively) an i-d never intended for publication.
>Please send suggested text.
>
>Although my personal preference would be to publish the i-d
>http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-04.txt
>as an Informational RFC, ideally marked "Historic" from
>the first day it appears, I do not object to non-RFC alternatives
>that let us accomplish the initialization, as long as we keep the
>initialization data out of any container that would cause it to be
>mistaken for the registry itself.
>
>Randy, ltru co-chair
>
>
>
>
>_______________________________________________
>Ltru mailing list
>Ltru@ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru


_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru