Re: XMLCONF Proposal

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Phil Shafer writes:

Phil> While I don't believe the case for SOAP is compelling at this
Phil> time, it may become a requirement in the future. At that some a
Phil> protocol mapping for XMLCONF over SOAP can be defined. There
Phil> should be sufficient flexibility in the spec to allow
Phil> this. Mapping over other protocols (ssh, ssl, serial console)
Phil> are also possible. The rpc mechanism in XMLCONF is trivial to
Phil> implement and can be carried over practically any transport.

Phil> SOAP has generated a large following in other areas, but has not
Phil> generated much excitement in the networking arena. For XMLCONF,
Phil> the benefits of wrapping the XMLCONF protocol in SOAP wrapped in
Phil> HTTP/HTTPS weren't clear to us. If the case for SOAP becomes
Phil> clear at some later point, we can define a mapping to it.

Not sure I understand what you are saying. Here is a figure taken from
the xmconf ID:

         +-------------+      +-----------------------------+
         |   Content   |      |     Configuration data      |
         +-------------+      +-----------------------------+
                |                           |
         +-------------+      +-----------------------------+
         | Operations  |      | <get-config>, <edit-config> |
         +-------------+      +-----------------------------+
                |                           |
         +-------------+      +-----------------------------+
         |     RPC     |      |    <rpc>, <rpc-reply>       |
         +-------------+      +-----------------------------+
                |                           |
         +-------------+      +-----------------------------+
         |  Transport  |      |   BEEP, SSH, SSL, Console   |
         +-------------+      +-----------------------------+

I think with SOAP (or some other existing XML RPC mechanism), it could
look like:

         +-------------+      +-----------------------------+
         |   Content   |      |     Configuration data      |
         +-------------+      +-----------------------------+
                |                           |
         +-------------+      +-----------------------------+
         | Operations  |      | <get-config>, <edit-config> |
         +-------------+      +-----------------------------+
                |                           |
         +-------------+      +-----------------------------+
         |     RPC     |      |           SOAP              |
         +-------------+      +-----------------------------+
                |                           |
         +-------------+      +-----------------------------+
         |  Transport  |      |   BEEP, SSH, SSL, Console   |
         +-------------+      +-----------------------------+

I heard folks wondering why not use an existing RPC layer, which is
different from adding another transport I would say. But I might be
confused since I did not read the draft in detail yet.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>



--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>