Subject: [BLISS] New document on BLISS and REST

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 27 Oct 2008 11:51:16 -0400

As a follow up from Dublin, I worked with a colleague of mine to put 
together a brief document which describes REST a bit and presents some 
examples of how it can be used for the kinds of configuration problems 
we have in ACH. The draft is here:

http://www.ietf.org/internet-drafts/draft-griffin-bliss-rest-00.txt

comments welcome.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: "Theo Zourzouvillys" <[email-masked]>
Date: Mon, 27 Oct 2008 16:14:34 +0000

On Mon, Oct 27, 2008 at 3:51 PM, Jonathan Rosenberg <[email-masked]> wrote:
> examples of how it can be used for the kinds of configuration problems we
> have in ACH. The draft is here:
>

Jonathan,

The biggest issue with using REST is for notifications of changes to
resources in a scalable way that works behind NAT.  There are a number
of choices: HTTP polling (perhaps COMET), XMPP, or in the case of
BLISS, a SIP event package.  However, this is a far more generic
problem than just this domain - think RSS and twitter, and the huge
amount of resource wasted every day from polling over HTTP for changes
- although none the less something i'm interested in helping solve.

So while i've not explicitly tackled the notification part of it yet,
I have documented an initial framework that can be used for providing
simple configuration/data API services in a RESTful manner:

 http://dev.voip.co.uk/~theo/ietf/draft-zourzouvillys-bliss-rest-for-sip-00.txt

The idea is that "profiles" then sit on top of this framework running
within the network, e.g:

 - ACH configuration
 - Phone book
 - Recent/missed calls
 - Voicemail access/configuration

I'd also appreciate any comments!

Kind regards,

 ~ Theo

-- 
Theo Zourzouvillys
Chief Technical Officer
VoIP.co.uk - Commerce House, Telford Road, Bicester, OX26 4LD
Tel: +44 1908 764 196
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: Dan York <[email-masked]>
Date: Fri, 31 Oct 2008 10:09:27 -0400

Theo and Jonathan,

I think both of these documents are great and I definitely like the  
idea of a REST interface for SIP as I could see it helping in the  
whole realm of web-based "mashups" that are going on right now.

My fundamental question, though, is this: why is this work to create a  
REST interface to SIP going on within BLISS?

Yes, I understand that it was developed through the ACH discussions  
and can provide a way to deal with ACH issues, but isn't the whole  
idea of a "REST interface to SIP" something that has much larger  
applicability?  And if so, shouldn't this really be brought up over on  
SIPPING?

I think it's definitely a good interface to develop for SIP... I just  
wonder if all the right folks who should be part of that discussion  
are actually subscribed to this list.

My 2 cents,
Dan

P.S. Jonathan, I'm sure you know this, but the "Security  
Considerations" section of draft-griffin-bliss-rest-00 obviously needs  
some work as there are very definitely security issues with a REST API  
(some of which Theo has mentioned in his draft).

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 31 Oct 2008 17:00:37 +0200

Hi there,

I think that the intentions of both the draft is not to develop REST 
interface for SIP,
but just to show how a service can be configured on a Server using REST.

All what we need to define here is XML file format (if as I guess we are 
going to use REST handling
state representations in XML format) for a service or a set of service
and showing how this XML document can be modified using REST (that is 
what is showed in
the Theo draft).
So for this reason bliss seems, at least to me, the perfect wg where 
define this stuff.

About the Theo question on "how using REST for notifications of changes to
resources in a scalable way that works behind NAT"
IMO the more natural way is go for BOSH ( 
http://xmpp.org/extensions/xep-0124.html )
and not for XMPP.
COMET could be another possibility but I think it is too heavy.

/Sal

---

From: Dan York <[email-masked]>
Date: Fri, 31 Oct 2008 11:45:23 -0400

Sal,

> but just to show how a service can be configured on a Server using  

DY> Ah... sorry, I guess I was reading more into it. (And admittedly  
finding it an exciting idea.)

> All what we need to define here is XML file format (if as I guess we  
> are going to use REST handling
> and showing how this XML document can be modified using REST (that  
> is what is showed in
> the Theo draft).

DY> Got it.  Makes sense for that reason.

DY> Having said that, I would say that there *would* be value, IMHO,  
in creating a standard RESTful interface to SIP that had broader  
applicability.

Thanks,
Dan

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 31 Oct 2008 12:56:03 -0400

Dan,

When you say, "RESTful interface to SIP" - what kind of functions do you 
mean?

Do you mean, have a way to make first person calls with REST, as a 
replacement for SIP? Or do you mean third party call control/CTI types 
of things? Or do you mean presence? e.g., a RESTful method to fetch 
someones presence state?

The piece BLISS is looking at, is RESTful configuration of feature 
parameters. That one is a no-brainer for REST.

-Jonathan R.

Dan York wrote:
> DY> Having said that, I would say that there *would* be value, IMHO, in 
> creating a standard RESTful interface to SIP that had broader 
> applicability.
> 
> Thanks,
> Dan
>

---

From: [email-masked]
Date: Fri, 31 Oct 2008 13:54:10 -0400 (EDT)

From: Jonathan Rosenberg <[email-masked]>

What is the security mechanism?

The REST model seems to be oriented toward "read-only" access, where
the data is expected to flow from the server to the client, whereas
the ACH problem has data flowing from the client (UA) to the server
(proxy), which is what leads to most of the problems.

Dale