Subject: [Ltru] Old country codes (was: Re: LTRU submission: draft-ietf-ltru-registry-10)

From: "Doug Ewell" <[email-masked]>
Date: Sat, 6 Aug 2005 10:49:12 -0700

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

> [3166-3]
>> It might be helpful if the contents of this standard were
>> freely available like 3166-1.
>
> Three 3166-3 newsletters since 1999 are available so far:
>
>
http://www.iso.org/iso/en/prods-services/iso3166ma/03updates-on-iso-3166/nlp3i-1.html
http://www.iso.org/iso/en/prods-services/iso3166ma/03updates-on-iso-3166/nlp3i-2.html
http://www.iso.org/iso/en/prods-services/iso3166ma/03updates-on-iso-3166/nlp3i-3.html
>
> Complete list incl. French versions:
>
>
http://www.iso.org/iso/en/prods-services/iso3166ma/03updates-on-iso-3166/index.html

Since 1999.  That is helpful, and it provides definitive guidance for
some code elements, but unfortunately the others (back to 1988, which is
our "Date A," and further back to the mid-1970s) are available only for
a price, or through unofficial sources.

>> In any case, whether it would be helpful to use 3166-3 or
>> not, the fact is that the current draft does not use it, and
>> thus does not need a reference to it.
>
> ACK, not in 3.1, we only disussed it as source for the initial
> registry and cases like YDYE or DDDE.

Background material for discussion doesn't necessarily need to be
referenced in the finished document.  What we said in the draft was that
the code elements from ISO 3166:1988 were used, along with subsequent
updates.  That might or might not have been accomplished by actually
procuring a copy of the 1988 standard.

>>> we ignored crap deprecated before 1988 like NHVU, RHZW, or
>>> VDVN.
>>
>> It's only crap because we ignore it.
>
> No, we ignore it because it's historical crap... <eg>

The fact that DY for Dahomey was changed to BN for Benin is not "crap"
just because it happened in 1977 any more than the change from TP to TL
that happened in 2002.  It happens that this WG's draft seeks to
maintain compatibility with tags generated under RFC 1766, which
referenced the 1988 version of ISO 3166, so we allow subtags based on
ISO 3166 code elements going back to 1988.  But for an application that
really uses ISO 3166 code elements per se, and might have to recognize
all previous code elements for its own compatibility reasons, DY as a
historical code element is just as legitimate as TL.

> And you
> had a hard time to gag me when I wanted to get rid of all old
> regions from the second millennium, based on the year of the
> publication of RfC 1766.

RFC 1766, published in 1995, allowed code elements dating back to 1988,
and notoriously did not contain any text about versioning of ISO 3166
except to say there was a Maintenance Agency.

> The seven years from 1988 - 1995 are a royal PITA.

No, they're not.  Older deprecated subtags don't cause any problems that
newer (or future) deprecated subtags won't cause.  They're a lot like
grandfathered tags; if you have to support one, supporting 500 is no big
deal.

> But Mark wanted BU, tough, let future software
> archaeologists have some fun.

1.  I don't see any need to personalize this.  Mark wasn't the only one.
I've explained the logic for maintaining compatibility with 1988 above.

2.  If you already have to support TP, there is no additional cost to
supporting BU.

3.  One major reason we have a registry at all is so that tag recipients
don't have to be software archaeologists, tracing their way back through
ISO change notices (if available) to interpret deprecated code elements.

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

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

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 6 Aug 2005 12:17:34 -0700

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

> One consistent way to do it, IMHO okay, it's the fiction that
> you created the initial registry at "date B".

That's not fiction, it's by definition.  From draft-initial, Section 2:

| 1.  For each source standard, the date of the standard referenced in
| [RFC1766] was selected as the starting date. Code elements that were
| valid on that date in the selected standard were added to the ILSR.

That's Date A.

| 2.  For each successive change to the standard, any additional
| assignments up to the date of the adoption of [I-D.ietf-ltru-registry]
| were added to the ILSR.

That's Date B, the date of adoption of draft-registry.  That day has not
come yet.

> Another way would be to get the "real" dates of the additions
> (more or less, e.g. using available 3166 newsletters) with a
> fiction, that the initial registry existed since 1988 "date A"
> and was updated a.s.a.p.

That isn't the date the subtag was added to the registry.  From
draft-registry, Section 3.1:

| Added's field-value contains the date the record was added to the
| registry.

Changing the rules about dates would require changing the text of
draft-registry and/or draft-initial.  As a technical contributor, I
don't think we should go down that path at this time.  As editor of
draft-initial, I will do what the co-chairs say.

Speaking of this, I'm still waiting for an answer to my question in
http://www1.ietf.org/mail-archive/web/ltru/current/msg03183.html.  I
know it's the weekend and not everyone is available right now.

> Probably you'd have a hard time to get the latter right, so I
> think you better stick to the former strategy.  In theory I'd
> prefer the latter, because "deprecated" before "added" is ugly,
> but in practice it would force you to guess in too many cases.

"Deprecated" before "added" is ugly, I agree, but the WG agreed to a
convention *quite some time ago* that subtags in the initial regsitry,
based on ISO code elements, would have a Deprecated date equal to the
date the code element was deprecated in the source standard.

