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
