Subject: [core] Comments on draft-ietf-core-coap-03

From: Klaus Hartke <[email-masked]>
Date: Thu, 28 Oct 2010 21:11:36 +0200

Just some random things I noted while reading coap-03:

2.1.1.
The figure suggests that the payload of a 4xx/5xx response is a
human-readable diagnostic message (here: "Not found"). This doesn't
seem to be defined anywhere, although I'd love if it was. (For
example, my CoAP server includes a complete stack trace in a 500
response when an exception is thrown and it's in debug mode. This
helps remote debugging a lot.)

2.1.1.
It's somewhat unclear to me from this section how ACKs and responses
relate to each other. Maybe it makes sense to explain asynchronous
responses first and present synchronous responses as optimization?

2.1.1.
This sections talks about the interaction between Req/Res and
Transaction layers, but section 2.1. is about the Interaction Model
between CoAP end-points.

2.1.2.
"Since no Token Option was included" - A Token Option is clearly
present in figure 3, no?

2.1.2.
Why does the server deny to answer the request if a client decides not
to include a token? If the client can relate the asynchronous response
to its request without a token, it's not the responsibility of the
server to tell the client it cannot.

2.1.2.
Given the current wording, it seems much simpler to me to let an
implementation simply always include a token in a request, instead of
hoping for a synchronous response and retrying in case of an
asynchronous one. After a successful request, the client cannot even
cache if it needs to include a token or not, because the same request
to the same resource may or may not yield an asynchronous response at
a later point of time.

2.1.3.
Section 2.1. says that transaction messages enable optional
reliability, and sections 2.1.1. and 2.1.2. describe reliable
requests, but no section talks about unreliable interactions. (The
only place where non-confirmable messages are mentioned is in section
4.1. "Multicast messages SHOULD be Non-Confirmable.")

2.3.2.
The section suggests that the only possible interpretation of POST is
to create a new subordinate resource on the server. Is this the case?
If yes, rename POST to CREATE?

2.5.1.
"including a copy of the critical option number in the payload of the
response." - in what format? I'd assume it's a variable-length
unsigned integer, but the section doesn't say. I'd also still prefer
to reserve the payload of error responses for human-readable messages
(utf-8 string, software must attribute no meaning to message).

3.2.
Table 2 lists the Token Option with a length of 1-2 B. That prevents a
lot of interesting usage cases wrt statelessness. What's the reasoning
to limit a token to 1-2 B?

3.2.
Table 2 lists the Max-age Option with a length of 1-4 B and a default
value of 60 seconds. Why not allow a value of 0 seconds to be
expressed with 0 bytes?

3.2.
The format of a variable-length unsigned identifier isn't defined anywhere.

3.2.8.
It is sufficient if token values are unique in use per server.

3.2.8.
"If a Token Option is included in a request, the response (and
any	subsequent delayed responses) MUST include the same value in a
Token Option." - section 2.1.1. says that Token can be omitted from
synchronous responses.

3.2.8.
"If a Token Option is included in a request, any resulting delayed
response SHOULD NOT include the URI option" - nothing in coap-03
encourages to ever include URI-related options in a response, or does
it?

3.2.
Would it make sense to expand table 2 with a column that indicates if
the option can occur in a request, in a response or in both?

4.2.
Should retransmits of responses transmit the current state of
resource, rather than a snapshot of the state at the time of the first
attempt?

Klaus

---

From: Peter Bigot <[email-masked]>
Date: Thu, 28 Oct 2010 15:49:42 -0500

Related specifically to Token:

> server to tell the client it cannot.

This might have been influenced by my comments related to use of Token to
enable the block protocol.  The reason to do this here is to allow the
client to influence the server's decision whether to use an asynchronous
response.  Some clients may not be able to accept asynchronous responses.
Some may accept only one outstanding at a time, and prefer to control which
requests might consume that resource.  A cooperative server might try harder
to return the response synchronously when no Token is present, rather than
immediately converting everything to synchronous.

Perhaps more convincingly: it takes less space to use the Token in the
response than to repeat all the URI-related options; and consistent use of
Token to pair an asynchronous response with the request eliminates ambiguity
in the case of multiple outstanding requests to the same URI.  This pattern
also eliminates the previous need to use URI data and envelope information
for correlation, along with all the code required to do so.

