CoAP Blockwise Indicator

[mkovatsc]

It would be good to have metadata in the TD that tells from which payload size blockwise transfers should be used.

In addition -- or combined, there should be metadata if blockwise transfers are supported at all by the Thing.

[egekorkan]

@mkovatsc could you provide an example on how this should look like? We said that this metadata format should be provided in the CoAP vocabulary and the binding templates references to it and gives an example.

[takuki]

On September 20 in Fukuoka, it was suggested to discuss this with IETF during Singapore F2F meeting. See minutes here.

[JKRhb]

Adding on to this issue (I noticed it because of w3c/wot-discovery#93), I think you could theoretically add a CoAP Block option like the following to a Form to indicate that a blocksize of 64 is going to be used in responses:

{
  "cov:optionName": "Block2",
  "cov:optionValue": {
    "num": 0,
    "m": 0,
    "szx": 64
  }
}

Maybe this could also be abbreviated using something like cov:block2Size or cov:block1Size. As the actual blocksize is negotiated between client and server during the message exchange, however, I am not sure if this is actually necessary.

[egekorkan]

As the actual blocksize is negotiated between client and server during the message exchange, however, I am not sure if this is actually necessary.

If this is indeed always the case, I do not think it makes sense. Can the client use this information in any way, like starting the negotiation with a better initial value?

[JKRhb]

Can the client use this information in any way, like starting the negotiation with a better initial value?

Oh, I think this might actually be a valid use case (c. f. figure 4 in RFC 7959). This way it could be avoided that a consumer is surprised by a Block2 size that is too large. Thinking about it, this could be especially relevant for Block1 (POST/PUT) requests where the Thing might prefer a smaller block size (c. f. figure 9), e. g. because it might not be able to process larger packets.

I think the main question here would then be how to deal with the Block option format where three values are encoded into one unsigned integer. To follow the current format, the example I gave above should probably actually look like this:

{
  "cov:optionName": "Block2",
  "cov:optionValue": 2
}

So, as the block size parameter accepts values from 0 to 6 you could simply use a 2 in this case. This does not work as intuitively for the Block1 option, though, as the more flag has to be set for the initial request, increasing the option value by 7. Therefore, being able to specify dedicated Block1 and Block2 sizes (in a human readable form) could probably make sense here.

[egekorkan]

Oh, I think this might actually be a valid use case (c. f. figure 4 in RFC 7959).

I have partially understood the figure but enough to see the need for it in those cases.

This does not work as intuitively for the Block1 option, though, as the more flag has to be set for the initial request, increasing the option value by 7.

I did not understand this though.

[JKRhb]

This does not work as intuitively for the Block1 option, though, as the more flag has to be set for the initial request, increasing the option value by 7.

I did not understand this though.

Oh, sorry, it should have been "8" instead of "7" -- the more flag is represented by the fourth bit. During Block1 transfer the more flag has to be 1 in the first request, therefore the option value (if it is represented by a single unsigned integer) has to be incremented by 8 and does not solely show the value of the szx bits.

This is in contrast to the Block2 option where the more flag has to be 0 if it is included in the first request for early negotiation. Therefore the integer value only represents the the value of the szx bits in this case which makes this variant a bit easier to read for humans. However, I think there is most likely a more intuitive way for indicating the blocksize in a TD.

[JKRhb]

I think a more general question that relates to this issue is whether a generalized option format as it is currently used by the Procotol Binding is actually feasible. I have the impression the current format works well for HTTP where you have text-based header fields which all have the same format, but not so well for CoAP where options are used for all sorts of things, including URI paths.

This means, that you could have a form like

{
  "href": "/foo/bar",
  "cov:options": [
    { "cov:optionName": "Uri-Path", "cov:optionValue": "bar" },
    { "cov:optionName": "Uri-Path", "cov:optionValue": "foo" }
  ]
}

where it would be unclear whether foo/bar or bar/foo should be used as the actual URI path (each Uri-Path option represents one path segment).

As all CoAP options have to be registered with IANA it might be worth discussing if there should only be specific indicators for special CoAP options like the blockwise ones, as many options like Uri-Path (which is implied by the href), Content-Format (which is implied by the contentType) or Observe (which is implied by the subprotocol) should not be indicated anyway.

[ektrah]

IMHO there are not many CoAP options where it makes sense to tell a CoAP client to set some option X to value Y in a request without the client being aware of the semantics of that option. For example, setting the Observe option in a request makes little sense if the client doesn't understand that it'll receive a stream of notifications instead of a single response.

I would therefore argue for identifying features in forms rather than options. A feature would be something like observing a resource, performing a block-wise transfer, using OSCORE, etc. that the CoAP client needs to understand when making the request (and that leads to the inclusion of the right options in that request).

[JKRhb]

I completely agree with you here, @ektrah :) I guess the question would then be which features should be able to be specified in a form (besides block-wise and OSCORE) and which ones are already covered by other fields (which should maybe also be indicated in the document). @egekorkan: Do you think we could/should discuss this issue at one of the upcoming meetings?

By the way: Could OSCORE maybe also qualify as a SecurityScheme?

[ektrah]

Maybe something like this?

Feature	Covered by
Request to Server	existing "href": ...
Request to Proxy	existing "href": ... + new "cov:proxy": ...
Caching: Validation	– (should be set by the CoAP client based on the contents of its cache)
Conditional Requests	– (doesn't seem very useful to specify in a TD)
Content Negotiation	new "cov:accept": ... or existing "cov:optionName": 17, "cov:optionValue": ...
Observing Resources	"subprotocol": "cov:observe"
Block-Wise Transfer	new "cov:maxBlock2SZX": ... + new "cov:maxBlock1SZX": ...
Quick Block-Wise Transfer	new "cov:maxQBlock2SZX": ... + new "cov:maxQBlock1SZX": ...
Hop Limit	new "cov:hopLimit": ... or existing "cov:optionName": 16, "cov:optionValue": ...
OSCORE	SecurityScheme
EDHOC	SecurityScheme

Details (click to expand)

Request to Server
3 Uri-Host
7 Uri-Port
11 Uri-Path
15 Uri-Query

Request to Proxy
3 Uri-Host
7 Uri-Port
11 Uri-Path
15 Uri-Query
35 Proxy-Uri
39 Proxy-Scheme

Caching: Validation
4 ETag

Conditional Requests
1 If-Match
5 If-None-Match

Content Negotiation
17 Accept

Observing Resources
6 Observe

Block-Wise Transfer
23 Block2
27 Block1
28 Size2
60 Size1

Quick Block-Wise Transfer
19 Q-Block1
28 Size2
31 Q-Block2
60 Size1

Hop Limit
16 Hop-Limit

OSCORE
9 OSCORE

EDHOC
21 EDHOC

[JKRhb]

Maybe something like this?

Looks great, thank you! :) Two questions: Maybe the Accept option could also be derived from the contentType of the form (or rather: its ExpectedResponse)? (The same question probably also applies to the HTTP binding.) Also, maybe Size2 could also be indicated in the form?

[egekorkan]

@egekorkan: Do you think we could/should discuss this issue at one of the upcoming meetings?

Yes sure, I propose this as a general item to identify what parts are to be described in a TD (like the table above). I have some other topics for a binding meeting but I was postponing them to help TD spec PRs and issues to resolve due to publication schedule.

[egekorkan]

Call of 23.02

• This is actually a general approach question: Should protocol options encapsulated in optionName and optionValue or more like features by doing cov:maxBlock2SZX?
  • There are some options that cannot be just "copy pasted" by taking the values from the forms but a behavior needs to be implemented (like observing: it is an option to set in the headers but a specific behavior is needed)
  • @ektrah would prefer the feature way
• The modbus is done in the "feature" way
• For other protocols, it is not necessary to write a "MyProtocol in RDF" first but doing this would be also beneficial for using the protocol outside of WoT.

[JKRhb]

I think this issue could be closed by now, right? :)

[egekorkan]

Yes can be closed, after a long time :)