Subject: [core] Accept option in 4.15 responses

From: Thomas Fossati <[email-masked]>
Date: Tue, 13 Dec 2011 15:26:13 +0100

Following up to the point raised by Guido, and given a related thread that has been recently started on HTTPbis mailing list:

  http://lists.w3.org/Archives/Public/ietf-http-wg/2011OctDec/0455.html

what's your opinion about having the Accept option added to responses with 4.15 code ?

---

From: Guido Moritz <[email-masked]>
Date: Tue, 13 Dec 2011 17:03:54 +0100

+1. Sounds reasonable for me.

Guido

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
> Thomas Fossati
> Gesendet: Dienstag, 13. Dezember 2011 15:26
> An: [email-masked] WG
> Betreff: [core] Accept option in 4.15 responses
> 
> Following up to the point raised by Guido, and given a related thread that
has
> been recently started on HTTPbis mailing list:
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Mirko Rossini <[email-masked]>
Date: Tue, 13 Dec 2011 17:08:00 +0100

+1

2011/12/13 Guido Moritz <[email-masked]>

> > what's your opinion about having the Accept option added to responses
> with
> > 4.15 code ?

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 13 Dec 2011 18:29:33 +0100

> what's your opinion about having the Accept option added to responses with 4.15 code ?

I think we should see how the discussion on the related HTTP feature converges.

But yes, similar considerations do apply.

Grüße, Carsten

---

From: Douglas Otis <[email-masked]>
Date: Tue, 13 Dec 2011 15:05:14 -0800

CoRE WG,

Please note, this message is cross posted with the Repute WG mailing-list.

The Repute WG seeks help in deciding whether CoAP offers a good solution 
for distribution of reputation reports that assess various message 
identities, such as those used within email.

The current state of art uses DNS and "<query>._label.<service-domain>" 
to extend queries appended to the service domain.  Often the extended 
query describes a domain being queried along with possible scopes.  In 
addition, information returned is fairly undefined, although details 
might become rather extensive.  These details might include various 
categories known about the identity, such as involvement with financial 
transactions, relative volume assessments, incident reports, etc.

To get the ball rolling, it seems the restful nature of CoAP will work 
well in conjunction with Akamai like services.  Section 2.3 of 
Constrained Application Protocol CoAP, defines response caching in 
addition to mapping between HTTP and CoAP.  While the message format is 
defined using TLV structures, the payload could include JSON structures 
if desired.  CoAP is bound to UDP and offers a minimum MTU of 1152 bytes 
that compares well against the 512 byte message size limitation often 
imposed on DNS.  CoAP includes UTF-8 encoded strings, opaque byte 
sequences, variable byte non-negative integers, URI-Host, URI-Path, 
URI-Port, Content-Type, etc.  CoAP uses 16 bit Message IDs analogous to 
that of the DNS Transaction ID in addition to a 1 to 8 byte optional 
Token.  CoAP can also be secured using Datagram TLS (DTLS).

-Doug

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 14 Dec 2011 11:43:01 +0100

Hi Doug,

thanks for taking to the mailing list what so far has happened mostly in the IETF hallways.

To really answer this question, it would be useful to examine some documentation about your objectives ("requirements").
Until that happens, let me offer some observations.

To a first level of approximation, CoAP provides the same service HTTP does.
If HTTP could solve your problem (performance considerations aside), and the problem is simple enough for the simple-minded protocol that CoAP is, then CoAP might be a good match.
In particular, requests are based on URIs, and payloads make use of the media type ("MIME type") architecture, so different kinds of resource representations can be transferred.

Of course, there are some differences to HTTP.
As you note, CoAP is UDP-based, so it is indeed possible to build CoAP servers that are completely stateless (not even keeping anything like TCP state).
For resource representations that are larger than the ~1KiB size that can meaningfully be transported in one packet, we have the CoAP block scheme.  This still stays completely stateless on the server.  Fragmentation is never needed.  (CoAP-block is not the optimal solution for, say, retrieving a video, but variable-size things where a good part of the distribution is inside a KiB work very well, with zero overhead for the ≤ ~ 1 KiB case.)

On the security front, I have the following observations:

