PROVREG and XML Protocol

[ I'm posting this message to both the PROVREG
  <ietf-provreg@cafax.se> and XMLP <xml-dist-app@w3.org> lists, to
  promote discussion.  AFAIK both lists accept posts from
  non-subscribed addresses; please trim the distribution if your
  message would only be interesting to one, or if the discussion
  starts to take up too much bandwidth. Thanks. ]

I got up at the PROVREG meeting in London to point out some
similarities in that group's work and the XMLP WG in the W3C.

This note is intended to generate discussion of SOAP as a potential
framework for use by PROVREG, as well as to stimulate feedback to the
XML Protocol WG regarding SOAP's suitability for such uses.


* Introduction

The IETF Provisioning Registry (PROVREG) Working Group has been
chartered [1] to provide a "protocol that enables a registrar to
access multiple registries." Furthermore, the group "... will
consider support for multiple operational choices, such as for
transport and security; it will create no new transport or security
protocols."

The W3C XML Protocol Working Group has been chartered [2] to provide
a framework for XML messaging, using SOAP [3] as a starting point.
Although SOAP is commonly believed to be only
'RPC-using-XML-over-HTTP', the group is bound to deliver
transport-agnostic services which enable a wide variety of
applications beyond RPC.

Superficially, it appears that XMLP may provide a framework with
which to implement a PROVREG protocol, with a number of advantages
and efficiencies, as such uses are within the scope of its charter.

This note seeks to examine the requirements of PROVREG from the
perspective of SOAP, both to bring XMLP's work to the attention of
PROVREG, and to generate feedback to XMLP about the suitability of
SOAP for uses such as PROVREG's. Additionally, it attempts to point
out the requirements and context of PROVREG to XMLP, in the hope that
it will serve as a use case for XMLP.

This note does not propose a SOAP-based registry protocol, and only
represents the thoughts of the author. Discussion should be directed
to the provreg mailing list [4] and the xml-dist-app [5] mailing list
as appropriate.


* XMLP Context and Deliverables

The XML Protocol Working group is charged with delivering a framework
for XML messaging, based on the SOAP submission. There are four
defined deliverables;

 1. A Message Envelope, which contains the XML message
 2. A Serialization Mechanism, to represent data structures as XML
 3. A Transport Binding, to move messages around; initially, HTTP
 4. An RPC Convention, to enable applications which require this common
    funtionality

However, the charter implies a more abstract architecture which, in
combination with these basic deliverables, has the following
attributes;

- A message processing model, which allows common functionality to be
  modularised.

  SOAP's processing model enables common functions like encryption,
  application of policy, caching, message routing, etc. to be
  standardized as Modules. This promotes interoperability and reduces
  the amount of replicated code - and specification - necessary to
  enable a service.

  Currently, a few modules have been defined, including one for XML
  Digital Signatures [6], which also encompasses encryption, and
  SOAP-RP [7], which enables multi-hop routing in SOAP.

- Intermediary targetting, to allow message processing to be
  distributed across nodes.

  SOAP is unique, in that it allows message functionality to be
  targetted at particular intermediary nodes. This allows, for
  example, a caching Module to be applied at a particular place in
  the network, or likewise a non-repudiation Module to be invoked
  between two unknown parties. SOAP's intermediary targetting
  operates as a modification of the message processing model (the
  'actor' attribute).

- Transport abstraction, allowing XML messages to be bound to and
  moved around by a variety of protocols.

  One of the core requirements for XML Protocol is to be able to bind
  messages to an arbitrary "underlying protocol", whether it be HTTP,
  BEEP, TCP or UDP.  This, more than anything, frames XMLP (and
  therefore SOAP) as an XML messaging framework, rather than a
  purpose-specific protocol. SOAP originally defined a HTTP binding;
  more recently, a BEEP binding [8] has been drafted, with discussion
  of bindings to TCP and SMTP in the near future.

