Hi Jonathan, Does this mean, you also propose a REST-based technique for Presence, PoC And IM?
Regards Christian -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Jonathan Rosenberg Sent: Monday, November 17, 2008 11:02 AM To: [EMAIL PROTECTED] Cc: [email protected] Subject: Re: [BLISS] 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
