Aller au contenu principal

2.2. Exigences de documentation pour les registres

2.2. Exigences de documentation pour les registres (Documentation Requirements for Registries)​

Les documents qui créent un nouvel espace de noms (ou modifient la définition d'un espace existant) et qui s'attendent à ce que l'IANA joue un rôle dans la maintenance de cet espace (servant de dépôt pour les valeurs enregistrées) doivent fournir des instructions claires sur les détails de l'espace de noms, soit dans la section IANA Considerations, soit référencées à partir de celle-ci.

En particulier, ces instructions doivent inclure :

Le nom du registre (The name of the registry)​

Ce nom apparaîtra sur la page web de l'IANA et sera référencé dans les documents futurs qui devront allouer une valeur à partir du nouvel espace. Le nom complet (et l'abréviation, le cas échéant) doit être fourni. Il est hautement souhaitable que le nom choisi ne soit pas facilement confondu avec le nom d'un autre registre.

Lors de la création d'un registre, le groupe dont il fait partie doit être identifié en utilisant son nom complet, exactement tel qu'il apparaît dans la liste des registres de protocoles.

Fournir une URL pour identifier précisément le registre aide l'IANA à comprendre la demande. Ces URL peuvent être supprimées du RFC avant la publication finale ou laissées dans le document pour référence. Si vous incluez des URL iana.org, l'IANA fournira des corrections, si nécessaire, lors de leur examen.

Informations requises pour les enregistrements (Required information for registrations)​

Cela indique aux demandeurs d'enregistrement quelles informations ils doivent inclure dans leurs demandes d'enregistrement. Certains registres ne nécessitent que la valeur demandée et une référence à un document où l'utilisation de la valeur est définie. D'autres registres nécessitent un modèle d'enregistrement plus détaillé qui décrit les considérations de sécurité pertinentes, les considérations d'internationalisation et d'autres informations de ce type.

Politique d'enregistrement applicable (Applicable registration policy)​

La politique qui s'appliquera à toutes les demandes d'enregistrement futures. Voir la section 4.

Taille, format et syntaxe des entrées de registre (Size, format, and syntax of registry entries)​

Quels champs enregistrer dans le registre, toutes les exigences techniques sur les entrées de registre (plages valides pour les entiers, limitations de longueur sur les chaînes, etc.) et le format exact dans lequel les valeurs de registre doivent être affichées. Pour les affectations numériques, on devrait spécifier si les valeurs doivent être enregistrées en décimal, en hexadécimal ou dans un autre format.

Les chaînes sont censées être en ASCII, et il doit être clairement spécifié si la casse importe, et si, par exemple, les chaînes doivent être affichées dans le registre en majuscules ou en minuscules.

Les chaînes qui représentent des paramètres de protocole auront rarement, voire jamais, besoin de contenir des caractères non-ASCII. Si des caractères non-ASCII sont vraiment nécessaires, les instructions doivent préciser très clairement qu'ils sont autorisés et que les caractères non-ASCII doivent être représentés comme des caractères Unicode en utilisant la convention "(U+XXXX)". Toute personne créant un tel registre devrait réfléchir attentivement à cela et considérer les conseils d'internationalisation tels que ceux de [RFC7564], section 10.

Affectations initiales et réservations (Initial assignments and reservations)​

Toutes les affectations ou enregistrements initiaux à inclure. De plus, toutes les plages qui doivent être réservées pour "Usage privé", "Réservé", "Non attribué", etc. (voir section 6) doivent être indiquées.

Par exemple, un document pourrait spécifier un nouveau registre en incluant :

---------------------------------------------------------------

X. Considérations IANA

Ce document définit une nouvelle option DHCP, intitulée "FooBar" (voir
section y), et attribue une valeur de TBD1 à partir de l'espace d'options DHCP
<https://www.iana.org/assignments/bootp-dhcp-parameters>
[RFC2132] [RFC2939] :
                                Data
       Tag     Name            Length      Meaning
       ----    ----            ------      -------
       TBD1    FooBar          N           Serveur FooBar

L'option FooBar définit également un champ FooType de 8 bits, pour lequel
l'IANA doit créer et maintenir un nouveau registre intitulé
"FooType values" utilisé par l'option FooBar. Les valeurs initiales pour le
registre DHCP FooBar FooType sont données ci-dessous ; les affectations futures
doivent être effectuées par Expert Review [BCP26]. Les affectations consistent
en un nom DHCP FooBar FooType et sa valeur associée.

       Value    DHCP FooBar FooType Name   Definition
       ----     ------------------------   ----------
       0        Reserved
       1        Frobnitz                   RFCXXXX, Section y.1
       2        NitzFrob                   RFCXXXX, Section y.2
       3-254    Unassigned
       255      Reserved
---------------------------------------------------------------

Pour des exemples de documents qui établissent des registres, consultez [RFC3575], [RFC3968] et [RFC4520].

Chaque fois que l'IANA inclut des noms et des informations de contact dans le registre public, certaines personnes peuvent préférer que leurs informations de contact ne soient pas rendues publiques. Dans de tels cas, des arrangements peuvent être pris avec l'IANA pour garder les informations de contact privées.

Dernière mise à jour le