On 3 Jun 2018, at 8:08, Nico Williams wrote:
>> * The freeze Patrik identified, which is, in some respects, just
>> another symptom of our inability to engage on the above issue.
>
> Slow review/publication process?
Lack of responses on the IDNA WG mailing list when I as an expert asked questions. As I know we have more people in the IETF eco-system than myself and John, and as we definitely are no priests ;-) I decided to simply not move forward due to the lack of responses.
Now I am asked again by IAB to move things forward and that *that* have been slow is my fault only.
This discussion and the possible BOF have made me increase the priorities on this work item.
>> * A draft clarifying the responsibilities of zone administrators
>> ("registries") under IDNA2008 which we have been unable to
>> process.
>
> Yes, *this* I think is urgent. But: who should do this?
>
> ICANN can require that registries set out some policies. Registries can require that registrars follow them. The IETF cannot do any of that --
> we can only give them advice.
After lots of work in ICANN ICANN Board finally passed a resolution saying IDNA2008 should be followed (it is in the applicant guidebook, but that is instructions to the evaluation process). This based on (yet another) note from SSAC on how bad the situation is. ICANN Board asked ccNSO and gNSO to look into the issue and they are. The issue is though that ICANN only have some gTLDs as contracted parties, and not all of them have new enough contract (although exact contractual situation to me is unclear). ccNSO do not have contracts with ccTLDs although many ccTLDs have signed MOU-like documents with ICANN stating they should follow the ICANN policies developed. So we have from ICANN perspective a number of parties, not all contracted, that should follow IDNA2008. The problem is because of this *not* a contractual violation within the ICANN eco-system.
In reality we know we do not have any protocol police. So all policies are implemented by volunteers (open source and not) and the question is then what they use, and why they do IDNA2008 "in their own way".
You point at one excellent example, that people do not use the same normalization mechanism.
Another is that people just use whatever their library is using, and if we look at libCurl it can be compiled nowadays with strict IDNA2008 or relaxed (see below), and the programmer do not even know what is used. On top of this one might link with whatever libidn is in the operating system version one use, and that can also create some confusion. Specifically as one might use one or more of:
- IDNA2003
- IDNA2003 but home-brew application on top of newer versions of Unicode
- IDNA2008 with UTS#46 and some random version of Unicode
- IDNA2008 as IETF have approved the versions of Unicode
- IDNA2008 applied to later versions of Unicode
Not fun.
paf
Attachment:
signature.asc
Description: OpenPGP digital signature
