Opened 11 years ago

Closed 9 years ago

#203 closed protocol defect (fixed)

Restrict the potential combinations of Block1 and Block2

Reported by: cabo@… Owned by: draft-ietf-core-block@…
Priority: major Milestone:
Component: block Version:
Severity: In WG Last Call Keywords:
Cc:

Description

Bert Greevenbosch noted that, currently, there is nothing that would
disallow a server to respond to a message that carries a non-final
(more=1) Block1 with a response carrying a Block2 option. This
creates a large number of potential combinations, not all of which
have been tested by examining them in examples or implementing them.

Instead, the set of combinations should be limited to the ones that we
created Block1/Block2 for in the first place. If more complex
exchanges are required later, they can be enabled by another option.

The main reason to have Block1 separate from Block2 was to be able to
send large response payloads to a POST request with a large payload.
It is therefore sufficient to allow the use of Block2 (or any payload,
for that matter) in the response only for requests that either don't
carry Block1 or carry a Block1 option with M=0 (i.e., final).

(Note that it still needs to be possible to send error indication
payloads with 4.xx/5.xx responses to requests that carry Block1 with
M=1).

Change History (1)

comment:1 Changed 9 years ago by cabo@…

  • Resolution set to fixed
  • Status changed from new to closed

Fixed in [1265]:

Fix #203
Fix #206
Fix #209
Fix #210
Fix #245

Note: See TracTickets for help on using tickets.