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
