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

From: [email-masked] (Stephane Bortzmeyer)
Date: Mon, 22 Jul 2002 17:04:48 +0200

Since the list is very quiet and since I wasn't able to attend the
Yokohama meeting, a bit of opinion.

I did not see a mention of this information service:

http://www.adamsnames.tc/api/xmlrpc.html

in the mailing list archives.

A part of it, the domquery and may be conquery procedures, are
directly related to the work of this WG. Any opinion, any user? I'm
specially interested by the fact that it relies on a standard
protocol, for which there are many libraries already available. With
this API, I can write a "whois" client in a few minutes.

---

From: [email-masked] (Andrew Newton)
Date: 22 Jul 2002 11:30:57 -0400

At first glance, this appears to be more like the work being done in the
PROVREG WG than in this one.  Plus I think we are aiming to solve a
couple more problems?

I wonder why they didn't decide to use EPP?

-andy

On Mon, 2002-07-22 at 11:04, Stephane Bortzmeyer wrote:
> _______________________________________________
> Ietf-not43 mailing list
> [email-masked]
> http://lists.verisignlabs.com/mailman/listinfo/ietf-not43

---

From: [email-masked] (Rick Wesson)
Date: Mon, 22 Jul 2002 09:02:55 -0700 (PDT)

andy,

actually its not at all like the epp work in PROVREG, epp is a protocol
for registries to talk to registrars over, epp is not no has it ever been
used to talk to registrants. although they are all simular they each have
different requirements.

This thread does beg the question... has anyone identified reasons not to
pull from the structures defined in epp?

-rick

---

From: [email-masked] (Patrick)
Date: Mon, 22 Jul 2002 18:16:48 +0200

> used to talk to registrants. although they are all simular they each have

But close enough I think...

> pull from the structures defined in epp?

... so that we (Gandi) will work on providing access to data to some
of our customers using EPP. We will see what turns out.

After all, EPP stands for Extensible Provisioning Protocol 
so Registrant provisioning Objects should only be one extension as
another one ;-)

As for the reasons, I think it is probably historical, since EPP is
very young after all.
On http://www.adamsnames.tc/api/xmlrpc.html it's written:
Last Modified: Wed Apr 11 08:06:03 2001
at which time EPP was not so defined as it is now.

Otherwise I agree that this WG is far further than just XMLRPC or
EPP.

Patrick.

---

From: [email-masked] (Andrew Newton)
Date: 22 Jul 2002 13:44:58 -0400

> But close enough I think...
[..snip..]
> so Registrant provisioning Objects should only be one extension as

And perhaps this may have been what James Seng was talking about when he
gave his OPP presentation (though, he may have conceptualized a few more
nodes in his network graph than is needed for this particular use case).

-andy

---

From: [email-masked] (Patrick)
Date: Mon, 22 Jul 2002 20:20:27 +0200

> nodes in his network graph than is needed for this particular use case).

Any link/reference for this presentation ?

Patrick.

---

From: [email-masked] (Edward Lewis)
Date: Mon, 22 Jul 2002 14:46:42 -0400

>Any link/reference for this presentation ?

No...

 From http://www.ietf.org/proceedings/01aug/index.html:

2. OPP Presentation - James Sang
Slides unavailable.

Mark Nottingham - Did you use existing XML protocol rather than 
develop a new DTD?

JS - Other author needs to answer. MN -I'll bring it to the list

Dave Crocker - What within EPP does not meet the needs of China?

JS - EPP is a 2 entity protocol, does not support communications btwn 
other nodes (r'ant-r'ar, r'ar-r'ar, etc.). (Ask Dave.)

Eric Brunner-Williams - What kind of graph is OPP?

Rich Shockey - How will you maintain transactional intergrity btwn the nodes?

JS - Every request is signed by each node.

RS - Do you prefer any transport protocol?

JS - No we are transport agnostic.

Dave Crocker - Clarification

Jordyn Buchanan - Can't EPP meet your needs if we added the 
requirements for signatures btwn nodes?

Mark Nottingham Guy - Do you plan on using XML schema rather than new DTD

Dan Manly - How do you make sure proper security is in each node?

Rich Shockey - What application would require coordination btwn four nodes?

Jordyn Buchanan - R'ant need to authenticate with a r'y, discussed on 
the list and has been desire of some ccTLDs.

JS - Multiple tiered phone companies. Scott Hollenbeck response to 
JB, current EPP draft doesn't provide this capability, but there's o 
reason why it couldn't be updated or extension added.

