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

From: [email-masked] (Stephane Bortzmeyer)
Date: Wed, 7 Aug 2002 14:34:23 +0200

On Fri, Jul 26, 2002 at 01:28:12PM -0400,
 Leslie Daigle <[email-masked]> wrote 
 a message of 75 lines which said:

> What you are proposing seems based on the assumption that you know
> what server you are going to connect to, 

Right. Referrals are another TODO.

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

Your explanation is very clear and precise but does not reflect the
work I've seen on this WG. The IRIS draft, for instance, is not very
detailed on this point and, like my proposal, focus on interaction
with a given server.

> such that a client starting with some label (e.g.
> a dns name) can find the authoritative server and make the
> relevant query. 

This could be done on the client-side, too, like many whois clients do
at the present time.

"\.(com|net|org)" -> whois.networksolutions.com
"\.(info)"        -> whois.affilias.info
"\.(.*)           -> whois.nic.$1

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

Glad you mention it. I could add just one line saying that the
authoritative server is found with RFC 2782.
  
> But until I'm a little more convinced you understand what problem
> this group is solving, 

I understand much better the issues, thanks to your explanations. But
I agree with the Ted Hardie's point of view: Crisp has several
problems to solve and my proposal more-or-less fits one (querying a
given server). Unlike you, I do not think it is the less important
question.

---

From: [email-masked] (Stephane Bortzmeyer)
Date: Wed, 7 Aug 2002 14:36:22 +0200

On Fri, Jul 26, 2002 at 02:39:50PM -0700,
 Ted Hardie <[email-masked]> wrote 
 a message of 58 lines which said:

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

Not completely because my proposal also addresses the schema chunk
(unlike IRIS which postpones the actual schema discussion, since it is
not clear we can all agree on a common schema).

---

From: [email-masked] (Stephane Bortzmeyer)
Date: Wed, 7 Aug 2002 14:38:59 +0200

On Fri, Jul 26, 2002 at 02:03:06PM -0700,
 Ted Hardie <[email-masked]> wrote 
 a message of 595 lines which said:

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

OK, I rephrase it in another way. The current requirments specify
things that have to be done when designing the protocol (i.e. the
drafts on IRIS or IRPI has to specify something that will fit the
requirments) and it also specify things that will have to be done when
actually implementing a service (like rate-limiting functions).

Hence, no protocol proposal (LDAP, IRIS, etc) can actually fulfill 100
% of the requirments.

---

From: [email-masked] (Stephane Bortzmeyer)
Date: Wed, 7 Aug 2002 14:44:08 +0200

On Fri, Jul 26, 2002 at 02:27:23PM -0400,
 Andrew Newton <[email-masked]> wrote 
 a message of 35 lines which said:

> I think I would be more supportive of a SOAP standard.

Could you explain why? A good explanation would be a proposal using
SOAP, with features that cannot be done in XML-RPC (for those who
never tried SOAP or XML-RPC, <summary level="rough">SOAP is a superset
of XML-RPC</summary>).
 
> this instance, it can easily slide into functions clearly outside the 
> charter of this group, such as registryDomain( domainName ).

You are absolutely  right. I am reading
<URL:http://www.cafax.se/ietf-provreg/maillist/2001-01/msg00189.html>
to study this issue :-)

---

From: [email-masked] (Patrick)
Date: Wed, 7 Aug 2002 16:41:03 +0200

> "\.(info)"        -> whois.affilias.info

A system that would not need to update *all* client software to
change something is something interesting... Like DNS for example:
you do not need to change your resolver when ICANN adds a new TLD.

It could be done, but it should not to. That is my point of view.
The mechanism in place should handle this sort of things
transparently.
Also I am not sure a system like the one you propose could be used
for all purposes in CRISP. Ok, easy for domain names (at least now),
but how for IPv4 adresses ? You plan to have each client software
having a mapping between netmasks and IP Registries ?

Personnally I would imagine that something like DNS SRV records may
be useful.

> given server). Unlike you, I do not think it is the less important

I would dare to say that it is the easier part. This is also a part where
many ideas already exists (SOAP, RPC-XML, Corba, whatever), and it
``just'' needs to be adapted to the current setup. It is not to say
that your work is less important, just that there are other parts.
(the charter have 6 points, querying is one among the 6)

Ok, I have done nothing, so who I am to criticize anyway...

Patrick.

---

From: [email-masked] (Patrick)
Date: Wed, 7 Aug 2002 16:48:26 +0200

