Abbreviated structured field dictionary keys about compression-dictionary-transport

[pmeenan]

Mostly to keep things short. We did the same with extensible HTTP priorities using u for urgency and i for incremental.

I think we're fine either way but the HTTP working group usually seems to skew towards brevity.

[annevk]

We didn't do this for https://w3c.github.io/reporting/#header. Seems unfortunate we're not consistent here.

If this is going for TAG review, could you ask about this? It seems https://w3ctag.github.io/design-principles/#naming-is-hard is in need of an update.

[pmeenan]

Looks like the reporting header is a flat dictionary with no pre-defined keys (each key is a "name" for the given endpoint).

We're still pre-experiment so it's a good time to make changes. I'll default to long prefixes as the starting point and see if shortening is necessary. We're already using base-16 hash strings instead of base-64 for convenience over brevity.

[mnot]

Brevity, yes, but that's usually regarding ReallyPointlesslyLongHeaderNames. I don't think you'd get much pushback on path vs p (although I agree someone will say something).

[pmeenan]

While we're looking at the naming, would match be clearer than path to the extent that what is being specified is the path-matching rule to be used for future requests?