[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: ietf-provreg@cafax.se
From: Eugenio Pinto <eugenio.pinto@fccn.pt>
Date: Tue, 06 Jun 2006 15:52:29 +0100
In-Reply-To: <44859340.1040705@nic.ve>
Sender: owner-ietf-provreg@cafax.se
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
Subject: Re: [ietf-provreg] a new core command...?

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


Home | Date list | Subject list