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
-----Original Message-----
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
regards,
-----Original Message-----
>>>>> Patrick R Gili writes: Patrick> Existing implementations of what? Has
someone implemented 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 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 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 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 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 -- -- archive: <http://ops.ietf.org/lists/xmlconf/> |