Re: [core] Subscriptions and policy

[Adam Roach <[e-mail]>]

   On 7/29/10 10:56 AM, Olaf Bergmann wrote:
> Adam,
>
> Adam Roach<[e-mail]>  writes:
>
> [...differentiation of data that presented to a subscriber...]
>
>> More in the roundhouse of what people are thinking about for typical
>> CORE usage: imagine a CORE-attached residential alarm system, with
>> sensors on external windows and doors, and on a number of internal
>> motion sensors. The information about individual sensors can be very
>> sensitive, and something I probably want to put tight controls on
>> when, for example, the alarm monitoring service asks. When I ask,
>> though, I would want a complete picture about what is going on.
>>
>> Now, there's nothing in baseline CORE that prevents this behavior. I
>> would hate to lose this ability by the selection of a model for
>> subscriptions that does.
> Apart from the question if this fits the REST model

I'm pretty certain it does. REST clearly allows the ability to convey 
alternate representations of a resource state. Examples include 
tailoring response MIME types to match the expressed capability of the 
client, choosing different encodings (UTF-8 vs. ISO-8859-1), and 
returning a different language (English versus French) according to 
expressed user preferences.

So, in general, I think allegations that altering the body based on 
characteristics of the requestor are in violation of the REST model need 
to be backed up with some description of the REST property being 
violated. This reference may help: 
<http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm>. In 
short, the mandatory characteristics of a RESTful system are:

   1. Client-Server Architecture
   2. Stateless Transactions
   3. Cacheability
   4. Uniform Interfaces
   5. Layered System


If you persist in asserting that what I'm describing is not consistent 
with REST, please cite one of these five properties in your assertions.


> I wonder if this
> scenario is in line with the intended use for a protocol such as CoAP.
> I do not think that it is reasonable to subscribe each single sensor
> node but instead have a sort of home gateway that does this for you and
> that you can query for your home's overall status from outside using
> HTTP or subscribe to alarms, etc. with a presence protocol of your
> choice.

Wait -- if CoAP is meant only for the kind of use case you describe, why 
are we messing with IP addresses for enrollment? Wouldn't it be much 
easier to use physical addresses, such as MACs? For that matter, if this 
is intended only for HANs, why is the work being done here instead of 
some place like IEEE?

Oh, wait. I know why. Because it's not meant for only this kind of use 
case. From the charter (elisions mine):

"CoAP will be designed for use... between Devices and general nodes on 
the Internet...."

> We should not attempt to design another presence protocol here.

But as that's what draft-hartke-coap-observe-01 effectively proposes to 
do, I'd like to make sure it's done correctly.

/a