[Rest] intiial rough draft
Salvatore Loreto
salvatore.loreto at ericsson.com
Wed Mar 4 01:50:03 CST 2009
sure,
then if we, in some way, just remove the xml editing stuff from XCAP we
have what we want in a way
that is forward compatible with XCAP
Sal
Sanjay Sinha (sanjsinh) wrote:
> XCAP is restful in its behavior but it does RESTful xml editing and this
> ends up bringing a
> bunch of complications.
>
>
>> -----Original Message-----
>> From: rest-bounces at bliss-ietf.org
>> [mailto:rest-bounces at bliss-ietf.org] On Behalf Of Schmidt,
>> Christian 1. (NSN - DE/Munich)
>> Sent: Wednesday, March 04, 2009 12:52 PM
>> To: ext Shida Schubert; Salvatore Loreto
>> Cc: rest at bliss-ietf.org
>> Subject: Re: [Rest] intiial rough draft
>>
>> Hi Shida,
>> There was a second idea behind this name XCAP light:
>> Is it possible, to generate a simple Restful protocol, somehow
>> compatible with XCAP?
>>
>> And we can use experience from XCAP
>> - not to invent the wheel again and again
>> - to exclude features, which adds too much complexity compared
>> with less additional value.
>>
>> Therefor I think this exercise is worth to do.
>> Servus
>> Christian
>>
>>
>>
>> -----Original Message-----
>> From: rest-bounces at bliss-ietf.org [mailto:rest-bounces at bliss-ietf.org]
>> On Behalf Of ext Shida Schubert
>> Sent: Wednesday, March 04, 2009 7:04 AM
>> To: Salvatore Loreto
>> Cc: rest at bliss-ietf.org
>> Subject: Re: [Rest] intiial rough draft
>>
>>
>> Salvatore;
>>
>> My comments inline..
>>
>> On 3-Mar-09, at 5:25 PM, Salvatore Loreto wrote:
>>
>>
>>> 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 ?
>>>
>> What is XCAP light protocol? My understanding of it was that
>> it's the merely a way we address the resources. Am I
>> understanding it correctly?
>>
>> Regards
>> Shida
>>
>>
>>
>>> 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
>>>
>> _______________________________________________
>> 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
>>
>>
More information about the Rest
mailing list