5. Identifiants de contexte

Le mécanisme de relais IP dans HTTP défini dans ce document permet aux extensions futures d'échanger des datagrammes HTTP qui portent des sémantiques différentes des charges utiles IP. Certaines de ces extensions peuvent augmenter les charges utiles IP avec des données supplémentaires ou compresser les champs d'en-tête IP, tandis que d'autres peuvent échanger des données qui sont complètement séparées des charges utiles IP. Pour accomplir cela, tous les datagrammes HTTP associés aux flux de requête de relais IP commencent par un champ ID de contexte (Context ID) ; voir Section 6.

Les ID de contexte sont des entiers de 62 bits (0 à 2^62-1). Les ID de contexte sont encodés sous forme d'entiers de longueur variable ; voir Section 16 de QUIC. La valeur d'ID de contexte 0 est réservée aux charges utiles IP, tandis que les valeurs non nulles sont allouées dynamiquement. Les ID de contexte pairs non nuls sont alloués par le client, et les ID de contexte impairs sont alloués par le proxy. L'espace de noms des ID de contexte est lié à une requête HTTP donnée ; il est possible qu'un ID de contexte avec la même valeur numérique soit alloué simultanément dans des requêtes distinctes, potentiellement avec des sémantiques différentes. Les ID de contexte NE DOIVENT PAS être réalloués au sein d'une requête HTTP donnée mais PEUVENT être alloués dans n'importe quel ordre. Les restrictions d'allocation d'ID de contexte à l'utilisation d'ID de contexte pairs et impairs existent afin d'éviter le besoin de synchronisation entre les points de terminaison. Cependant, une fois qu'un ID de contexte a été alloué, ces restrictions ne s'appliquent pas à l'utilisation de l'ID de contexte ; il peut être utilisé soit par le client soit par le proxy IP, indépendamment de quel point de terminaison l'a initialement alloué.

L'enregistrement est l'action par laquelle un point de terminaison informe son pair de la sémantique et du format d'un ID de contexte donné. Ce document ne définit pas comment l'enregistrement se produit. Les extensions futures PEUVENT utiliser des champs d'en-tête HTTP ou des capsules pour enregistrer des ID de contexte. Selon la méthode utilisée, il est possible que des datagrammes soient reçus avec des ID de contexte qui n'ont pas encore été enregistrés. Par exemple, cela peut être dû au réordonnancement du paquet contenant le datagramme et du paquet contenant le message d'enregistrement pendant la transmission.