Not sure as to the kind of protocol, but we definitely use SOAP.2. How many folks have a REST-like implementations in their OSS-BSS systems for the kinds of protocols DRINKS is looking out?
No, although we aim towards some REST-like principles in our use of SOAP.
3. In general what data model or protocol properties do your organizations ultimately lean towards - SOAP vs. REST? Other?
As others have said, SOAP is here, but REST has a lot of virtues, We do SOAP, (because our customers do) but would be happy with REST if our customers want it.
4. What are the specific applications that SSP are looking for DRINKS to enable .. LNP?..MMS/SMS interoperability, SIP interconnection etc ?
No opinion... Questions to reach WG concensus on:3. Do you agree that the design team should define the architecture data model independently from the definition of a potential transport protocol? (as far as possible)
Absolutely; data models outlive transports; otherwise we will at some point find ourselves building tunnels to carry the old transport over the new transport.
4. Given the goal to define the data model outside its transport, do you prefer the group to: A. Define a SOAP based transport protocol and if anyone is interested they can work on a RESTful version?
Yes. If the SOAP based one is (I hate this expression :) ) RESTful in architecture, the REST version should be relatively easy. And bearing REST in mind for the SOAP definition should bend it in a simpler, cleaner direction. (Which is not to say the WG wouldn't come up with a clean design regardless; I've just seen SOAP definitions that could have used some REST.)
B. The WG try and do both? No.(Kenneth Cartwright's response to the survey pretty much corresponds to my opinion, with useful detail.)
Jonathan Cronin EGH, Inc.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.