Subject: [core] Question about Location and redirection

From: "Thoma, Matthias" <[email-masked]>
Date: Thu, 3 Oct 2013 13:02:58 +0000

Hello all,

I have been lurking on this mailing list for a while and also saw that in earlier days there were quite some discussions on redirection and location. Nonetheless, I haven't been able to figure out what was the conclusion out of this discussions.

What I am looking for is a standards compliant way to tell a service consumer that either the requested resource can be found somewhere else (like the 3xx-family of response codes would allow me), or that it has has been created on a different coap endpoint (the location case).

The (simplified) rational is that I have a system of cooperating objects, some with different capabilities, but all speak CoAP. Now  the objects have to deliver some document as a result of a GET. Sometimes, it would now be preferable to have this document stored on a CoAP node with higher storage capacities, so I would like to have this very constrained device reply with a "yes, you can get that document, but you need to fetch it from here" in a  CoAP  compliant way.

Furthermore, the devices support getting historical data (like sensor values from the last month). These are also stored on a different node in the system for capacity reasons. Now a GET like get coap://nodeX:1000/data/jan2011 would answer, with something like "yes, you can get that data, but I do not store that on my own persistent memory anymore, please get it from here coap://nodeY:1000/nodeX/data/jan2011. For performance reasons, the nodeX should not get the data from nodeY first and then return it to the caller.

I have similar use cases for POSTs where data is generated on a different node in my network of cooperating devices.

As far as I can see this use cases are not yet supported by CoAP at the moment (please, correct me if I am wrong!) as neither the 3xx family known from HTTP is supported nor non relative location options. In HTTP it wouldn't be a problem to implement the use case.

Is something like this possible at the moment without specifying my own application layer protocol on top of CoAP, or by introducing custom response codes and thus being no longer standards compliant?  Is supporting redirection/non-relative location planned in any planned further version of CoAP? I noticed, that the 3.xx response code family is reserved as well as some options for location. Nonetheless, this wouldn't be the first standard, where things stay reserved forever :)

Best,
  Matthias Thoma

Matthias Thoma
P&I BIT PA&TS
SAP (Switzerland) Inc. | Althardstrasse 80 | 8105 Regensdorf  | Switzerland
Please consider to send me encrypted mail: http://keys.sap.com

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 3 Oct 2013 17:05:03 +0200

Hi Matthias,

On Oct 3, 2013, at 15:02, "Thoma, Matthias" <[email-masked]> wrote:

> As far as I can see this use cases are not yet supported by CoAP at the moment (please, correct me if I am wrong!) as neither the 3xx family known from HTTP is supported nor non relative location options.

Indeed.  While early drafts of CoAP did have some forms of redirection, we found that the use cases most people had in mind did not call for redirects.  The main reason is that in a CoRE world, URIs are usually found through a discovery process, and these URIs can be made to point to the right place right away.

> In HTTP it wouldn’t be a problem to implement the use case.

Right.  HTTP has more support for a human user, who is likely to type a URI and expect to arrive at the right document even if its real URI is longer or points to somewhere else.  We didn't have strong support for making the protocol machine more complex to support redirection.  We also didn't want to have the security considerations.

> Is something like this possible at the moment without specifying my own application layer protocol on top of CoAP,

Actually, it seems you already have your own little application layer protocol here.
How does the client arrive at coap://nodeX:1000/data/jan2011 without some form of URI arithmetic?
(If the server supplies the URI as in HATEOAS, it can already supply the URI pointing to the final place.)

> or by introducing custom response codes and thus being no longer standards compliant?  

That would probably be a way to do this that creates large integration problems.
A better way might be to define an "application/vnd-xxx.indirection" media type that your constrained node can send back to point to the real place.  This could also provide some further application semantics if needed (e.g., some form of authentication, if this needs to run in NoSec mode).
(It is easy to construct something like this from JSON or CBOR.)

> Is supporting redirection/non-relative location planned in any planned further version of CoAP?

There are no plans.  Should there be?  Convince the WG!

