Subject: [core] Subscriptions and policy

From: Adam Roach <[email-masked]>
Date: Wed, 28 Jul 2010 11:23:12 +0200

At the meeting, I pointed out that some of the subscription models 
under discussion -- such as those that use multicast and those that use 
an intermediary for fan-out of requests -- preclude the use of any 
policy that returns different values to different users (based, e.g., on 
identity, address, etc).

Carsten indicated that he believes that such an approach is inconsistent 
with REST in general. This isn't immediately obvious to me -- as long as 
the view of a resource is consistent from the perspective of any single 
user, it seems completely in line with what REST attempts to achieve.

In terms of the potential uses for this kind of differentiation, I'll go 
for the hard but obvious one first: location.

Imagine a mobile-data-enabled, gps-enabled tracking device that 
implements CORE for retrieving location information. It is quite 
sensible to imagine that it would want to vary the precision of the 
delivered location based on who is asking.

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.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 29 Jul 2010 16:05:38 +0200

On 7/29/10 10:56 AM, Olaf Bergmann wrote:
> Adam,
>
> Adam Roach<[email-masked]>  writes:
>
> [...differentiation of data that presented to a subscriber...]
>
>> 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.
>>
> 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

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 29 Jul 2010 10:56:32 +0200

Adam,

Adam Roach <[email-masked]> writes:

> would hate to lose this ability by the selection of a model for

Apart from the question if this fits the REST model, 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. We should not attempt to design another presence protocol here.

Gruesse,
Olaf