EL - Should the WG accept the document?

Dave Crocker - Not good to have two protocol documents but we could 
try to address the needs met in the document by integrating it into 
EPP documents.

EL - It may be best for JS to get the document where he wants it 
before accepting it.

George Ballotsky - Process is too rushed to get a good protocol.

EL - We'll take the question to the list.

(Document has since been withdrawn from consideration.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: [email-masked] (Stephane Bortzmeyer)
Date: Tue, 23 Jul 2002 14:34:36 +0200

On Mon, Jul 22, 2002 at 11:30:57AM -0400,
 Andrew Newton <[email-masked]> wrote 
 a message of 31 lines which said:

> PROVREG WG than in this one.

Not at all. The XML-RPC interface of Adam's Names merges two tasks:
provisioning of objects (the conreg and domreg procedures) and
querying of objects (the domquery and conquery procedures). In this
WG, I was referring to the second one, which can be seen as a
competitor to IRIS.

> I wonder why they didn't decide to use EPP?

Besides the timing issue, there is the simple fact that one can
implement Adam's Names interface in one day, something that is far
from the huge complexity of EPP... (flames welcome but remember they
are off-topic in that WG).

---

From: [email-masked] (Stephane Bortzmeyer)
Date: Wed, 24 Jul 2002 12:46:15 +0200

On Mon, Jul 22, 2002 at 05:04:48PM +0200,
 Stephane Bortzmeyer <[email-masked]> wrote 

> http://www.adamsnames.tc/api/xmlrpc.html

And another example:

A new XML-RPC based service someone might be interested in:

DoWhois is an XML-RPC based whois client. It supports lookups for a
variety of different domain types as weel as IP addresses. It can also
handle 'thin' registries (such as com) where individual registrars
maintain their own whois servers.

One important feature is its ability to decode some whois results into
their constitunt parts, so names, addresses, nameservers, etc are easily
found and can be used by automated scripts.

The service can both be used from the main website plus can be
downloaded and installed on your own server.

Version 0.02alpha has just been released. For more info (and to try a
web based smaple client) from the website - http://www.DoWhois.com/

---

From: [email-masked] (Ted Hardie)
Date: Wed, 24 Jul 2002 07:54:58 -0700

Stephane,

Thanks for the pointer to DoWhois and to starting this conversation
on the list.  I am interested in the idea of XML-RPC, and I wonder
whether you are interested in writing a draft describing a CRISP
service using XML-RPC.  While we have not yet moved the requirements
document into the AD's queue, we are fairly far along on it and
it certainly can be used to begin parallel development of 
documents proposing specific solutions.

At the moment, we have one document proposing an LDAP-based solution
and one set of documents proposing IRIS (with a binding to HTTP).
Now is the time to put forward other proposals, and a draft specifying
how those proposals meet the requirements would be great.

			regards,
				Ted Hardie

---

From: [email-masked] (Andrew Newton)
Date: 24 Jul 2002 11:47:31 -0400

> A new XML-RPC based service someone might be interested in:

What about other generic RPC mechanisms such as SOAP and/or CORBA/IIOP?

-andy

---

From: [email-masked] (Stephane Bortzmeyer)
Date: Wed, 24 Jul 2002 18:05:33 +0200

On Wed, Jul 24, 2002 at 11:47:31AM -0400,
 Andrew Newton <[email-masked]> wrote 

> What about other generic RPC mechanisms such as SOAP and/or CORBA/IIOP?

Very good question. 

SOAP : still a moving target, quite complicated partly because of
featurism, interoperability problems.

Corba : not really in the same category. But I would say that it is
overkill when you have only two partners (a client and a server, like
in IR protocols).

---

From: [email-masked] (Patrick)
Date: Thu, 25 Jul 2002 14:24:21 +0200

> A new XML-RPC based service someone might be interested in:

[..]

> web based smaple client) from the website - http://www.DoWhois.com/

FYI, Gandi::WhoisExtract [1] does the same thing, except the parse is not
so generic (but that could be easily achieved), and it does not use
XML-RPC (whish should also be very easy to use). 
However it correctly parses around 80 (IIRC) Registrars under
.com/.net/.org (which does not seem to be the case of dowhois)
It is production quality code and really used. Available under a BSD
licence. Done in Perl OO.

However I really think that this WG has a far bigger aim than parsing
whois and stuff like that.
XML-RPC can be an idea as for the transport, but other than that...

