[Rest] intiial rough draft

Tue Mar 3 03:53:56 CST 2009

Hi Christian,

yes it could be a good summary.

I want however to stress the fact that also XCAP at the begin was 
simple, then people with comments
and additional requirements made it complex.
Are we sure that we won't end up to the same story?

see more in line

Schmidt, Christian 1. (NSN - DE/Munich) wrote:
> Hi Theo,
>
> Good start with this ID.
> Here is one proposal to summarize our design targets in the abstract,
> something along these lines:
>
> "XCAP was not chosen for remote configuration, because its complexity.
>   
I would underline the fact that XCAP is to modify xml document or better 
to modify specific element
or attribute directly inside an xml document, and "maybe" we do not need it!
Especially in a RESTfull approach that consider the important data of 
the application
in an abstract way as "resource", and expose all the elements and 
attributes of an xml document
could be too much.
> For
> This draft, a simple RESTful approach has been taken. Nevertheless
> valuable
> ideas, for example the XCAP URI structure, have been adopted."
>   
I like this second part, even if we still haven't explored if it would 
be possible, and how, to keep also the
Node Selector part of the XCAP URI structure

cheers
Sal
> What do you think about?
>
> Regards
> Christian
>
>
>
>  
>
> -----Original Message-----
> From: rest-bounces at bliss-ietf.org [mailto:rest-bounces at bliss-ietf.org]
> On Behalf Of ext Salvatore Loreto
> Sent: Tuesday, March 03, 2009 9:26 AM
> To: Theo Zourzouvillys
> Cc: rest at bliss-ietf.org
> Subject: Re: [Rest] intiial rough draft
>
> Hi Theo,
>
> thanks for your effort to put it together,  I have some comments.
> The first two points are more generic consideration, the third one is 
> something you should
> consider and use to update the draft.
>
> 1)
> the draft should at least explain why not to use XCAP and instead go for
>
> a RESTful approach.
> Moreover, in my opinion saying only RESTful approach is not enough 
> because I think XCAP
> can be considered a sort of RESTful technology as well.
> Maybe this is subject for a different draft, but we need to clarify this
>
> point and evaluate the alternative
> between a totally new RESTful protocol as the one described in your 
> draft, and something like an
> XCAP light protocol.
>
> *Shida* what do you think of a similar proposal during the next IETF 
> BLISS wg in SF ?
>
> 2)
> the draft should follow a more systematic way and explain the approach 
> followed to draft this Restful protocol.
> But maybe it is something that can be done in the next versions.
>
> 3)
> we should at least trying to reuse the XCAP  URI  structure and  do not
> throw the baby out with the bath water
>
> draft, the draft propose this kind of structure
>
>    `-- ach/
>        |-- barring/
>        |   |-- incoming/
>        |   |   |-- all
>        |   |   `-- anonymous
>        |   `-- outgoing/
>        |       |-- all
>        |       |-- premium
>        |       `-- tollfree
>        |-- dnd/
>        |   `-- status
>        `-- forwarding/
>            |-- all/
>            |   |-- status
>            |   |-- target
>            |   `-- timeout
>            |-- busy/
>            |   |-- status
>            |   `-- target
>            `-- unreachable/
>                |-- status
>                `-- target
>
> As I said we should keep as much as possible consistent with the XCAP
> URI
>
> /Application Unique ID (AUID) /XCAP User Identifier (XUI)/specific 
> documents for that application usage/
>
> more thoughts need to done about how use the XCAP *node selector* in 
> this situation.
> I haven't had time to think about it!
> However I feel that even if we won't be able to reuse the *node 
> selector* we can define something similar
> that is extensible and let us to also support more complex operations 
> such as time-of-day routing.
>
> in our situation:
> - the Application Unique ID (AUID) = ach
> - XCAP User Identifier (XUI)= user name (would it be better in sip uri 
> form?)
> -specific documents for that application usage= barring, dnd, forwarding
>
> then for example in section 4.1 instead of having
>
>
> https://api.example.com/alice/ach/dnd/status
>
>
> I think it should be (and in this case 'status' should not go in the URI
>
> at all)
>
> https://api.example.com/ach/alice/dnd/status
>
>
>
> best regards
> Sal
>
>
>
>
>
>
> Theo Zourzouvillys wrote:
>   
>> So turned out my weekend was more exciting than i thought it was goign
>> to be, and have only just managed to get around to it.  Good thing
>> deadline isn''t until weds now :-)
>>
>> Please take a look at ...
>>
>>
>>     
> <http://dev.voip.co.uk/~theo/ietf/draft-zourzouvillys-bliss-ach-http-api
> -00.txt>
>   
>> ... and get some discussion going on it.
>>
>> I hope there is enough text (and typos) in there to get people to
>> understand what i'm trying to document - although if anyone has any
>> other ideas i'm all up for them instead!
>>
>> I'll wait for some feedback (and questions, which i'll answer) before
>> fleshing it up and actually making it more spec-like :)
>>
>> I'm in meetings most the day tomorrow but will be able to spend more
>> time on it in the evening (GMT).
>>
>>  ~ Theo
>>
>> _______________________________________________
>> Rest mailing list
>> Rest at bliss-ietf.org
>> http://bliss-ietf.org/mailman/listinfo/rest_bliss-ietf.org
>>   
>>     
>
>
> _______________________________________________
> Rest mailing list
> Rest at bliss-ietf.org
> http://bliss-ietf.org/mailman/listinfo/rest_bliss-ietf.org
>   