New principle: When handling extensibility by having clients ignore unknown parameters, consider a "critical" list

[jyasskin]

This was brought up in our discussion of w3ctag/design-reviews#1041 and WICG/signature-based-sri#38.

One common way to allow future extensibility of a protocol is to have a list of named parameters, and have clients ignore parameters they don't understand, rather than always erroring. That way, future senders can opt into the new abilities without breaking old recipients. But sometimes a new ability is "critical" for the client to safely handle the message, and it would be better to fail rather than skip that part of the processing. This shows up in PNG and X.509 certificates. It's absent from HTTP headers and HTML.

[martinthomson]

I've seen this pattern used in a number of places, so it might be worth documenting.

However, I don't think that it is necessarily a good pattern. You are baking in a breaking change without the other components necessary to manage that breaking change.

What you do when you specify something like this is provide a way to break the entire thing (the PNG image doesn't show, the certificate isn't valid, the signature fails to validate).

You can sometimes lift this problem up a layer. To continue your examples, image/png might be supplanted by image/better-png so that clients can gracefully select between the new and old thing. (In practice, you only need one decoder for both formats.) In TLS, you might negotiate the use of a "new" form of certificate rather than have a server present what is now a useless chunk of bytes to a client.

Any time you make a breaking change to a format, you are asking everyone who consumes that format to change, or else. Because -- often -- you have not given them an alternative. Sure, you can detect that something is wrong, but the "must understand" addition on its own does nothing to address the migration problem.

In HTTP, we had to invent that next layer up before we could do HTTP/2. We defined ALPN in TLS to cleanly negotiate the use of a breaking change protocol. We then discovered that that wasn't enough and we have since flailed around with a bunch of ways to smooth the transition. Managing breaking changes is the work, adding new ways to break things is often working against that goal.