Subject: [core] A few questions about the latest coap draft

From: Gilman Tolle <[email-masked]>
Date: Tue, 6 Jul 2010 22:55:19 -0400

I have a few additional questions and comments about the latest CoAP  
draft:

Why was the "Location" header omitted from the allowable header  
options? At the very least, properly supporting the "201 Created"  
response requires it.

"201 Created - The request has been fulfilled and resulted in a new  
resource being created. The newly created resource can be referenced  
by the URI(s) returned in the entity of the response, with the most  
specific URI for the resource given by a Location header field." - RFC  
2616

Why must the URI be broken up into separate "scheme", "authority", and  
"path" components? Was that decision intended to save 2 bytes by  
replacing the 3-byte "://" portion of the URI with 1 byte's worth of  
option headers in the case when a CoAP node is requesting resources  
via a proxy, and to save a byte in non-proxied requests by enabling  
omission of the leading "/"? It just seems like needless complexity to  
me, as compared with a single "URI" option. And, if we add the  
Location header, then will it be split up like the URI header or  
maintained as a single option?

Why were the HTTP redirection codes (301, 302, 303) omitted from the  
allowed CoAP response codes? Even though the common-practice  
implementation of code 302 doesn't match the standard, having a well- 
specified redirection technique within CoAP seems like it would be  
valuable. A 301 redirection code could be used to notify clients about  
the preferred URIs on a server for the purposes of URI-shortening, for  
example, or to support evolution in REST APIs defined over CoAP.

Since the options are variable-length and must be sequentially parsed  
in all cases, what's the intended benefit of including the option  
count in the header?

Gil

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 7 Jul 2010 08:16:52 +0200

Hi Gilman,

that is great feedback.  Let my try to answer this from what I know.

> Why was the "Location" header omitted from the allowable header options? At the very least, properly supporting the "201 Created" response requires it.

I can't answer that question ("why"), but obviously, the use cases for POST have received little discussion so far.
Do you have some that you could share?

> "201 Created - The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field." - RFC 2616

(This is from the POST section.  201 Created on a PUT relies less on Location:)

> Why must the URI be broken up into separate "scheme", "authority", and "path" components? Was that decision intended to save 2 bytes by replacing the 3-byte "://" portion of the URI with 1 byte's worth of option headers in the case when a CoAP node is requesting resources via a proxy, and to save a byte in non-proxied requests by enabling omission of the leading "/"? It just seems like needless complexity to me, as compared with a single "URI" option.

In the majority of cases, there will be "path" only.  Saving the redundant byte consumed by the initial "/" seemed worth adding another option for the case when there indeed is a scheme and an authority in the message.  Separating scheme and authority allows some useful defaulting and possibly opens the door to a binary representation of authority (see coap-misc-05).

> And, if we add the Location header, then will it be split up like the URI header or maintained as a single option?

It would be logical to handle it the same way.

> Why were the HTTP redirection codes (301, 302, 303) omitted from the allowed CoAP response codes? Even though the common-practice implementation of code 302 doesn't match the standard, having a well-specified redirection technique within CoAP seems like it would be valuable. A 301 redirection code could be used to notify clients about the preferred URIs on a server for the purposes of URI-shortening, for example, or to support evolution in REST APIs defined over CoAP.

Again, it would be beneficial to discuss use cases -- just because HTTP has it is not sufficient IMHO.
E.g., do we need all of the redirects?
But I agree one can imagine use cases where some redirect functionality would be useful.

> Since the options are variable-length and must be sequentially parsed in all cases, what's the intended benefit of including the option count in the header?

