Re: [drinks] WG poll on transport protocol

["Brian Rosen" <br at brianrosen.net>]

Our OSS-BSS products use SOAP.  We don't currently use REST, although we try
to adhere to some of the RESTful principals.  Our customers seem to use
SOAP.  We have never, to my knowledge, had a request to support a straight
REST/no SOAP interface.  No one seems to have any problems with the
overhead.

Brian

> -----Original Message-----
> From: drinks-bounces at ietf.org [mailto:drinks-bounces at ietf.org] On
> Behalf Of Alexander Mayrhofer
> Sent: Friday, June 26, 2009 9:29 AM
> To: IETF DRINKS WG
> Subject: [drinks] WG poll on transport protocol
> 
> 
> All,
> 
> The chairs would like to seek some input from the list on the practical
> options the WG now needs to confront on what is the most appropriate,
> but
> more importantly,  what is also most deployable transport protocol for
> DRINKS.
> 
> The protocol design team has made good progress towards a first draft
> of the DRINKS protocol, and the issue of which transport protocol to
> proceed with was discussed during several conference calls.
> 
> The chairs wish to formally reach concensus on how the group
> should proceed regarding that protocol transport issue.
> 
> Discussions during our face to face meetings have indicated that
> a SOAP/XML based approach would fit most of the various vendors
> and service providers that would potentially deploy a DRINKS protocol.
> 
> http://en.wikipedia.org/wiki/SOAP
> 
> The design team been advised that it might also be useful to look at
> REST-like
> protocols as REST design principles for WEB protocols overcome many of
> the
> known limitations and interoperability problems associated with SOAP.
> 
> There are arguments that a RESTful Web Services approach for a DRINKS
> protocol from a provisioning would not only be appropriate for a Client
> 2
> Server but also Server 2 Server approaches as well.
> 
> It should be understood that REST is not a protocol but a series of
> design
> principals.
> 
> http://en.wikipedia.org/wiki/REST
> 
> The central counter argument is that SOAP is the most universally
> deployed
> data exchange mechanism out there and that anecdotal evidence indicates
> that
> SOAP is the predominant form of transport mechanism in current use
> among
> SSP's and will be for the foreseeable future.
> 
> The design team has currently concluded that it would be beneficial to
> seperate the definition of the data object from the underlying
> transport protocol to permit defining more than one transport, if
> necessary.
> 
> In order to document WG consensus on this issue the chairs would like
> to
> poll the WG on the following questions:
> 
> It is very important that as many members of the list participate in
> this
> poll as possible. Please provide feedback to each question as fully as
> possible.
> 
> 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?
> 
> 2. How many folks have a REST-like implementations in their OSS-BSS
> systems
> for the kinds of protocols DRINKS is looking out?
> 
> 3. In general what data model or protocol properties do your
> organizations
> ultimately lean towards - SOAP vs. REST? Other?
> 
> 4. What are the specific applications that SSP are looking for DRINKS
> to
> enable .. LNP?..MMS/SMS interoperability, SIP interconnection etc ??
> 
> 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)
> 
> 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?
> 
> 
> 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