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 _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
