Subject: Re: [BLISS] New document on BLISS and REST

From: "Theo Zourzouvillys" <[email-masked]>
Date: Sun, 2 Nov 2008 03:24:09 +0000

On Fri, Oct 31, 2008 at 5:54 PM,  <[email-masked]> wrote:
> 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.

Not at all;  the REST model uses the PUT, POST, and DELETE HTTP verbs
for creation/manipulation of resources.

 ~ 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: "Theo Zourzouvillys" <[email-masked]>
Date: Sun, 2 Nov 2008 03:50:52 +0000

On Fri, Oct 31, 2008 at 3:00 PM, Salvatore Loreto
<[email-masked]> wrote:

> 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.

well, the way i've split up the work is by defining a document for the
REST framework itself which makes defining profiles very easy, but
left monitoring out of it.

There is then a separate document for monitoring of the HTTP resources
- I've done some initial work [1] on a interface for monitoring HTTP
URI's over a SIP event package, although other protocols could also be
defined in the future (e.g XMPP, COMET, BOSH, AMQP).

The reason for working on a SIP event package for notifications was
that the use cases within bliss most commonly involve running on a SIP
UA - although by splitting it out of the main document others can be
added as there is the need.

 ~ Theo

1 - note, I did say "initial" :) -
http://dev.voip.co.uk/~theo/ietf/draft-zourzouvillys-bliss-http-uri-monitoring-00.txt
- i will try to spend some more time on it soon.

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 02 Nov 2008 13:24:34 +0200

the security mechanism is https or any other security mechanism already 
defined for http
if we think that https is not enough

Sal

[email-masked] wrote:
>    From: Jonathan Rosenberg <[email-masked]>
>
>    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
>
> What is the security mechanism?
>
> Dale

---

From: Dan York <[email-masked]>
Date: Mon, 3 Nov 2008 09:59:50 -0500

As an example of what Theo notes here (that REST can used for updates  
as well as read-only), those of you wanting to see a RESTful API in  
action may want to look at Twitter's documentation of their REST API:

http://apiwiki.twitter.com/REST+API+Documentation

It works in both directions.

Regards,
Dan

-- 
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: [email-masked]
Date: Mon, 3 Nov 2008 14:25:14 -0500 (EST)

There's something about this proposal that I don't understand.  The
proposal seems to be "Use HTTP PUT to set/clear the call forwarding
indicator."  Not having been involved in ACH, I'm not certain, but I
expect that this proposal has been put forth before.  Is there
something that is gained by explaining at length that it is an example
of the REST methodology?

Dale

---

From: <[email-masked]>
Date: Sun, 16 Nov 2008 16:13:02 +0200

Hi,

