Re: XMLCONF Proposal

[Phil Shafer <phil@juniper.net>]

"Putzolu, David" writes:
>A couple people have already questioned the need to
>define yet another RPCoXML.  I looked at what was done 
>and it seems pretty reasonable, but would like at least 
>to see some justification for not reusing prior art.

The core justification is that none of the existing art was well
suited to the needs of the XMLCONF protocol. These needs are
basically:

- connection-oriented
- capacity for security and privacy
- capacity for authentication
- support for communication channels

The desire for a connection-oriented transport is driven by a desire
for simple resource handling and failure recovery. A developer 
debugging a perl script will be able to exit the perl debugger knowing
that when the connection is closed and the session ends, the server
will release any locked resources and perform appropriate recovery.
The same will happen when an application loses network connectivity
with the server. The connection will fail, the client and server will
be informed, and they can recovery as appropriate.

The XMLCONF protocol relies on the underlaying protocol for security,
privacy, and authentication. The protocol mapping for each underlaying
protocol will specify how this is accomplished and it will vary by
protocol. Certainly both SOAP/HTTPS and BEEP are capable of providing
these facilities.

XMLCONF's use of a distinct channels for management, operations, and
notifications reflects the desire to distinguish between the logical
content flowing over each of these channels. Intermixing XML content
over a single channel makes you choose between two evils. Either
schemas become so general as to be meaningless or painfully repetitive
(since the management operations like <rpc-abort/> can appear
anywhere in the stream of an operation) or management operations are
not documented in the schema. In Junoscript, we chose the latter and
have regretted it.

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

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

Thanks,
 Phil

--
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/>