WG Chair HAT off. > > General questions regarding deployed transport protocols: > > 1. How many folks have SOAP implementations in their OSS-BSS systems > for the kinds of protocols DRINKS is looking out? As far as I have been able to tell the vast majority of Global Telecommunications firms I have personally consulted with and for and other potential SSP's have formalized their Data Exchange Mechanisms on SOAP based transport mechanisms. Teleco firms are traditionally very very conservative and DRINKS is not exactly a WEB 2.0 like application. > > 2. How many folks have a REST-like implementations in their OSS-BSS > systems for the kinds of protocols DRINKS is looking out? I know of NO telecommunications OSS-BSS systems that currently use REST like systems for data provisioning. > > 3. In general what data model or protocol properties do your > organizations ultimately lean towards - SOAP vs. REST? Other? In the majority of telecommunications I am acquainted with SOAP is the current flavor dejure though there are provisioning systems that I could describe involving Local Number Portability that have not been fundamentally updated in decades. Of course TELEX is still in wide deployment as well as Frame Relay, ATM. > > 4. What are the specific applications that SSP are looking for DRINKS > to enable .. LNP?..MMS/SMS interoperability, SIP interconnection etc ?? All of the above and realtime video point to point using E.164 addressing. > > 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) Yes. > > 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? > B. The WG try and do both? Option A. I do not believe the WG can do both though if anyone want to do B they are more than welcome to do so. PLUS IMHO any SOAP version MUST be a Proposed Standard or no vendor will seriously adopt it except under severe threat of loss of revenue. Any idea that a SOAP based transport protocol for DRINKS would be classified 'Experimental' is completely unacceptable. > > > Please provide feedback before July 8th, if possible. > > Thanks, > > Richard & Alex > _______________________________________________ > drinks mailing list > drinks at ietf.org > https://www.ietf.org/mailman/listinfo/drinks
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.