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