Subject: RE: [Ltru] Re: Update to proposed registry

From: "Addison Phillips" <[email-masked]>
Date: Sun, 13 Mar 2005 12:22:30 -0800

I think that what Frank is suggesting below is documenting the *content* of the registry, as distinct from the registry itself.

Based on our experience to date, my suggestions would be:

1. Appoint Doug as the official editor of the draft registry (assuming he is willing to continue).

2. NOT make the draft registry into a version controlled document until the IESG approves the registry draft. Changes in the registry draft have an effect on the format and contents of the registry itself. Save doing version control on the document until its own approval process starts.

3. DO figure out how to do it under the auspices of the IETF and RFC 2616 (if applicable) or in line with what others have done (if not).

4. DO discuss the rules for appropriate content, etc. To the extent possible, these should be embodied in the registry draft, of which the prototype registry should be (and currently *is*) a reflection. Think of the prototype registry as an expression of those rules useful in debating the finer grained rules.

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Frank Ellermann
> Sent: Saturday, March 12, 2005 1:29 PM
> To: [email-masked]
> Subject: [Ltru] Re: Update to proposed registry
> 
> Randy Presuhn wrote:
> 
>  [http://users.adelphia.net/~dewell/lstreg.txt]
> > Would it make sense to make this into a working group i-d?
> 
> Yes, please.
> Same procedure as with RfC 3864 and draft-klyne-hdrreg-mail-05.
> 
> Unfortunately IANA used this nice document listing all header
> fields to be defined in [RFC-klyne-hdrreg-mail-05], which is
> not exactly what RfC 3864 wanted.  But for new header fields
> defined after RfC 3864 it works, e.g. Solicitation [RFC3865].
> 
> > it would be nice to be able to give IANA something that had
> > been under WG change control
> 
> I tried to convince IANA that i-klingon should be marked as
> "deprecated, use tlh", but so far that had no effect.  Maybe
> using the generic registry update Web form was a bad idea (?)
> 
> > the format of the entries would be hard to reconcile with
> > the constraints on i-ds.  Many of the lines exceed
> > 72 characters.
> 
> Maybe something like this is possible with xml2rfc:
> 
> Column 1 goes to the scetion title, it would be redundant in
> the I-D lines.  One section "region", one "language", etc.
> 
> Columns 2 and 4 (subtag and date) always exist, that could be
> the first line of each entry.  Column 5 (canonical value) also
> fits into the first line.  Column 3 and 6 could go into the
> second line for each entry.  Some style of list in xml2rfc
> could probably handle this.  That strategy would work for the
> worst case (longest line) grandfathered | zh-min-nan | etc.
> 
>                           Bye, Frank
> 
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

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

---

From: Martin Duerst <[email-masked]>
Date: Mon, 14 Mar 2005 07:33:04 +0900

Hello Addison, others,

At 05:22 05/03/14, Addison Phillips wrote:
 >I think that what Frank is suggesting below is documenting the *content* of
 >the registry, as distinct from the registry itself.
 >

With my chairs hat on, but only asking, not appointing:
Doug, would you be willing to edit the draft registry for the LTRU WG?
Would you volunteer to turn that into an internet-draft if that's what
we decide needs to be done?

 >2. NOT make the draft registry into a version controlled document until the
 >IESG approves the registry draft. Changes in the registry draft have an
 >effect on the format and contents of the registry itself. Save doing
 >version control on the document until its own approval process starts.

With my chairs hat off:

Are you suggesting that we publish the draft registry as an internet
draft (which we might call draft-ietf-ltru-initial or draft-ietf-ltru-populate),
but we only publish the -00.txt version when draft-ietf-ltru-registry
has been approved?

In general, developping things in sync seems a better idea. I.e. if
we would do it as an internet draft, the ideal would be that
draft-ietf-ltru-initial would be published just a day or two after
each publication of draft-ietf-ltru-registry.

 >3. DO figure out how to do it under the auspices of the IETF and RFC 2616
 >(if applicable) or in line with what others have done (if not).

With my chairs hat on:

I don't think there is any question about the fact that this should
be done under the auspices of the IETF. But we have to find out what
that means, and how it can be done best.

Chairs hat off again.

 >4. DO discuss the rules for appropriate content, etc. To the extent
 >possible, these should be embodied in the registry draft, of which the
 >prototype registry should be (and currently *is*) a reflection. Think of
 >the prototype registry as an expression of those rules useful in debating
 >the finer grained rules.

 >> > been under WG change control

I agree. For those not too familliar with IANA, it is also important
to say that IANA prefers very clear rules that allow them to work
in a purely secretarial function, without having to make any
judgement decisions on matter they may not understand anyway.

 >> worst case (longest line) grandfathered | zh-min-nan | etc.

Would that mean that we would change the registry format, or
would that I-D come with detailled instructions of how to reconstruct
the current registry format from the I-D, or would this mean that
we change the format?

Also, I have heard that this has been considered, but would
a rather different approach to a registry format (e.g. using
XML) make it easier to put the initial registry data into an
I-D and back? Can we move to an XML format without making
things too complicated?

Regards,    Martin.

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 13 Mar 2005 15:10:30 -0800

> Doug, would you be willing to edit the draft registry for the LTRU WG?

Certainly.

> we decide needs to be done?

If that's what you decide.  But if that involves changing the format of
the registry to make it fit into 72-character lines, we need to discuss
that first.  One of the existing descriptions is 94 characters long *just
by itself*.

>> 2. NOT make the draft registry into a version controlled document
>> until the IESG approves the registry draft. Changes in the registry
>> draft have an effect on the format and contents of the registry
>> itself. Save doing version control on the document until its own
>> approval process starts.
>
> With my chairs hat off:
>
> draft (which we might call draft-ietf-ltru-initial or draft-ietf-ltru-
> populate), but we only publish the -00.txt version when draft-ietf-
> ltru-registry has been approved?
>

I agree with Addison.  Appendix C says that the "real" proposed registry
is created (converted) only *after* the draft is approved.  However,
certain items within the current proposed registry have generated as much
controversy as the draft itself, so we need to continue developing it in
parallel with the draft.  But that may not mean it needs to be under
change control yet.  The registry does have its own Last Call period.

> judgement decisions on matter they may not understand anyway.

Can't fault them for that.  :-)

>>> ...

We need to decide this first, before suggesting particular tools.

> I-D and back? Can we move to an XML format without making

I could certainly convert it to XML with no problem.  Whether that is the
format we want is another question, and needs to be discussed.

-Doug Ewell
 Fullerton, California
 http://users.adelphia.net/~dewell/

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 14 Mar 2005 01:06:48 +0100

Martin Duerst wrote:

> Would that mean that we would change the registry format

Not necessarily.  With your hat on you could decree that
Doug is an ISO or W3C liaison, and maybe then it's possible
to use a more flexible format than "I-D" for his registry.

> would that I-D come with detailled instructions of how to
> reconstruct the current registry format from the I-D

As you said IANA is probably not interested to read the RfC
only to create its own "xml2registry" script.  Another idea:

Just use the registry as is accepting the horrible I-D line
wraps in the plain text version, xml2rfc can also create
HTML, and that should be readable.

Actually I'm more interested to have some format, whatever it
is, then pretend that 3066bis existed 1990 or earlier, prove
that some resulting regional tags would be plain nonsense
today, and then really _think_ about this part in the draft.

                Bye, Frank

---

From: Martin Duerst <[email-masked]>
Date: Mon, 14 Mar 2005 15:06:17 +0900

At 09:06 05/03/14, Frank Ellermann wrote:
 >Doug is an ISO or W3C liaison,

[with several hats on]

A liaison always needs two sides. I have some hats on the
W3C side, but I don't think I'd want to use them for that.
While W3C is an important customer of IETF language tags,
the IETF is in charge, and it would feel really weird to
have something like "IETF approves new spec for language
tag registry; initial registry data provided by W3C".

Regards,    Martin.