Subject: [BLISS] Minutes from the BLISS-REST teleconf

From: Shida Schubert <[email-masked]>
Date: Mon, 16 Feb 2009 18:30:38 +0900

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

---

From: <[email-masked]>
Date: Mon, 16 Feb 2009 12:10:10 +0100

Hello,
in case someone's wondering, Kemo => Simo ;)

Cheers,
Simo

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Shida Schubert
Sent: 16 February, 2009 11:31
To: [email-masked]
Subject: [BLISS] Minutes from the BLISS-REST teleconf

All;

Meeting Date: 2009.02.06

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?

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

     > Application level error codes and transport level error codes,
        and where error codes are to be sent need to be carefully considered

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

    >  Salvatore commented that XCAP can be considered a RESTful protocol,
    > 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.

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

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

Many Thanks
  Shida