-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Thursday, April 24, 2003
3:48 PM
To: 'Juergen Schoenwaelder';
pgili@cisco.com
Cc: xmlconf@ops.ietf.org
Subject: RE: how bad is soap?
I'll join
Juergen in this role at well. It appears that SOAP is more misunderstood than
it is understood. Headers are optional, and again, there's no reason why you
can't use existing SOAP mechanisms (i.e., mustUnderstand) to cut down the
clutter. You could also choose to support a subset of SOAP.
After
talking privately with Bert, here's the offer TO NETWORK OPERATORS on this
list:
If
there is sufficient interest from NETWORK
OPERATORS in seeing what the
advantages of
WSDL and SOAP (and possibly
UDDI) have in
simplifying configuration
management, then
I will organize a group to
write an I-D and
have it published in time
for the Vienna
meeting. If not, have a nice
day. ;-)
regards,
John
John Strassner
Chief Strategy Officer
Intelliden Corporation
90 South Cascade Avenue
Colorado Springs, CO
80903 USA
phone: +1.719.785.0648
FAX: +1.719.785.0644
email:
john.strassner@intelliden.com
-----Original
Message-----
From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de]
Sent: Thursday, April 24, 2003 9:59
AM
To: pgili@cisco.com
Cc: xmlconf@ops.ietf.org
Subject: Re: how bad is soap?
>>>>>
Patrick R Gili writes:
Patrick>
Existing implementations of what? Has someone implemented
Patrick> XMLCONF (or NETCONF, or
whatever we're calling it today)? I
Patrick> would not think that
interoperability would be an issue at this
Patrick> point.
I was
just saying that using an existing RPC mechanism has the advantage that there
are existing implementations to interface with.
Patrick>
In my experience, the SOAP header will exceed the size of most
Patrick> configuration
operations.
Fine. We
might have different environments in mind and we do not have to agree.
Patrick>
I realize that the SOAP encoding is XML. However, I've seen
Patrick> some down-right ugly to
read SOAP headers.
I assume
you mean SOAP headers as defined in section 4.2 of the SOAP 1.1 specification
as follows:
: SOAP
provides a flexible mechanism for extending a message in a
: decentralized and modular way
without prior knowledge between the
: communicating parties. Typical
examples of extensions that can be
: implemented as header entries are
authentication, transaction
: management, payment etc.
:
: The Header element is encoded as
the first immediate child element of
: the SOAP Envelope XML element.
All immediate child elements of the
: Header element are called header
entries.
Sure, if
you put complexity there such as authentication machinery, then header becomes
longer and harder to read. But will it be substantially different from an
xmlconf over beep message with apropriate security?
Patrick>
Observe that I am not presenting an argument against using
Patrick> SOAP. I just want
to make sure that we talk through all the
Patrick> salient points of why
or why not to employ SOAP for the
Patrick> purposes of this
solution.
Sure, I
also just want to make sure we understand why existing RPC mechanisms simply do
not work here and why the costs for a new special purpose RPC mechanism are
well justified. And to really get there, I think someone has to play devils
advocate and right now, it looks like I end up having this role. ;-)
/js
--
Juergen Schoenwaelder
International University Bremen
Phone: +49 421 200 3587
P.O. Box 750 561, 28725 Bremen,
Germany
Fax: +49 421 200 3103
<http://www.iu-bremen.de/>
--
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/>