I think rationale like this should be part of the specification.

2.1.2.
> to the same resource may or may not yield an asynchronous response at

I doubt many resources will normally change whether or not operations on
them are likely to be asynchronous, but yes: applications are certainly
allowed to always include a Token in a request.

 3.2.
> to limit a token to 1-2 B?

I had the same question.  While a limit is reasonable to allow a fixed
representation on the server, I  see Etag and Token be essentially the same
type of object, so would expect them to support the same length (1-4B)

> It is sufficient if token values are unique in use per server.

Not generally.  This is only true if the implementation retains the server
network information along with the outstanding request, and uses envelope
information from the response in combination with the token to uniquely
identify the corresponding request.  A more decoupled implementation can
accomplish this more simply by disallowing use of the same token for
outstanding requests to different servers.

3.2.8.
> Token Option." - section 2.1.1. says that Token can be omitted from

Concur.

> encourages to ever include URI-related options in a response, or does

With the addition of Token, I believe the only time URI-related options
should appear in a response is when they are required to convey a
redirection involving Location (which as defined only specifies the path
component of the target; Uri-Authority is still required, as will Uri-Scheme
if/when that gets put back).

Wording in several places needs to be updated to reflect this; I'll note
where in my detailed comments.

Peter

---

From: Peter Bigot <[email-masked]>
Date: Thu, 28 Oct 2010 15:59:20 -0500

> resource, rather than a snapshot of the state at the time of the first

I would say no.

If this is required, it imposes a fairly tight coupling between the
transaction and REST levels: the transaction level must up-call to the REST
level to get an updated representation for each retransmission.

If this is allowed, it leaves open a potential for confusion as one request
has produced multiple, inconsistent responses with network behavior
determining which one makes it through.

Is there a way to make it clear that the CoAP message octet sequence must be
identical in each retransmission?

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 28 Oct 2010 23:11:09 +0200

On Oct 28, 2010, at 22:59, Peter Bigot wrote:

> Is there a way to make it clear that the CoAP message octet sequence must be identical in each retransmission?

I don't think we want to impose that -- the server may simply not have enough memory to store that version.  Constrainedness always wins :-)
I also think the confusion incurred is rather limited.
(But we also don't want to impose that the state must be fresh.)

Gruesse, Carsten

---

From: Peter Bigot <[email-masked]>
Date: Thu, 28 Oct 2010 16:30:03 -0500

There must be some limit: constrainedness should not excuse clearly
undesirable behavior.

Whether inconsistent retransmitted messages is such a case isn't something
I'd want to argue either way without a lot of thought about the
ramifications (consider multiple recipients with multicast, or possibly
gateways on different paths seeing different retransmissions, or what it
would mean to allow regenerating the response for something other than a
GET).

In any case, since there's no initial unanimity, whether or not this is
allowed should be explicit with either a MAY or a MUST NOT clause.

Peter

On Thu, Oct 28, 2010 at 4:11 PM, Carsten Bormann <[email-masked]> wrote:

> I don't think we want to impose that -- the server may simply not have
> enough memory to store that version.  Constrainedness always wins :-)

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 28 Oct 2010 23:50:51 +0200

On Oct 28, 2010, at 23:30, Peter Bigot wrote:

> inconsistent

Philosophical observation:
Knowing when to give up consistency (the C in ACID) was one of the major enabling innovations of the web.

My gut feeling is that not constraining applications in that respect (i.e., not requiring consistent retransmissions) cannot possibly cause problems.
But yes, it can't be wrong to spend some more thought on this.

Gruesse, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Fri, 29 Oct 2010 09:56:10 +0300

On Oct 29, 2010, at 12:30 AM, Peter Bigot wrote:

> In any case, since there's no initial unanimity, whether or not this is allowed should be explicit with either a MAY or a MUST NOT clause.

Sure, we should at least describe this better in the draft. My own assumption has been that a retransmitted request is equivalent (if not identical) to the original request. Implementation wise, this is usually handled at the transaction layer, where you tend to keep a copy of the buffer. I definitely don't recommend sending a different version of the resource representation for each retransmission.... I'll open up a ticket on this.

Zach  

-- 
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: Zach Shelby <[email-masked]>
Date: Fri, 29 Oct 2010 10:34:03 +0300