On Wed, Aug 07, 2002 at 02:44:08PM +0200, Stephane Bortzmeyer took time to =
write:
>  Andrew Newton <[email-masked]> wrote=20
>=20
>=20
> never tried SOAP or XML-RPC, <summary level=3D"rough">SOAP is a superset
> of XML-RPC</summary>).

Probably a good start for a comparison:
http://weblog.masukomi.org/writings/xml-rpc_vs_soap.htm
(particularly the last =A7)

Based on that, and what I know, I would also favor SOAP over XML-RPC.
Mainly because the thing_to_be_designed is not just about passing
domain names between a client and a server. It is about passing
``something'' between a client and many servers (with the task of
choosing the right one).

Patrick.

---

From: [email-masked] (Andrew Newton)
Date: Wed, 07 Aug 2002 10:39:20 -0400

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zark-31653-1028731762-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> > a dns name) can find the authoritative server and make the

It is in the back of the IRIS drafts on the TODO list.  Anyway, the
forthcoming IRIS drafts will have it in there.

Anyway, I think we can all thank Eric Hall for providing the clue that
got us all to this point.  His LDAP-WHOIS drafts quite clearly spell-out
how this works.

-andy
--=_zark-31653-1028731762-0001-2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--=_zark-31653-1028731762-0001-2--

---

From: [email-masked] (Andrew Newton)
Date: Wed, 07 Aug 2002 10:40:24 -0400

--=_zark-31721-1028731826-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> not clear we can all agree on a common schema).

Yes it does.  Read the DREG draft.

-andy
--=_zark-31721-1028731826-0001-2

--=_zark-31721-1028731826-0001-2--

---

From: [email-masked] (Andrew Newton)
Date: Wed, 07 Aug 2002 11:08:57 -0400

--=_zark-32294-1028733538-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> never tried SOAP or XML-RPC, <summary level="rough">SOAP is a superset

Why SOAP over XML-RPC?
1) Dave Winer has even moved on.  He co-authored the first SOAP spec.
2) XML-RPC is tied to HTTP (as is SOAP 1.0).  To understand why the
firewall-bypass protocol is a bad idea, read RFC 3205.
3) XML-RPC is copyright Dave Winer, with a fairly liberal copyright. 
SOAP 1.2 will be a W3C spec.  That makes some people a little more
comfortable (and, I hate to say it, even me).
4) SOAP implementations are available from open source good guys and the
likes of enterprise solutions providers such as IBM, MicroSoft, BEA,
etc.

However, I don't think it is right of us to dismiss your idea at least
without a proper explanation.  I had to think about it some more to
actually get an answer I felt comfortable with.

Both XML-RPC and SOAP are abstraction layers intended to divorce the
"business logic" programmer of the murky details of the layers
underneath.  However, what we are proposing also involves the use of DNS
SRV or NAPTR records to a greater extent than can be found in most
library implementations.  This means the implementer will need a fair
bit of knowledge about the total solution anyway.

In addition, both XML-RPC and SOAP 1.0 seem to violate RFC 3205.  This
isn't good.  While there is a SOAP to BEEP spec that could get around
this, I would bet you'd be hard pressed to find an implementation of it
that suits your needs.  This also eliminates your ability to plug-in the
underlying stuff and just go.

-andy
--=_zark-32294-1028733538-0001-2

--=_zark-32294-1028733538-0001-2--

---

From: [email-masked] (Stephane Bortzmeyer)
Date: Wed, 7 Aug 2002 17:41:27 +0200

On Wed, Aug 07, 2002 at 11:08:57AM -0400,
 Andrew Newton <[email-masked]> wrote 
 a message of 95 lines which said:

> 2) XML-RPC is tied to HTTP (as is SOAP 1.0).

There are implementations of XML-RPC over Jabber and BEEP (under
construction). However, I agree they are extensions of the original
spec (like many good things in XML-RPC, like the introspection API or
the Unicode support).

>  To understand why the firewall-bypass protocol is a bad idea, read
> RFC 3205.

I've read it and, like many people, I disagree with it. If I have a
XML-RPC server which uses HTTP and listens on port 8080, explain how
it violates firewall rules. And what is the difference between a
XML-RPC server using port 80 and a CGI?

> comfortable (and, I hate to say it, even me).

Me too. It is clearly a problem with XML-RPC. Should I start an IETF
WG to standardize XML-RPC? :-) (I'm joking but it is how the IETF made
SSL into the IETF-compliant TLS.)

> likes of enterprise solutions providers such as IBM, MicroSoft, BEA,

Same thing for XML-RPC.

> isn't good.

It does not bother me. SOAP 1.0 violates it less (thanks to the
SOAPAction header but SOAP 1.2 will deprecate it).