Patrick.

[1] http://open.gandi.net/

---

From: [email-masked] (Stephane Bortzmeyer)
Date: Fri, 26 Jul 2002 11:53:10 +0200

--x+6KMIRAuhnl3hBn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Jul 24, 2002 at 07:54:58AM -0700,
 Ted Hardie <[email-masked]> wrote 
 a message of 51 lines which said:

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

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

--x+6KMIRAuhnl3hBn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="draft-bortzmeyer-irpi.txt"

Network Working Group                                      S. Bortzmeyer
Internet-Draft                                                     AFNIC
Expires: January 24, 2003                                  July 26, 2002

                 Internet Registry Procedural Interface
                         draft-bortzmeyer-irpi

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 24, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   DRAFT OF DRAFT - DO NOT USE YET

   This document describes a procedural interface to query the database
   of an Internet Registry, for instance the various contacts for a
   domain.

   It is specified as an API for the XML-RPC protocol.

   It is intended to be simple and easy to implement.  It is not a full
   solution to a complicated problem, but a way to get rid of whois more
   rapidly.

Bortzmeyer              Expires January 24, 2003                [Page 1]

Internet-Draft    Internet Registry Procedural Interface       July 2002

1. Introduction

   The specification outlined in this document is based on the
   functional requirements described in the Internet Registry Directory
   requirments [5].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [9].

1.1 General view

   IRPI is specified as an Application Programming Interface of XML-RPC
   [1].  XML-RPC is a way to call remote procedures, here we assume that
   the RPC callee will be on a Registry machine and that the caller
   wants to access information in the Registry.

   XML-RPC provides a way to marshall parameters, send them over HTTP ,
   retrieve the results and unmarshall them.  The results can be
   structured.  They can also be a fault, i.e.  an exception.  The rest
   of this document will assume familiarity with XML-RPC.

1.2 Transport

   XML-RPC specifies only one transport, HTTP.  But it should be
   straightforward to make IRPI run over other non-standard transports
   like Jabber [8].

1.3 Objects

   IRPI has a fixed set of objects, unlike, for instance, IRIS [6].
   This is to make it simpler and easier to implement fast.  A general-
   purpose Internet directory is out of scope.

Bortzmeyer              Expires January 24, 2003                [Page 2]

Internet-Draft    Internet Registry Procedural Interface       July 2002

2. The API

2.1 General rules for the server

   The server MUST implement the introspection API [7].

   The server MUST reacts gracefully (sending a fault) to calls of
   unknown methods.

   The server MUST accepts XML-RPC structs with unknown members (in
   order to extend the protocol in the future) and SHOULD ignore them.
   It MUST accepts XML-RPC arrays with more elements than expected and
   SHOULD ignore them.

2.2 General rules for the client

   The client SHOULD use the introspection API [7] before trying
   methods.

   The client MUST accepts XML-RPC structs with unknown members (in
   order to extend the protocol in the future) and SHOULD ignore them.
   It MUST accepts XML-RPC arrays with more elements than expected and
   SHOULD ignore them.

