Subject: [core] Block for Req and Res

From: Guido Moritz <[email-masked]>
Date: Thu, 27 Jan 2011 10:49:33 +0100

I know that there was in consensus in Bejing about that, but I am not
completely sure about the interaction of the CoAP core and block protocols.

I am still in favor to have a mechanism to allow block for both request and
response of e.g. POST. The background: We carry SOAP over CoAP as a new
lightweight reliable binding
(http://tools.ietf.org/html/draft-moritz-core-soap-over-coap-00).

I was thinking about if the messaging layer (aka transaction) of CoAP would
make this possible with the existing block-01 draft. Due to the M flag, both
endpoints are aware if this was the last block of the request. So the last
block responded with an empty ACK (i.e. deferred response). For the block
wise response, a new CON is initiated by the origin receiver starting a new
"blockwise transfer session".

Even if it was not the intention of the existing block draft, I am not sure
if it is possible with it. 

Guido

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 27 Jan 2011 11:11:52 +0100

On Jan 27, 2011, at 10:49, Guido Moritz wrote:

> a new CON 

Hmm.  Doing this in a deferred response sounds possible, because there is no ambiguity between the ACK of the last request block and the response body carrying the first response block.
Haven't thought this through though.
It is needed?

Gruesse, Carsten

---

From: Guido Moritz <[email-masked]>
Date: Thu, 27 Jan 2011 11:22:13 +0100

> It is needed?
I would say yes, but I misuse CoAP for something not necessarily
RESTful...so my comment may not have a huge weight ;)
Based on the Webex discussion yesterday, in some way it also depends on the
maximum message size defined in the CoAP core. If there is a hard size limit
instead of the existing solution, maybe applications get in trouble?

Guido

> -----Ursprüngliche Nachricht-----
> Von: Carsten Bormann [mailto:[email-masked]]
> Gesendet: Donnerstag, 27. Januar 2011 11:12
> An: Guido Moritz
> Cc: 'core'
> Betreff: Re: [core] Block for Req and Res
> 
> Hmm.  Doing this in a deferred response sounds possible, because there is
> no ambiguity between the ACK of the last request block and the response
> body carrying the first response block.

---

From: "Clark, Gilbert" <[email-masked]>
Date: Fri, 28 Jan 2011 01:23:22 -0500

Hi:

I noticed ticket #60 (Access control and proxy caches) was listed as being
better off described as an extension, so thought I'd throw out a tentative
idea.  If it seems workable, then I can write it up as a draft; if not, then
maybe something will be useful to somebody else.

To define a proxy's behavior, a given node publishes a resource (either in
binary or plaintext form) that is used to inform interested proxies what
they can do with the node's content.

Note that the proxy would need to verify the node's identity when the
resource was retrieved, or spoofed ACLs could be a problem.  Additionally,
securing access to this resource somehow (require SharedKey?) would be
highly recommended.

In any case, I'd imagine the resource itself could be pretty simple; perhaps
something like:

"
ACL_VERSION
Allow/deny OPERATION for RESOURCE from SOURCE
"

where:

ACL_VERSION = 1
OPERATION = "GET", "PUT", "OBSERVE", *
RESOURCE = "/path/to/resource"  (with an optional wildcard)
SOURCE = "trusted", "local", "external", IPv6 address + mask, *

and the rules would be applied in order of their definition.  "external" /
"trusted" / "local" would be keywords that would apply to the external
network (beyond the proxy), trusted network (SharedKey / MultiKey /
Certificate / pre-arranged IP address from the node's perspective), and the
local network (local CoAP network).  In place of those keywords, an IPv6
address + mask or a wildcard character could be used.

For example:

"
CoAP ACL version 1
allow * for coap://mynode/* from trusted
allow * for coap://mynode/* from local
allow GET for coap://mynode/* from external
deny * for * from *
"

The proxy could either poll or observe this resource for nodes it was
servicing, and use it to restrict traffic destined for various CoAP nodes.

The existence of this resource would be provided as a way to specify *only*
what the proxy should do with the node's content (e.g. It wouldn't say
anything about what the node's access controls were).   If neither the
plaintext nor the binary version of this resource were to not exist, the
proxy would assume the equivalent of "allow * for * from *".

Perhaps cache information could be additionally specified in this resource
as:

"
cache a/specific/resource TIMEOUT
"

Per-host access control lists / cache rules could optionally be specified on
the proxy, with the caveat that resolving conflicts between a proxy that
said one thing and a node that said another could be interesting.
Additionally, upon notification of an updated rule set, the cache entries
for all entries the previous rule set affected would be flushed on the
proxy.

All rules would be applied to inbound HTTP --> CoAP traffic at the proxy.

Tangent: for protocols other than HTTP, a mechanism could be defined to map
required information into CoAP URIs (for example, SNMPv1 / v2c might be
mapped to an snmp/community_string/o/i/d resource, with each individual SNMP
transaction broken down into a relevant series of CoAP commands or something
that all had to complete successfully for the operation to succeed).

--Gilbert Clark