- A framework for message exchange patterns, to allow business
  protocols to be defined.

  One of the consequences of transport abstraction is the ability to
  build application message exchange patterns that are separate from
  the underlying protocols' messaging patterns. For example, while
  HTTP has a request-response pattern, SOAP applications may use it
  as part of a larger, orchestrated service that spans multiple HTTP
  connections or even multiple underlying protocols.

- A means of propogating status and error information, through
  Faults.



* PROVREG Context and Requirements

PROVREG is charged with delivering a business protocol that enables
registration. The target application is the registration of domain
names, but the group is also considering other uses of a registration
mechanism.

PROVREG's preliminary requirements [9] include:

  Communications Interfaces

    Registries, registrars, and registrants interact using a wide
    spectrum of communications interfaces built upon multiple
    protocols, including transport layer protocols such as TCP and
    application layer protocols such as SMTP.  The protocol SHOULD be
    serviceable over multiple standard communications protocols.

  Extensibility

    Extensibility is a measure of the extent to which a protocol can
    be adapted for future uses that were not readily evident when the
    protocol was originally designed.  The protocol SHOULD provide
    features that at a minimum allow for the management of new object
    types without requiring revisions to the protocol itself.

The initial specification of a PROVREG protocol is the Extensible
Provisioning Protocol (EPP) [10]. EPP describes itself as;

  EPP is an XML protocol that can be layered over multiple transport
  protocols.  Protected using lower-layer security protocols, clients
  exchange identification, authentication, and option information,
  and then engage in a series of client-initiated command-response
  exchanges.  All EPP commands are atomic and idempotent.

  EPP provides four basic service elements: service discovery,
  commands, responses, and an extension framework that supports
  definition of managed objects and the relationship of protocol
  requests and responses to those objects.

EPP abstracts out the transport by allowing multiple mappings; the
first [11] is onto TCP.  Establishing a mapping to BEEP has been
discussed.


* Recommendations

Both of these efforts are works in progress; XMLP is more than
halfway through a clarification process which will culminate in SOAP
1.2; PROVREG is just staring to gather consensus about its
requirements, and is still entertaining candidates for a protocol.

Fundamentally, this note is intended to generate cross-discussion
between the groups, to introduce the work in SOAP to PROVREG, and to
gather feedback about SOAP from PROVREG.

In particular, PROVREG may benefit from considering SOAP, in part or
whole, as a framework for its deliverables. If there is sufficient
interest, an I-D outlining how EPP could use SOAP may be generated.
Otherwise, PROVREG may benefit from individual works in XMLP,
including the concepts surrounding the transport abstraction, the
transport bindings themselves, and XMLP's tentative use of XML
Infoset to describe a protocol.

Likewise, if after consideration SOAP is felt inappropriate to
PROVREG's purposes, or if it is deemed unintelligable, this feedback
is valueable to XMLP, as uses such as PROVREG should be addressable
by the output of the Working Group.

I'd ask that, to start, interested PROVREG WG members read the SOAP
1.2 working draft [12], and generate feedback to both lists as
appropriate. I'll be happy to draft an I-D (with help, hopefully) if
there's interest.


  [1] http://www.ietf.org/html.charters/provreg-charter.html
  [2] http://www.w3.org/2000/09/XML-Protocol-Charter
  [3] http://www.w3.org/TR/SOAP/
  [4] To subscribe; mailto:ietf-provreg-request@cafax.se
      Archives; http://www.cafax.se/ietf-provreg/maillist/
  [5] To subscribe; mailto:xml-dist-app-request@w3.org
      Archives; http://lists.w3.org/Archives/Public/xml-dist-app/
  [6] http://www.w3.org/TR/SOAP-dsig/
  [7] http://www.gotdotnet.com/team/xml_wsspecs/soap-rp/default.html
  [8] http://search.ietf.org/internet-drafts/draft-etal-beep-soap-03.txt
  [9] http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-03.txt
  [10] http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-04.txt
  [11] http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-02.txt
  [12] http://www.w3.org/TR/soap12/


-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

Received on Wednesday, 15 August 2001 18:29:29 UTC