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.
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.
Cheers,
Michael
--
____________________________________________________________________
| |
| knipp | Knipp Medien und Kommunikation GmbH
------- Technologiepark
Martin-Schmeisser-Weg 9
44227 Dortmund
Germany
Dipl.-Informatiker Fon: +49 231 9703-0
Fax: +49 231 9703-200
Dr. Michael Bauland SIP: [email protected]
Software Development E-mail: [email protected]
Register Court:
Amtsgericht Dortmund, HRB 13728
Chief Executive Officers:
Dietmar Knipp, Elmar Knipp
Certified according
DIN ISO/IEC 27001:2017
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
