Subject: [core] draft-ietf-core-block-08 - Response matching rules

From: Klaus Hartke <[email-masked]>
Date: Wed, 11 Apr 2012 06:31:24 +0200

The normal rules for matching responses to requests are that the IP
address, port, security context and token must match. The Block
options extend this, but it's not explicitly stated how.

There are numerous cases where the response does not literally echo
the Block options in the request, including:

- A request without Block2 Option can result in matching response with
Block2 Option.
- A request with Block2 Option can result in a matching response
without Block2 Option.
- A request with Block2 Option can result in a matching response with
a different Block2 Option.
- A request with Block1 and Block2 Option can result in a matching
response without Block2 Option.
- A request with Block1 Option can result in a matching response with
both Block1 and Block2 Option.
- ...

So, what are the exact rules for matching a response to a request when
-block is involved?

Related questions:

* Is a client required to start an up/download at block number 0?

* Does an error response have to include Block options (so it can be
matched to its request)?

* Does a Block option in descriptive usage in an error response
describe the error payload or does it describe the payload that would
have been returned if the request was successful?

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Apr 2012 13:28:14 +0200

Ah, and now the fun part.

> So, what are the exact rules for matching a response to a request when

This is not spelled out, but needs to be.

The Block options have a default value, so I don't think we need to discuss present and absent separately.

I'd say that a response matches a request if the block number/szx combination points to the same initial byte (this enables going from no option to an option with block number 0 or from one szx to a different szx).

I'd still be happier if people were only invoking the special "same-token" magic for those cases in the use of Block1 where this is needed.  (Maybe it was wrong to involve Token in atomic Block1 in the first place.  Hmm.)

> * Is a client required to start an up/download at block number 0?

See discussion about order in separate email.

> * Does an error response have to include Block options (so it can be

Now, that is an interesting question indeed.
Given that Block is optional, but critical, the answer can't always be yes (i.e., a "unknown critical option not supported" response shouldn't have to carry Block1 or Block2 :-).
That happens to match an initial blockwise request, but I think it would be unwise to always rely on that.

Some error messages will pertain to the option values given in the request (e.g., if there were an "unknown Block number" error, that would only make sense when it can be correlated to the request option).

> have been returned if the request was successful?

Good catch.

We need to spell out more explicitly that Block2 options do not govern error payloads (4.xx/5.xx).  (The text currently talks about what they mean for 2.xx only, but that is not enough.)

Grüße, Carsten