[Rest] intiial rough draft
Simo.Veikkolainen at nokia.com
Simo.Veikkolainen at nokia.com
Wed Mar 4 01:59:52 CST 2009
>-----Original Message-----
>From: rest-bounces at bliss-ietf.org
>[mailto:rest-bounces at bliss-ietf.org] On Behalf Of ext Salvatore Loreto
>Sent: 04 March, 2009 09:50
>To: Sanjay Sinha (sanjsinh)
>Cc: rest at bliss-ietf.org
>Subject: Re: [Rest] intiial rough draft
>
>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
Right. If we use XCAP in a way that only whole XML documents are manipulated, we can avoid much of the complexity of XCAP (not having to deal with the node selectors, for example). There are some things XCAP already defines which we could use, namely
- URI hierarchy
- querying the server for its capabilities (supported AUIDs and namespaces)
- an event package for subscribing to changes in the XML data.
That said, what I think we should now concentrate on are the actual services and parameters which we want have. At this time we should not exclude either (REST/XCAP) solution, which is why I think Sal's proposal to change the URI structure to be aligned with XCAP is a good idea.
Simo
>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
>>>
>>>
>
>
>_______________________________________________
>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