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
Dan York wrote:
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).
On Oct 27, 2008, at 12:14 PM, Theo Zourzouvillys wrote:
On Mon, Oct 27, 2008 at 3:51 PM, Jonathan Rosenberg
<[EMAIL PROTECTED]> wrote:
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.
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 protected]
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