-- we completely rely on lower- or higher-layer security if any is needed.  Higher-layer security could be object security (think CMS or JOSE).  For lower-layer security (i.e., communication security), our mandatory-to-implement scheme is DTLS.  Without knowing your requirements on authentication, confidentiality etc., I have to stop here.
-- being based on UDP, CoAP has the same kind of amplification properties that other protocols like DNS have, so Internet-facing CoAP servers must be prepared to be implicated in DoS attacks.  (This is mitigated a bit by the ease of building a CoAP server such that it never responds with more packets than it gets.)

CoAP supports the same style of caching architecture that HTTP does -- again, knowing more about your objectives would help us find out whether this is a good match.

We have defined CoAP to support REST on simple-minded nodes and networks.  The resulting simplicity is likely to bring some advantages outside our space.  We haven't really explored that, though (and as a WG, we are chartered to focus on the inside).

Grüße, Carsten

On Dec 14, 2011, at 00:05, Douglas Otis wrote:

> The Repute WG seeks help in deciding whether CoAP offers a good solution for distribution of reputation reports that assess various message identities, such as those used within email.
> 
> The current state of art uses DNS and "<query>._label.<service-domain>" to extend queries appended to the service domain.  Often the extended query describes a domain being queried along with possible scopes.  In addition, information returned is fairly undefined, although details might become rather extensive.  These details might include various categories known about the identity, such as involvement with financial transactions, relative volume assessments, incident reports, etc.
> 
> To get the ball rolling, it seems the restful nature of CoAP will work well in conjunction with Akamai like services.  Section 2.3 of Constrained Application Protocol CoAP, defines response caching in addition to mapping between HTTP and CoAP.  While the message format is defined using TLV structures, the payload could include JSON structures if desired.  CoAP is bound to UDP and offers a minimum MTU of 1152 bytes that compares well against the 512 byte message size limitation often imposed on DNS.  CoAP includes UTF-8 encoded strings, opaque byte sequences, variable byte non-negative integers, URI-Host, URI-Path, URI-Port, Content-Type, etc.  CoAP uses 16 bit Message IDs analogous to that of the DNS Transaction ID in addition to a 1 to 8 byte optional Token.  CoAP can also be secured using Datagram TLS (DTLS).
> 
> -Doug
> 
> 
> 
> 
> 
>

---

From: Douglas Otis <[email-masked]>
Date: Wed, 14 Dec 2011 16:41:18 -0800

> In particular, requests are based on URIs, and payloads make use of the media type ("MIME type") architecture, so different kinds of resource representations can be transferred.
Many have suggested DNS can be (ab)used to provide URI based 
Get/Response exchanges where CoAP provides similar overheads.  In format 
comparison, JSON offers advantages for moderately complex exchanges.  
IMHO, to retain single packet exchanges, XML and HTTP represent a poor 
choice, and this speaks well for CoAP.
> For resource representations that are larger than the ~1KiB size that can meaningfully be transported in one packet, we have the CoAP block scheme.  This still stays completely stateless on the ser…
When large file transfers are required, rsync offers a better solution 
IMHO.  CoAP over UDP should be easier to deploy.  Ease of deployment is 
likely the greatest determining factor.

For mid-range services, network overhead and latency is often the 
greater concern.  When inbound servers become overwhelmed, reputation 
services are intended to mitigate this which represents >90% abuse.  As 
such caching helps which is also supported by CoAP, but unfortunately 
aliases used in abuse to be stealthy offer poor caching 
characteristics.  As such, round trip times related with UDP is 
significantly better than what is offered by TCP.  A better alternative 
would use SCTP data framing for sustained virtual long term sessions, 
but I suspect there is not enough requisite background to support this 
approach.
> CoAP supports the same style of caching architecture that HTTP does -- again, knowing more about your objectives would help us find out whether this is a good match.
Some customers will want the DTLS feature.  In most cases, the Token 
exchange would be fairly ideal for our purposes.  As such, CoAP looks 
rather attractive.
> We have defined CoAP to support REST on simple-minded nodes and networks.  The resulting simplicity is likely to bring some advantages outside our space.  We haven't really explored that, though (a…
I would also suspect that 99% of transactions will be Get where other 
transaction types would be limited to authenticated sessions and used 
for maintenance and updates.

-Doug

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 18 Dec 2011 14:18:22 +0200

I fully agree with Carsten,
if the idea flies in HTTP we should consider the same for CoAP

Salvatore