Re: [ietf-provreg] a new core command...?

[Francisco Obispo <fobispo@nic.ve>]

So far,

The list of domains managed by a certain email address, and
the list of hosts asociated to a domain name.

for example, the domain, test.com.ve  has dns1.test.com.ve y 
dns2.test.com.ve

regards


Eugenio Pinto wrote:
> Ok.
>
> It's not an extension but an entire external service. Thanks for you 
> feed-back.
>
> Just a question: Are you using that SOAP service for anything else?
>
> There is anyone else who would like to use (or is actually using, by 
> means of extensions or external services) an EPP command for searching 
> objects stored in a shared central repository?
>
> Eugenio Pinto
> FCCN - DNS.PT
>
>
> Francisco Obispo escreveu:
>> Dear Eugenio,
>>
>> For our registration system, whatever was not accesible via de EPP 
>> protocol, was implemented
>> using WebServices (SOAP).
>>
>> But, it would probably be helpful to have a list of objects given a 
>> search pattern :-/
>>
>> regards
>>
>> -francisco
>>
>>
>> Michael Young wrote:
>>>  Eugenio I also have to support James. This doesn't seem scalable 
>>> for the
>>> core protocol, an extension seems the most appropriate place for it.
>>>
>>> I could see how in an extension you could address a lot of concerns, 
>>> i.e.
>>> queueing a large request, applying policy rules to frequency of 
>>> these types
>>> of requests, etc.
>>> I am looking forward to your I-D.
>>>
>>> Best Regards,
>>>
>>> Michael Young -----Original Message-----
>>> From: owner-ietf-provreg@cafax.se 
>>> [mailto:owner-ietf-provreg@cafax.se] On
>>> Behalf Of James Gould
>>> Sent: Tuesday, June 06, 2006 8:24 AM
>>> To: Eugenio Pinto; ietf-provreg@cafax.se
>>> Subject: Re: [ietf-provreg] a new core command...?
>>>
>>> Eugenio,
>>>
>>> We have not had a need to support a bulk form of query in EPP.  This 
>>> had
>>> come up several times, but we kept the EPP protocol strictly a 
>>> provisioning
>>> protocol and left the bulk information up to reports.  I know that a 
>>> bulk
>>> query would be a real problem for a Registry like COM/NET.
>>>
>>>
>>> JG
>>> -------------------------------------------------------
>>> James F. Gould
>>> Senior Software Engineer
>>> VeriSign Information Services
>>> jgould@verisign.com
>>> Direct: 703.948.3271
>>> Mobile: 703.628.7063
>>>
>>>
>>> 21345 Ridgetop Circle
>>> LS2-2-1
>>> Dulles, VA 20166
>>>
>>> Notice to Recipient:  This e-mail contains confidential, proprietary 
>>> and/or
>>> Registry  Sensitive information intended solely for the recipient 
>>> and, thus
>>> may not be  retransmitted, reproduced or disclosed without the prior 
>>> written
>>> consent of  VeriSign Naming and Directory Services.  If you have 
>>> received
>>> this e-mail message in error, please notify the sender immediately by
>>> telephone or reply e-mail and destroy the original message without 
>>> making a
>>> copy.  Thank you.
>>>
>>>
>>>  
>>>> From: Eugenio Pinto <eugenio.pinto@fccn.pt>
>>>> Date: Tue, 06 Jun 2006 12:02:36 +0100
>>>> To: <ietf-provreg@cafax.se>
>>>> Subject: [ietf-provreg] a new core command...?
>>>>
>>>> Hi all,
>>>>
>>>> I don't know if this subject was already discussed in the past, in 
>>>> the provreg-wg, but I need some opinions about it.
>>>>
>>>> As a Provisioning Protocol I'm wondering if it shouldn't be there 
>>>> another query command besides <check>, <info> and <transfer> that 
>>>> would allow us to retrieve all the objects actually provisioned by a
>>>>     
>>> repository.
>>>  
>>>> In DNS.PT we needed a command with such functionality in order to 
>>>> retrieve all the domains owned/managed by the current logged user 
>>>> and we needed to do an extension.
>>>>
>>>> My question is:
>>>>
>>>> Is it reasonable to include such a command in the core protocol?
>>>>
>>>> We have two nearly candidates for that goal:
>>>>
>>>> 1 - The EPP <check> command which is used to determine if an object 
>>>> can be provisioned within a repository.
>>>>
>>>> 2 - The EPP <info> command which is used to retrieve information 
>>>> associated with an existing object.
>>>>
>>>> The problem is that the commands above are designed to check well 
>>>> identified objects each time. If we are not looking for a specific 
>>>> object we get nothing...
>>>>
>>>> As Andrew Sullivan and Frederico Neves already did, I'm working on 
>>>> an I-D detailing some of the DNS.PT experiences with 
>>>> implementation. This extension will be there.
>>>>
>>>> Once I've completed this, I'll be sure to forward it here.
>>>>
>>>> Waiting for feed-back,
>>>>
>>>> Eugenio Pinto
>>>> FCCN - DNS.PT
>>>>
>>>>     
>>>
>>>
>>>
>>>
>>>
>>>   
>>
>
>
>