[Mathmesh] Interaction between MATHMESH and WPACK

[Phillip Hallam-Baker <[e-mail]>]

Given that we have two BOFs that are considering similar technology
proposals, it seems to me that we should consider whether we need to have
two new formats or whether one can do both.

To that end, I would like to encourage some discussion of these issues
prior to Singapore. In particular, I would like to see if a common approach
is feasible. Otherwise, the risk is we end up having to support two new
formats.

Looking at the various WPACK proposals, I can see two possible paths. One
is to work out some way to cram what is wanted into ZIP or MHTML. The
objective being 'code reuse'. Which is great in theory but only if it is
possible to reuse the existing code. Re-use of existing design is
considerably less appealing and especially so if we end up needing to do
backwards compatibility etc.

This also applies to the attempt to reuse parts of HTML. I stopped being
active in HTML when we were still trying to move from 1.0 to 1.1. It was
already clear that RFC822 header syntax was a major constraint but it was
too late to change that decision without a complete redesign. Which we
couldn't even get to in HTTP/2 and are only just starting to look at for
HTTP/3. WPACK should attempt to hit the target where it is going to be in
the future, not where it is now. Some of us have been through signing
headers in the world of DKIM. It was necessary but it certainly wasn't at
all pleasant.

So what I would like to see WPACK do for its own sake even if it is never
taken up in the world of HTTP, is to introduce the structured separation of
headers into functional units that we wanted in HTTP/1.1 (Simon Spero
tried) but couldn't do. In other words instead of

Connection: Keep-Alive
Content-Type: text/html
Date: blah
Content-Encoding: gzip

We should have had (using JSON for clarity but at the time it was
S-expressions being discussed)

Connection: Keep-Alive
Date: blah
Content-Meta {
  "type":"text/html"
  "Content-Encoding" : "gzip" }

If we had had this type of separation, HTTP/1.1 would have been a lot
easier.

The protocol headers can and do change in transit. But if the content
metadata had been collected together in one place it should actually be
unmolested end-to-end unless the content itself had been changed. It does
present the material in a form that allows it to be signed.

I don't think the choice of JSON or CBOR is particularly consequential. But
the browser is going to have a JSON parser which is why I focus on that.

Providing a ZIP like capability does not require us to go any further than
content metadata. But WPACK potentially requires a bit more as we are not
just looking to display the content to the user, we want to push it into
their browser cache. And so it is not just the content and associated
metadata that are at issue here, it is also the binding of that data to the
resource identifier. So what we are looking at is actually something more
like:

Resource {
  "uri" : "http://example.com/fred.html"
  "expires" : "2019-dec-01: blah"
  "Content-Meta" : {
    "type":"text/html"
    "Content-Encoding" : "gzip" }

And this could potentially be signed separately in certain contexts.