John,
It's an option that we would like to
see explored. Sign me up.
Keith
Allen
SBC
Technology Resources
9505
Arboretum Blvd.
Austin, TX 78759
(512)
372-5741
kallen@tri.sbc.com
-----Original Message-----
From: John Strassner
[mailto:John.Strassner@intelliden.com]
Sent: Thursday, April
24, 2003 2: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/>