> I noticed, that the 3.xx response code family is reserved as well as some options for location.

Right, we didn't want to close the door to extensions of the protocol state machine forever.
However a strong objective remains to avoid baggage from HTTP that is not really needed in the CoRE world.

Grüße, Carsten

---

From: "Thoma, Matthias" <[email-masked]>
Date: Thu, 3 Oct 2013 17:23:11 +0000

Hello Carsten,

> Indeed.  While early drafts of CoAP did have some forms of redirection, we found that the use cases most people had in mind did not call for redirects.  The > main reason is that in a CoRE world, URIs are usually found through a discovery process, and these URIs can be made to point to the right place right away.

Agreed, but with a but: Especially, in CoRE world I believe an "out of resource" situation and changes of resources after discovery is something that is not that out of scope. With regard to the redirection I currently have to have a very data-centric view (interacting with data on constrained devices via RESTful interfaces). I agree that it is not needed if "just" consider "simple" temperature sensors without storage or home automation actors, but with some data collection in mind some questions pop up:

(1) Going the plain discovery approach and assuming that resources can be moved (like the historical data in my example). How should I tell the user (does not need to be a human user) that a resource he maybe just discovered seconds ago is no longer available here, but is somewhere else and he needs to rediscover? None of the existing response codes seems to really fit in such a dynamic scenario. Of course, I can encode that information in the payload of one of the responses, but that hurts interoperability as well. 

(2) Clean API and semantics. Semantically speaking, I want to have the data from a nodeX, and asking something like nodeX/data/02102013 enables a clean API design and eases discovery (discovery just could return nodeX is a SensorDeviceWithStorage). In maybe 95% of all cases the node  might be able to return the data itself, but it would be nice to also support the remaining 5%. The problem of where to store information in an out of resource situation is now on the side of the application itself. Following a rediscovery approach the complexity on the caller side increases and more complex discovery mechanisms are needed. 

> > In HTTP it wouldn't be a problem to implement the use case.
>
> Right.  HTTP has more support for a human user, who is likely to type a URI and expect to arrive at the right document even if its real URI is longer or points > to somewhere else.  

As you might have seen, I did not have had a human user in mind. What I was looking for, was a way that an arbitrary COAP client  can ask for resources on my nodes, even if it had to be moved to somewhere else because the device is too constrained and any CoAP client would be able to bring you to the right place immediately... 

> How does the client arrive at coap://nodeX:1000/data/jan2011 without some form of URI arithmetic?

The Uniform Resource Identifiers (URIs) are defined in a data model. The nodes provide as part of their discovery process standard resource (like temperature) and URI construction rules for data-centric access. With very very constrained nodes even this documents do not fit on the node. Kind of a problem similar to what to do when ".well-known/core" cannot be provided by the note (or only that and nothing else). This is an exceptional border case though.

> A better way might be to define an "application/vnd-xxx.indirection" media type that your constrained node can send back to point to the real place.  This > could also provide some further application semantics if needed (e.g., some form of authentication, if this needs to run in NoSec mode).

Sure, on the application layer there are many options to deal with my specific use case. I just hoped to find something that works with any CoAP client just out-of-the-box, kind of do a GET and the URI and get the JSON result with or without any redirection. Nonetheless, I will explore application level options a little bit further then. Just wanted to be really sure, that CoAP does not have something built-in...

Best,
  Matthias

---

From: Klaus Hartke <[email-masked]>
Date: Sat, 5 Oct 2013 12:27:56 +0300

Matthias Thoma wrote:
> Just wanted to be really sure, that CoAP does not have something built-in...

As Carsten said, there are no plans at this time. But the 3.xx family
of response codes has indeed been reserved for this purpose, and there
are some option numbers reserved to express locations on a different
CoAP endpoint or non-CoAP resources. To validate the reservations, I
wrote a small specification for myself some time ago and also added it
experimentally to my CoAP implementation. If there is enough interest
in the working group, I could quickly turn it into a draft.

Best regards,
Klaus