3.1. Exigences de documentation pour les enregistrements
3.1. Exigences de documentation pour les enregistrements (Documentation Requirements for Registrations)
Souvent, les documents demandent une affectation dans un registre existant (un registre créé par un document précédemment publié).
Ces documents doivent clairement identifier le registre dans lequel chaque valeur doit être enregistrée. Utilisez le nom exact du registre tel qu'il figure sur la page web de l'IANA et citez le RFC où le registre est défini. Lorsque vous faites référence à un registre existant, fournir une URL pour identifier précisément le registre est utile (voir section 2.2).
Il n'est pas nécessaire de mentionner quelle est la politique d'affectation lors de nouvelles affectations dans des registres existants, car cela devrait être clair à partir des références. Cependant, si plusieurs politiques d'affectation peuvent s'appliquer, comme dans les registres avec différentes plages ayant différentes politiques, il est important de préciser quelle plage est demandée, afin que l'IANA sache quelle politique s'applique et puisse affecter une valeur dans la plage correcte.
Assurez-vous de fournir toutes les informations requises pour un enregistrement et de suivre tous les processus spéciaux définis pour le registre. Les registres exigent parfois de remplir un modèle d'enregistrement ou demandent aux demandeurs de publier leur demande sur une liste de diffusion particulière pour discussion avant l'enregistrement. Consultez le document de référence du registre : les informations requises et les processus spéciaux devraient y être documentés.
Normalement, les valeurs numériques à utiliser sont choisies par l'IANA lorsque le document est approuvé ; les projets ne doivent pas spécifier de valeurs finales. Au lieu de cela, des espaces réservés tels que "TBD1" et "TBD2" doivent être utilisés de manière cohérente dans tout le document, en donnant à chaque élément à enregistrer un espace réservé différent. Les considérations IANA doivent demander à l'éditeur RFC de remplacer les noms d'espaces réservés par les valeurs attribuées par l'IANA. Lorsque les projets doivent spécifier des valeurs numériques pour les tests ou les premières implémentations, ils demanderont soit une allocation anticipée (voir section 3.4), soit utiliseront des valeurs déjà réservées pour les tests ou l'expérimentation (si le registre en question le permet sans affectation explicite). Il est important que les projets ne choisissent pas leurs propres valeurs, de peur que l'IANA attribue l'une de ces valeurs à un autre document entre-temps. Un projet peut demander une valeur spécifique dans la section Considérations IANA, et l'IANA répondra à de telles demandes lorsque cela est possible, mais le numéro proposé pourrait avoir été attribué à un autre usage au moment où le projet est approuvé.
Normalement, les valeurs de chaînes de texte à utiliser sont spécifiées dans le document, car les collisions sont moins probables avec les chaînes de texte. L'IANA consultera les auteurs s'il y a, en fait, une collision et qu'une valeur différente doit être utilisée. Lorsque les projets doivent spécifier des valeurs de chaîne pour les tests ou les premières implémentations, ils utilisent parfois la valeur finale attendue. Mais il est souvent utile d'utiliser plutôt une valeur de projet, incluant éventuellement le numéro de version du projet. Cela permet de distinguer les premières implémentations de celles qui implémentent la version finale. Un document qui a l'intention d'utiliser "foobar" dans la version finale pourrait utiliser "foobar-testing-draft-05" pour la version -05 du projet, par exemple.
Pour certains registres, il existe une politique de longue date interdisant l'attribution de noms ou de codes sur la base de la vanité ou du nom de l'organisation. Par exemple, les codes peuvent toujours être attribués séquentiellement à moins qu'il n'y ait une raison forte de faire une exception. Rien dans ce document n'est destiné à modifier ces politiques ou à empêcher leur application future.
À titre d'exemple, le texte suivant pourrait être utilisé pour demander l'attribution d'un numéro d'option DHCPv6 :
L'IANA est priée d'attribuer une valeur de code d'option de TBD1 à l'option
DNS Recursive Name Server et une valeur de code d'option de TBD2 à l'option
Domain Search List à partir de l'espace de codes d'options DHCP défini dans
la section 24.3 du RFC 3315.
La section Considérations IANA doit résumer toutes les actions IANA, avec des pointeurs vers les sections pertinentes ailleurs dans le document, le cas échéant. L'inclusion de numéros de section est particulièrement utile lorsque le document de référence est volumineux ; les numéros de section faciliteront la recherche des informations pertinentes pour ceux qui consultent le document de référence.
Lorsque plusieurs valeurs sont demandées, il est généralement utile d'inclure un tableau récapitulatif des ajouts/modifications. Il est également utile que ce tableau soit dans le même format qu'il apparaît ou apparaîtra sur le site web de l'IANA. Par exemple :
Value Description Reference
-------- ------------------- ---------
TBD1 Foobar this RFC, Section 3.2
TBD2 Gumbo this RFC, Section 3.3
TBD3 Banana this RFC, Section 3.4
Note : Dans les cas où les auteurs estiment que l'inclusion du tableau complet des modifications est trop verbeuse ou répétitive, les auteurs doivent néanmoins inclure le tableau dans le projet, mais peuvent inclure une note demandant que le tableau soit supprimé avant la publication du RFC final.