Subject: [core] #210: Disentangle Block and Token

From: "core issue tracker" <[email-masked]>
Date: Mon, 16 Apr 2012 09:01:24 -0000

#210: Disentangle Block and Token

 During the ETSI plugtest, it became clear that the interaction between
 the Block options (in particular Block1) on one hand and the Token
 option on the other hand creates problems in implementations.  Closer
 analysis shows that the complex interaction in -block-08 is not really
 needed.  Implicating a mechanism like tokens into the server state
 that is created for some block-wise transfers would only be needed if
 multiple concurrent block-wise transfers from one endpoint were
 required.  As we have seen in Paris, this is just way too much
 complexity for this obscure usecase.

 Simplify the interaction of Tokens and Block:

 1. retain, and do not extend, the exact response matching rules
   defined in CoAP-09 (this obviates the need to define how Block
   options influence the response matching: they simply don't).

 2. remove the somewhat opaque text about using the Token for the
   selection of cache state for fast-changing resources (Block2):

     "The client MAY
     facilitate identifying the sequence by using the Token Option with a
     non-default value.  "

   This leaves the client end-point and the URI as the cache selector
   for fast-changing resources.
   (#206 will be solved in the process of spelling this out in more
 detail.)

   This is exactly all that is needed (unless we want to enable the
   rather rare use case of concurrent Block2 transfers from one client
   all to the same URI on one server, but concurrently retrieving
   different cached versions).

 3. similarly, for the state for atomic POST/PUT ("context"):
   select this per end-point (and URI), too.

   Remove this text:

    "If multiple concurrently proceeding block-wise request payload
    transfer (e.g., PUT or POST) operations are possible, the requester
    SHOULD use the Token Option to clearly separate the different
    sequences.  In this case, when reassembling the representation from
    the blocks being exchanged to enable atomic processing, the
    reassembler MUST compare any Token Options present (and, as usual,
    taking an absent Token Option to default to the empty Token).  If
    atomic processing is not desired, there is no need to process the
    Token Option (but it is still returned in the response as usual)."

     * note that this means a new upload to the same URI (before an old
     one from the same endpoint was finished) simply overwrites the
     context.  This is probably exactly what one wants.

     * Future work could define a version of Pledge that informs the
     client how long the server is willing to keep such a context.

 4. There now is never a need to send back Block options in error
   responses (except for 4.13 negotiation, where it is clear what is
   meant)

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

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