Subject: [core] REST, URIs, and constrained devices

From: Peter Bigot <[email-masked]>
Date: Mon, 26 Jul 2010 10:19:24 -0500

After an impromptu telecon with Kerry this morning (very effective), I have
a better understanding for my own concerns about CoAP's compability with
basic REST principles.

1) URI Reconstruction

A key feature of REST is self-contained messages: this is what enables
caching and gateways to be transparent.  Anything that requires access to
non-REST layers to obtain complete information interferes with this.
>From Fielding's
dissertation<http://www.ics.uci.edu/%7Efielding/pubs/dissertation/evaluation.htm#sec_6_3>(section
6.3.2.1):

One of the worst mistakes in the early HTTP design was the decision not to
send the complete URI that is the target of a request message, but rather
send only those portions that were not used in setting up the connection.
The assumption was that a server would know its own naming authority based
on the IP address and TCP port of the connection. However, this failed to
anticipate that multiple naming authorities might exist on a single server,
which became a critical problem as the Web grew at an exponential rate and
new domain names (the basis for naming authority within the http URL
namespace) far exceeded the availability of new IP addresses.

HTTP/1.0 provided the scheme, path, query, and fragment parts, but addition
of Host was required in HTTP/1.1 because it was not possible to adequately
reconstruct the URI authority from available envelope information.  (Note
that constrained nodes may be unable to identify the name used to resolve
their unicast address, let alone the name used to locate a multicast address
they listen to.)

CoAP must clearly define how it intends to solve the same problem of URI
reconstruction.

It is CoAP's responsibility to translate the authority part of a URI into
the address and port to which messages should be sent, and to reconstruct
from address, port, and other envelope information sufficient information to
provide the REST level with the URI to which the message pertains, both at
servers to which requests are sent and at clients to which responses are
sent (synchronously or asynchronously).

In a REST-ful system, I may not know whether a specific URI identifies a
proxy or an origin server.  If the transaction layer requires this in order
to determine whether it is necessary to include Uri-Authority and other
options, or to address the message to a different host and port than is
implied by the authority, CoAP must define how this is done.

2) Groups of resources on distributed devices

A second key feature of REST is that it describes a client-server model
where addressable resources are transferred through a representation of
their state.

If CoRE wants to extend the concept of URI to denote a distributed resource
which is an aggregation of independently managed state, it must define the
processes by which (a) the state representation in a request is distributed,
and (b) the state representations gathered from responses are combined to
return to the REST client a meaningful representation of the state of the
distributed resource.

In particular, this is necessary for any access to constrained devices
through an HTTP gateway, as implied by the "HTTP REST based API" requirement
in the CoRE charter.  An HTTP client will not accept multiple responses to a
single request.

Peter

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Mon, 26 Jul 2010 18:04:21 +0200

+1

On Mon, Jul 26, 2010 at 17:19, Peter Bigot <[email-masked]> wrote:
> non-REST layers to obtain complete information interferes with this.  From
> Fielding's dissertation (section 6.3.2.1):
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 26 Jul 2010 18:32:15 +0200

On Jul 26, 2010, at 17:19, Peter Bigot copied from Roy Fielding's dissertation:

> One of the worst mistakes in the early HTTP design was the decision not to send the complete URI that is the target of a request message, but rather send only those portions that were not used in setting up the connection. The assumption was that a server would know its own naming authority based on the IP address and TCP port of the connection. However, this failed to anticipate that multiple naming authorities might exist on a single server, which became a critical problem as the Web grew at an exponential rate and new domain names (the basis for naming authority within the http URL namespace) far exceeded the availability of new IP addresses

This is referring to the common practice of hosting multiple "virtual servers" or "virtual hosts" behind one IPv4 address.

An analogue in the world of constrained nodes might be an A/D converter with multiple inputs that mean completely different things (e.g., temperature in room X and airflow in room Y) and are therefore addressed under a different authority.

There are several differences between HTTP and CoAP that may make the solution look different than the one that would have been optimal for HTTP.

-- Many applications of CoAP will use an IPv6 address as the authority.  
   Running "virtual servers" in this case requires multiple IPv6 addresses.

-- It is much easier to put multiple IPv6 addresses on a host than multiple IPv4 addresses.

-- Sending the IPv6 address twice in a packet (destination address, authority) is a much higher expense in constrained networks than with the 500 byte HTTP headers we are used to.

Using some form of compression (as I proposed in http://www.tzi.org/~cabo/draft-bormann-6lowpan-ghc-00pre.txt for other uses in 6LoWPAN) would solve the latter problem (if we have a binary representation, such as the Uri-Authority-Binary in coap-misc).

But can't we do that optimization at the CoAP level?  Can't the default value for Uri-Authority be the destination (transport) address of the packet?

Such a default value would still require simple nodes to process the option if present.  We could go one step further and disallow sending the option with a value that coincides with the destination transport address.

That might be part of a solution for using IPv6 addresses as authority.  We still need a way to efficiently handle DNS names as the authority -- of course, there is no way to apply the default proposed above, and to make simple nodes simple (i.e., not requiring support of DNS names on them).

Gruesse, Carsten