Subject: [core] draft-ietf-core-coap-13 WGLC - my comments

From: Bert Greevenbosch <[email-masked]>
Date: Fri, 21 Dec 2012 02:42:56 +0000

Hello all,

I have reviewed the CoAP spec. I have the comments below.
After each comment number, I wrote an "E" for "Editorial" or "T" for "Technical".
I think the draft is in a very good shape, and that most comments below can be resolved quite easily.
I look forward to your opinions!

Best regards,
Bert

1,E) p.9: "Provoking a Reset message (e.g., by sending an empty Confirmable message) is also useful as an inexpensive check of the liveness of an endpoint ("CoAP ping")."
I am not sure if we should endorse provoking RST messages by sending empty CON messages.

2,E) p.11: "One could think of CoAP logically as using a two-layer approach, a CoAP messaging layer used to deal with UDP and the asynchronous nature of the interactions, and the request/response interactions using Method and Response codes (see Figure 1). CoAP is however a single protocol, with messages and request/response just features of the CoAP header."
I do not follow the thread about CoAP as a two layer protocol, whereas in my view it is a plain single application layer protocol. Is this text needed?

3,E) p.14: "almost, but not entirely unlike"
Should this be "almost, but not entirely alike"?

4,T) p.21: "An empty message has a Code field set to 0. The Token Length field MUST be set to 0 and no bytes MUST be present after the Message ID field. If there are any bytes, they MUST be processed as a message format error."
p.32: "The Acknowledgement to the Confirmable response MUST also be an empty message, i.e. one that carries neither a request nor a response."
This is violated by figure 10 in the block-10 draft, where a block option is included in the ACK from a CON response. Change here or in block? Maybe there will be future options that may need inclusion in ACKs to CON responses too?

5,E) p.23: "A server MAY relax the requirement to answer all retransmissions of an idempotent request with the same response (Section 4.2), so that it does not have to maintain state for Message IDs. For example, an implementation might want to process duplicate transmissions of a GET, PUT or DELETE request as separate requests if the effort incurred by duplicate processing is less expensive than keeping track of previous responses would be."
Although not explicitly stated here, the draft seems to imply that DELETE is idempotent. This is true from the result point of view (afterwards the resource is deleted), however the first request should give a different response (2.02 Deleted) than the subsequent request (4.04 Not Found). Is this issue too small to declare DELETE non-idempotent?

6,E) p.25: "In order not to cause congestion, Clients (including proxies) MUST strictly limit the number of simultaneous outstanding interactions that they maintain to a given server (including proxies) to NSTART. ... The default value of NSTART for this representation is 1."
The usage of NSTART is confusing in this text. It may be better to start the text with "Let NSTART be an integer, which has a default value 1.", after which continuing with "In order not to cause congestion, ...".

7,T) p.25: "Unless this is modified by additional congestion control optimizations, it MUST be chosen in such a way that an endpoint does not exceed an average data rate of PROBING_RATE in sending to another endpoint that does not respond."
p.26, in the table: "PROBING_RATE = 1 Byte/second".
p.21: "Retransmission is controlled by two things that a CoAP endpoint MUST keep track of for each Confirmable message it sends while waiting for an acknowledgement (or reset): a timeout and a retransmission counter. For a new Confirmable message, the initial timeout is set to a random counter between ACK_TIMEOUT and (ACK_TIMEOUT*ACK_RANDOM_FACTOR) (see Section 4.8), and the retransmission counter is set to 0. When the timeout is triggered and the retransmission counter is less than MAX_RETRANSMIT, the message is retransmitted, the retransmission counter is incremented, and the timeout is doubled. If the retransmission counter reaches MAX_RETRANSMIT on a timeout, or if the endpoint receives a Reset message, then the attempt to transmit the message is canceled and the application process informed of failure."
It seems that PROBING_RATE is another constraint on top of what is defined on p.21, since the algorithm of p.21 alone would already violate the probing rate, especially at the beginning of the retransmissions. Is 1 Byte/second reasonable? Does it mean that a 16 byte CoAP message needs at least 16 seconds between two subsequent retransmissions? Over which time frame is the PROBING_RATE calculated?
Suggestion: remove PROBING_RATE.

