Add reserved code range for private use by applications

[ntninja]

See GH/#158. Changes are analogous to those proposed in GH/#159.

[Stebalien]

Unfortunately, this has the same problem as X- headers. People will use them, systems will start to rely on them, then they'll no longer be "reserved" or "private".

If you just want to experiment, you don't actually need a reserved private range. You can just pick random numbers that aren't currently used, because you can change them at any time... If you can't change them at any time, you should just ask for a "draft/experimental" allocation.

So, I'm not terribly against this change as, at worst, it's a foot gun. I just don't think this range is particularly necessary, or something anyone should actually use.

[rvagg]

I think this is fine, an analogy of 10.0.0.0/8, 192.168.0.0/16 and friends would be more appropriate than X- headers I think. They are explicitly excluded from inclusion here or in code that consumes the table.

It might be interesting to hear your usecase though @ntninja?

[Stebalien]

I think this is fine, an analogy of 10.0.0.0/8, 192.168.0.0/16 and friends would be more appropriate than X- headers I think. They are explicitly excluded from inclusion here or in code that consumes the table.

Well, private IP addresses can't be used on the public internet while I can definitely see app devs using "private" multicodecs.

However, I see your point. "X-" are considered "experimental" while app-specific multicodecs cannot be stabilized. We'd have to very carefully document how they should be used, but I could see them being useful in, e.g., a local database where I need to identify types that don't actually make any sense in a more global context.

[mikeal]

It’s certainly better to have experiments use a high range rather than running experiments against a low range.

Not reserving the space doesn’t prevent people from doing ‘X-‘ header like experiments, it just pushes them into a high number range instead of running their experiments in a number range closer to what they may want the codec to be in the future. If their experiment ends up solidifying on that number and can’t change, at least that happened in a high number range where we have plenty of space and are less likely to see conflicts.

We may want to add some guidance though, like “when using this range please generate a random number in the range using SOME_MATH” so that they are less likely to conflict with other experiments. I worry that just noting the range will mean that everyone just uses the first or last entry in the range.

[Stebalien]

I believe #165 is the real solution for experiments:

1. Encourage experiments in a high range.
2. Encourage experimenters to actually register experimental codecs, and make it really easy.

Codes in the private range absolutely should not be used for experiments.