Improve quic:alpn_information

[rmarx]

As reported by @hlandau on the mailing list:

quic:alpn_information:

RFC 7301 states that ALPN protocol strings are byte strings, not text.
How should ALPN protocol strings which are not valid UTF-8 or not
valid text be logged?

[LPardue]

This issue is correct. Implementations that treat ALPN IDs as if they were strings can hit issues. Although qlog is not in the hot path, assuming sequence is safe to encode is not robust (especially as it is uncontrolled data).

My inclination would be to define a ALPN ID type for qlog. That could carry the raw bytes encoded as hexstring and/or the "friendly" representation if its safe. e.g.

ALPNIdentifier = {
  ? bytes: hexstring
  ? string: string
}

The reason being that most people would recognise h3 on sight, but scratch their heads about what 0x68 0x33 is.

Furthermore, while looking at the section, I think we should actually cite the ALPN RFC and tighten up the text at the same time.

[hlandau]

Personally I would just go with the hex encoding. Providing the ability to use either seems overkill. Not being able to eyeball a qlog file to read the ALPN might be annoying, but that will be the case anyway if an implementation does the robust thing and only serialises the hex encoding.

[marten-seemann]

Not being able to quickly read the "h3" ALPN from a qlog seems like a non-starter to me. I don't want to remember (or rather, look up 1000 times) what that is in hex.

[LPardue]

Agree with Marten here.

HTTP headers might actually suffer the same issues now I think about it.