Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP)
draft-harold-beep-xmlrpc-03

It is not clear to me whether publishing this on the standards track
*at this time* is entirely sensible.  In particular, there are a lot of
different XML-related efforts going on in and around the IETF, but we don't
appear to have an overall plan or architecture in the XML arena.

I suggest that this I-D be published as Informational or Experimental
RFC *at this time*.  My idea is that we ought to have a plan and
architecture for how we will be using XML-related technologies BEFORE
we publish a lot of standards-track documents in that area.  In particular,
from recent email I understand that there will be some related discussions
in Atlanta at WGs and/or a BOF.  So it seems premature to publish this
as a standards-track document right this minute.

Had this come from a specific IETF WG and had the broader community
involvement, review, and buy-in that a WG generally provides, I might have
a slightly different view.

Publishing the specification as an Informational or Experimental status
RFC permits any interested users have a stable reference for implementation,
without endorsing this approach as the preferred IETF approach.

This document:

http://www.ietf.org/internet-drafts/draft-harold-beep-xmlrpc-00.txt

makes an incorrect fundamental statement:

  XML-RPC is a Remote Procedure Calling protocol that works over the
  Internet.  It defines an XML format for messages that are transfered
  between clients and servers.  The message specifies a procedure to be
  invoked by the server and contains the parameters to use in the
  invocation.  Procedure parameters can be scalars, numbers, strings,
  dates, etc.; they can also be complex record and list structures.

  XML-RPC bindings describe how a specific transport protocol transfers
  XML-RPC formatted messages between clients and servers.  This
  document specifies a binding to the Blocks Extensible Exchange
  Protocol core (BEEP).

In fact, XML-RPC specifies HTTP as its transport.

If a protocol uses BEEP as its transport, it is not XML-RPC.

----------------------------

Is the following an acceptable revision?

  XML-RPC is a Remote Procedure Calling protocol that works over the
  Internet.  It defines an XML format for messages that are transfered
  between clients and servers using HTTP.  An XML-RPC message encodes
  either a procedure to be invoked by the server, along with the
  parameters to use in the invocation, or the result of an invocation.
  Procedure parameters and results can be scalars, numbers, strings,
  dates, etc.; they can also be complex record and list structures.

  This document specifies a how to use the Blocks Extensible Exchange
  Protocol (BEEP) to transfer messages encoded in the XML-RPC format
  between clients and servers.

... WkH

-----------------------------------

Yes, that's okay.

Sections 5.2 describes the URI scheme to be used with TLS.  However, there is no language on the process of authenticating the server's identity (or the peer acting in the server role).  A description on a proper method for checking the server's identity once a TLS session has been established would be beneficial to implementors.  Examples of such language are section 3.1 of RFC 2818 and  section 2.4 of RFC 2595.  Lack of this definition may cause interoperability problems when this specification is put into practice.

In addition, because the URI scheme may explicitly cause SRV lookups, the expected behaviour needed for the server identity check in this case is not evident.  Because an SRV lookup may yield a server presenting a certificate with an identifier different that the one in the authority component of a given URI, the identity check may fail.  Mandatory use of the 'serverName' attribute in this scenario may solve this problem.  An example describing the process would be useful.

Finally, the references section may contain a few problems.  Reference 7 should probably refer to RFC 2732 and reference 10 should probably refer to RFC 3288.