Thanks Klaus for the detailed review. I start to miss some of these details from knowing the text too well. Some comments in-line, my goal is to turn the key points you brought up into tickets. 

> helps remote debugging a lot.)

We could do that, I guess it would go into Section 11.1 where codes are defined in general?

> responses first and present synchronous responses as optimization?

OK, we need to play with the organization. I am not totally sure changing that order would help though, as asynchronous responses should be an exception.

> Transaction layers, but section 2.1. is about the Interaction Model

Maybe Section 2.1 needs to be re-named? Or we could split the section differently:

2.1. Transaction Model
2.1.1. Reliable Transaction
2.1.2. Unreliable Transaction
2.1.3. Transaction Messages

2.2. Request/Response Model
2.2.1. Synchronous Responses
2.2.2. Asynchronous Responses
2.2.3. Methods
2.2.4. Codes

2.3. Options

> "Since no Token Option was included" - A Token Option is clearly

Oops. That's what I get trying to hack the old example text. Needs to be fixed.

> server to tell the client it cannot.

See the thread continued by peter on this. We had this discussion when deciding on including the Token option.

> to the same resource may or may not yield an asynchronous response at

The purpose of this was to give the client some control whether it wants an asynchronous response in the first place. The draft does not prevent you always including a token if your client likes. But maybe this would need better explanation in the text anyways. 

> 4.1. "Multicast messages SHOULD be Non-Confirmable.")

Good point, see my outline suggestion above... we should add a subsection on that.

> If yes, rename POST to CREATE?

Kerry Lynn suggested an improvement on the text for -03. Sorry I was in too much of a hurry submitting -03 to synchronize this with RFC2616. Did this break something? 

> (utf-8 string, software must attribute no meaning to message).

I was thinking this would be text/plain. This relates to your earlier comment in general about the payload of error messages.

> to limit a token to 1-2 B?

I take responsibility for this one. Let's ask the question the other way around. Why do you need more than 64k token possibilities? Overhead was my reasoning, especially if you are including this token quite often. The problem is, constrained nodes will be forced to process or even store most options. On some architectures this might force a node to reserve space for the largest possible option length. So I would like to avoid having all options be up to 4 bytes. 

> value of 60 seconds. Why not allow a value of 0 seconds to be

Good idea.

> The format of a variable-length unsigned identifier isn't defined anywhere.

We had that before, but many people commented that it is not necessary. I guess we should have some text defining this. 

> It is sufficient if token values are unique in use per server.

Per client? The token is generated and matched by the client. 

> Token Option." - section 2.1.1. says that Token can be omitted from

Hmmm.. that should be fixed. The idea is that if a token is included by the client, it MUST be included in the response (synchronous or asynchronous).

> encourages to ever include URI-related options in a response, or does

Oops, left over from an older version. I would still like to leave the URI as an option for observe notifications, but that is for the observe draft. 

> the option can occur in a request, in a response or in both?

We had that before. But it turns out that most of these can occur in either one. Exceptions? Does Location ever occur in a request?

> resource, rather than a snapshot of the state at the time of the first

Made a ticket on this.

Cheers,
Zach

> 
> 
> Klaus
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: [email-masked]
Date: Fri, 29 Oct 2010 10:10:46 +0200

>We had that before. But it turns out that most of these can occur in
either one. Exceptions? Does Location ever occur in a request?

Now that we have the Token option to relate a response to a request do we
really need the URI-Path option in a response? If not we could merge
Location and URI-Path into one option or keep it as separate option but
cleary specify in a table if they can be present in requests or responses.
This would help to reduce the size of the option set for requests and
responses.

Regards,
Matthieu

             Zach Shelby                                                   
             <[email-masked]                                             
             om>                                                         A 
             Envoyé par :              Klaus Hartke <[email-masked]>       
             core-bounces@ietf                                          cc 
             .org                      core <[email-masked]>                
                                                                     Objet 
                                       Re: [core] Comments on              
             29/10/2010 09:34          draft-ietf-core-coap-03             

                                                                           

Thanks Klaus for the detailed review. I start to miss some of these details
from knowing the text too well. Some comments in-line, my goal is to turn
the key points you brought up into tickets.

> helps remote debugging a lot.)