I read through
[http://www.ietf.org/internet-drafts/draft-griffin-bliss-rest-00.txt]
and have been following some of the discussion on how to configure call
treatment related settings on the server.

Although I haven't been active in BLISS, the topic itself is familiar to
me as we had very similar discussion a few years ago in SIMPLE (how to
configure/manage buddylists and authorization policy) and in XCON (how
to manage conference policy and various other conference related
parameters).

I definitely think that REST/HTTP as the *model* is correct here.
However, what is not as clear is that how XCAP is related. As far as I
can see, XCAP is built very much based on the REST principle: It uses
GET, PUT and DELETE in a semantically correct way, the URI defines the
scope of the operation and so on.  Some people are saying XCAP is too
complex, but at the same time when the discussion about RESTful
interface matures, the solution seems to develop closer and closer to
what XCAP is. 

It's true that there has been some pushback for XCAP even in the
SIMPLE/Presence context: not too many fully working implementations at
SIPit and so on. Some people have left out the "partial" or
"sub-document" operations and just do GET, PUT, DELETE for the whole
baseline resource. Perhaps some sort of XCAP-lite would be a good model
for BLISS as well: full XCAP could be supported as an
extension/optimization. 

But perhaps instead of debating what flavor of REST we are using, it
would be better to work on the actual data model, i.e. what pieces of
information need to be configured, and define some kind of
"RESTful-compliant" data representation out of that. One thing to think
would be how to make the baseline schema extensible so that extensions
would not cause interop-confusion.

Markus

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 17 Nov 2008 12:02:26 -0500

Markus,

Very good question.

You are correct that, in terms of architectural approach, XCAP can be 
considered a 'restful' protocol, and it follows the general principles 
that define a REST-based technique.

However, in the intervening years since XCAP development began, the 
Internet has evolved to a specific way of using HTTP in a REstful way, 
which is quite different from XCAP. That way, which is described in the 
various documents here, does NOT involve using HTTP as a sort-of 
xml-editing protocol, which is what xcap is. Thus, all of the 
complexities of XCAP around etags and schema dependencies and all of the 
work on the server to maintain idempotency - those all evaporate.

And so, really what the drafts are proposing is that we follow the same 
model that has evolved in the Internet for restful services. And that 
model is not xcap.

-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: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 17 Nov 2008 18:19:40 +0100

Hi Jonathan,

Does this mean, you also propose a REST-based technique for Presence,
PoC
And IM?

Regards
Christian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Jonathan Rosenberg
Sent: Monday, November 17, 2008 11:02 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [BLISS] REST vs. XCAP

Markus,

Very good question.

-Jonathan R.

---

From: <[email-masked]>
Date: Tue, 18 Nov 2008 01:36:34 +0200

Hi,

Yes, I can see the benefits of the approach where you would explicitly
define all the resources that need to be manipulated and give them
explicit URIs. I think that is indeed the technically correct approach,
and this is how modern web services are designed. 

The concern I have is actually not technical. I happen to know that
3GPP/TISPAN already have a similar type of solution as what BLISS is now
working on, and that is based on using XCAP and defining the related XML
schema. So the risk is that once again there will be fragmentation on
how this is done. I'm sure Keith or someone else can fill in the
details. Having said that, I don't think anyone has implemented that
stuff, at least we haven't. 

But technically I think the right thing is to go with the RESTful
proposal. But for it to have any practical benefit, I do hope that the
main SIP PBX vendors would really commit to it.

Markus

>From: ext Jonathan Rosenberg [mailto:[email-masked]] 
>Sent: 17 November, 2008 19:02
>To: Isomaki Markus (Nokia-CIC/Espoo)
>Cc: [email-masked]
>Subject: Re: REST vs. XCAP
>
>Markus,
>
>Very good question.
>
>You are correct that, in terms of architectural approach, XCAP 
>can be considered a 'restful' protocol, and it follows the 
>general principles that define a REST-based technique.
>
>However, in the intervening years since XCAP development 
>began, the Internet has evolved to a specific way of using 
>HTTP in a REstful way, which is quite different from XCAP. 
>That way, which is described in the various documents here, 
>does NOT involve using HTTP as a sort-of xml-editing protocol, 
>which is what xcap is. Thus, all of the complexities of XCAP 
>around etags and schema dependencies and all of the work on 
>the server to maintain idempotency - those all evaporate.
>
>And so, really what the drafts are proposing is that we follow 
>the same model that has evolved in the Internet for restful 
>services. And that model is not xcap.
>
>-Jonathan R.
>
>
>> and have been following some of the discussion on how to configure 
>> call treatment related settings on the server.
>> 
>> Although I haven't been active in BLISS, the topic itself is 
>familiar 
>> to me as we had very similar discussion a few years ago in 
>SIMPLE (how 
>> to configure/manage buddylists and authorization policy) and in XCON 
>> (how to manage conference policy and various other 
>conference related 
>> parameters).
>> 
>> baseline resource. Perhaps some sort of XCAP-lite would be a good 
>> model for BLISS as well: full XCAP could be supported as an 
>> extension/optimization.
>> 
>> "RESTful-compliant" data representation out of that. One thing to 
>> think would be how to make the baseline schema extensible so that 
>> extensions would not cause interop-confusion.
>> 
>> Markus
>> 
>
>--

---

From: salvatore loreto <[email-masked]>
Date: Tue, 18 Nov 2008 15:34:58 +0200

Hi,

I also think that technically the right thing is to go with the RESTful 
proposalI
even if I also share the same Markus concerns related to once again 
fragment how things are done.

However as Jonathan as pointed out XCAP is just a sort of 'restful' 
protocol (even if for me
Restful is more a technology than a protocol)
so if we will do the things in the right way, I mean defining a good 
data model, using XCAP or Rest
it will be just a mater of choice.

Sal

[email-masked] wrote:
>>> However, what is not as clear is that how XCAP is related. 
>>>       
>> As far as I 
>>     
>>> can see, XCAP is built very much based on the REST 
>>>       
>> principle: It uses 
>>     
>>> GET, PUT and DELETE in a semantically correct way, the URI 
>>>       
>> defines the 
>>     
>>> scope of the operation and so on.  Some people are saying 
>>>       
>> XCAP is too 
>>     
>>> interface matures, the solution seems to develop closer and 
>>>       
>> closer to 
>>     
>>> what XCAP is.
>>>
>>> SIMPLE/Presence context: not too many fully working 
>>>       
>> implementations at 
>>     
>>> would be better to work on the actual data model, i.e. what 
>>>       
>> pieces of 
>>

---

From: salvatore loreto <[email-masked]>
Date: Tue, 18 Nov 2008 16:07:22 +0200

hi Jonathan and Keith,

as I have already written in this same mailing list I like your proposal 
of using Rest
I completely agree with Jonathan that we should follow the same model 
that has evolved in the Internet for restful services.
But I think that if we want follow how Internet has evolved or is 
evolving we have to do it completely.

unfortunately yesterday I wasn't able to attend the Bliss wg due to the 
concurrent OAuth bof,
however I have followed the meeting via the jabber room, and I was the 
one asking about the possibility
to at least *investigate* the possibility of use BOSH ( 
http://xmpp.org/extensions/xep-0124.html ) as a mechanism
to notify the eventual HTTP resource changes as an alternative or in 
combination to a new sip event package.*

*Bosh is a protocol that emulates a bidirectional stream between two 
entities (e.g. client and server) by using multiple
synchronous HTTP request/response pairs without requiring the use of 
polling or asynchronous chunking.
I want to also stress the fact that *Bosh is not part of XMPP*, in fact 
BOSH can be used to implement any bidirectional
XML stream transporting a mixture of elements qualified by namespaces.

Bosh is already (largely ?) used in Internet to exchange notifications 
between clients and web servers, so it would be interesting
to investigate if we can use it also for our aims.
Of course I am perfectly aware that Bosh is not the only possibility, 
and there is also Comet or if you prefer web socket,
however IMO they do not fit so well for our scope as Bosh does.

best regards
/Sal

---

From: Gustavo Garcia Bernardo <[email-masked]>
Date: Tue, 18 Nov 2008 16:36:35 +0100

But, is this something specific to BLISS?  

For me the transport of SIP Events Packages (or in general SIP messages) on top of BOSH is something I'm very interesting in, but it is not specific of BLISS.   IMHO BLISS should define a normal event package that could be transported on top of UDP, TCP, BOSH.... 

Regards,
G.
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of salvatore loreto [[email-masked]]
Sent: Tuesday, November 18, 2008 3:07 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [BLISS] REST and Bosh

hi Jonathan and Keith,

best regards
/Sal