Hi Michael, On 06.11.25 11:45, Michael Bauland wrote:
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.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 would prefer this draft to focus more on the statuses, requests and responses (the things happening on the wire) instead of that much focus on what kind of complex rules to apply for these statuses to appear. In the current shape I think there might be difficulty to get energy in the working group to work on it.As said above, the gTLD world will need to have such an extension very soon. I'd hope that provides enough energy. But we will discuss this internally whether there are some simplifications possible, while still covering the full requirement.On the protocol itself I don't like the logic of overloading update operation for creating (named allocating) and deleting (deallocating?), instead of using standard semantics of create and delete commands. I think this would disrupt the way registries implement lifecycle of the names, lead to confusions and have unforeseen consequences downstream. There is a technical issue about it, that the related names actually can have distinct dataset compared to their primary name. Update (allocate) is having differential semantic compared to create having a declarative semantics. Update of something that was never created would have a missing point of reference for the differential semantic.The question whether to use create/delete or update, has been a long and complex one. However, I see your points and we'll discuss this further and get back to you.
Thanks.
If the feature would become mainstream I can imagine things happening differently to past experience. This will highly depend on the business models behind it (whether these variants would be for free or for fee). Thanks for considering that.I am also a bit nervous about all the responses which define potentially large lists or related domains without any way for the client to opt out (or opt in) from them. The information may be useful to a client but likely not in every response so some control on this would be useful.That's an interesting point. I don't see large lists of related domains being activated. For example, .cat has been using variants right from the start, so even before the 2012 round, and there are usually just 1 or 2 variant activated, but I agree that this might be different for other scripts. But even then, I don't think a single entity would be interested in having tens or even more of related domains.We'll discuss whether it makes sense to introduce some kind of flag to not return the activated related domains. However, this would make the whole extension even more complex (at least a bit), which you complained about in the beginning. Alternatively, the registrar could always send requests without using the extension to avoid getting the additional information.
Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
