Subject: RE: [Ltru] Update to proposed registry

From: "Addison Phillips" <[email-masked]>
Date: Sat, 12 Mar 2005 12:08:04 -0800

All,

I also incorporated another change we promised during the last call period: codes that are deprecated by their parent agency (ISO 639, ISO 3166, etc.) can be deprecated in the registry. See sections 2.4.1 and 3.1.

I am submitting the official first draft now. It also includes the corrections that Doug mentions below to make the text consistent.

Best Regards,

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 Doug Ewell
> Sent: Saturday, March 12, 2005 11:22 AM
> To: LTRU Working Group
> Subject: [Ltru] Update to proposed registry
> 
> 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

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

---

From: "Addison Phillips" <[email-masked]>
Date: Mon, 14 Mar 2005 09:28:58 -0800

Elision as necessary in a response to Martin below.

Addison

Addison P. Phillips

> From: Martin Duerst [mailto:[email-masked]]
> Sent: Sunday, March 13, 2005 2:33 PM

> 
>  >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?
[Addison Phillips] 

No. My understanding of Randy's message was that he wanted the registry to be versioned and hosted by the IETF. I'm explicitly suggesting that we not  place the registry under version control until the document that controls the format (the registry I-D) is finalized. Maintaining a shadow registry in the meantime is a good idea: the details that we work out in debating its content should be recorded and memorialized in the registry draft (which contains the rules for populating the registry, after all). IOW, don't rely on the registry to memorialize why it contains what it contains. 

> 
> 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.
[Addison Phillips] 

Yes, exactly so. And that would be "draft-initial-00".
> 
>  >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.
[Addison Phillips] 

The "if not" was meant to apply to RFC 2616, not the IETF. I agree that this is an all-IETF effort. The question is whether the draft registry is an I-D or just a document. Personally, I think torturing the thing to be an I-D is a waste of time. The registry draft defines the registry just fine. It should be possible to point to every entry in the initial registry and say why it is there (from text in the registry I-D). If subsequent to the registry I-D's adoption, there is objection to something that was defined by the rules in the registry I-D and we change it.... that suggests changing the new RFC. Which is messy.