Speaking as a participant: 1 comment inline below
On 12 Nov 2025, at 10:54, Pawel Kowalik wrote: > Hi Michael, > > On 06.11.25 11:45, Michael Bauland wrote: >> Hi Pawel, >> >> thank you very much for your review and your comments/suggestions. >> I'll try to respond to your comments. >> >> Am 05.11.2025 um 23:19 schrieb Pawel Kowalik: >>> I actually read this draft and I have concerns. >>> >>> For me the draft is super complex and pretty hard to follow. It seems to me >>> to include quite a bit of business rules description, which almost read >>> like policy. >> >> We can try to rephrase some parts. However, we cannot really remove the >> complexity. It comes from the quite complex requirements from ICANN's IDN >> EPDP. This sets a lot of rules how variants, both at the top level and >> second level need to be handled. While there are several related extension >> currently used by different TLDs, none cover all the requirements. We >> therefore need to have an EPP extension that is capable of implementing >> those policies in full. They will become a requirement for all gTLDs in the >> future. So, if we're not coming up with a standard, registry operators will >> (again) start implementing their own versions to cover ICANN policies. >> > I understand the need, but same time I don't think technical standard > document shall be a transcription of ICANN policy. EPDP is good enough to > describe what ICANN requires and EPP extension shall only describe how > clients and servers exchange information so that provisioning and management > of such domain sets is possible. Actually the mechanics and rules how some > domains are in a set or not is not even relevant. There might be a set of > IDN-variants, of diacritics, of typo-domains or of homoglyph-domains or > whatever rules some registry might come up with. The extension shall be able > to work in all those cases without spelling them out too much. Michael and I are in complete agreement with you, Pawel. While it is true we will often talk about ICANN policies in the context of this work, the technical work is designed and derived from technical requirements. Of course, as we thought about what the technical solution needed to look like, we reviewed what was currently deployed and being considered (of which ICANN policies is one). As noted in the document, backwards compatibility is paramount. We want to ensure broad applicability, and we will likely refer to existing circumstances in discussion. We agree there is some work to do in order to ensure the narrative reflects technical issues, not policy issues, and we will do this as this work progresses. Jim _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
