Opened 10 years ago

Closed 9 years ago

#210 closed editorial (fixed)

Disentangle Block and Token

Reported by: cabo@… Owned by: cabo@…
Priority: major Milestone: post-WGLC-1
Component: block Version: block-08
Severity: In WG Last Call Keywords:
Cc:

Description

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

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

Change History (3)

comment:1 Changed 10 years ago by hartke@…

  • Version set to block-08

comment:2 Changed 10 years ago by cabo@…

  • Owner changed from draft-ietf-core-block@… to cabo@…
  • Status changed from new to assigned
  • Type changed from protocol defect to editorial

Modified this to an editorial ticket:
-- the technical changes have been made in block-10, and
-- we now just need to make sure that all editorial repercussions are covered.

comment:3 Changed 9 years ago by cabo@…

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

Fixed in [1265]:

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

Note: See TracTickets for help on using tickets.