Re: PROVREG and XML Protocol

Mark,

I looked at SOAP and BXXP (some call it BEEP) and our TCP transport.
I can live with TLS/TCP, I'd love to buse BXXP and I just can't find any
way to justify using SOAP.

While I appreciate your intro on it, you can write a EPP over SOAP
transfer if you like, but most registries have chosen BXXO or TLS/TCP.


-rick

ps my view on soap isn't from an I hate anything that uses http as
   a transport either.


On Wed, 15 Aug 2001, Mark Nottingham wrote:

>
> [ 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 Thursday, 16 August 2001 10:54:24 UTC