Re: Lists and EPP

I really think that there should be an extension to define such functionality, but it should be a policy issue whether it is enabled or not.

It's exactly the same case as the domain:check command. there's currently no limit on how many domain names can be queried (well technically 2^32 - 4 bytes long with the EPP over TCP transport) with a single XML document.

Some registries limit the number of domain:checks a registrar can perform within a certain period of time, and that's the way the deal with this problem.

Others limit the total size of the XML payload, etc. 

We can probably work around the issues that have been surfaced in this list, specially if there is consensus that this is needed. The technical barriers, can be worked out.



On Jun 8, 2011, at 9:20 AM, Klaus Malorny wrote:

> On 08/06/11 15:31, Andrew Sullivan wrote:
>> On Wed, Jun 08, 2011 at 12:00:25PM +0200, Klaus Malorny wrote:
>> 
>>> However, generally, a reporting mechanism could be done in an
>>> incremental way, so that it even could be implemented in EPP:
>> 
>> Why do you want to Extend the protocol so that it's no longer even
>> about Provisioning?
>> 
>> I can see a possibly useful extension that requests a report be
>> generated.  That is, like other things in EPP, one can request that
>> something be provisioned (in this case, a report).  But the response
>> to that should not be a long list of domains in-protocol, I think.
>> EPP is poorly structured for that sort of bulk operation, on purpose.
>> 
>> A
>> 
> 
> 
> Hi Andrew,
> 
> I understand the criticism and I am actually ambivalent about such an approach. My posting was just to point out that there is a middle course between having no list and a full list, just from a technical (and not philosophical) perspective.
> 
> But generally, where to draw the line regarding the functionality? Why is the retrieval of the contents of the the registrar's repository at the registry not part of the provisioning? With the same argument you could argue that the domain:info command is superfluous in most of the cases -- most of the data you should have in your own database. But likely nobody would consider to remove this command from the protocol.
> 
> I think that a registrar-registry protocol should cover the whole technical interaction between the two parties. Any kind of communication besides this protocol, including downloading reports from FTP servers, reduces the value of the protocol.
> 
> On the other hand, this requirement collides with a general demand, the frugality of a protocol -- once I read the nice sentence "don't reason about what you can add to a protocol, but what you can remove from it" (or correspondingly). The balance needs to be found.
> 
> Regards,
> 
> Klaus
> _______________________________________________
> provreg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/provreg

Francisco Obispo 
Hosted@ Programme Manager
email: [email protected]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
Key fingerprint = 532F 84EB 06B4 3806 D5FA  09C6 463E 614E B38D B1BE




_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg