Re: PROVREG and XML Protocol

[Rick H Wesson <[e-mail]>]

Mark,

frankly when EPP started SOAP was just an idea with HTTP as atransport and
a Apache module. The Registries need a highly robust transport with as
little cruft ( Apache would be ALOT of cruft ) as possable.

There was also the fact that no transport for SOAP existed at the time
so it was easy to see that SOAP was not an option.

you can still write up the docs for the transport, but you would have to
convince a registry to use if.

IMHO, SOAP isns't anything you would use where speed and security are
required. When it comes down to brass tacks, if we picked SOAP when we
started we wouldn't have any registries going live any time soon, and we
have one up and two more out the door in a couple of months.

Companies cant wait for standards w/o transports.The last time I checked,
I think  thats what we do here, write the standards for whats one the
wire.

Why doesn't the W3C just standardise on BXXP? Or, should I just not ask
that question and leave all the layer 10 questions out of it?

-rick





On Wed, 15 Aug 2001, Mark Nottingham wrote:

>
> Rick,
>
> So, if the work in PROVREG was done with an awareness of SOAP, the
> question that I find interesting is:
>
> Why does EPP use XML for messaging, yet not use what will be XML's
> messaging framework? Is it simply a matter of timing (SOAP is new,
> and there is no TCP binding defined), or is there some other, more
> functional reason?
>
> Anyone else from PROVREG care to comment?
>
> Cheers,
>
>
>
> On Wed, Aug 15, 2001 at 05:15:22PM -0700, Rick H Wesson wrote:
> >
> >
> > 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
> > >   <[e-mail]> and XMLP <[e-mail]> 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:[e-mail]
> > >       Archives; http://www.cafax.se/ietf-provreg/maillist/
> > >   [5] To subscribe; mailto:[e-mail]
> > >       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)
> > >
> >
>
> --
> Mark Nottingham, Research Scientist
> Akamai Technologies (San Mateo, CA USA)
>