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

[Ted Hardie]

On Fri, Jul 26, 2002 at 01:28:12PM -0400, Leslie Daigle wrote:
> 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:

Note that one of the current proposals is described in multiple
documents.  One of the things I like about this is that it is easy to
bite off chunks of the problem for discussion.  Another thing I like
about it is it lets you see if a new proposal for one element can be
fit into a structure already described.  The answer may well be no,
but I see nothing wrong with proposing a solution to one chunk of the
problem, *provided we as a group can go on to look it in the context
of the whole solution*.  That may mean looking at how this fits
into other solutions already proposed, and it may mean deciding
as a group whether the advantages of a proposal for its problem
chunk are worth building the other bits around it.

In general, it is easier to finish a requirements doc and then work on
the intended solution, and it may be my fault for assuming we could do
the work in parallel at this point.  I hope we can, because we have an
aggressive schedule.  To do that, it is useful for both those
proposing a a solution and those concerned about a solution's
completeness to indicate how it fails to meet the needs of the
service by reference to the requirements document.  If that can't
be done while we wordsmith the requirements document, I believe
we can reference the scope of the problem a particular document
attempts to address.

In an example case, we might have someone put forward an abstract
schema (without reference to the language in which the schema is
expressed).  This would be a substantial chunk of the problem,
and could be discussed as such, but it would have to be seen as
only a part of the larger problem, the "schema chunk" if you will.

In this case, it looks to me like the draft takes on a "transport (or
possibly transaction) chunk".  We can certainly discuss this proposal
in relation to those requirements; we then need to fit the proposal
into the larger picture and understand if it brings specific
advantages or disadvantages when we see it in relation to the other
bits of the problem.

Stephane, is this an accurate reflection of the part of the problem
you meant to tackle?  If so, how do you see it fitting into the
other bits that have been described in the requirements documents
or other proposals (i.e. does it require new methods or can it
inherit from LDAP or IRIS for some of these other chunks?)

			regards,
				Ted Hardie