Re: Lists and EPP

Eric,

I'm sure that a method could be created to support a bulk list command and
response in EPP, but I question whether it is appropriate for EPP.  This
information is already provided via reports and made available via FTP and
via a web application, so what is the driver for adding this to the
provisioning channel?  Creating an XML response of thousands to millions
of records does represent a scalability issue for the server and the
client.  For bulk data it's best to separate format definition from data,
which is why for data escrow I'm not a fan of the use of XML.  The same
holds true for bulk information.  I don't believe it's a good use of the
limited provisioning resources to support an unbounded bulk data feed,
where the focus should continue to serve the provisioning needs and not
the reporting and synchronization needs.

--


JG



James Gould
Principal Software Engineer
[email protected]

703-948-3271
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

VerisignInc.com




On 6/9/11 7:42 AM, "[email protected]" <[email protected]> wrote:

>The "scale" claim I'm still mulling on. When I wrote the first ICANN
>escrow
>spec (registries) I put in the means for an escrow deposit to span more
>than
>a single media capacity, a means also present in the second ICANN escrow
>spec
>(registrars), which somebody wrote.
>
>So the unboundednes of a "record" (or sequence of grouped XML glop) is at
>least by the capacity bounds of the transport media (current DVDs are big,
>but not infinite), and the transmit capacity between the source and sink
>does determine the limit before the trasmission of an instance of a
>record 
>must also contain updates to data within that record.
>
>But I'm not interested in edge cases of EPP-for-Verisign or
>EPP-for-GoDaddy,
>or transport-for-domainers-slamming-the-com-drop-pool, but in the more
>common
>problem, for which a registry policy declaration of the maximum size of a
>unit of data (or the equivalent unerlying database access bandwidth) can
>be
>announced to the registrar, just like a dcp.
>
>For this, a LIST command semantics and syntax can be specified and
>implemented
>and interoperability demonstrated, with the option of using the IETF or
>any
>equivalent means of making the specification available without liability
>to
>its authors, implementors and eventual users.
>
>Based upon limited experience with one registry platform operator's dbms,
>the LIST command and the LIST response may be sufficienty seperated in
>time
>to require more bookkeeping overhead than a mere wait() and the assumption
>of stream semantics.
>
>Eric
>_______________________________________________
>provreg mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/provreg

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