Man, sorry for the weird random capitalization, y’all. Autocorrect has a mind of its own.
Also, what Matt said: perhaps we could approach consensus if those in favor of the proposal would articulate their thoughts on why specifying a two-letter is the best solution to (this, any) problem, the rest of us might be able to see why you feel your case is compelling. -Bill > On Nov 22, 2019, at 07:15, Bill Woodcock <wo...@pch.net> wrote: > > Eberhard: > > The principle I’m trying to articulate is that our relationship to ISO 3166 > is that of a standards body which has delegated to it. > > ISO 3166, in turn, specifies that this code is (for now, and at their > authority) to be used by USERS for their purposes. > > It’s my assertion that it’s bad form for us, having placed ourselves in the > standards body role on one side of ISO, to now also claim that we, the same > people, are also “users” Standing on the other side of ISO. > > That seems to me to not be in the spirit of a good-faith delegation. > > If we want to start individually specifying the meaning or use of two-letter > TLDs, it’s my assertion that We should first un-delegate that role from ISO, > and take direct control of the task, not attempt to stand on both sides of > them. And I think the harm of doing so would vastly outweigh any benefit. > Therefore I think this shouldn’t be done. Either we delegate authority to > them, or we don’t. No splitting the baby. > > -Bill > > >> On Nov 22, 2019, at 02:17, Dr Eberhard W Lisse <e...@lisse.na> wrote: >> >> Bill, >> >> ISO has new draft out as part of their regular maintenance cycle which >> states >> >> [...] In addition exactly 42 alpha-2 code elements are not used in >> the ISO 3166, AA, QM to QZ, XA to XZ, ZZ. This rule may change in >> the future. [...] >> >> and then references this >> >> If users need code elements to represent country names not included >> in this part of ISO 3166, the series of letters AA, QM to QZ, XA to >> XZ, and ZZ [...] are available. >> >> I read that to mean that a .ZZ (or rather any of the 42 possibles) would >> be safe to use in our context. >> >> If the rule were to change I would however speculate that the wishes of >> the government concerned might prevail over the wishes of ICANN. >> >> Whether this all is safe enough to write a standard, I don't know. >> >> >> el >> >> >>> On 22/11/2019 10:26, Bill Woodcock wrote: >>>> On Nov 22, 2019, at 12:20 AM, Shane Kerr <sh...@time-travellers.org> >>>> wrote: >>>> >>>> "User-assigned codes - If users need code elements to represent >>>> country names not included in ISO 3166-1, the series of letters AA, >>>> QM to QZ, XA to XZ, and ZZ, and the series AAA to AAZ, QMA to QZZ, >>>> XAA to XZZ, and ZZA to ZZZ respectively, and the series of numbers >>>> 900 to 999 are available. NOTE: Please be advised that the above >>>> series of codes are not universal, those code elements are not >>>> compatible between different entities." >>>> >>>> So the intention of the ISO at least is that these codes are used by >>>> users. (I'm not sure what the scary warning means.) Certainly I >>>> have made heavy use of .Q* and .X* in my own testing, with the >>>> assumption that these would never be assigned (and yes, there is >>>> .TEST but sometimes you need more than one one TLD). >>> >>> Right. And in fact, “unassigned” ISO codes _do_ get used, for places >>> like Kosovo, that are in a state of disputed or partially-recognized >>> countryhood, and ranges that are reserved for user use really should >>> be left for that use, because they do in fact get used by users, so >>> any centrally-coordinated use will run afoul of that. >>> >>> Again, this is an argument from principle rather than an argument >>> based on the specific case at hand. I just think that we have a >>> well-established precedent that all two-letter TLDs are derived from >>> ISO 3166 Alpha-2, and it’s bad form to cross back over and start >>> poaching in their territory. >>> >>> -Bill >> >> -- >> Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist >> e...@lisse.na / * | Telephone: +264 81 124 6733 (cell) >> PO Box 8421 \ / >> Bachbrecht 10007, Namibia ;____/ >> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop