-------------------------------------------------------------------------
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