Should there be a way to mass-register multiple context IDs? about draft-ietf-masque-h3-datagram HOT 5 CLOSED

If you need to carry 8 bits, then I think the simplest solution is to register a single context whose format contains those 8 bits at the start of theHTTP Datagram Payload? Since the context ID is encoded as a variable-length integer, these two encodings have the same amount of wire overhead. Can you think of any use cases that would be better solved by "mass registration"?

from draft-ietf-masque-h3-datagram.

The issue I saw was that if you need lets say the equivalent of 4 bits, then you can either register 16 contexts for a Datagram overhead of 1 bytes if you had no prior need for context IDs. If you want to go from one format to two and also are adding a front byte then you consume 2 bytes, one for the context ID you didn't need before, and one byte to carry the actual value. With the context ID's variable encoding and only half of the values can be initiated by the endpoint the limit for keeping the context ID within one byte is anyway no more than 5 bits worth of values anyway.

However, I think the later is the cleaner solution and likely the one we should go with. For our Connect-IP proposal it looks like we will have context IDs anyway for our flow forwarding mode.

But this was a question to ask openly as we had this thoughts and maybe others have even stronger aversion for overhead to carry a couple of bits and thus may want to encoded it in the context ID. But if not anyone else has strong need, then I don't think we really need any mass registration mechanism.

from draft-ietf-masque-h3-datagram.

Thanks, that makes sense. Let's leave this open for some time to see if anyone has use cases or other thoughts.

from draft-ietf-masque-h3-datagram.

From a parsing standpoint, the first thing you need to know is whether datagrams contain a context ID or not, so there's obviously value in context/no-context.

Next, you need to be able to map a particular context to a purpose. That might be done with Context Extensions, in which case there's value in declaring them. But it might also be done in HTTP headers, in which case the registration of a particular context before use might be unnecessary. (Obviously you'll still need to register locally with your HTTP implementation which contexts you should receive the datagrams for once you read the headers.)

Context Extensions feel more useful in declaring parameters for a particular purpose -- but if that's how they're used, I don't see the point of the global registry. Each purpose is essentially defining a custom datagram protocol at that point and can define what the parameters in the Extensions mean for that purpose.

from draft-ietf-masque-h3-datagram.

We haven't seen more use-cases for a context mass registration system, so I'm closing this issue for now. We can reopen it if use-cases arise.

from draft-ietf-masque-h3-datagram.