Hello, in case someone's wondering, Kemo => Simo ;) Cheers, Simo
________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of ext Shida Schubert Sent: 16 February, 2009 11:31 To: [email protected] Subject: [BLISS] Minutes from the BLISS-REST teleconf All; Attached is a minutes from our first BLISS-REST design team meeting. I want to thank the members of design team to put aside time to attend the meeting and contribute. We really need some more use-cases beside what's already mentioned in the ACH analysis and ach-config-requirements draft. Please do submit a comment if you have any use-cases for REST like protocol in the context of ACH. Meeting Date: 2009.02.06 Note-taker: Shida Schubert Attendees: Andrew Christien Kemo Salvatore Sanjay Simon Shida Theo 1. Debate about the scoping of the REST-BLISS activity. - Need to distinguish from XCAP. - Chair asked the motivation behind what Nokia is doing with regards to XCAP/HTTP+CPL and the background behind Marku's comment. - Kemo explained that Markus's comment was based on the requirements draft. draft-zourzouvillys-bliss-ach-config-requirements<http://tools.ietf.org/id/draft-zourzouvillys-bliss-ach-config-requirements-00.txt> - Kemo further went on to explain that in the req draft, something like time based policy etc. was being discussed. - Based on the req, if Common Policy based ruleset is necessary, it's already defined in 3GPP or may be something like CPL + HTTP may be considered? > Kemo suggested that if policy based ruleset is to be considered, the design team should look at the ongoing work in 3GPP.. - Salvatore expressed that even if REST approach is taken, there is still a need to identify the resources available for alteration. - Salvatore also added the need to decide anything that is important enough to be referenced as a thing in itself, namely resource. Then associate to each resource at least one URI, and decide the structure of that URI in a way that should vary in a predictable way. - Simon pointed out the following points about adopting REST like approach as it has been debated in XCON. > Application level error codes and transport level error codes, and where error codes are to be sent need to be carefully considered > Can simply use HTTP error + body with error indication > Salvatore explained that REST is a set of design criteria, not very well specified anywhere. However one defining feature of a RESTful architecture is its use of HTTP response code,where an error response code is a signal to the client that the metadata (headers) and entity-body should not be interpreted as a response to the request. In general a first step we should take is to agree on the set of design criteria we consider to be REST. > Debate on why use REST? XCAP? > Salvatore commented that XCAP can be considered a RESTful protocol, maybe not 100% pure REST. > Salvatore explained the possibility to modify XCAP to be 100% RESTful compliant, and re-utilize all the stuff that has been already defined for XCAP, like event packages, etc.etc. > Sanjay asked if we are designing SIP-REST general framework. > Shida explained that at the last meeting, as part of the scope of BLISS WG, BLISS will not design a general framework and focus only on the use-cases of ACH but do not limit the extensibility and further usage. > It was agreed that we need use-cases/requirements > Sanjay asked if we want to gather use-cases for anything or ACH? > Shida suggests to open up for anything. > Andrew argued that that we should focus on ACH only. > Shida agress. > Debate on the current requirements draft. draft-zourzouvillys-bliss-ach-config-requirements<http://tools.ietf.org/id/draft-zourzouvillys-bliss-ach-config-requirements-00.txt> > Has a lot in there.. > Theo agreed, and explained that it was because it included everything people expressed for its potential uses. > It was pointed out that by presenting the draft, we were able to narrow the scope of this work a tad. Conclusion: We need use-cases/requirements. Especially use-cases beside what's mentioned in the ACH draft. Many Thanks Shida
_______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
