Subject: [quicwg/base-drafts] Lead to fragment code-spaces (#4296)

From: Lars Eggert <[email-masked]>
Date: Wed, 28 Oct 2020 07:17:18 -0700

>22.1.2.  Selecting Codepoints
>
>  New uses of codepoints from QUIC registries SHOULD use a randomly
  selected codepoint that excludes both existing allocations and the
  first unallocated codepoint in the selected space.  Requests for
  multiple codepoints MAY use a contiguous range.

Doesn’t this lead to fragment code-spaces where it becomes progressively
harder to get blocks. Why this policy?

Related to which I am not sure the process in para 2 of 22.1.3 is realistic
and wonder of it is really needed.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4296

---

From: Mike Bishop <[email-masked]>
Date: Wed, 28 Oct 2020 09:44:16 -0700

The comment on 22.1.3 is a duplicate of #4275.

The policy was selected to avoid incentives to "squat" on the next available value, causing deployment conflicts.

Yes, theoretically lack of contiguous blocks could occur in the limit.  However, the questions is what size block would be needed, and how many registrations would need to occur in a 62-bit space for there to be _no_ blocks of that size remaining.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4296#issuecomment-718062268

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Oct 2020 23:22:58 -0700

As Mike says, it is hard to conceive of any human being able to approve registrations at a rate sufficient to exhaust the available space.  That is, unless the blocks are extremely broad, suggesting that they registration might be denied for being spammy.

In any case, where a block is desired it is likely to be more efficient to acquire a single codepoint with a short encoding and then encode additional information in the associated value.

As this is second-guessing a carefully negotiated aspect of the protocol, I don't think that a change is warranted here.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4296#issuecomment-718388124