8,T) NSTART=1 implies that you cannot send a bulk of requests at once. Is this the intention, or would a small but higher value of NSTART still be acceptable?

9,E) p. 28, According to my calculations the final value EXCHANGE_LIFETIME should be 247, not 248.

10,E) An important goal of section 4.8.2 seems to be finding a reasonable time after which message IDs can be re-used. Maybe that goal should be explicitly mentioned at the beginning of the section?

11,E) Depending on the resolution of comment 5, the text in section 5.1, p29 may need to be updated.

12,E) p.32: "A token is intended for use as a client-local identifier for differentiating between concurrent requests (see Section 5.3); it could have been called a "request ID"."
Remove the reference to Section 5.3, especially since the text is in its subsection 5.3.1.

13,T) p.35: "an option is never "mandatory""
Maybe in the future there will be options that require other options to be included? Or a option could be mandatory in the response, when responding on a critical option from a request.

14,T) p.37: "Implementation Note: On a quality of implementation level, there is a strong expectation that a Content-Format indication will be provided with resource representations whenever possible. This is not a "SHOULD"-level requirement solely because it is not a protocol requirement, and it also would be difficult to outline exactly in what cases this expectation can be violated."
There could be other means to determine the content-format. For example, if the resource URI has the suffix ".jpg", it is highly expectable that it refers to a picture coded as an octet-stream. Would it be good to define a default value "octet-stream" for the content-format option?

15,E) p.37: "For responses indicating a client or server error, the payload is considered a representation of the result of the requested action only if a Content-Format Option is given. In the absence of this option, the payload is a Diagnostic Payload ({{diagnostic-message-payload}})."
Is this text needed? What does ({{diagnostic-message-payload}}) mean? What is the format of the Diagnostic Payload?
Suggestion: remove the text.