We could do that, I guess it would go into Section 11.1 where codes are
defined in general?

> responses first and present synchronous responses as optimization?

OK, we need to play with the organization. I am not totally sure changing
that order would help though, as asynchronous responses should be an
exception.

> Transaction layers, but section 2.1. is about the Interaction Model

Maybe Section 2.1 needs to be re-named? Or we could split the section
differently:

2.1. Transaction Model

2.3. Options

> "Since no Token Option was included" - A Token Option is clearly

Oops. That's what I get trying to hack the old example text. Needs to be
fixed.

> server to tell the client it cannot.

See the thread continued by peter on this. We had this discussion when
deciding on including the Token option.

> to the same resource may or may not yield an asynchronous response at

The purpose of this was to give the client some control whether it wants an
asynchronous response in the first place. The draft does not prevent you
always including a token if your client likes. But maybe this would need
better explanation in the text anyways.

> 4.1. "Multicast messages SHOULD be Non-Confirmable.")

Good point, see my outline suggestion above... we should add a subsection
on that.

> If yes, rename POST to CREATE?

Kerry Lynn suggested an improvement on the text for -03. Sorry I was in too
much of a hurry submitting -03 to synchronize this with RFC2616. Did this
break something?

> (utf-8 string, software must attribute no meaning to message).

I was thinking this would be text/plain. This relates to your earlier
comment in general about the payload of error messages.

> to limit a token to 1-2 B?

I take responsibility for this one. Let's ask the question the other way
around. Why do you need more than 64k token possibilities? Overhead was my
reasoning, especially if you are including this token quite often. The
problem is, constrained nodes will be forced to process or even store most
options. On some architectures this might force a node to reserve space for
the largest possible option length. So I would like to avoid having all
options be up to 4 bytes.

Good idea.

> The format of a variable-length unsigned identifier isn't defined
anywhere.

We had that before, but many people commented that it is not necessary. I
guess we should have some text defining this.

> Token Option." - section 2.1.1. says that Token can be omitted from

Hmmm.. that should be fixed. The idea is that if a token is included by the
client, it MUST be included in the response (synchronous or asynchronous).

> encourages to ever include URI-related options in a response, or does

Oops, left over from an older version. I would still like to leave the URI
as an option for observe notifications, but that is for the observe draft.

> the option can occur in a request, in a response or in both?

We had that before. But it turns out that most of these can occur in either
one. Exceptions? Does Location ever occur in a request?

Made a ticket on this.

Cheers,
Zach

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________(See
attached file: smime.p7s)_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Zach Shelby <[email-masked]>
Date: Fri, 29 Oct 2010 11:34:28 +0300

On Oct 29, 2010, at 11:10 AM, [email-masked] wrote:

> Now that we have the Token option to relate a response to a request do we really need the URI-Path option in a response? If not we could merge Location and URI-Path into one option or keep it as separate option but cleary specify in a table if they can be present in requests or responses. This would help to reduce the size of the option set for requests and responses.

Interesting idea. Although Uri-Path is not needed in a normal response, it is useful in coap-observe, so I would not like to disallow it. However, Location could maybe be used for the same purpose I have in mind. Personally, I wouldn't have a problem with combining them either. So in a response Uri-Path would serve the same function as Location in a response to a POST, and in coap-observe it would indicate the resource the notification is about. 

Zach

---

From: [email-masked]
Date: Fri, 29 Oct 2010 11:03:53 +0200

>Sure, we should at least describe this better in the draft. My own
assumption has been that a retransmitted request is equivalent (if not
>identical) to the original request. Implementation wise, this is usually
handled at the transaction layer, where you tend to keep a copy of the
>buffer. I definitely don't recommend sending a different version of the
resource representation for each retransmission.... I'll open up a ticket
>on this.

In section 2.2 of coap-observe one can read:
If a confirmable notification requires a
   retransmission, it is RECOMMENDED to send the state that is current
   at the instant of the retransmission;

As I understand this sentence the representation can change for each
retransmission of the transaction. Like Carsten I think it can be much more
memory efficient in many use cases so I would recommend a MAY.

