Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote: > Doug, I _know_ what "date A" is, I was here, remember ? Yes, sorry. I just wanted to make sure everyone was on the same page. > 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. See my other message. Non-updated copies of the standard and unofficial code lists were much more common than official subscribed copies of the standard. (How many people, even now, know about the special meaning of "OO" and "OOO" in ISO 3166? You can really only find out about those by reading the standard.) >> 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 didn't ask about Date B. I asked, somewhat rhetorically, because Addison responded to Kent: >> 2. Will all the "added" dates be changed to that of the date when >> the actual registry goes "live"? (As well for the initial value >> of the "File-Date".) > > No. The initial value of File-Date should change, but not the added > dates. and this came as a surprise to me, based on my understanding of Date B and File-Date and Added. So far nobody's responded (it's a nice weekend). > 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". Kent asked what would happen "when the actual registry goes 'live'." That could only refer to the initial registry. I think everyone understands that the Added dates for existing subtags won't change after the registry goes live, and indeed draft-registry mandates that. >> 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. I wish we did have exact dates for these things. >> 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. I didn't ask about Date B. Really. We can never tell when there will be "potential major changes" to the source standards. With the notable exception of CS, which ISO 3166/MA apparently knew would cause problems, the MAs don't generally tell us when there is a change in the works. They simply announce the change after it is approved (or in the case of UNSD, post it on the Web with no announcement). >> 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. Section 4 of draft-initial is essentially just a code list, an "unregistry" as you once called it. Removing 831 through 833 would not cause me any grief personally, and we can be fairly sure we will not have to remove 830. The editors of draft-registry have essentially mirrored that list in Section 3.3, point 11, and they can decide whether amending that section would cause problems. -- 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.