Re: Lists and EPP

Like Andrew I view EPP as a provisioning protocol for one or a small set of objects.  Reports already serve the purpose of providing a full inventory of Registrar objects and their relationships.  Although EPP could be used to support the delivery of reports I don't believe that it was designed for it and I don't believe that it's appropriate to do so from the provisioning system.  The EPP provisioning systems are setup for provisioning activity where generating a response of thousands to millions of records is out of scope.  The systems for the generation and availability of reports are designed for bulk data like what has been discussed.  Let's not try to fit the round peg into the EPP square hole.  

________________________________________
From: [email protected] [[email protected]] on behalf of Andrew Sullivan [[email protected]]
Sent: Wednesday, June 08, 2011 1:02 PM
To: [email protected]
Subject: Re: [provreg] Lists and EPP

On Wed, Jun 08, 2011 at 06:20:58PM +0200, Klaus Malorny wrote:

> 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.

Right.  My real objection is that the protocol is designed to be
"retail" rather than "wholesale".  That is, most of the protocol
(actually, I can't think of an exception) is intended to deal with one
object at a time.  A report of the proposed kind would return not one
object, but instead a set of other objects.

This is also why I think it would be fine to define a report object to
be provisioned: you make the provisioning request, and get back your
answer (I would imagine it would be a URI with the location the report
will be, and the validity period -- perhaps "available by" and
"expires on", both timestamps).  This maintains the model of working
on one object at a time.  I suppose the return would also include a
report identifier, so that you could use the poll queue to find out
when your report was ready, if you wanted.

A

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