Subject: [Ltru] Re: Small bibliography error in RFC 4930

From: "Doug Ewell" <[email-masked]>
Date: Tue, 19 Jun 2007 08:10:20 -0700

Debbie Garside <debbie at ictmarketing dot co dot uk> wrote:

> Is there a way to pull that historical registry once ISO 639-3 is added?

In theory it's always possible to recover a historical version of the RFC 
*4646* Registry by looking at the "Added" dates.  This actually doesn't work 
perfectly because modifications don't affect the Added date.

Extracting the RFC *3066* registry is a different problem, because the 
nature of the records to be extracted isn't the same.  Not only were there 
no script subtags, but language and region subtags weren't defined within 
the 3066 registry, but rather within ISO 639 and 3166 (so users had to dig 
through the standards to find valid code elements, and the status of 
"withdrawn" code elements was unclear).  The 3066 registry contained only 
things that we would today consider for "variant" status.  Going from 4646 
to 3066 has more to do with understanding the two specifications and 
registries, and the differences between them, than with the actual data.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages

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

---

From: Addison Phillips <[email-masked]>
Date: Tue, 19 Jun 2007 08:24:13 -0700

Proposal: RFC4645bis should preserve existing dates in the 4646-based 
registry. Then pulling the "historical" (4646) registry would be 
possible. Probably this is what you're doing already, Doug, but the text 
doesn't say so.

Addison

Doug Ewell wrote:
> In theory it's always possible to recover a historical version of the 
> RFC *4646* Registry by looking at the "Added" dates.  This actually 
> doesn't work perfectly because modifications don't affect the Added date.
> 
> nature of the records to be extracted isn't the same.  Not only were 
> there no script subtags, but language and region subtags weren't defined 
> within the 3066 registry, but rather within ISO 639 and 3166 (so users 
> had to dig through the standards to find valid code elements, and the 
> status of "withdrawn" code elements was unclear).  The 3066 registry 
> contained only things that we would today consider for "variant" 
> status.  Going from 4646 to 3066 has more to do with understanding the 
> two specifications and registries, and the differences between them, 
> than with the actual data.
> 
> -- 

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 20 Jun 2007 22:36:35 -0700

Addison Phillips <addison at yahoo dash inc dot com> wrote:

> registry. Then pulling the "historical" (4646) registry would be possible. 
> Probably this is what you're doing already, Doug, but the text doesn't say 
> so.

That is exactly what I'm doing, and thank you for bringing it up.  In RFC 
4645bis, existing records may be changed slightly to add language names 
listed in ISO 639-3, and to put the 639-3 "reference name" first, but in no 
case will the Added date of an existing record be changed.

Thanks for the comment on RFC 4645bis -- there have been very few of those 
up to this point!

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 21 Jun 2007 10:52:17 +0200

On Wed, Jun 20, 2007 at 10:36:35PM -0700,
 Doug Ewell <[email-masked]> wrote 
 a message of 27 lines which said:

> That is exactly what I'm doing, and thank you for bringing it up.
> In RFC 4645bis, existing records may be changed slightly to add
> language names listed in ISO 639-3, and to put the 639-3 "reference
> name" first, but in no case will the Added date of an existing
> record be changed.

Is it already the case with 4646? Yes, according to section 3.4.
"Stability of IANA Registry Entries"

But, yesterday, the subtag baku1926 was modified (change in the
Comments) and the Added field *was* modified, from 2007-04-18 to
2007-04-20, which puzzles me (why changing it and why for a date two
months in the past?)

IANA's blunder or ambiguity in the procedures/RFCs?

---

From: "Doug Ewell" <[email-masked]>
Date: Thu, 21 Jun 2007 08:58:16 -0700

Stephane Bortzmeyer <bortzmeyer at nic dot fr> wrote:

> But, yesterday, the subtag baku1926 was modified (change in the Comments) 
> and the Added field *was* modified, from 2007-04-18 to 2007-04-20, which 
> puzzles me (why changing it and why for a date two months in the past?)
>

Apparently an error in the second record that was sent to IANA, the one with 
Resat's replacement transcription.  IANA perfectly reproduced the record 
they were sent.  We'll ask them to fix the mistake.

You can't get much less ambiguous than this:

> 3.4.  Stability of IANA Registry Entries
>
>  1.   Values in the fields 'Type', 'Subtag', 'Tag', 'Added',
>       'Deprecated' and 'Preferred-Value' MUST NOT be changed and are
>       guaranteed to be stable over time.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 21 Jun 2007 22:33:59 +0200

> name" first, but in no case will the Added date of an existing

Isn't it a problem that there is no way to know the modification date?
Should we work on a Modified: field in the registry?

I ask so because the LSR syndication feed
http://www.langtag.net/registries/lsr.atom would certainly benefit
from it. Its format, Atom (RFC 4287), makes a difference between
<published> and <updated> (other syndication formats do it as well).