Re: HTML for email

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

On Tue, Mar 2, 2021 at 12:44 PM Larry Masinter <[e-mail]> wrote:

> There is a working group WPACK which could have taken on the problem of
> how to package HTML, embedded image, JavaScript libraries in a way that
> could be interpreted in a sandboxed environment. Maybe what they are doing
> could be retargeted for such a purpose?
>

No.

And here is my objection to the current IETF approach of 'focused' WGs:
They are more likely to produce an output but it is very likely to be an
output that it would be better hadn't been created in the first place.

What I needed for my work is a packaging format that supports:

1) Incremental Encryption
2) Incremental Integrity
3) Authentication

What Google needed for their immediate commercial needs was a simple
archive technology that zips up a few Web page components delivered over
HTTP/TLS. So they wrote a very narrow spec that only addressed their use
case and then came to IETF to get it blessed as a niche solution. But it is
a solution that was designed with absolutely no thought to the wider
problem. They didn't want to consider the wider problem at all.

This is how PKIX got in the state it has. Instead of considering revocation
from a high level standpoint and building a scalable solution we had a
'make do' solution which led to another incremental solution which was
again curtailed and... That is how we ended up with five separate assertion
types in PKIX. TAXI which became the basis for XKMS and SAML was an attempt
to simplify and get back to basics.

What I fully expect will happen of course is that at some point we will
want to introduce DARE into IETF. Security of Data at Rest is starting to
become an enterprise concern. And of course there will be people asking
'why not build it on WPACK' and 'why not use CBOR' and the answer will be
that there are very specific requirements that apply to DARE which the
people working on those systems told me are out of scope and they do not
want to consider.

Oh and the reason DARE is designed the way it is is for backwards
compatibility with a different set of standards. JSON-B is a strict
superset of JSON encoding so that every valid JSON document is also JSON-B.
You need a separate serializer to make use of JSON-B encoding but a single
decoder will decode both and also the compressed version and the version
with binary encodings for extended binary data types.


Using DARE for HTML packaging is easy because I designed it to support HTML
packaging even though I had absolutely no need for that at the time I did
the work. Why did I design that spec to meet a use case I don't care about?
Well if you want your spec to support unexpected and new use cases you
cannot imagine, you had better start by meeting the use cases you can.

The SAML TC had a use cases sub-committee that spent hours arguing over
which use cases to include. Some of that argument was productive because it
resulted in a better statement of the use case. But a lot of it was
pointless discussion of whether a use case was important enough to generate
a requirement and I didn't care whether it was important enough, I worked
out a way to meet the requirement regardless.