16,E) p.38: ""selected representation"""
Fix the typo of the double quotes. Consider if the "selected representation" is a good name, as in fact the representation is not selected. Maybe "candidate representation" is better?

17,T) p.39: "Unlike HTTP, the cachability of CoAP responses does not depend on the request method, but on the Response Code."
What does this mean? When the choice of the methods is between PUT and GET, I suspect that the caching depends on that choice.

18,T) p.42: "The request URI in a proxy request is specified as a string in the Proxy-Uri Option (see Section 5.10.2), while the request URI in a request to an origin server is split into the Uri-Host, Uri-Port, Uri-Path and Uri-Query Options (see Section 5.10.1); alternatively the URI in a proxy request can be assembled from a Proxy-Scheme option and the split options mentioned."
Also related to section 5.10.2 on p.50.
Why are there two ways to define the proxy URI? Maybe the Proxy-Uri option is not needed.
An advantage of the proxy-uri option may be that multiple URIs can be included in a single request. If that is the case, why not mandate proxy-uri for all forward-proxy requests? Two mechanisms to provide the same functionality is unnecessary overhead.

19,T) The cache key seems to be the collection of options that are needed to identify a particular representation of a resource. After much reading, I understand that when a request contains options that are in the cache key, and the proxy does not have a cached representation for exactly those values of the cache key options, then it needs to acquire the related representation, whereas if all options are proxy-safe and not in the cache key, the proxy can ignore them and provide the cached response.
The draft already implies that the no-cache-key property will seldom be used, as it reserves three bits of the option number for it, and the option is only considered not a cache key when these three bits are all set. In addition, the no-cache-key property can only hold for options that are proxy safe, leading to possible option numbers 28, 29, 40, 41, 72, 73, ...
A proxy can safely ignore the no-cache-key property, in which case it will consider all proxy-safe options to be in the cache key and it does not need to check these bits.
The draft itself does not provide itself a proxy safe option that is not in the cache key.
Is this mechanism really needed? If so, provide a clear definition of the cache-key is needed, also in the definitions section.

20,E) It would be easier to look up the default port value directly from table 1 on p.49.

21,E) The '-' in the 'N' column in table 1 on p.49 indicates that the option per definition is in the cache-key. Provided that we keep the no-cache-key property, add a clarification to the table.

22,E) p. 51: "The CoAP Accept option indicates when included one or more times in a request, one or more Content-Formats, each of which is an acceptable Content-Format for the client, in the order of preference (most preferred first)."
This sentence is hard to read. How about the following rewrite:
"The CoAP Accept option can be used to indicate which Content-Formats are acceptable to the client. Multiple Accept options can be included in a request, in order of preferred Content-Format (most preferred first)."

23,E) p.52: "If one or more Location-* options are present and thus a location URI is indicated (Section 5.10.7), the tagged representation is the representation that would be retried by a GET request to the location URI."
Replace "retried" by "retrieved"

24,T) p.53: "... more Location-* options may be defined in the future, and have been reserved option numbers 128, 132, 136, and 140."
Are these reservations still needed, or are they remnants of the long jump times?

25,T) p.58: "7. If /port/ does not equal the request's destination UDP port, include a Uri-Port Option and let that option's value be /port/."
Is my understanding correct that this happens only when talking with forward-proxies?

26,T) p.63: "The NoSec and RawPublicKey modes are mandatory to implement for this specification."
Do we really want to mandate DTLS for all CoAP implementations?

27,T) p.66: "A message is the same when it is sent within the same DTLS session and same epoch and has the same Message ID."
This requires the epoch to be shorter than the EXCHANGE_LIFETIME from section 4.8.1, as after this EXCHANGE_LIFETIME message ids can be re-used.

28,T) p.71, section 10.1.4: "If the action performed by the POST method does not result in a resource that can be identified by a URI, a 2.04 (Changed) response MUST be returned to the client. If a resource has been created on the origin server, a 2.01 (Created) response MUST be returned."
Can a resource that can be identified by an URI also be changed, and thus a 2.04 (Changed) response returned? If so, simplify the first sentence.

29,E) p.71: "Unless otherwise specified all the statements made are RECOMMENDED behavior; some highly constrained implementations may need to resort to shortcuts."
I am not sure if there will be much constrained proxies. Maybe it could be rephrased as follows:
"Unless otherwise specified all the statements made are RECOMMENDED behavior; implementations MAY defer from those recommendations in accordance with their requirements."

30,E) p.71: "As the OPTIONS and TRACE methods are not supported in CoAP a 501 (Not Implemented) error MUST be returned to the client."
Should the MUST be a SHOULD, as the section contains recommendations?

31,E) p.74: "Also, a caching proxy MUST NOT make cached values available to requests that have lesser transport security properties than to which it would make available the process of forwarding the request in the first place."
What does this sentence mean? Clarify.

32,T) p.75: "A CoAP server can reduce the amount of amplification it provides to an attacker by using slicing/blocking modes of CoAP [I-D.ietf-core-block] and offering large resource representations only in relatively small slices. E.g., for a 1000 byte resource, a 10-byte request might result in an 80-byte response (with a 64-byte block) instead of a 1016-byte response, considerably reducing the amplification provided."
This indeed reduces the amplification attack, but instead it increases the network traffic and transport complexity in the normal case. How about the adding the following sentence:
"The advantages of the amplification attack mitigation should be weighed against the increase in network traffic in the general case."

33,E) Section 12.1.1:
If we want to maintain the no-cache-key indication, we need to reflect that in the requirements for IANA registration of new options too.

34,T) p.80: "Each entry in the sub-registry must include the Response Code in the range 64-191, a description of the Response Code, and a reference to the Response Code's documentation."
Do we exclude 1.xx codes on purpose?

35,E) Depending on the outcome of comment 24, remove the reserved options 128, 132, 136 and 140 from table 4 on p.82.

36,T) p.83: "The default value, if any. For a critical option with a default value, a discussion on how the default value enables processing by implementations not implementing the critical option (Section 5.4.4)."
Non-critical options need to have a well considered default value too, as the other endpoint may not know whether the option was ignored or was not included because the endpoint uses the default value. I think IANA registration should require text on default values in any case, although the text "No default value has been defined." may be acceptable.

37,E) p.93: "The response includes a Payload of "22.3 C" and is 10 bytes long."
I think this should be 11 bytes.

38,E) p.94: "Figure 16 shows a similar example, but the inclusion of an non-empty Token (Value 0x20) in the request and (Jump 15 + 4 = 19) in the response, increasing the sizes to 18 and 12 bytes respectively."
Remove "and (Jump 15 + 4 = 19) in the response".
According to my calculations, the value 18 should be replaced by 17.

39,E) In the last example of Appendix B, a rather exotic URI is encoded. Is such an URI allowed? I especially worry about the empty uri-path options and "/" characters.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 20 Dec 2012 23:19:24 -0500

> Should this be "almost, but not entirely alike"?
It's a kind of "inside joke."  It's referring to a line from the book "The
Hitchhiker's Guide to the Galaxy", in which, when they ask the food
synthesizer for tea, they get something "almost, but not entirely unlike
tea."

Barry

---

From: Bert Greevenbosch <[email-masked]>
Date: Fri, 21 Dec 2012 05:50:29 +0000

Hi Barry,

Haha, yes, I have seen that citation more often. Maybe it here misses the "quite" as in "Almost, but not quite, entirely unlike tea." tough. Maybe that was done on purpose as the food synthesizer did a bad job in making tea, whereas we want to convey much similarity between the CoAP methods and their HTTP counterparts?

Best regards,
Bert

From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: 21 December 2012 12:19
To: Bert Greevenbosch
Cc: [email-masked] WG
Subject: Re: [core] draft-ietf-core-coap-13 WGLC - my comments

> Should this be "almost, but not entirely alike"?
It's a kind of "inside joke."  It's referring to a line from the book "The Hitchhiker's Guide to the Galaxy", in which, when they ask the food synthesizer for tea, they get something "almost, but not entirely unlike tea."

Barry

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Dec 2012 08:10:52 +0100

On Dec 21, 2012, at 06:50, Bert Greevenbosch <[email-masked]> wrote:

> Maybe it here misses the "quite" as in "Almost, but not quite, entirely unlike tea."

Oh, I'll take that as an editorial comment :-)

(This wasn't intended as a direct quote, but more in the sense of the general jargon as documented in
http://www.catb.org/~esr/jargon/html/N/not-entirely-unlike-X.html
as Barry correctly decoded.)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Dec 2012 08:36:29 +0100

Hi Bert,

I'll pick some of your comments and reply with my personal view.
I'll construct a separate subject for each so we have some threading if the discussion continues.

> I am not sure if we should endorse provoking RST messages by sending empty CON messages.

We have found that it is very useful to have some lightweight "are you there" mechanism.
This is both for diagnostics, and for address selection ahead of a heavy-weight non-idempotent operation.

Now we could define a NOOP method that does nothing.  In a Confirmable message, this would elicit an empty ACK.
In total, this would look a lot like the mechanism described above, but with a "positive" ACK.
4-byte request, 4-byte ACK.

However, the empty/RST exchange has essentially the same properties, with the simple advantage that you already (should) have implemented it.
One method less, requires no additional code.
Calling it out here was motivated by noticing that not every implementation before ETSI CoAP2 caught the MUSTs that make it work.

One could argue that a ping that "works" should not end in an "error" message like RST.
However, there are other cases where a RST is somewhat "normal", so seeing a RST should not be raising red alarms anyway.

So I agree a bit with the sentiment you are expressing, but I think it is not sufficient reason to add a NOOP method.
(I also briefly thought about instead adding an ECHO method (sends back the payload) so you can run diagnostics with different packet sizes.
With a payload of 0 bytes, this becomes similar to NOOP, except that the ACK would carry a response code.
Also sounds somewhat useful, but do we really need it?  
We most likely don't want an equivalent of CHARGEN, as this would be inviting amplification attacks.)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Dec 2012 08:47:26 +0100

On Dec 21, 2012, at 03:42, Bert Greevenbosch <[email-masked]> wrote:

> This is violated by figure 10 in the block-10 draft, where a block option is included in the ACK from a CON response. Change here or in block?

We had a long discussion of this in Sophia-Antipolis (ETSI CoAP2).
This needs to be fixed in -block.
(See my notes below.)

> Maybe there will be future options that may need inclusion in ACKs to CON responses too?

The conclusion from this discussion was that it is a good thing to keep empty ACKs empty so they can be left out when running CoAP over alternate transports that have their own reliability mechanisms, such as SMS or TCP.

Grüße, Carsten

Fixed examples for Block1-Block2 interaction:
(Needs to add discussion of "Initiative".)

Block options may be used in both directions of a single exchange.
The following example demonstrates a blockwise POST request, resulting
in a separate blockwise response.

~~~~~~~~~~~
CLIENT                                                     SERVER
  |                                                              |
  | CON [MID=1234], POST, /soap, 1/0/1/128      ------>          |
  |                                                              |
  | <------   ACK [MID=1234], 2.01 Created, 1/0/1/128            |
  |                                                              |
  | CON [MID=1235], POST, /soap, 1/1/1/128      ------>          |
  |                                                              |
  | <------   ACK [MID=1235], 2.01 Created, 1/1/1/128            |
  |                                                              |
  | CON [MID=1236], POST, /soap, 1/2/0/128      ------>          |
  |                                                              |
  | <------   ACK [MID=1236], 0                                  |
  |                                                              |
  | <------   CON [MID=4712], 2.01 Created, 2/0/1/128, 1/2/0/128 |
  |                                                              |
  | ACK [MID=4712], 0                           ------>          |
  |                                                              |
  | <------   CON [MID=4713], 2.01 Created, 2/1/1/128            |
  |                                                              |
  | ACK [MID=4713], 0                           ------>          |
  |                                                              |
  | <------   CON [MID=4714], 2.01 Created, 2/2/1/128            |
  |                                                              |
  | ACK [MID=4714], 0                           ------>          |
  |                                                              |
  | <------   CON [MID=4715], 2.01 Created, 2/3/0/128            |
  |                                                              |
  | ACK [MID=4715], 0                           ------>          |
~~~~~~~~~~~
{: #post-response title="Atomic blockwise POST with separate blockwise response" }

This model does provide for early negotiation input to the 

~~~~~~~~~~~
CLIENT                                                     SERVER
  |                                                             |
  | CON [MID=1234], POST, /soap, 1/0/1/128 ------>              |
  |                                                             |
  | <------   ACK [MID=1234], 2.01 Created, 1/0/1/128           |
  |                                                             |
  | CON [MID=1235], POST, /soap, 1/1/1/128 ------>              |
  |                                                             |
  | <------   ACK [MID=1235], 2.01 Created, 1/1/1/128           |
  |                                                             |
  | CON [MID=1236], POST, /soap, 1/2/0/128, 2/0/0/64 ------>    |
  |                                                             |
  | <------   ACK [MID=1236], 0                                 |
  |                                                             |
  | <------   CON [MID=4712], 2.01 Created, 1/2/0/128, 2/0/1/64 |
  |                                                             |
  | ACK [MID=4712], 0                           ------>         |
  |                                                             |
  | <------   CON [MID=4713], 2.01 Created, 2/1/1/64            |
  |                                                             |
  | ACK [MID=4713], 0                           ------>         |
  |                                                             |
  | <------   CON [MID=4714], 2.01 Created, 2/2/1/64            |
  |                                                             |
  | ACK [MID=4714], 0                           ------>         |
  |                                                             |
  | <------   CON [MID=4715], 2.01 Created, 2/3/0/64            |
  |                                                             |
  | ACK [MID=4715], 0                           ------>         |
~~~~~~~~~~~
{: #post-response-e title="Atomic blockwise POST with separate blockwise response, early negotiation" }

THERE IS NO LATE NEGOTIATION...

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Dec 2012 10:24:13 +0100

On Dec 21, 2012, at 03:42, Bert Greevenbosch <[email-masked]> wrote:

> 8,T) NSTART=1 implies that you cannot send a bulk of requests at once. Is this the intention,

Yes.

> or would a small but higher value of NSTART still be acceptable?

According to RFC 5405, no.
However, this is qualified for a 3-second interval, so there may be some leeway here.

What happens is this:
The first request goes out.  If it is acknowledged, the counter limited by NSTART (we need a name for that) goes back to 0 and we can send the second request.
If it isn't, we retransmit the first request after 2-3 seconds, so we continue to use up the RFC 5405 limit.
If the first retransmission of the first request is acknowledged, we can send the second request.
If not, we might be able to squeeze in a second request if we only want to stick to the letter of RFC 5405.
However, the point of BEBO is to actually slow down in the face of losses, so this shouldn't be overdone.
If we have to do this, it may be a good idea to operate the second request on the BEBO schedule of the first request (i.e., stick to the maximum of the BEBO variables per peer).

Of course, the 3 seconds of RFC 5405 were picked out of thin air at a time when people weren't thinking that much about constrained networks.
Maybe it actually is too low (i.e., too high a rate) for us!

But, actually, clamping down NSTART to 1 if you know nothing about path or peer is a *feature*.  
The poor server receiving those requests has to process them.  It may only have one buffer.
If a new request comes in before it had a chance to respond to the first one, it will essentially have to drop the packet (or trash the old request).
(And similar considerations may apply to constrained routers on the way.)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Dec 2012 10:34:07 +0100

This may actually mainly be an editorial problem.

> 7,T) p.25: "Unless this is modified by additional congestion control optimizations, it MUST be chosen in such a way that an endpoint does not exceed an average data rate of PROBING_RATE in sending…

You are quoting this out of context.

The context is:

   In order not to cause congestion, Clients (including proxies) MUST
   strictly limit the number of simultaneous outstanding interactions
   that they maintain to a given server (including proxies) to NSTART.
   An outstanding interaction is either a CON for which an ACK has not
   yet been received but is still expected (message layer) or a request
   for which neither a response nor an Acknowledgment message has yet
   been received but is still expected (which may both occur at the same
   time, counting as one outstanding interaction).  The default value of
   NSTART for this specification is 1.

Now this is the text that explains how to handle non-responding peers:

   A client stops expecting a response to a Confirmable request for
   which no acknowledgment message was received, after
   EXCHANGE_LIFETIME.  The specific algorithm by which a client stops to
   "expect" a response to a Confirmable request that was acknowledged,
   or to a Non-confirmable request, is not defined.  Unless this is
   modified by additional congestion control optimizations, it MUST be
   chosen in such a way that an endpoint does not exceed an average data
   rate of PROBING_RATE in sending to another endpoint that does not
   respond.

So:

1) If a Confirmable request times out, you reset the NSTART counter (for which we still need a name) to 0 after EXCHANGE_LIFETIME.
2) For Non-confirmables, we don't have a timeout.  So we use PROBING_RATE to decay the NSTART counter.

> p.26, in the table: "PROBING_RATE = 1 Byte/second".

Yes, that is quite conservative.  I had 7 bytes/second, but there was some transport input that this might be too much.

> p.21: "Retransmission is controlled by two things that a CoAP endpoint MUST keep track of for each Confirmable message it sends while waiting for an acknowledgement (or reset): a timeout and a retr…

Well, this is unrelated; none of this is controlled by PROBING_RATE.

> It seems that PROBING_RATE is another constraint on top of what is defined on p.21, since the algorithm of p.21 alone would already violate the probing rate, especially at the beginning of the retransmissions.

This is the editorial issue: We need to make clear that these two don't interact.

> Is 1 Byte/second reasonable? Does it mean that a 16 byte CoAP message needs at least 16 seconds between two subsequent retransmissions? Over which time frame is the PROBING_RATE calculated?

Actually, there is a need for another clarification: The usage of PROBING_RATE needs to account for overhead.  So, for a 16 byte CoAP message, you would account 16+8+40 = 64 bytes (IPv6), so, the next one goes out only after 64 seconds or when the response is received, whatever comes earlier.

> Suggestion: remove PROBING_RATE.

PROBING_RATE is needed to keep some control over Non-confirmables.  I don't think we can take that away.
If you never send a Non-confirmable, you can ignore PROBING_RATE.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Dec 2012 11:12:07 +0100

> 39,E) In the last example of Appendix B, a rather exotic URI is encoded. Is such an URI allowed? I especially worry about the empty uri-path options and "/" characters.

Yes, such a URI is allowed.  There have been comments to the previous WGLC that the likelihood of implementers getting this right is low.
Thus the example.  (We all know that implementers tend to implement the examples, not so much the text.)

Empty Uri-Path options just reared their ugly head when we started to do nested link-format resources.

If you have a link-format resource at

coap://foo.bar

then <baz> as an anchor means

coap://foo.bar/baz

which is what most people would expect.

If you have a "nested" link-format resource at

coap://foo.bar/qux

then <baz> as an anchor means

coap://foo.bar/baz

which is NOT what most people expect.
You have to put the resource at

coap://foo.bar/qux/

so that <baz> as an anchor means

coap://foo.bar/qux/baz

Aren't relative-path URIs fun?

To encode

coap://foo.bar/qux/

you need

Uri-Path "qux"
Uri-Path ""

This is a piece of URI complexity that I don't think we can avoid to mimic in CoAP.

Grüße, Carsten

(PS.: Fun observation: The encoding of the second Uri-Path option is a single null byte.)

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 21 Dec 2012 13:04:09 +0200

> so that <baz> as an anchor means

RFC6690 says that, if the link has no "anchor" and no "rel" attribute,
then the Context URI is the Origin of the link format resource's base
URI. The Origin of <coap://foo.bar/qux/> is the triple ("coap",
"foo.bar", 5683). So, for this example, the result should be
<coap://foo.bar/baz>, no?

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Dec 2012 12:28:43 +0100

> <coap://foo.bar/baz>, no?

OK, so let's not take RFC 6690 as an example but any other content format that simply makes use of the rules in section 5 of RFC 3986.

My more general point is that

>> coap://foo.bar/qux/

is different from

>> coap://foo.bar/qux

so we need a way to represent it.  And that's probably the most important reason Uri-Path components need to be able to be zero-length.
(The more general principle enabled by this is data transparency, which is also a good thing to have.)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Dec 2012 16:47:05 +0100

> 35,E) Depending on the outcome of comment 24, remove the reserved options 128, 132, 136 and 140 from table 4 on p.82.

They are still needed.

Long jump just facilitated giving them higher option numbers (and we could go even higher if we wanted).
But the point is that any endpoint that is trying to piece together a Location and finds one of these options BUT doesn't understand it knows that it can't properly piece together the location.
This is an evolvability problem:
We don't have any other way right now to make elective options depend on each other, where some of them will only be defined in the future, if ever.

Grüße, Carsten

---

From: Bert Greevenbosch <[email-masked]>
Date: Thu, 27 Dec 2012 06:48:46 +0000

Hi Carsten and Klaus,

I have checked RFC 3986, and section 6.2.4 indeed indicates that the two URIs "http://example.com/data" and "http://example.com/data/" are considered different unless there are strong reasons to believe they are equivalent. That justifies an empty URI-Path option on the end of the URI.

I didn't find text in RFC 3986 that forbids the example URI (coap://198.51.100.1:61616//%2F//?%2F%2F&?%26), so on the risk of a false positive, I would say the URI indeed is valid.
 
I had some worries about the two slashes at the beginning of the path component. However RFC 3986 forbids this only for relative URIs, not for absolute URIs such as this one (see also the schema below).

Best regards,
Bert

      URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

      hier-part   = "//" authority path-abempty
                  / path-absolute
                  / path-rootless
                  / path-empty

      path-abempty  = *( "/" segment )
      path-absolute = "/" [ segment-nz *( "/" segment ) ]
      path-rootless = segment-nz *( "/" segment )
      path-empty    = 0<pchar>

      segment       = *pchar
      segment-nz    = 1*pchar

      pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
      unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"      
      pct-encoded   = "%" HEXDIG HEXDIG
      sub-delims    = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="	

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: 21 December 2012 19:29
To: Klaus Hartke
Cc: [email-masked] WG
Subject: Re: [core] BG39 -- Exotic URI (Re: draft-ietf-core-coap-13 WGLC - my comments)

is different from

Grüße, Carsten

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

---

From: Bert Greevenbosch <[email-masked]>
Date: Thu, 27 Dec 2012 07:13:35 +0000

Hi Carsten,

Thanks for your explanation. I certainly understand your point.

However, I am not sure if reserving the location options justifies it. Especially since now every client that supports location-path and location-query MUST check for the absence of the elective options 128, 132, 136 and 140 before interpreting the known location options.

Although the draft indeed requires this check: "If any of these reserved option numbers occurs in addition to Location-Path and/or Location-Query and are not supported, then a 4.02 (Bad Option) error MUST be returned.", I wonder how many implementations actually do it.
 
Apart from that, there may be other elective options in the future that relate to already existent options. Why not reserve numbers for them? I am not really proposing this, but I wonder why, as an exceptional case, we do this for future location-* options.

It seems we are looking for some kind of option hierarchy: elective options that are not really elective when other options are present. Why not just make these options critical?

Best regards,
Bert

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: 21 December 2012 23:47
To: Bert Greevenbosch
Cc: [email-masked] WG
Subject: BG24, BG35 -- reserved Location-* options (Re: [core] draft-ietf-core-coap-13 WGLC - my comments)

They are still needed.

Grüße, Carsten

---

From: Bert Greevenbosch <[email-masked]>
Date: Thu, 27 Dec 2012 07:47:05 +0000

Hi Carsten,

<quote>
...
</quote>

Yes, that makes a lot of sense. Then indeed it is best to fix it in the Block draft.

B.T.W. The below sequence could also make sense when the client sent a PUT/POST request without Block, but the server needs to use Block in its response. Would it then would be something like below?

CLIENT                                                SERVER
  |                                                     |
  | CON [MID=1234], POST, /soap                 ------> |
  |                                                     |
  | <------   CON [MID=4712], 2.01 Created, 2/0/1/128   |

Best regards,
Bert

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: 21 December 2012 15:47
To: Bert Greevenbosch
Cc: [email-masked] WG
Subject: BG4 -- empty ACKs (Re: [core] draft-ietf-core-coap-13 WGLC - my comments)

Grüße, Carsten

~~~~~~~~~~~
CLIENT                                                     SERVER
  |                                                              |

~~~~~~~~~~~
CLIENT                                                     SERVER
  |                                                             |

---

From: Bert Greevenbosch <[email-masked]>
Date: Thu, 27 Dec 2012 09:28:07 +0000

Hi Carsten,

Thank you for your many answers to my comments.

I believe to understand that you mean, that the probing rate does not apply to messages that are resent as part as the CON resend mechanism. So only a new message (with a new message ID) needs to observe the probing rate?

What I mean is, when we send a 64 byte message, we need at least 64*PROBING_RATE = 64 seconds between sending two messages *with different message ids*, for which no ACK or response is received? However, resending *the same* message (as part of the CON resend mechanism) within this time is OK?

Why is the probing rate dependent on the message size? Can't we just set a fixed value for all messages?

Best regards,
Bert

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: 21 December 2012 17:34
To: Bert Greevenbosch
Cc: [email-masked] WG
Subject: BG7 -- PROBING_RATE (Re: [core] draft-ietf-core-coap-13 WGLC - my comments)

The context is:

So:

Grüße, Carsten