UPGRADE: Do we need granular control?

I believe https://github.com/w3c/webappsec/issues/184 is the only
outstanding issue on UPGRADE at the moment. The goal there is to split the
behavior into "navigational" and "other", and turn both into source lists.
We'd end up with something like (insert naming bikeshed)
`upgrade-insecure-navigations example.com other-example.com;
upgrade-insecure-resources cdn.example.com othercdn.example.com`, and the
current `upgrade-insecure-requests` would desugar into
`upgrade-insecure-navigations [insert protected resources' host];
upgrade-insecure-resources *`.

Before I dive into adding that to the text, I'd like to determine whether
it's necessary. :)

Right now, we have two more or less compatible implementations of the
current spec (though I think Firefox doesn't yet send the signaling
header). I haven't heard any requests for the functionality from folks
using the header, just from Brad and Yan. Is it something we should add
before moving to CR? It would explain the current functionality with better
primitives, but it's not clear to me whether it's worth the added
complexity.

Brad, Yan, Alex? If any of you (or anyone else, really) feels strongly
about it, that's probably good enough, but if this is just a nice-to-have,
I'd suggest we punt it and just call v1 done.

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)