Re: [W3c WoT IG]: Review of "RESTful Design for Internet of Things Systems -draft"

Hi Claes,

Thanks for the feedback! Please see inline.

On 03/11/15 17:35, Nilsson, Claes1 wrote:
>
> Hi Ari,
>
> I hope that the IETF meeting last week was successful.
>
> As promised I have read your document: 
> https://tools.ietf.org/html/draft-keranen-t2trg-rest-iot-00and have a 
> few comments. However, they may already be obsolete due to your 
> discussions at the IETF meeting.
>
> ·Section 3.1, Architecture:
> Not sure on the distinction between Forward Proxy and Reverse Proxy. 
> As far as I understand an example of a Reverse Proxy is a HTTP-CoAP 
> GW. But could examples of Forward Proxies be given? What does this 
> mean for IoT systems? In figure 3 it is stated that the Origin Server 
> is “Legacy System” but I assume that it could also be a normal web server?
>
HTTP-CoAP proxy could be forward proxy for a node in the constrained 
network using CoAP to access HTTP servers. For IoT systems this is a 
fairly common scenario (don't have enough resources to run HTTP on its 
own). We should indeed clarify this and add examples.

> ·Section 3.5 HTTP and CoAP methods:
> Would be fine with tangible examples on methods used in IoT use cases. 
> I can guess the following for an “Assisted Living” device that uses 
> sensors to detect a fall and also has a vibrator. The device uses HTTP 
> or CoAP to communicate with an application cloud server.
>
> Cloud server àdevice:
> PUT /startFallDetection      ---   as a new PUT does not change the 
> state (fall being detected) if a previous PUT already has been issued.
> POST /vibrate    ---    as each POST creates a new vibration.
>
> Device -> cloud server:
> POST /fallDetected  --- as it is send every time a fall occurs
>
> Am I correct?
>
The problem with these particular example usages is that they are "RPC 
like" (invoking methods), instead of RESTful (changing resource states). 
But yes, we should add examples to the methods. Will try to work 
something for the next version.

> ·Section 3.5.3 PUT:
> The sentence “Hence, the intent of PUT  is idempotent and visible to 
> intermediaries, even though the exact effect is only known by the 
> origin server.” Does not seem correct if HTTPS or CoAPS is used. Then 
> the message is not visible to intermediaries.
>
Good point and should be clarified. This does actually apply also to 
HTTPS and CoAPS if the security is terminated in a proxy, but in general 
the intermediaries don't see the message if transport layer security is 
used. But object security changes this again.


Cheers,
Ari