Subject: [core] Client default rules

From: Peter Bigot <[email-masked]>
Date: Tue, 19 Oct 2010 07:57:06 -0500

On Tue, Oct 19, 2010 at 3:14 AM, <
[email-masked]> wrote:

> But I'm a bit afraid of all the bad request error codes that force the
> client to reformulate its request.
> First the authority option, now the token option, then...
> It involves more and more transactions to get a valid response If a client
> must try all of them one by one.
> What should be the default rules for clients that support asynchronous
> responses ? They should always include a token option to avoid an error code
> or only include it on demand and cache the result to try to save bandwith ?
>
I don't think there's a simple answer to that question.

ReST as an architectural style requires uniformity of interface, regardless
of protocol and transport.  The limited resources of the platforms on which
CoAP will be used require trade-offs that introduce variation points.
Network bandwidth limitations, latency, processing power, and the
applications themselves all impact the selection of alternatives in CoAP.

I'll outline my current thinking for two implementation environments I'll be
supporting, after first reviewing the variation points that come to mind:

   - URI-Authority can be omitted from a request to save space in the CoAP
   message.  Doing so risks rejection of the ReST transaction if an intervening
   server requires the authority to identify the resource.
   - Token can be added if the client is capable of accepting asynchronous
   responses.  Doing so increases the size of each message (though probably
   only by 3 octets, much less impact than adding URI-Authority).
   - Block can be added if the client is capable of accepting large
   representations in chunks.

 I have two target implementations:

   - CoAPy is a Python library which is assumed to run on a non-constrained
   node, and will almost uniformly be used in clients that interact with
   arbitrary CoAP servers.  Its server capability would mostly be used for
   value-added proxies, including integration into ReST architectures.  It will
   abstract three layers:  a pure ReST layer that should be one-to-one mappable
   to ReST as implemented in HTTP; a pseudo-ReST layer that uses CoAP
   transactions for observation and multicast actions; and the CoAP transaction
   layer.
   - OSIAN is a TinyOS extension supporting a POSIX-style IPv6 network
   stack.  It's not tied to specific hardware, but the initial platform uses
   the Texas Instruments CC430 microcontroller+ISM-band radio, which has 4kB of
   RAM and 32 kB of ROM.  CoAP endpoints in this environment will uniformly be
   servers, responding to clients outside the radio network.  If clients are
   needed within the network, they can be assumed to be talking to OSIAN
   servers.  Code size dictates what features will be supported, and it's
   likely that the layers will be collapsed to make things fit.  Within reason,
   reduced code size is more important than reduced message size.  A CoAP
   (ReST-style) proxy on a less constrained gateway node can help hide the
   variation from external clients.

CoAPy will by default include the URI-Authority, to simplify composition of
services (which is a likely application for CoAPy).  At worst, use of
URI-Authority will result in a path MTU overrun and failure to access the
server, so the application should have the option to inhibit it.  Whether
the server will require the authority will probably be an application
configuration decision, but implemented at the pseudo-ReST layer.

OSIAN will probably ignore URI-Authority at the server, and assume the
client addressed the message correctly.  If client support is added to
OSIAN, it will not include the URI-Authority since the servers won't look at
it anyway.

CoAPy will support asynchronous transactions.  The Token option will
automatically be added at the pseudo-ReST layer, and will never appear at
the pure ReST layer, as asynchrony is irrelevant to the ReST transaction.
For completeness there will be an option to inhibit adding Token, again to
reduce the message size when its presence causes problems with a particular
server.

OSIAN: I'm not sure yet.  Because TinyOS's run-to-completion task structure
encourages split-phase architectures, I expect that if any request must be
made asynchronous, every request will be made asynchronous, to eliminate the
code required to support both.  If so, a client that omits the option will
have to retransmit with it added.  As the application domain assumes clients
that have more resources than the servers, transferring the burden to the
client is defensible.

CoAPy will support the block option, but my current belief is that the block
option is best viewed as transport-level syntactic sugar for use of the
fragment part of a URI (with a query-part to define the block size).  As
such, it will not appear at the pure ReST layer, and will be an explicit
part of the pseudo-ReST layer interface.

OSIAN will support the block option, but only for specific resources.
Attempts to use it on others are likely to be rejected.  (I'll have to check
the spec to make sure this is permitted: if a resource representation is
24-bytes, I do not want to have to waste code space with block support for
it just because somebody wants to retrieve it in 16-byte chunks.  However, a
1500-byte high-resolution sample sequence will have to be retrieved in
pieces.)

So: no answers, but maybe some things to think about.

Peter