Re: [core] WG Last Call on draft-ietf-core-new-block

["Christian M. Amsüss" <[e-mail]>]

Hello,

where not explicitly responded to, the updates address my points, thank
you for updating the document.

> >   * The Q-Block options do not support stateless operation / random
> >     access.
> 
> [Jon] Actually Q-Block2 does now support this following the redefinition of
> the M bit usage in a previous iteration (with M=0 you can ask for any
> individual block).

Random access can also be in the Block1 phase; a standalone `PUT
/resource Block1:5/0/6` can be used independenlty of other operations to
overwrite a particular part of a resource.

> [Jon] For stateless, Request-Tag is included so this should be fine.
> https://datatracker.ietf.org/doc/html/draft-ietf-core-stateless-06#section-4

By stateless, I was referring to the server not keeping state per body.
That is the opposite of using a Request-Tag.

> >   * Proxying of Q-Block is limited to caching full representations.
> > 
> >   (The latter might be mitigated by additional text around caching, but
> >   I doubt it's worth the effort given it's not part of the use case).
>
> [Jon] I am not entirely convinced that Block1/2 have got the caching by
> block properly sorted out - e.g. what happens when different clients make
> requests with different SZX and Block2 is part of the cache key.  The
> limiting to caching full representations is there so that a new can of worms
> is not opened up.

The Block options are not part of the cache key -- they are
not-safe-to-forward and thus come with rules as to the cache behavior,
rather than havign a cache-key property.

The behavior is sorted out: If an earlier client requested, say,
block2:0//6 (first 1KiB), then while that is fresh, it may be used to
serve any request for smaller chunks (say, block2:1//5 for bytes
512-1024).

The same is true in the other direction: A proxy may use its cached
3x256 bytes (even exceeding the Max-Age), ask the server for the 4th 256
byte block (which by its ETag confirms the others are still good), and
then serve them combined as a 1KiB response.


Thus, I think these two points (Incomplete support for random access,
and block-by-block proxying) still stand to be added to the
considerations.

To give you background on why I'm so picky about this list: People
*will* still get the initial impression that this is the
later-and-greater version, and for the outlined purposes it is, but if
we don't set the expectations right here, there will be disappointment.

BR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom