Subject: [Ltru] Update to proposed registry

From: "Doug Ewell" <[email-masked]>
Date: Sat, 12 Mar 2005 11:21:44 -0800

Addison and Mark's new draft contains an important change: grandfathered
tags are allowed to have a canonical value.  This means grandfathered
tags can be formally deprecated, not just marked with a comment.  This
is a change we've talked about for some time.  The wording is still a
bit inconsistent, but I expect that will be cleared up soon.

Accordingly, I've updated the proposed draft registry available at:

http://users.adelphia.net/~dewell/lstreg.html
http://users.adelphia.net/~dewell/lstreg.txt

to add canonical values to all the grandfathered tags that were
previously commented as "deprecated."  This update also removes the
variant subtag 'lojban' and changes the status of "art-lojban" from
redundant to grandfathered (with a canonical value of "jbo").

There is also a change history at
http://users.adelphia.net/~dewell/lstreg-history.html.

All comments within the scope of the charter are welcome.

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

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 12 Mar 2005 12:36:26 -0800

Hi -

> From: "Doug Ewell" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Saturday, March 12, 2005 11:21 AM
> Subject: [Ltru] Update to proposed registry
>

> All comments within the scope of the charter are welcome.

(co-chair hat OFF)

Would it make sense to make this into a working group i-d?
When (re-)populating a registry, it seems like it would be nice
to be able to give IANA something that had been under WG change
control, without having to incorporate it all in the registry document.
On the other hand, the format of the entries would be hard to
reconcile with the constraints on i-ds.  Many of the lines exceed
72 characters.  In any case, if the updated registry would contain
information that cannot be derived algorithmically from the current
registry contents, we *somehow* would have to provide that information
to IANA, whether in the registry document itself or in a new companion
document.  Ideas?

Randy

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 12 Mar 2005 22:28:42 +0100

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