Subject: Cache Digests status

From: Mark Nottingham <[email-masked]>
Date: Mon, 14 Jan 2019 15:29:57 +0900

After discussion with the editors, the chairs believe that it isn't likely that this draft will be implemented widely enough to justify standardisation - even as Experimental - in the foreseeable future.

Therefore, we intend to move it to the "dead" state (as described in <https://datatracker.ietf.org/help/state/draft/ietf>). 

Note that if sentiment changes, the draft *can* be "resurrected." If we've misread the signals and there are people intending to implement (especially on the browser side, as that's the primary use case it's designed for), please bring that to our attention. 

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Loïc Hoguin <[email-masked]>
Date: Wed, 23 Jan 2019 12:28:04 +0100

Thanks for the notice.

This draft seemed like a good solution to optimize PUSH and I was 
looking forward to it (mostly for server/API/mobile clients). Are there 
any plans for an alternative?

Thanks,

-- 
Loïc Hoguin
https://ninenines.eu

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 24 Jan 2019 18:39:52 +0900

I don't wanna let Cache Digest dead too.

currently mozilla seems not mention about this,
so I'm asking Mozilla Standard Position.

https://github.com/mozilla/standards-positions/issues/131

reply for this will good material for considering this specs future.

Jxck

2019年1月24日(木) 18:12 Loïc Hoguin <[email-masked]>:

> > After discussion with the editors, the chairs believe that it isn't
> likely that this draft will be implemented widely enough to justify
> standardisation - even as Experimental - in the foreseeable future.
> >
> > Therefore, we intend to move it to the "dead" state (as described in <
> https://datatracker.ietf.org/help/state/draft/ietf>).
> >
> > Note that if sentiment changes, the draft *can* be "resurrected." If
> we've misread the signals and there are people intending to implement
> (especially on the browser side, as that's the primary use case it's
> designed for), please bring that to our attention.
> >
> > Cheers,
> >
> >
> > --

---

From: Sebastiaan Deckers <[email-masked]>
Date: Thu, 24 Jan 2019 19:31:29 +0800

> any plans for an alternative?

Browser native support is lacking but I have recently been using Cuckoo
Filters purely on the server side to avoid repeated push_promise on the
same connection. Found it to be quite effective. [1] Others in the Node.js
community expressed interest in CD. Ironically the main concern, from
discussion, was the Experimental status of the CD RFC. Since Node.js does
not expose a low level API to HTTP/2 frames it is impossible (afaik?) to
implement the spec properly at this time. Not sure about other popular
frameworks/languages and their HTTP/2 implementations. Perhaps affordance
could be made in the spec to use headers instead of custom frames. Or maybe
implementors of HTTP/2 could be encouraged to expose frame-level access,
just like custom HTTP header fields, to allow more experimentation.

1. https://gitlab.com/commonshost/server/merge_requests/35/diffs

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 24 Jan 2019 11:51:44 +0000

On Thu, 24 Jan 2019, 11:35 Sebastiaan Deckers <[email-masked] wrote:

> Since Node.js does not expose a low level API to HTTP/2 frames it is
> impossible (afaik?) to implement the spec properly at this time. Not sure
> about other popular frameworks/languages and their HTTP/2 implementations.
> Perhaps affordance could be made in the spec to use headers instead of
> custom frames. Or maybe implementors of HTTP/2 could be encouraged to
> expose frame-level access, just like custom HTTP header fields
>

I think this is an important observation. The utility of H2 extension
frames is restricted by their ease of use (or lack thereof). It is very
difficult to experiment with ideas for extension frames. The current
landscape seems to place the client-side as a gate with a high bar. In
contrast, headers are very easy to experiment with and build a supporting
case.

If we consider the origins of Cache Digest, would it have even been adopted
without the evidence from the sub-optimal cookie-based prior work?

Frames have some unique characteristics that are not possible with headers
alone.  It is a shame that the present state of affairs make it hard to
realize their potential.

Lucas

---

From: Martin Thomson <[email-masked]>
Date: Fri, 25 Jan 2019 09:53:45 +1100

> reply for this will good material for considering this specs future.

Thanks for opening that.  I've responded there.  This is somewhat difficult, and I sympathize with the chairs' thinking here as well.  This is a neat idea and it - at least in theory - offers prospects for making server push better/viable (depending on your perspective there...).

However, for us at least, our current understanding of the cost-benefit tradeoff is that it isn't really worth doing right now.  The chairs are making the right call.