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
