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.

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



_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru