[Ietf-not43] XML-RPC for an information service?

Leslie Daigle leslie@thinkingcat.com
Fri, 26 Jul 2002 13:28:12 -0400


Howdy,

So, the draft looks like a reasonable rough draft of an xml-rpc
based approach to querying a single whois server.  (Rough because
the "todo" count is 13... :-)

But there are a number of basic requirements (for the protocol
and data structure -- not just implementation) that this does
not address.  Heck, look at the first bullet item of this
group's charter:

> The CRISP service definition will define: 
> 
> o a standard mechanism that can be used to determine the 
> authoritative server(s) for information about a given label 

What you are proposing seems based on the assumption that you know
what server you are going to connect to, and then defining some
queries you might make against it.  That's the easy part of what
CRISP is trying to do.  CRISP is tasked with defining a _service_
that will work across the individual servers managed by 
registries, such that a client starting with some label (e.g.
a dns name) can find the authoritative server and make the
relevant query.  For example, the domain name SERVICE is 
not just about the packet format for making dns queries; it's
also about having a well-known, universally-supported mechanism
for navigating the tree of servers to find authoritative information.

There may well be an xml-rpc based approach to solve the CRISP
problem, and perhaps it would be better than iris or ldap-whois.  
But until I'm a little more convinced you understand what problem
this group is solving, I, at least, am not going to spend my time
reading more of your (nice, but not relevant) proposals.

Leslie.


Stephane Bortzmeyer wrote:
> 
> On Wed, Jul 24, 2002 at 07:54:58AM -0700,
>  Ted Hardie <Ted.Hardie@nominum.com> wrote
>  a message of 51 lines which said:
> 
> > whether you are interested in writing a draft describing a CRISP
> > service using XML-RPC.
> 
> Ask and thou shall receive. The draft is here, I'll provide a sample
> implementation soon (anyone has one for IRIS, BTW?).
> 
> Feel free to comments, flame, suggest, etc. But do remember that my
> draft does not follow exactly the same ideas as IRIS: IRIS is more
> open, IRPI is less flexible, in order to be ready faster.
> 
> > Now is the time to put forward other proposals, and a draft specifying
> > how those proposals meet the requirements would be great.
> 
> Nice idea, but the requirments specify both things to be done at the
> protocol level and things to be done only at the implementation level
> (such as rate-limiting functions).
> 
>   ------------------------------------------------------------------------
> 
>    Part 1.2    Type: Plain Text (text/plain)
>            Encoding: 7bit

-- 

-------------------------------------------------------------------
"An essential element of a successful journey
    is recognizing when you have arrived."
       -- ThinkingCat

Leslie Daigle
leslie@thinkingcat.com
-------------------------------------------------------------------