Почему идентификатор потока 31 бит в HTTP/2 и почему ему предшествует зарезервированный бит?

Question

Формат кадра в HTTP/2 выглядит следующим образом (источник: HTTP/2: Frame Format):

+-----------------------------------------------+ 
|     Length (24)     | 
+---------------+---------------+---------------+ 
| Type (8) | Flags (8) | 
+-+-------------+---------------+-------------------------------+ 
|R|     Stream Identifier (31)      | 
+=+=============================================================+ 
|     Frame Payload (0...)      ... 
+---------------------------------------------------------------+ 

R: Зарезервированного 1-битовое поле. Семантика этого бита не определена, и бит ДОЛЖЕН оставаться неустановленным (0x0) при отправке и ДОЛЖЕН быть проигнорирован при получении.

Указатель потока: Идентификатор потока (см. Section 5.1.1), выраженный как 31-битное целое число без знака. Значение 0x0 зарезервировано для фреймов, связанных с соединением в целом, в отличие от отдельного потока.

Есть ли причина, по которой они не использовали 32-разрядное целое число без знака? И зачем указывать, что зарезервированный бит должен быть установлен в 0 и должен быть проигнорирован приемником?

Это просто уступка языкам, таким как Java, у которых нет 32-разрядного целого числа без знака?

Answer 1

Обсуждаемые здесь: https://github.com/http2/http2-spec/issues/67

Цель для экспериментов с потоком изменения приоритетов.

http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0135.html

Также для защиты от некоторых реализациях, имеющих проблемы с подписали против беззнаковое

Обсуждаемые в Гамбурге; это различные варианты использования, нет необходимости удалять (сейчас).