That is the way to know when the options end.
(And "end of options" indication would consume one byte by itself or one bit per option, which we don't really have; it would also make at least one option required.  Since there is space in the header, spending four bits there sounds right.)

Gruesse, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Wed, 07 Jul 2010 07:41:03 +0100

I presume this refers to the 'pre-draft'. Is coap-01 going to be
released soon? Otherwise this is going to get complicated.

Robert

----- Original Message -----
From: Carsten Bormann 
To:"Gilman Tolle" 
Cc:
Sent:Wed, 7 Jul 2010 08:16:52 +0200
Subject:Re: [core] A few questions about the latest coap draft

 Hi Gilman,

 I can't answer that question ("why"), but obviously, the use cases
for POST have received little discussion so far.
 Do you have some that you could share?

 > "201 Created - The request has been fulfilled and resulted in a
new resource being created. The newly created resource can be
referenced by the URI(s) returned in the entity of the response, with
the most specific URI for the resource given by a Location header
field." - RFC 2616

 (This is from the POST section. 201 Created on a PUT relies less on
Location:)

 > Why must the URI be broken up into separate "scheme", "authority",
and "path" components? Was that decision intended to save 2 bytes by
replacing the 3-byte "://" portion of the URI with 1 byte's worth of
option headers in the case when a CoAP node is requesting resources
via a proxy, and to save a byte in non-proxied requests by enabling
omission of the leading "/"? It just seems like needless complexity to
me, as compared with a single "URI" option.

 In the majority of cases, there will be "path" only. Saving the
redundant byte consumed by the initial "/" seemed worth adding another
option for the case when there indeed is a scheme and an authority in
the message. Separating scheme and authority allows some useful
defaulting and possibly opens the door to a binary representation of
authority (see coap-misc-05).

 > And, if we add the Location header, then will it be split up like
the URI header or maintained as a single option?

 > Why were the HTTP redirection codes (301, 302, 303) omitted from
the allowed CoAP response codes? Even though the common-practice
implementation of code 302 doesn't match the standard, having a
well-specified redirection technique within CoAP seems like it would
be valuable. A 301 redirection code could be used to notify clients
about the preferred URIs on a server for the purposes of
URI-shortening, for example, or to support evolution in REST APIs
defined over CoAP.

 Again, it would be beneficial to discuss use cases -- just because
HTTP has it is not sufficient IMHO.
 E.g., do we need all of the redirects?
 But I agree one can imagine use cases where some redirect
functionality would be useful.

 > Since the options are variable-length and must be sequentially
parsed in all cases, what's the intended benefit of including the
option count in the header?

 That is the way to know when the options end.
 (And "end of options" indication would consume one byte by itself or
one bit per option, which we don't really have; it would also make at
least one option required. Since there is space in the header,
spending four bits there sounds right.)

 Gruesse, Carsten

 _______________________________________________
 core mailing list

 [email-masked]
 https://www.ietf.org [1]/mailman/listinfo/core

Links:
------
[1] http://www.ietf.org

---

From: Zach Shelby <[email-masked]>
Date: Wed, 7 Jul 2010 11:38:19 +0300

coap-01 is being released at the end of today EET, currently just integrating the last contributions and finishing editing. Yes, Gil is discussing a draft which was sent to interested developers. Let's keep that feedback discussion with the authors for now as not to confuse people. 

In general I agree with Carsten, the goal here is to support response codes and options that have a clearly identified purpose for CoAP use cases. As we find a need for a specific option or code then we will analyze them, make a ticket, and then get it into the next draft based on WG discussion. So no hurry there to get every possible option and code into coap-01. coap-misc is currently being used as a playground for things we think we might need... 

Zach

On Jul 7, 2010, at 9:41 AM, Robert Cragie wrote:

> I presume this refers to the 'pre-draft'. Is coap-01 going to be released soon? Otherwise this is going to get complicated.
> 
> Robert
> 
> From:
> Carsten Bormann <[email-masked]>
> 
> To:
> "Gilman Tolle" <[email-masked]>
> Cc:
> <[email-masked]>
> Sent:
> Subject:
> Re: [core] A few questions about the latest coap draft
> 
> 
> Hi Gilman,
> 
> https://www.ietf.org/mailman/listinfo/core
> https://www.ietf.org/mailman/listinfo/core

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: "Simpson, Robby (GE Energy Services)" <[email-masked]>
Date: Wed, 7 Jul 2010 09:12:11 -0400

> I can't answer that question ("why"), but obviously, the use cases for
POST have received little discussion so far.
> Do you have some that you could share?

I'm uncertain as to how formal a use case you'd like to see, but here's
a simple example:
Imagine a list of events, where each event is a resource.  Further,
imagine that each resource is addressed via an arbitrary number (event
ID) assigned by the server.

If an external device (client) wished to POST a new event, but leave it
to the server to assign the address, then a Location header would be
very useful in pointing to the newly assigned address for the event
POSTed.

In short, when a server exposes a set of resources in a collection,
where the addresses of the items of the collection are assigned by the
server, but items are added to the collection by clients.

- Robby

---

From: Zach Shelby <[email-masked]>
Date: Wed, 7 Jul 2010 16:31:27 +0300

Robby,

I agree, this is a clear case for Location, as is a redirect in case a resource has moved on a CoAP end-point. But in both cases we only need a Location with a relative URI (as supported in modern HTTP browsers as well). 

Proposal: How about a Location Option supporting only a relative URI? The format  would be identical to Uri-Path but Location would be Elective. 

Zach

---

From: Gilman Tolle <[email-masked]>
Date: Wed, 7 Jul 2010 09:56:54 -0400

Responding on the list because I was discussing issues which appear in  
the coap-00 draft (excluding the option count, which was added in the  
coap-01 prerelease). I wouldn't reasonably expect this feedback to be  
included in coap-01 because it's so close to being released, and am  
happy to keep specific comments about the prerelease draft among the  
authors.

Seconding Robby's use case for Location on 201 Created. When a sensor  
or meter is POSTing a new event to a server, the server should be able  
to notify the client of the URL for the stored event. A second use  
case: an end-user device sends a command via POST to another device,  
but that command may take a long time to execute. The server should be  
able to return the URL for a resource that can be periodically  
accessed in order to get the progress of the command, so the client  
can update a display.

In response to Carsten's earlier comment, we don't need all the  
redirect codes, but I'd suggest including 301 (permanent redirect) and  
302 (temporary redirect while maintaining the same method, as it's  
specified in HTTP/1.1). Both of those will enable a degree of  
flexibility in the resource locations defined by a particular REST API  
over CoAP. The 303 See Other redirect is intended for GET-after-POST,  
but I think our intended use of 201 Created fulfills a similar role,  
suggesting that 303 is not needed.

Between 201 Created and the redirects, I'd support adding an elective  
Location header with a relative URI, similar to Uri-Path.

Comment withdrawn about the option count -- I agree that it's necessary.

Gil

On Jul 7, 2010, at 9:31 AM, Zach Shelby wrote:

> Robby,
>
> I agree, this is a clear case for Location, as is a redirect in case  
> a resource has moved on a CoAP end-point. But in both cases we only  
> need a Location with a relative URI (as supported in modern HTTP  
> browsers as well).
>
> Proposal: How about a Location Option supporting only a relative  
> URI? The format  would be identical to Uri-Path but Location would  
> be Elective.
>
> Zach
>
>>> for