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 PROTECTED] wrote:
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
-----Original Message-----
From: ext Jonathan Rosenberg [mailto:[EMAIL PROTECTED]
Sent: 17 November, 2008 19:02
To: Isomaki Markus (Nokia-CIC/Espoo)
Cc: [email protected]
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.
[EMAIL PROTECTED] wrote:
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
--
Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South
Cisco Fellow Iselin, NJ 08830
Cisco, Voice Technology Group
[EMAIL PROTECTED]
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
