4. LA FILIÈRE DES STANDARDS INTERNET
- LA FILIÈRE DES STANDARDS INTERNET (THE INTERNET STANDARDS TRACK)
Les spécifications destinées à devenir des Standards Internet évoluent à travers un ensemble de niveaux de maturité connus sous le nom de "filière des standards" (standards track). Ces niveaux de maturité -- "Proposed Standard" (Standard proposé), "Draft Standard" (Projet de standard) et "Standard" -- sont définis et discutés dans la section 4.1. La manière dont les spécifications progressent le long de la filière des standards est décrite dans la section 6.
Même après qu'une spécification a été adoptée comme Standard Internet, une évolution ultérieure se produit souvent sur la base de l'expérience et de la reconnaissance de nouvelles exigences. La nomenclature et les procédures de la normalisation Internet prévoient le remplacement des anciens Standards Internet par de nouveaux, et l'attribution d'étiquettes descriptives pour indiquer le statut des Standards Internet "retirés". Un ensemble de niveaux de maturité est défini dans la section 4.2 pour couvrir ces spécifications et d'autres qui ne sont pas considérées comme étant sur la filière des standards.
4.1 Niveaux de maturité de la filière des standards (Standards Track Maturity Levels)
Les spécifications Internet passent par des étapes de développement, de test et d'acceptation. Dans le cadre du processus de normalisation Internet, ces étapes sont formellement appelées "niveaux de maturité".
Cette section décrit les niveaux de maturité et les caractéristiques attendues des spécifications à chaque niveau.
4.1.1 Proposed Standard (Standard proposé)
Le niveau de maturité d'entrée pour la filière des standards est "Proposed Standard". Une action spécifique de l'IESG est requise pour placer une spécification sur la filière des standards au niveau "Proposed Standard".
Une spécification Proposed Standard est généralement stable, a résolu les choix de conception connus, est considérée comme bien comprise, a reçu un examen communautaire important et semble susciter un intérêt communautaire suffisant pour être considérée comme précieuse. Cependant, une expérience ultérieure pourrait entraîner une modification ou même un retrait de la spécification avant qu'elle ne progresse.
Habituellement, ni la mise en œuvre ni l'expérience opérationnelle ne sont requises pour la désignation d'une spécification comme Proposed Standard. Cependant, une telle expérience est hautement souhaitable et représentera généralement un argument solide en faveur d'une désignation Proposed Standard.
L'IESG peut exiger une mise en œuvre et/ou une expérience opérationnelle avant d'accorder le statut Proposed Standard à une spécification qui affecte matériellement les protocoles Internet de base ou qui spécifie un comportement pouvant avoir un impact opérationnel significatif sur l'Internet.
Un Proposed Standard ne devrait avoir aucune omission technique connue par rapport aux exigences qui lui sont imposées. Cependant, l'IESG peut renoncer à cette exigence afin de permettre à une spécification de passer à l'état Proposed Standard lorsqu'elle est considérée comme utile et nécessaire (et opportune) même avec des omissions techniques connues.
Les implémenteurs devraient traiter les Proposed Standards comme des spécifications immatures. Il est souhaitable de les mettre en œuvre afin d'acquérir de l'expérience et de valider, tester et clarifier la spécification. Cependant, étant donné que le contenu des Proposed Standards peut être modifié si des problèmes sont trouvés ou si de meilleures solutions sont identifiées, le déploiement d'implémentations de tels standards dans un environnement sensible aux perturbations n'est pas recommandé.
4.1.2 Draft Standard (Projet de standard)
Une spécification à partir de laquelle au moins deux implémentations indépendantes et interopérables provenant de bases de code différentes ont été développées, et pour laquelle une expérience opérationnelle réussie suffisante a été obtenue, peut être élevée au niveau "Draft Standard". Aux fins de cette section, "interopérable" signifie être des composants fonctionnellement équivalents ou interchangeables du système ou du processus dans lequel ils sont utilisés. Si une technologie brevetée ou autrement contrôlée est requise pour la mise en œuvre, les implémentations séparées doivent également avoir résulté d'un exercice séparé du processus de licence. L'élévation au Draft Standard est une avancée majeure de statut, indiquant une forte conviction que la spécification est mature et sera utile.
L'exigence d'au moins deux implémentations indépendantes et interopérables s'applique à toutes les options et fonctionnalités de la spécification. Dans les cas où une ou plusieurs options ou fonctionnalités n'ont pas été démontrées dans au moins deux implémentations interopérables, la spécification ne peut passer au niveau Draft Standard que si ces options ou fonctionnalités sont supprimées.
Le président du groupe de travail (Working Group) est responsable de documenter les implémentations spécifiques qui qualifient la spécification pour le statut Draft ou Internet Standard, ainsi que la documentation sur le test de l'interopération de ces implémentations. La documentation doit inclure des informations sur le support de chacune des options et fonctionnalités individuelles. Cette documentation doit être soumise au directeur de zone (Area Director) avec la demande d'action de protocole. (voir section 6)
Un Draft Standard doit être bien compris et connu pour être assez stable, tant dans sa sémantique qu'en tant que base pour développer une implémentation. Un Draft Standard peut encore nécessiter une expérience de terrain supplémentaire ou plus répandue, car il est possible que des implémentations basées sur des spécifications Draft Standard démontrent un comportement imprévu lorsqu'elles sont soumises à une utilisation à grande échelle dans des environnements de production.
Un Draft Standard est normalement considéré comme une spécification finale, et des modifications ne sont susceptibles d'être apportées que pour résoudre des problèmes spécifiques rencontrés. Dans la plupart des circonstances, il est raisonnable pour les fournisseurs de déployer des implémentations de Draft Standards dans un environnement sensible aux perturbations.
4.1.3 Internet Standard (Standard Internet)
Une spécification pour laquelle une mise en œuvre significative et une expérience opérationnelle réussie ont été obtenues peut être élevée au niveau Internet Standard. Un Internet Standard (qui peut simplement être désigné comme Standard) est caractérisé par un degré élevé de maturité technique et par une conviction généralement partagée que le protocole ou le service spécifié apporte un avantage significatif à la communauté Internet.
Une spécification qui atteint le statut de Standard se voit attribuer un numéro dans la série STD tout en conservant son numéro RFC.
4.2 Niveaux de maturité hors filière des standards (Non-Standards Track Maturity Levels)
Toutes les spécifications ne sont pas sur la filière des standards. Une spécification peut ne pas être destinée à être un Standard Internet, ou elle peut être destinée à une normalisation éventuelle mais pas encore prête à entrer dans la filière des standards. Une spécification peut avoir été remplacée par un Standard Internet plus récent, ou être tombée en désuétude ou en défaveur d'une autre manière.
Les spécifications qui ne sont pas sur la filière des standards sont étiquetées avec l'un des trois niveaux de maturité "hors filière": "Experimental" (Expérimental), "Informational" (Informatif) ou "Historic" (Historique). Les documents portant ces étiquettes ne sont en aucun cas des Standards Internet.
4.2.1 Experimental (Expérimental)
La désignation "Experimental" désigne généralement une spécification qui fait partie d'un effort de recherche ou de développement. Une telle spécification est publiée pour l'information générale de la communauté technique Internet et comme enregistrement archivistique du travail, sous réserve uniquement de considérations éditoriales et de vérification qu'il y a eu une coordination adéquate avec le processus de normalisation (voir ci-dessous). Une spécification expérimentale peut être le résultat d'un effort de recherche Internet organisé (par exemple, un groupe de recherche de l'IRTF), d'un groupe de travail IETF, ou il peut s'agir d'une contribution individuelle.
4.2.2 Informational (Informatif)
Une spécification "Informational" est publiée pour l'information générale de la communauté Internet et ne représente pas un consensus ou une recommandation de la communauté Internet. La désignation Informational vise à permettre la publication en temps opportun d'une très large gamme de documents informatifs responsables provenant de nombreuses sources, sous réserve uniquement de considérations éditoriales et de vérification qu'il y a eu une coordination adéquate avec le processus de normalisation (voir section 4.2.3).
Les spécifications qui ont été préparées en dehors de la communauté Internet et qui ne sont pas incorporées dans le processus de normalisation Internet par l'une des dispositions de la section 10 peuvent être publiées comme RFC informatifs, avec la permission du propriétaire et l'accord de l'éditeur RFC.
4.2.3 Procédures pour les RFC expérimentaux et informatifs
Sauf s'ils sont le résultat d'une action de groupe de travail IETF, les documents destinés à être publiés avec le statut Experimental ou Informational doivent être soumis directement à l'éditeur RFC. L'éditeur RFC publiera tous ces documents en tant qu'Internet-Drafts qui n'ont pas déjà été publiés ainsi. Afin de différencier ces Internet-Drafts, ils seront étiquetés ou regroupés dans le répertoire I-D afin qu'ils soient facilement reconnaissables. L'éditeur RFC attendra deux semaines après cette publication pour recevoir des commentaires avant de procéder. L'éditeur RFC est censé exercer son jugement concernant la pertinence éditoriale d'un document pour publication avec le statut Experimental ou Informational, et peut refuser de publier un document qui, selon l'opinion d'expert de l'éditeur RFC, n'est pas lié à l'activité Internet ou se situe en dessous du standard technique et/ou éditorial pour les RFC.
Pour s'assurer que les désignations Experimental et Informational hors filière des standards ne sont pas mal utilisées pour contourner le processus de normalisation Internet, l'IESG et l'éditeur RFC ont convenu que l'éditeur RFC référera à l'IESG tout document soumis pour publication Experimental ou Informational qui, selon l'opinion de l'éditeur RFC, pourrait être lié au travail effectué, ou prévu d'être effectué, au sein de la communauté IETF. L'IESG examinera un tel document référé dans un délai raisonnable et recommandera soit qu'il soit publié tel que soumis à l'origine, soit qu'il soit référé à l'IETF en tant que contribution au processus de normalisation Internet.
Si (a) l'IESG recommande que le document soit intégré dans l'IETF et progressé dans le contexte IETF, mais que l'auteur refuse de le faire, ou (b) l'IESG considère que le document propose quelque chose qui entre en conflit avec, ou est en fait préjudiciable à, un effort IETF établi, le document peut néanmoins être publié comme RFC Experimental ou Informational. Dans ces cas, cependant, l'IESG peut insérer un texte de "clause de non-responsabilité" approprié dans le RFC, soit dans ou immédiatement après la section "Status of this Memo", afin de clarifier les circonstances de sa publication pour les lecteurs.
Les documents proposés pour des RFC expérimentaux et informatifs par des groupes de travail IETF passent par un examen de l'IESG. L'examen est initié en utilisant le processus décrit dans la section 6.1.1.
4.2.4 Historic (Historique)
Une spécification qui a été remplacée par une spécification plus récente ou qui est pour toute autre raison considérée comme obsolète est assignée au niveau "Historic". (Les puristes ont suggéré que le mot devrait être "Historical"; cependant, à ce stade, l'utilisation de "Historic" est historique.)
Note: Les spécifications de la filière des standards ne doivent normalement pas dépendre d'autres spécifications de la filière des standards qui sont à un niveau de maturité inférieur ou de spécifications hors filière des standards autres que les spécifications référencées d'autres organismes de normalisation. (Voir section 7.)