We (Mark and I) welcome the last call process and timelines and the feedback these generate. That's the whole point of having a Last Call. The -CS subtag issue doesn't strike me as a technical issue with the draft. The draft stabilizes the meaning of subtags. There is a process in the draft for setting the initial (and thus stable) meaning of the -CS subtag. While it probably matters which value (Czechoslovakia or Serbia and Montenegro) that is selected, it is only of editorial interest to the draft itself... unless what Bruce is trying to prove is that stabilizing the meaning of the subtags is a Bad Idea, which I don't think is his point. I'm willing to entertain a debate about which meaning ought to be selected. But really it ought to be recognized as not an editorial issue with the draft and not a technical objection. Best Regards, Addison Addison P. Phillips Director, Globalization Architecture http://www.webMethods.com Chair, W3C Internationalization Working Group http://www.w3.org/International Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: ietf-languages-bounces@xxxxxxxxxxxxx > [mailto:ietf-languages-bounces@xxxxxxxxxxxxx]On Behalf Of > ned.freed@xxxxxxxxxxx > Sent: 2004å12æ18æ 15:41 > To: Bruce Lilly > Cc: ietf@xxxxxxxx; ietf-languages@xxxxxxxxxxxxx > Subject: Re: New Last Call: 'Tags for Identifying Languages' to BCP > > > > > I am somewhat sympathetic to the idea of having some > > > total limit (except for the late date for the proposed change). > > > Earlier feedback would have been had if there had been > > some announcement of the proposed considerable changes > > on the ietf-822 mailing list, or via an IETF WG > > charter. > > This sort of thing is exactly why we last call non-WG documents > for four weeks > rather than two. Less review is assumed to have occured and this > may well mean > the document is in some sense "less done". > > So, while I know of no problems caused by inordinantly long > language tags, now > that the issue has been brought up using this opportunity to add > a max length > restriction seems like a very reasonable thing to do. > > > > However, we > > > got considerable pushback on having RFC 3066bis make any > previously valid > > > RFC3066 tag be invalid > > > Entirely appropriate. And the proposed draft would > > invalidate the meaning of the valid RFC 3066 language > > tag "sr-CS", which is currently in use. > > > > and any length restriction would do that. > > > If it makes you happy, you can exclude private-use > > tags from an explicit limit. > > I would only suggest doing this if it helps us reach consensus. > > Ned > _______________________________________________ > Ietf-languages mailing list > Ietf-languages@xxxxxxxxxxxxx > http://www.alvestrand.no/mailman/listinfo/ietf-languages _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf