On 2019-07-03 09:45 -0500, Pieter Vandepitte
<pieter.vandepi...@dnsbelgium.be> wrote:> The current EPP specifications
do not prevent a client to perform “bulk > updates”, it’s just the
clients that are not smart enough. If clients > would operate
asynchronously (not waiting for a server response), the
(except that sometimes updates may be linked in the sense of one should
stop if one is giving out errors; using pipelining is explicitly allowed
by the RFC, may or may not be allowed by registries - so it is not just
a matter of clients being not smart enough - and will certainly not
solve the problem of conditionally continuing the batch or not)
only overhead is the verbosity of XML (vs. message RTT when operating
synchronously). I doubt that this is a real issue (except if you’re
provisioning billions of objects/updates)...
There is (at least) one (existing[1]) use case that is absolutely not
covered:
in some registry, some names are "bundled" together.
If you transfer/update one name from the bundle, you need to apply the
same operation to others.
Currently it is done in a fashion where the first command is put in
pending state until all other commands are done, at which point all are
released as done.
In situations like that, you would need a way to send multiple commands
in the same "batch", like a logical unit, or a DB transaction.
Or an EPP extension clearly describing bundles, identifying them, and
being then able to send commands not on a domain but on a bundle of
domains, and I do not think this extension exists anywhere.
EPP does not provide that and I am not sure it should provide that anyway.
I will try to read the underlying proposal at some time, but I wanted to
react to add a use case that may not be known.
[1] upon checking, that specific behavior I described existed but ceased
to recently when the registry changed its backend (now any single
operation on a domain in a bundle does the same operation for all other
domains in the bundle - that clearly solves the "batch" problem but then
exposes to many other pitfalls)
--
Patrick Mevzek
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
