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 at lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.