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
- 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
> 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
