[Rest] intiial rough draft

[Salvatore Loreto]

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
>