Unspecified handling of `urgency` values outside the defined range

[LPardue]

The defined range of the urgency parameter is [0,7]. We don't have any text that explains how endpoints generate or consume urgency parameters outside the range.

One option for the endpoints that receive such a parameter is to ignore it. This is problematic if ignoring means use default urgency level.

Another option is to specify that the values outside the range are floored/clamped. e.g. a value less than 0 MUST be interpreted as 0, a value greater 7 MUST be interpreted as 7.

[kazuho]

My preference goes to handling them as default (i.e. urgency=1).

The reason behind is that I think it would be a good idea to penalize (likely) intentionally broken endpoints, rather than awarding them sometimes (by allowing some servers to interpret negative numbers as more urgent than urgency=0, or numbers greater than 7 as urgencies below "background").

[ianswett]

I believe I prefer clamping. I also prefer to avoid situations where values aren't expressible, which is possible in this case, but requires some changes we may not like(ie: allowing all 31 bits of values and saying that at least 3 bits of prioritization MUST be supported).

[ianswett]

I realize we can also allow the request or response to fail(ie: 500) if we want to be strict about this. That doesn't seem like the right option, but I figured it was worth writing down.

Thought: clamping works well for integer values, but not as well for non-integer values. That makes me think Kazuho's suggestion of treating it as the default might be the simplest option?

[kazuho]

Thought: clamping works well for integer values, but not as well for non-integer values. That makes me think Kazuho's suggestion of treating it as the default might be the simplest option?

:+1: Maybe something like "MUST ignore parameters with a value of unexpected type or range."

[LPardue]

Sounds good, but we need then need some text to mandate that all parameter definitions MUST provide a default

[kazuho]

we need then need some text to mandate that all parameter definitions MUST provide a default

I am not sure if that is the case. I think that an extension can define different behavior based on the existence (or the absence) of a parameter.

[LPardue]

Ooh good point. In this case, an invalid urgency value on a response header would lead to it being ignored and therefore the initial request priority would not be overridden.

[c-taylor]

Where changing underneath the client, some kind of server echo would aid diagnosis/debug. Client error attribute?

[LPardue]

@c-taylor I don't understand what you're asking for exactly.

When the initial priority is sent, there may be many parties involved in the collaboration of the effective response priority that is used to start delivering the first bytes. It is useful to echo the chosen priority information as a response header in this phase. (This is something permitted by the spec today).

Anything extra is, I think, asking for a new carriage mechanism and I think is out of scope. For example, there is no way to respond to a PRIORITY_UPDATE frame that includes a parameter that is invalid and ignored. Attempting to use an error code would have a critical effect on the connection.

[kazuho]

To be closed by #111. The PR adopts https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/102#issuecomment-555793774, stating that "unknown parameters, parameters with out-of-range values or values of unexpected types MUST be ignored."