Subject: Re: [drinks] WG poll on transport protocol

From: Jonathan Cronin <[email-masked]>
Date: Tue, 30 Jun 2009 13:21:11 -0400

1. How many folks have SOAP implementations in their OSS-BSS systems  
for the kinds of protocols DRINKS is looking out?

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.

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 2 Jul 2009 12:04:11 -0400

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: [email-masked] [mailto:[email-masked]] 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:
> 
> for
> the
> kinds of protocols DRINKS is looking out?
> 
> systems
> organizations
> ultimately lean towards - SOAP vs. REST? Other?
> 
> to
> enable .. LNP?..MMS/SMS interoperability, SIP interconnection etc ??
> 
> 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)
> 
> you
> prefer the group to
> 	A. Define a SOAP based transport protocol and if anyone is
> interested they can work on a RESTful version?
> Please provide feedback before July 8th, if possible.
> 
> Thanks,
> 
> Richard & Alex
> _______________________________________________
> drinks mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/drinks

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 2 Jul 2009 13:05:27 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Alexander Mayrhofer
> 
> 1. How many folks have SOAP implementations in their OSS-BSS systems for
> the

We have both on the embedded systems, but from OSS we only offer/expose SOAP because that's what every single customer (in the SP market) seems to want.  (in the Enterprise market there's a mix)

That's assuming the "kinds of protocols DRINKS is looking at" are "provisioning" protocols to OSS systems, for LUF type global data.  As opposed to, for example, "peering" protocols for LRF type local data with real-time topology-aware SIP routing decision implications.  

> 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.  One step at a time.

-hadriel