Hi John,I just want to be sure I understand your offer (not that it applies to me ;-)Are you looking for operators to volunteers to help assess the advantages of WSDL and SOAP (and possibly UDDI)?Will they be the members of the group you are offering to organize?dbh-----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/>