2.3 Credentials

   Credentials are always transmitted as XML-RPC structs.  If they are
   empty (no members), it means the client has no credential to present.
   If they are non-empty, credentials always have the member "name" (a
   string) and they also have the possible members (at least one must be
   present):

      password: a plain password

      signature: TODO.  Sign what, a concatenation of the parameters,
      and how, X509 or OpenPGP?

   If non-empty credentials are presented, they MUST be checked.

   TODO: describe how the server may use the underlying authentication
   (X509 client certificate if https).  The server may also use other
   underlying information (such as the client's IP address) before
   deciding to send data or not.

   When the reply includes several named members, the server MAY choose
   to omit some for privacy reasons, depending on the client.  The
   client MUST reacts gracefully to such missing members.  TODO: a way
   for the client to discover if the information exists? Not sure it

Bortzmeyer              Expires January 24, 2003                [Page 3]

Internet-Draft    Internet Registry Procedural Interface       July 2002

   would not help the stalker.

2.4 Exceptions

   Every procedure may return faults (raise exceptions).  XML-RPC [1]
   does not define standard faults so we specify these (as faultCode and
   explanation, you may choose a different faultString):

      TODO: should we specify the fault for an nonexisting method?

      400: Badly formed request

      403: Access forbidden

      404: No such object

2.5 Mandatory procedures

   All the mandatory procedures are prefixed by 'registry.'.  Adding new
   procedures whould be done with the prefix 'registry-local.', in order
   to avoid name clashes.

      queryDomain (name <string>, credentials <struct>) returns
      <struct>.  The struct has the following members (remember that
      some may be missing, either for privacy reasons or because this
      information has no meaning for a given registry):

         name <string>

         status <string> TODO: define statuses, using the enumerated
         values of EPP domain mapping [3]?

         registered <dateTime.iso8601>

         modified <dateTime.iso8601>

         expires <dateTime.iso8601>

         holder <string> TODO: name it registrant because EPP and IRIS
         call it that way?

         technical_c <string>

         administrative_c <string>

         billing_c <string>

Bortzmeyer              Expires January 24, 2003                [Page 4]

Internet-Draft    Internet Registry Procedural Interface       July 2002

         comments <string>

         TODO: maintainer like in RIPE-NCC registry?

         nameservers <array> This array is made of two-members structs,
         each struct has two strings, "name" and "address" (the second
         may be missing if the registry does not keep that information
         for a given nameserver).

      queryContact (handle <string>, credentials <struct>) returns
      <struct>.  The returned struct has the following members (remember
      that some may be missing, either for privacy reasons or because
      this information has is not kept by a given registry):

         handle <string>

         registered <dateTime.iso8601>

         modified <dateTime.iso8601>

         status <string> TODO: define statuses, using the enumerated
         values of EPP contact mapping [4]?

         address <struct> This struct is made of:

            street <string> TODO: several strings?

            city <string>

            country <string>

            email <string>

            phone <string>

            fax <string>

            zipcode <string>

         TODO: maintainer like in RIPE-NCC registry?

      queryHost (info <struct>, credentials <struct>) returns <struct>.
      The input struct has one member, either "name" when you indicate
      the name of the host or "ipaddress" when you indicate its address.
      The returned struct has the following members:

         name <string>

Bortzmeyer              Expires January 24, 2003                [Page 5]

Internet-Draft    Internet Registry Procedural Interface       July 2002

         ipaddress <string>, may be missing if the registry does not
         keep it.  TODO: and if several addresses?

2.6 Optional procedures

   All the optional procedures are prefixed by 'registry.'.  Adding new
   procedures whould be done with the prefix 'registry-local.', in order
   to avoid name clashes.

      queryObject, query an obect without specifying the type.  TODO:
      describe the API

      queryIPaddress, query an IP address, for a RIR or an IRR, although
      it is outside of the scope of our requirments [5].

      search, fuzzy search, with regexps or things like that.  TODO:
      very dangerous for privacy.

2.7 Extending the API

   You can extend the above API in several ways:

      A registry can add new procedures, prefixed by 'registry-local.'.

      A registry can add new fields to structs passed or returned.
      These fields SHOULD be prefixed by 'x-'.

   Other extensions (such as adding parameters to procedures) are
   prohibited.

Bortzmeyer              Expires January 24, 2003                [Page 6]

Internet-Draft    Internet Registry Procedural Interface       July 2002

3. Internationalization Considerations

   Contact information, such as names and addresses may be stored in
   Unicode and sent back in whatever encoding the caller or the callee
   chose.  The general rules of XML apply: UTF-8 and UTF-16 encoding
   MUST be supported by the parties.  Other encodings SHOULD NOT be used
   unless there is a serious reason to believe they are supported by the
   other party (XML-RPC does not allow encoding negociation).

   IDN domain names MUST be in ACE encoded form.  It is up to the client
   to translate.

Bortzmeyer              Expires January 24, 2003                [Page 7]

Internet-Draft    Internet Registry Procedural Interface       July 2002

4. Security considerations

   There are many privacy and authentication considerations at various
   places of that document.  Apart from authentication, IRPI completely
   resides on the layers below for its security against passive
   eavesdropping or session replay.  The security model in XML-RPC
   defers all the security to the transport layer.  So you should use
   HTTPS and not HTTP is security is a concern.  See also the
   requirments [5] for a general discussion of security of an Internet
   Registry Directory.

Bortzmeyer              Expires January 24, 2003                [Page 8]

Internet-Draft    Internet Registry Procedural Interface       July 2002

References

   [1]  UserLand Software, "The XML-RPC protocol", November 2001,
        <http://www.xml-rpc.com/>.

   [2]  AdamsNames, "AdamsNames XMLRPC API", April 2001, <http://
        www.adamsnames.tc/api/xmlrpc.html>.

   [3]  Hollenbeck, S., "Extensible Provisioning Protocol Domain
        Mapping", draft-ietf-provreg-epp-domain-04 (work in progress),
        January 2002.

   [4]  Hollenbeck, S., "Extensible Provisioning Protocol Contact
        Mapping", draft-ietf-provreg-epp-contact-04 (work in progress),
        January 2002.

   [5]  Newton, A., "Internet Registry Directory Requirements", draft-
        newton-ir-dir-requirments-00 (work in progress), June 2002.

   [6]  Newton, A., "Internet Registry Information Service", draft-
        newton-iris-00 (work in progress), February 2002.

   [7]  Dumbill, Edd., "XML-RPC introspection API", Unknown Unknown,
        <http://xmlrpc.usefulinc.com/doc/reserved.html>.

   [8]  Adams, DJ., "Jabber RPC", September 2001, <http://
        www.pipetree.com/jabber/jrpc/>.

   [9]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, March 1997.

Author's Address

   Stephane Bortzmeyer
   AFNIC
   Immeuble International
   Saint-Quentin en Yvelines cedex  78181
   France

   Phone: +33 1 39 30 83 46
   EMail: [email-masked]

Bortzmeyer              Expires January 24, 2003                [Page 9]

Internet-Draft    Internet Registry Procedural Interface       July 2002

Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Bortzmeyer              Expires January 24, 2003               [Page 10]


--x+6KMIRAuhnl3hBn--

---

From: [email-masked] (David Blacka)
Date: Fri, 26 Jul 2002 11:24:29 -0400

>>>>> "Stephane" == Stephane Bortzmeyer <[email-masked]> writes:

 >> whether you are interested in writing a draft describing a CRISP

 Stephane> Ask and thou shall receive. The draft is here, I'll provide
 Stephane> a sample implementation soon (anyone has one for IRIS,
 Stephane> BTW?).

Actually, I have a sample IRIS implementation (at least for the domain
registry portion).  I'm not sure when I will be able to make it
generally available though.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

From: [email-masked] (Leslie Daigle)
Date: 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:
>   ------------------------------------------------------------------------
> 
>    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
[email-masked]
-------------------------------------------------------------------

---

From: [email-masked] (Andrew Newton)
Date: Fri, 26 Jul 2002 14:27:23 -0400

> featurism, interoperability problems.

Actually, I disagree with this.  There are many, many pieces of software 
that can use SOAP.  Perhaps a good comparison between the XML-RPC and 
SOAP would be good.  I think I would be more supportive of a SOAP standard.

> overkill when you have only two partners (a client and a server, like

What!? I disagree with this, but considering nobody is considering 
specifying this via CORBA, let's drop this subject.

However, I do think there is a significant difference between something 
like IRIS (and also EPP) and just using a generic RPC mechanism like 
XML-RPC, SOAP, CORBA, DCE, etc...  IRIS defines ways of talking about 
different registry types, not just different registry instances.  This 
can be modeled within SOAP or whatever, but the use of a generic RPC 
mechanism gives you enough rope to hang yourself.  It also does not 
allow the finer grain of control that is sometimes desirable.  And in 
this instance, it can easily slide into functions clearly outside the 
charter of this group, such as registryDomain( domainName ).

As for the speed it takes to implement a client that can simply query a 
server for domain information, I think the LDAP-WHOIS proposal has this 
pretty much zipped up.  It can be done in about 5 seconds using the 
'ldapsearch' command.

-andy

---

From: [email-masked] (Ted Hardie)
Date: Fri, 26 Jul 2002 14:03:06 -0700

> implementation soon (anyone has one for IRIS, BTW?).

Thanks for putting together a draft; I'll review it in detail as
soon as I can, as, I am sure, will other members of the list.

> (such as rate-limiting functions).

Hmm. If it does suggest something at the implementation level it's a
doc bug.  The draft is meant to describe how the *service* should work
and that includes both on-the-wire and off the wire details.
Implementation details (like "use this Java package" or "use XML
namepsaces" or even "avoid buffer overuns") don't belong there.
If you see things in there that reach into implementation, please
note them to the list, so we can disucss removing them.
				thanks,
					Ted Hardie

---

From: [email-masked] (Ted Hardie)
Date: Fri, 26 Jul 2002 14:39:50 -0700

> not address.  Heck, look at the first bullet item of this

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