Claiming that a given subtag was added to the registry 10 or 20 or 30
years ago before the registry was even created is also ugly IMHO.

>> What should the dates be?  Fixed at the date when
>> draft-initial passes WGLC and moves into IETF Last Call?
>
> Pick the last possible "date B" where you're confident to have
> _all_ changes in _all_ sources.  If that's in your AUTH48 in
> some months it's okay.  But tf they introduce GG, IM, and JE
> next week (example) use a "date B" in this week, because it
> would confuse several parts of the text if you try to integrate
> these changes in the initial registry:
>
> Let the normal specified update procedure handle GG, IM, JE,
> and pick a "date B" before this change.  OTOH don't pick a
> "date B" before the introduction of 831 and 832, because this
> could again confuse the existing text.

Date B has already been picked.  Read item 2 in Section 2 of
draft-initial, and then go back and read it again.  That is the
definition of Date B that this WG has agreed to.  We will not know the
final value of Date B until the left side of the equation has been
filled in (i.e. the date of adoption of draft-registry).  If that date
is delayed until GG and IM and JE are added to ISO 3166-1, then those
subtags will be added to the initial registry.  It is as simple as that.

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 07 Aug 2005 14:06:12 +0200

Doug Ewell wrote:

> Since 1999.  That is helpful, and it provides definitive
> guidance for some code elements, but unfortunately the others
> (back to 1988, which is our "Date A," and further back to the
> mid-1970s) are available only for a price, or through
> unofficial sources.

Older stuff is their "initial" 3166-3, it's not as old as the
other parts.  See their iso3166-past-present-and-future page:

http://www.iso.org/iso/en/prods-services/iso3166ma/04background-on-iso-3166/iso3166-past-present-and-future.html

3166-3 was created 1997-99, the newsletters cover all updates.
One of my several "date A" proposals was "5th edition" (1999).

Somebody here ordered and got it, and IIRC the result was that
your unofficial source of code changes was complete.

> this WG's draft seeks to maintain compatibility with tags
> generated under RFC 1766, which referenced the 1988 version
> of ISO 3166, so we allow subtags based on ISO 3166 code
> elements going back to 1988.

Are you talking with me or for the press ?  I know what we did,
in theory I could find Randy's ticket number, and the article
where he declared consens about "date A".  Nobody cared to
produce any tags deprecated before 1995, maybe not one exists,
but we can't be sure.

> DY as a historical code element is just as legitimate as TL.

Not in language tags, it was never valid under 1766 / 3066.
If DYBN was 1977, then it was dead 11 years before 1988, and
18 years before RfC 1766.  There are precisely zero reasons
to find it in the wild in 1766 / 3066 / 3066bis language tage.
 
> No, they're not.  Older deprecated subtags don't cause any
> problems that newer (or future) deprecated subtags won't
> cause.  They're a lot like grandfathered tags; if you have
> to support one, supporting 500 is no big deal.

We all discussed this here again and again, of course they
are a PITA because they are blocked for future "recycling".

Nobody can use any future BU in language tags, because it's
blocked by the old BUMM.  Unlike DY and NH.   BUMM was 1989,
one year after "date A", but still before the WWW was started,
and maybe also before somebody counted 18 letters in I18N.

> If you already have to support TP, there is no additional
> cost to supporting BU.

As far as I'm concerned this error is the main reason why an
LTRU WG was created.  Plus the "most perverse tag" issue, and
"Suppress-Script".  Anything else is essentially the same as
you (= language tag list) already had it in the old last call.

                          Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 07 Aug 2005 15:04:47 +0200

> That's Date A.

Doug, I _know_ what "date A" is, I was here, remember ?

 From my POV it was the most conservative choice, there
were no language tags before 1995, nobody had a reason
to use anything deprecated before RfC 1766 - unless he
had an old copy of ISO 3166-1 region codes without the
updates.  Rough consensus was to be paranoid about this
hypothetical case => ready, "date A" is 1988.

> Changing the rules about dates would require changing
> the text of draft-registry and/or draft-initial.

If the rules are clear why did you ask ?  I'm fine with
your strategy to use "date B" everywhere.  Addison did
not propose another strategy for the "ILSR", his remark
was about the future function of "Added" dates for all
registry updates after "date B".

> Claiming that a given subtag was added to the registry
> 10 or 20 or 30 years ago before the registry was even
> created is also ugly IMHO.

The idea is fine - we've used past modifications in the
sources to simulate the effects on an imaginary registry
started at various potential "date A".  But in practice
getting these "Added" dates right would be too difficult.

And one day before the end of the second dress rehearsal
it's also too late for such major "nice to have" changes.

> Date B has already been picked.  Read item 2 in Section
> 2 of draft-initial, and then go back and read it again.

If you don't want answers you don't like beause you already
have your own answers don't ask.  I only told you what I'd
do about it, delay "date B" as long as possible, but not
beyond potential major changes of the sources, if it causes
inconsistencies with the "last called" texts.

> If that date is delayed until GG and IM and JE are added
> to ISO 3166-1, then those subtags will be added to the
> initial registry.  It is as simple as that.

It's not, it could invalidate parts of your chapter 4, in
the "worst" (= best) case completely.  It would also affect
the text in 3.3 point 11 in 3066bis.

                         Bye, Frank