Regards,
Matthieu

             Zach Shelby                                                   
             <[email-masked]                                             
             om>                                                         A 
             Envoyé par :              Peter Bigot <[email-masked]> 
             core-bounces@ietf                                          cc 
             .org                      Klaus Hartke <[email-masked]>, core 
                                       <[email-masked]>                     
                                                                     Objet 
             29/10/2010 08:56          Re: [core] Comments on              
                                       draft-ietf-core-coap-03             

                                                                           

Sure, we should at least describe this better in the draft. My own
assumption has been that a retransmitted request is equivalent (if not
identical) to the original request. Implementation wise, this is usually
handled at the transaction layer, where you tend to keep a copy of the
buffer. I definitely don't recommend sending a different version of the
resource representation for each retransmission.... I'll open up a ticket
on this.

Zach

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 Oct 2010 12:11:01 +0200

> Kerry Lynn suggested an improvement on the text for -03. Sorry I was in too much of a hurry submitting -03 to synchronize this with RFC2616. Did this break something? 

In HTTP, POST pretty much means "send a message to a resource".

RFC 2616 9.5:
   The POST method is used to request that the origin server accept the
   entity enclosed in the request as a new subordinate of the resource...
   The actual function performed by the POST method is determined by the
   server and is usually dependent on the Request-URI....
   The action performed by the POST method might not result in a
   resource that can be identified by a URI...

CoAP-03 appears to be more specific in that it actually talks about requesting to create a new resource:
2.3.2:
   The POST method is used to request the server to create a new
   subordinate resource under the requested parent URI.  

(The server then may go ahead and not actually do that and still return a 200 OK, which doesn't quite fit the language of the first sentence.)

By appeal to authority, Roy Fielding likes POST in HTTP's semantics:
http://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post
"It is okay to use POST » Untangled"

But maybe we do indeed want to have the more specific semantics.
With a bit more work, this might even enable us to make POST idempotent.
We need realistic usecases to make a well-founded decision.

Gruesse, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Fri, 29 Oct 2010 14:36:06 +0300

On Oct 29, 2010, at 12:03 PM, [email-masked] wrote:

> >Sure, we should at least describe this better in the draft. My own assumption has been that a retransmitted request is equivalent (if not >identical) to the original request. Implementation wise, this is usually handled at the transaction layer, where you tend to keep a copy of the >buffer. I definitely don't recommend sending a different version of the resource representation for each retransmission.... I'll open up a ticket >on this.
> 

Oops. This shows how Klaus and I have interpreted how that should be done differently. We'll need to synchronize the two drafts for the next versions.

> 
> As I understand this sentence the representation can change for each retransmission of the transaction. Like Carsten I think it can be much more memory efficient in many use cases so I would recommend a MAY.

I do understand how this optimization might be useful in some cases, especially with observe. In that way I have no problem in making that a MAY.

Zach

> 
> Regards,
> Matthieu
> 
> 
> Zach Shelby <[email-masked]>
> 
> 
> 
> 
> Zach Shelby <[email-masked]> 
> Envoyé par : [email-masked]
> 29/10/2010 08:56
> 
> 
> A
> 
> Peter Bigot <[email-masked]>
> 
> cc
> 
> Klaus Hartke <[email-masked]>, core <[email-masked]>
> 
> Objet
> 
> Re: [core] Comments on draft-ietf-core-coap-03
> 	
> 
> ______________________________________________________________________(See attached file: smime.p7s)_______________________________________________
> core mailing list
> [email-masked]
> <smime.p7s>

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 29 Oct 2010 09:55:38 -0400

If you diff -02 and -03, you'll see that I only suggested two words,
"subordinate" and "parent" to clarify the wording that was already
in place.

I am the last one to serve as an arbiter of taste when it comes to
RESTful application of HTTP methods; most of what I know comes
from O'Reilly's "RESTful Web Services" by Richardson and Ruby.
In that book they develop a concept of a Resource Oriented
Architecture (ROA) and discuss two potential ways to employ
post.  I'll paraphrase to say that the way that's most consistent
with ROA is to use it as "append".  I know that other systems
claiming to be RESTful may use it more in the manner of
"invoke", but this seems like a trapdoor to a more RPC-like
behavior and is not deemed to be uniform by the O'Reilly
authors.

I don't think the CoAP spec prohibits the use of POST in this
manner, but perhaps the language should be a little more
equivocal to say the suggested use is more like "append".

Regards, -K-