-------------------------------------------------------------------------         RFC 1311: Introduction aux notes de STD. ------------------------------------------------------------------------- Auteur : J. Postel, Internet Activities Board, 03/92 Traduction : Franck "Linuxshell" Verrot $Id: $ ------------------------------------------------------------------------- Note du traducteur: =================== Ce document est une traduction non-officielle de la RFC 1311. L'auteur de cette traduction décline toute responsabilité sur l'utilisation de ce document et/ou su d'éventuelles erreurs de traduction. Concernant les droits du traducteur: le traducteur renonce à ses droits sur la reproduction de ce document si l'ensemble de ces conditions est respecté: les reproductions doivent être complètes(contenant cette note), d'un seul tenant(un seul fichier ou un ensemble de pages physiquement reliées), sans aucune modification du contenu et réalisées à partir de la dernière  version de ce document disponible ici ou bien en mailant le traducteur. A noter, et l'information est importante, que les licenses sont traduites, procurez-vous la RFC officielle pour les version originales. Status de ce document ===================== Cette RFC décrit une nouvelle sous-série de RFC,appelées STDs(standards). La distribution de ce document est ilimitée. 1. Introduction =============== Les STDs sont une sous-séries des notes dans les séries de RFC qui sont les normes d'Internet. Leur but est de permettre une identification claire pour la communauté internet de ces RFCs qui sont des normes Internet. 2. L'assignation des numéros des STD ==================================== C'est une nécessaité d'être très clair à propos des spécifications qui complètent le processus de standardisation complète sur Internet. Pour faire cela un numéro STD sera assigné à la spécification quand celle-ci atteindra un niveau de maturité Standard. A noter que les spécifications peuvent être soit des Technical Spécifications (TS) ("Spécifications Techniques") ou Applicability Statements(AS)("Rapports d'applicabilités"). Quand une spécification atteint l'étape finale du processus de standardisation et que l'IAB l'a désigné en tant que standard pour internet, un numéro STD sera assigné à cete spécification. Les standards existants ont eu des numéros STD (voir Appendice). Le standard pour un protocole particulier aura toujours le même numéro STD. Si le protocole est retravaillé ultérieurement et qu'un nouveau document est produit comme la spécification de ce standard et que la nouvelle spécification est désignée par l'IAB comme standard pour internet, alors ce nouveau document sera désigné par le même numéro STD (bien sûr, ce nouveau document aura un nouveau numéro RFC). Multiples documents pour un même standard: Un numéro STD identifie un standard, pas un document. Un document est identifié par son numéro RFC. Si la spécification de ce stadard est étendue sur plusieurs document, ils se partageront le même numéro STD. Par exemple, le Système de Noms de Domaines (DNS) est actuellemnt désigné par la combinaison des RFCs 1034 et 1035. Les deux documents sont aussi désigné par le label STD-13. Afin d'être parfaitement clair, le document DNS " Concepts et Facilities" peut être référencé par "STD-13/RFC-1034". Dans ce tels cas, si possible, l'ensemble des documents qui définissent un standard particulier auront des références qui se renvoient les unes aux autres. Unique Standard ou Multiples Standards: Une décision difficile est celle de décider entre un ensemble de documents décrivant un standard ou des standars multiples. En appendice, on peut voir qu'il y a différents situations dans lesquels un STD s'applique sur de multiples RFCs ( voir STDs 5, 13, et 20). IL y a un cas dans lequel une famille de spécifications ont des nombres STD multiples, ce sont les options Telnet. La règle générale est qu'un numéro STD séparé est utilisé quand la spécification est logicquement séparable. Cela étant, des options logiquement séparables ont des numéros STD assignés distincts pendant que les les amendements et les prolongements non-facultatifs emploient le même numéro STD que les spécifications de base. Versions multiples our Editions d'un standard: Il peut arriver que la documentation d'un standard soit mise à jour ou remplacée par un nouveau document. Dans de tels cas, le même numéro STD sera utilisé pour référencer le standard. Aucun numéro de versions ne sera attaché aux numéro STD. IL ne doit pas y avoir de confusion sur la possession d'un document mis à jour à propos du STD-9 puisque chaque version du document aura un numéro RFC distinct (et bien sûr une date différente). L'identification complète de la spécification et ses documents est la combinaison du STD et du RFC. Par exemple, "STD-13/RFC-1035" définira entièrement la version actuelle de la seconde partie de la spécification du Domain Name System(DNS). Pour identifier complètement tout standard du DNS, la citation deviendra "STD-13/RFC-1034/RFC-1035". Une manière de penser à cela est qu'un acronyme (comme TCP) réfère un concept, lequel est appelé protocole. Un numéro RFC (comme RFC-793) indique la version spécifique de la spécification du protocole. Un numéro STD (comme STD-7) désigne le status de ce protocole. 3. Pourquoi une sous-série au RFC? ================================== Il y a plusieurs raisons pour lesquelles les STDs sont une partie des larges séries de notes RFC. La raison première est que les mécanismes de distribution pour les RFCs sont triés et vrai. N'importe qui peut obtenir une RFC, peut obtenir automatiquement un STD. Plus iportant, n'importe qui connaissant les séries RFC peut aisément trouvé les STDs. Une autre raison pour faire des STDs une part des séries RFC est que les mécanismes de maintenance pour les RFCs sont déjà en place. On comprend que maintenir ces documents se fait de la même façon. 4. Règles de format =================== Puisque les STDs sont une part des séries RFC, ils doivent se conformer avec respect au format du "Request for Comments on Request for Comments: Instruction to RFC Authors"(la RFC des RFC) (RFC-1111). 4.1 Rapport de Statut ===================== Chaque STD RFC doit inclure sur sa première page la section "Status de ce document" qui contient un paragraphe décrivant l'intention de la RFC. Cette section doit donner le statut approuvé par le Conseil d'Activités d'Internet (IAB). 4.2 Rapport de distribution =========================== Chaque STD RFC incluera également un "rapport de distribution". Comme le but des séries STD est de disséminer les informations, il n'y a aucune raison pour que les distributions soient autre que "illimitées". Typiquement, le rapport de distribution sera simplement la phrase "La distribution de ce document est illimitée." ajoutée à la section "Status de ce document". 4.3 Considérations sur la sécurité ================================== Tout STD RFC doit contenir une section qui parle des considérations de sécurité des procédures qui sont le principal sujet de la RFC. 4.4 Adresse de l'auteur ======================= Chauqe STD RFC doit avoir à son extrême fin une section donnant l'adresse de l'auteur, incluant son nom et son adresse postale, le numéro de téléphone, et l'adresse email Internet. Dans le cas où il y ait de multiples auteurs, chauq auteur devra être listé. Dans le cas où un document est produit par un groupe, l'éditeur de ce document devra être listé et optionnellement le siège de ce groupe peut être listé. 5. La publication du STD ======================== Les nouveaux documents ne peuvent devenir seulement des STD RFCs après une action de l'IAB. La publication des STDs sera faite par l'Editeur RFC ("RFC Editor"). 6. Annoncements de STD ====================== Les nouvelles STD RFCs sont annoncées par la liste de distribution des RFCs maintenue par le centre d'information réseau ou NetWork Information Center(NIC). Contacter le NIC pour être ajouté ou retiré de cette liste de diffusion en envoyant un message email à RFC-REQUEST@NIC.DDN.MIL. 7. Obtenir les STDs =================== Les STD RFCs peuvent êre obtenues de la même manière que les RFCs. Des détails sur l'obtention des RFCs via FTP ou EMAIL peuvent être obtenus en envoyant un message EMAIL à "rfc-info@ISI.EDU" avec le corps de message "help:ways_yo_get_rfcs"(moyen_d'obtenir_des_rfs". Par exemple:         To: rfc-info@ISI.EDU         Subject: getting rfcs         help: ways_to_get_rfcs Les standards actuels sont listés dans "le Protocole IAB officiel des Standards" ("IAB Official Protocol Standards") (lequel est STD-1), dont l'édition actuelle est la RFC-1280. Considérations sur la sécurité ============================= Ce titre n'est pas discuté dans cette note. Adresse de l'auteur ===================    Jon Postel    USC/Information Sciences Institute    4676 Admiralty Way    Marina del Rey, CA 90292    Téléphone: 310-822-1511    Fax:   310-823-6714    Email: Postel@ISI.EDU APPENDICE -- Les STDs principales ================================= Protocole   Nom                                       Statut    RFC  STD =========   =====================================     ======    ==== === --------   IAB Official Protocol Standards           Req      1280    1 --------   Assigned Numbers                          Req      1060    2 --------   Host Requirements                         Req 1122,1123    3 --------   Gateway Requirements                      Req      1009    4 IP         Internet Protocol                         Req       791    5             as amended by: --------     IP Subnet Extension                     Req       950    5 --------     IP Broadcast Datagrams                  Req       919    5 --------     IP Broadcast Datagrams with Subnets     Req       922    5 ICMP       Internet Control Message Protocol         Req       792    5 IGMP       Internet Group Multicast Protocol         Rec      1112    5 UDP        User Datagram Protocol                    Rec       768    6 TCP        Transmission Control Protocol             Rec       793    7 TELNET     Telnet Protocol                           Rec   854,855    8 FTP        File Transfer Protocol                    Rec       959    9 SMTP       Simple Mail Transfer Protocol             Rec       821   10 MAIL       Format of Electronic Mail Messages        Rec       822   11 CONTENT    Content Type Header Field                 Rec      1049   11 NTP        Network Time Protocol                     Rec      1119   12 DOMAIN     Domain Name System                        Rec 1034,1035   13 DNS-MX     Mail Routing and the Domain System        Rec       974   14 SNMP       Simple Network Management Protocol        Rec      1157   15 SMI        Structure of Management Information       Rec      1155   16 MIB-II     Management Information Base-II            Rec      1213   17 EGP        Exterior Gateway Protocol                 Rec       904   18 NETBIOS    NetBIOS Service Protocols                 Ele 1001,1002   19 ECHO       Echo Protocol                             Rec       862   20 DISCARD    Discard Protocol                          Ele       863   21 CHARGEN    Character Generator Protocol              Ele       864   22 QUOTE      Quote of the Day Protocol                 Ele       865   23 USERS      Active Users Protocol                     Ele       866   24 DAYTIME    Daytime Protocol                          Ele       867   25 TIME       Time Server Protocol                      Ele       868   26 Telnet Options                               Option  Status    RFC  STD ========   ================================= ======  ======= ===== ==== TOPT-BIN   Binary Transmission                 0     Rec       856   27 TOPT-ECHO  Echo                                1     Rec       857   28 TOPT-SUPP  Suppress Go Ahead                   3     Rec       858   29 TOPT-STAT  Status                              5     Rec       859   30 TOPT-TIM   Timing Mark                         6     Rec       860   31 TOPT-EXTOP Extended-Options-List             255     Rec       861   32