Re: Lists and EPP

Christopher Browne <[email protected]>
Newsgroups gmane.ietf.provreg
Message-ID <[email protected]>
2011/6/8 Jim Reid <[email protected]>:
> On 8 Jun 2011, at 10:12, Patrik Fältström wrote:
>
>> There are a number of other sync-mechanisms I would not mind seeing, but
>> it is important the registries do that the same way... I do see registrars
>> start to be irritated on the high number of different implementations of The
>> Same Thing between registries.
>
> Yes, an industry-wide standarised way to do this kind of thing would of
> course be good Patrik. I'm not convinced EPP is the tool to use though. Not
> every registry and registrar speaks EPP. There could be icky implementation
> issues too: eg locking the database while something ploughs through it to
> generate the list. [We can't have the database changing while the list is
> generated, eh?] I fear this could be the start of a slippery slope as more
> SQL reporting type stuff gets shoe-horned into EPP: "gimme a list of all the
> domain names I registered for this contact that then got transferred to that
> registrar over the last N months", "which domains I manage reference this
> nameserver (or contact) object?".

When I think about this, my brain heads down quite a similar trail, as
one part of me starts looking for the semantic minutiae of how it
ought to work, and the successive set of problems that lead to
defining a more and more extensive set of commands to characterize the
necessary actions, and to cope with various concurrency and
transaction management problems.  Franciso, downthread, observes that
limits may be indicated in a multiplicity of ways (e.g. - counts,
maximum sizes of requests).

I quickly leap to "wait, stop here!" since adding in such details
winds up mandating quite a lot about implementation, which is
something that the protocol ought to generally protect us from, rather
than fairly directly implying.

I'd be fearful that a "<domain:listall>" command would turn out to be
so complex in its behavior that it's effectively unusable.  CRISP/IRIS
was intended to provide this sort of functionality, but, in practice,
there has been little adoption, which seems suggestive that something
is problematic about it as solution.

None of the directions that are evident seem palatable:
- The "straightforward" way is undesirable as it leads to unacceptably
expensive requests (e.g. - where the response set will be unacceptably
large)
- Performance-sensitive methods will be complex, and need to specify
semantics (e.g. - assumptions about transaction handling,
serialization, and such) that are not desirable to have in the
protocol.

In practice, registry contracts have tended to define a set of
mandatory reports (including formats) for the regular release of this
sort of information, and while that's not "one stop shopping" (or pick
your favorite business-y idiom), it generally does function.

Andrew Sullivan's suggestion of passing URIs around using the poll
queue facility is plausible, certainly involving a goodly amount of
indirection.  It implies an interaction between EPP registry and an
outside URI server (quite likely a web/ftp server).
-- 
Christopher Browne
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.