Subject: [core] #203: Restrict the potential combinations of Block1 and Block2

From: "core issue tracker" <[email-masked]>
Date: Wed, 28 Mar 2012 14:05:28 -0000

#203: Restrict the potential combinations of Block1 and Block2

 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).

-- 
-----------------------------+-------------------------------------
 Reporter:  cabo@…           |      Owner:  draft-ietf-core-block@…
     Type:  protocol defect  |     Status:  new
 Priority:  major            |  Milestone:
Component:  block            |    Version:
 Severity:  In WG Last Call  |   Keywords:
-----------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/203>
core <http://tools.ietf.org/core/>