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

[[e-mail]]

Hi Christian,

We have gone for adding in the following to the disadvantages list. 

* The Q-Block Options do not support stateless operation/random access.
* Proxying of Q-Block is limited to caching full representations.

Regards

Jon
> -----Original Message-----
> From: Christian M. Amsüss [mailto: [e-mail]]
> Sent: 16 February 2021 23:49
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block
> 
> 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#sec
> > tion-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