Subject: [core] CoAP Block: zero length default values

From: Markus Becker <[email-masked]>
Date: Wed, 17 Oct 2012 15:02:52 +0200

Dear Carsten, dear WG,

please advise us on an issue with the Block Option and its default values.

Assuming a client requests a block transfer of resource with the Block2 option 
and the default value of 0.

According to draft-ietf-core-coap-12#section-5.4.4 the complete option SHOULD 
NOT be included:

   Options may be defined to have a default value.  If the value of
   option is intended to be this default value, the option SHOULD NOT be
   included in the message.  If the option is not present, the default
   value MUST be assumed.

For the server to detect that a Block transfer is requested, the option cannot 
be completely left out of the request, though. Should this valid reason 
speaking against the SHOULD NOT (BCP14) and the possibility of zero-length 
options be stated explicitly in core-block? E.g.

   The default value of both the Block1 and the Block2 Option is zero,
   indicating that the current block is the first and only block of the
   transfer (block number 0, M bit not set); however, there is no
   explicit size implied by this default value.
+   Contrary to the default value behaviour specified in draft-ietf-core-
+   coap-12#section-5.4.4, the Block options need to be included for the
+   0-length default values, as the other end-point would not be able to
+   notice that a block transfer is desired.

This text fragment should be similarly extended:

   The default value of both the Block1 and the Block2 Option is zero,
   indicating that the current block is the first and only block of the
   transfer (block number 0, M bit not set); however, there is no
   explicit size implied by this default value.

The table might need to be adapted to 0-3 B as well, to make this more clear:

      +------+----------+--------+--------+--------+---------------+
      | Type | C/E      | Name   | Format | Length | Default       |
      +------+----------+--------+--------+--------+---------------+
      |   19 | Critical | Block1 | uint   | 1-3 B  | 0 (see below) |
      |      |          |        |        |        |               |
      |   17 | Critical | Block2 | uint   | 1-3 B  | 0 (see below) |
      +------+----------+--------+--------+--------+---------------+

Or, should there be no default value for Block options thus increasing the 
size of the request by 1 byte for a rare case?

--
Markus

------------------------------------------------
| Dipl.-Ing. Markus Becker
| Communication Networks
| TZI - Center for Computing Technologies
| University Bremen
| Germany
------------------------------------------------
| web: http://www.comnets.uni-bremen.de/~mab/
| mailto: [email-masked]
| telephone: +49 421 218 62379
| building: NW1 room: N2260
------------------------------------------------

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 17 Oct 2012 15:53:36 +0200

> size of the request by 1 byte for a rare case?

Well, maybe it is indeed best to get rid of the fiction of a "default value" for Block1/2.
This was maybe more the reflection of an implementation strategy than a piece of actual semantics.

As you say, if the Block option is not present, this is different from a Block option value of 0 (SZX=0, M=0, NUM=0).
Say maybe we should just say that the Block option does NOT have a default value, and that absence of the Block option is equivalent to (SZX=unspecified, M=0, NUM=0).
[Looking into my own implementation -- that is exactly what I'm doing.  Oops.]

Also, as you say, for consistency we should also allow giving an explicit zero-length uint value.
0 again happens to mean SZX=0, M=0, NUM=0, and even though SZX=0 is one of the less likely choices and therefore not one we would be specifically optimizing for, we allow zero length uint for a zero everywhere else.

Very timely input for the upcoming -10, thanks!

Grüße, Carsten

---

From: Markus Becker <[email-masked]>
Date: Wed, 17 Oct 2012 16:06:58 +0200

> > Or, should there be no default value for Block options thus increasing
> > the size of the request by 1 byte for a rare case?
> 
> Well, maybe it is indeed best to get rid of the fiction of a "default
> value" for Block1/2. This was maybe more the reflection of an
> implementation strategy than a piece of actual semantics.
> 
> As you say, if the Block option is not present, this is different from a
> Block option value of 0 (SZX=0, M=0, NUM=0). Say maybe we should just say
> that the Block option does NOT have a default value, and that absence of
> the Block option is equivalent to (SZX=unspecified, M=0, NUM=0). [Looking
> into my own implementation -- that is exactly what I'm doing.  Oops.]

Would that mean that the server can decide to send a Block option for a 
"large" resource in a response, even though the client did not put a Block 
option in the request? What is the supposed behaviour of a client not 
implementing Block, but receiving a Block option in the response? RST?

> Also, as you say, for consistency we should also allow giving an explicit
> zero-length uint value. 0 again happens to mean SZX=0, M=0, NUM=0, and
> even though SZX=0 is one of the less likely choices and therefore not one
> we would be specifically optimizing for, we allow zero length uint for a
> zero everywhere else.
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 17 Oct 2012 16:57:33 +0200

> option in the request?

We indeed made that decision.
That is not very related to the question whether the Block2 option has a default value or not.

The reasoning that we allow a server to spontaneously insert a Block2 option is as follows:
-- a client can't really know whether the resource representation is "large" from the p.o.v of the server
-- so a client that does implement Block would need to send the option with every single request
-- clients that are actually interested in the representations of large respurces are more likely to implement Block2 than not.

The underlying assumption is that the distribution of representation sizes is somewhat bimodal:
Sensor readings are very likely not to be "large" for a sensor.
Manifests like .well-known/core are like to be large enough that a client that wants them already implements Block2.

> What is the supposed behaviour of a client not 

We recently clarified this in coap-12.
Section 5.4.1 now says:

   o  Unrecognized options of class "critical" that occur in a
      confirmable response, or piggy-backed in an acknowledgement, MUST
      cause the response to be rejected (Section 4.2).

Now, 4.2 says:

... rejecting a Confirmable message is effected
    by sending a matching Reset message and otherwise ignoring it.  
... Rejecting an Acknowledgement
    or Reset message is effected by silently ignoring it.

and 4.3:
... rejecting a Non-Confirmable message MAY involve sending a matching
    Reset message, and apart from the Reset message the rejected message
    MUST be silently ignored.

So if the response was piggy-backed, you do nothing about the Block option.
If the response was in a separate CON request, you RST.
If the response was in a separate NON, you MAY RST.

In any case, you can't do anything about the fact that the server is only prepared to give you the resource representation if you implement Block2.
We wanted to give servers this freedom.
Conclusion: As a client that wants to handle large resources, you better do implement Block2.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 21 Oct 2012 14:01:34 +0200

On Oct 17, 2012, at 15:53, Carsten Bormann <[email-masked]> wrote:

> [...]

Well, I decided to backport this and submit a -10 with just this fix, and with the new option numbers that fit coap-12.
(Otherwise these small but important updates would be buried in the large number of outstanding editorial changes, which are now scheduled for block-11.)

Htmlized:        http://tools.ietf.org/html/draft-ietf-core-block-10
Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-10

Grüße, Carsten