Groupe de travail Réseau |
J. Reynolds |
Request for Comments : 1011 |
J. Postel, ISI |
RFC rendues obsolètes : 991, 961, 943, 924, 901, 880, 840 |
mai 1987 |
Statut du présent mémoire
Le présent mémoire est un rapport d’état officiel sur les protocoles utilisés dans la communauté de l’Internet. Sa distribution n’est soumise à aucune restriction.
La présente RFC identifie les documents qui spécifient les protocoles officiels utilisés sur l’Internet. Les commentaires indiquent les révisions ou les changements prévus.
Au premier rang, les protocoles officiels sont ceux qui sont spécifiés dans le "Manuel des protocoles du DDN" (DPH), daté de décembre 1985 (c’est un ensemble de trois volumes d’une épaisseur totale d’environ cinq pouces).
Les plus anciennes collections qui comportent la plupart de ces spécifications sont le "Internet Protocol Transition Workbook" (IPTW), daté de mars 1982 ; le "Internet Mail Protocols", daté de novembre 1982 ; et le "Internet Telnet Protocols and Options", daté de juin 1983. Il y a aussi un volume d’informations en rapport avec les protocoles qui s’appelle "Internet Protocol Implementers Guide" (IPIG) daté d’août 1982. Une collection encore plus ancienne est le "ARPANET Protocol Handbook" (APH) daté de janvier 1978. Presque tous les matériaux pertinents de ces collections ont été reproduits dans le DPH actuel.
Les matériaux suivants sont organisés selon une présentation vague. Les entrées sont les protocoles (par exemple, Protocole de commande de transmission). Dans chaque entrée il y a des notes sur le statut, la spécification, des commentaires, d’autres références, les dépendances, et un contact.
Le statut est : exigé, recommandé, facultatif, expérimental, ou aucun.
La spécification identifie les documents qui spécifient le protocole.
Les commentaires décrivent toutes les différences avec la spécification ou les problèmes avec le protocole.
Les autres références identifient les documents qui commentent le protocole ou l’étendent.
Les dépendances indiquent quels autres protocoles sont invoqués par ce protocole.
Le contact indique une personne qui peut répondre aux questions sur le protocole.
En particulier, le statut peut être :
exigé – tous les hôtes doivent mettre en œuvre le protocole requis,
recommandé – tous les hôtes sont encouragés à mettre en œuvre le protocole recommandé,
facultatif – les hôtes peuvent ou non mettre en œuvre le protocole facultatif,
expérimental – les hôtes ne devraient pas mettre en œuvre le protocole expérimental sauf s’il participent à l’expérience et ont coordonné leur utilisation de ce protocole avec la personne indiquée comme contact,
aucun – ce n’est pas un protocole.
Pour des informations complémentaires sur les protocoles en général, prière de contacter :
Joyce K. Reynolds
USC - Information Sciences Institute
4676 Admiralty Way
Marina del Rey, California 90292-6695
Téléphone : (213) 822-1511
mél : JKREYNOLDS@ISI.EDU
Statut : Aucun
Spécification : IEN 48 (en DPH)
Commentaires : Donne une présentation de l’organisation et des principes de l’Internet. Pourrait être révisé et étendu.
Autres références :
- B. Leiner, R. Cole, J. Postel et D. Mills, "The DARPA Protocol Suite", IEEE INFOCOM 85, Washington, D.C., mars 1985. Aussi dans IEEE Communications Magazine, et dans ISI/RS-85-153, mars 1985.
- J. Postel, "Internetwork Applications Using the DARPA Protocol Suite", IEEE INFOCOM 85, Washington, D.C., mars 1985. Aussi dans IEEE Communications Magazine, et dans ISI/RS-85-151, avril 1985.
M.A. Padlipsky, "The Elements of Networking Style and other Essays and Animadversions on the Art of Intercomputer Networking", Prentice-Hall, New Jersey, 1985.
- RFC 871 - Perspectives du modèle de référence ARPANET
Dépendances :
Contact : Postel@ISI.EDU
Statut : Exigé
Spécification : RFC 791 (en DPH)
Commentaires : C’est le protocole universel de l’Internet. Ce protocole de datagrammes fournit l’adressage universel des hôtes dans l’Internet. Quelques problèmes mineurs ont été notés dans ce document. Le plus sérieux est un peu de confusion dans les options d’acheminement. Les options d’acheminement ont un pointeur qui indique quel octet de la route est le prochain utilisé. La confusion est entre les phrases "le pointeur se rapporte à cette option" et "la plus petite valeur légale pour le pointeur est 4". Si vous être troublé, oubliez la partie relative, le pointeur commence à 4. La description du MIL-STD de l’acheminement de source est fausse sur quelques détails.
Un autre point important est la procédure de réassemblage alternée suggérée dans la RFC 815.
Des changements sont en préparation pour l’option de sécurité.
Noter que ICMP est défini comme partie intégrante de IP. Vous n’avez pas achevé une mise en œuvre de IP si elle n’inclut pas ICMP.
La procédures de sous-réseau définie dans la RFC 950 est maintenant considérée comme une partie essentielle de l’architecture IP et doit être mise en œuvre par tous les hôtes et passerelles.
Autres références :
RFC 815 (en DPH) – Algorithmes de réassemblage de datagrammes IP
RFC 814 (en DPH) - Noms, adresses, accès, et routes
RFC 816 (en DPH) - Isolation et récupération des fautes
RFC 817 (en DPH) - Modularité et efficacité dans la mise en œuvre du protocole
MIL-STD-1777 (en DPH) – Norme militaire du protocole Internet
RFC 963 – Quelques problèmes de la spécification de la Norme militaire du protocole Internet
Dépendances :
Contact : Postel@ISI.EDU
Statut : Exigé
Spécification : RFC 792 (en DPH)
Commentaires : Ce sont les messages de commande et les rapports d’erreur qui vont avec le protocole Internet.
Quelques erreurs mineures ont été notées dans le document. Des suggestions de types supplémentaires de message de redirection et de messages de destination injoignable supplémentaires ont été faites.
Deux types de message ICMP supplémentaires sont définis dans la RFC 950 "Sous-réseaux Internet", Demande de gabarit d’adresse (A1=17), et Réponse de gabarit d’adresse (A2=18).
Noter qu’ICMP est défini comme partie intégrante de IP. On ne peut pas achever une mise en œuvre de IP si elle n’inclut pas ICMP.
Autres références : RFC 950
Dépendances : protocole Internet
Contact : Postel@ISI.EDU
Statut : Recommandé
Spécification : RFC 988
Commentaires : Ce protocole spécifie les extensions exigées d’une mise en œuvre du protocole Internet (IP) par un hôte pour prendre en charge la diffusion groupée inter réseaux. Cette spécification se substitue à celle donnée dans la RFC 966, et constitue une proposition de norme de protocole pour la diffusion groupée IP dans l’Internet. Se référer à la RFC 966 pour un exposé sur les motivations et la raison de l’extension de diffusion groupée spécifiée ici.
Autres références : RFC 966
Dépendances : protocole Internet
Contact : Deering@PESCADERO.STANFORD.EDU
Statut : Recommandé
Spécification : RFC 768 (en DPH)
Commentaires : Fournit un service de datagrammes aux applications. Ajoute l’adressage des accès aux services IP. Le seul changement noté pour la spécification UDP est un éclaircissement mineur sur le fait que en calculant la somme de contrôle, si on utilise un octet de bourrage pour le calcul, il n’est ni transmis ni compté dans la longueur.
Autres références :
Dépendances : protocole Internet
Contact: Postel@ISI.EDU
Statut : Recommandé
Spécification : RFC 793 (en DPH)
Commentaires : Fournit un service fiable de données de bout en bout. De nombreux commentaires et corrections ont été reçus pour le document de spécification de TCP. Ce sont principalement des fautes de frappe du document plutôt que des fautes du protocole.
Section Traitement des événements : Il y a de nombreuses corrections d’erreurs et d’éclaircissements nécessaires dans cette section.
Push : Il y a encore dans le document certaines phrases qui donnent un air de "record mark" au push. Elles devraient être précisées ; le push n’est pas un record mark.
Urgent : La page 17 est erronée. Le pointeur urgent pointe sur le dernier octet des données urgentes (et non sur le premier octet de données non urgentes).
Serveurs en écoute : Plusieurs commentaires ont été reçus sur la difficulté de contacter les serveurs en écoute. IL devrait y avoir des discussions sur les questions de mise en œuvre pour les serveurs, et des notes sur des modèles d’organisation de système et de traitement de remplacement pour les serveurs.
Taille de segment maximum : L’option Taille de segment maximum devrait être généralisée et précisée. Elle peut être utilisée pour augmenter ou diminuer la taille maximum du segment à partir de la valeur par défaut. La Taille de segment maximum de TCP est la Taille maximum de datagramme IP moins quarante. La Taille maximum de datagramme IP par défaut est 576. La Taille de segment maximum par défaut de TCP est de 536. Pour des précisions, voir la RFC 879.
Connexions inactives : Il y a eu des questions sur la fermeture automatique des connexions inactives. Les connexions inactives ne posent pas de problème et ne devraient pas être closes. Il y a plusieurs cas où apparaissent des connexions inactives, par exemple, dans Telnet lorsque un usager réfléchit pendant un long moment suite à un message provenant de l’ordinateur serveur avant d’envoyer l’entrée suivante. Il n’y a pas de mécanisme "probatoire" dans TCP, et il n’en est pas besoin.
Données en file d’attente de réception à la fermeture : Plusieurs points ne sont pas clairs d’après la description sur ce qu’il convient de faire des données reçues par le protocole TCP mais pas encore passées à l’utilisateur, en particulier lorsque la clôture de la connexion est en cours. En général, les données sont à conserver pour les donner à l’utilisateur au cas où il ferait un appel RECV.
Segments décalés : La description dit que les segments qui arrivent décalés, c’est-à-dire que celui qui arrive n’est pas exactement le prochain segment à traiter, peuvent être gardés en sous main. Il devrait aussi être souligné que ne pas le faire pénalise fortement les performances.
Usager arrivé en fin de temporisation : Il s’agit du temporisateur lancé sur l’ouverture ou l’envoi d’un appel. Si cette temporisation d’utilisateur arrive à expiration , l’usager devrait en être averti, mais la connexion ne devrait pas être close ni le TCP supprimé. L’usager devrait explicitement envoyer la commande ABORT pour la connexion s’il veut arrêter.
Autres références :
RFC 813 (en DPH) – Stratégie de fenêtre et d’accusé de réception dans TCP
RFC 814 (en DPH) - Noms, adresses, accès, et routes
RFC 816 (en DPH) - Isolement et récupération des fautes
RFC 817 (en DPH) - Modularité et efficacité dans la mise en œuvre du protocole
RFC 879 – Taille maximum de segment TCP
RFC 889 – Expérience des retards sur Internet
RFC 896 – Contrôle de l’encombrement sur TCP/IP
MIL-STD-1778 (en DPH) – Norme militaire du protocole de commande de transmission
RFC 964 – Quelques problèmes de la spécification de la norme militaire du protocole de commande de transmission
Zhang, Lixia, "Pourquoi les temporisateurs de TCP ne fonctionnent pas bien", Communications Architectures and Protocols, ACM SIGCOMM Proceedings, Computer Communications Review, V.16, N.3, août 1986.
Dépendances : protocole Internet
Contact : Postel@ISI.EDU
Statut : Expérimental
Spécification : RFC 998
Commentaires : C’est la révision d’un RFC sur l’exposé du protocole de transfert de bloc réseau (NETBLT). NETBLT (NETwork BLock Transfer) est un protocole de niveau transport destiné au transfert rapide de grandes quantités de données entre ordinateurs. Il fournit un transfert fiable et le contrôle des flux, et il est conçu pour fournir le débit maximum sur une grande variété de réseaux. Bien que NETBLT fonctionne actuellement par dessus le protocole Internet (IP), il devrait être capable de fonctionne par dessus tout protocole de datagramme de fonctions similaires à celles d’IP.
Ce document est publié pour discussion et commentaires, et ne constitue pas une norme. La proposition pourrait changer et certaines parties du protocole n’ont pas encore été spécifiées ; la mise en œuvre de ce document n’est donc pas conseillée.
Autres références : RFC 969
Dépendances : Protocole de commande de transmission, Protocole de datagrammes d’utilisateur
Contact : markl@PTT.LCS.MIT.EDU
Statut : Recommandé pour les passerelles (routeurs)
Spécification : RFC 888, RFC 904 (en DPH), RFC 975, RFC 985
Commentaires : Protocole utilisé entre les passerelles des différentes administrations pour échanger les informations d’acheminement. Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références : RFC 827, RFC 890
Dépendances : protocole Internet
Contact: Mills@UDEL.EDU
Statut : Expérimental
Spécification : RFC 823 (en DPH)
Commentaires : Protocole de passerelle utilisé actuellement dans les passerelles centrales. Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références :
Dépendances : protocole Internet
Contact: Brescia@BBN.COM
Statut : Facultatif
Spécification : RFC 869 (en DPH)
Commentaires : Bon outil pour le débogage des mises en œuvre de protocole dans les ordinateurs distants. Ce protocole est utilisé pour surveiller les passerelles et les TAC Internet.
Autres références :
Dépendances : protocole Internet
Contact : Hinden@BBN.COM
Statut : Expérimental
Spécification : RFC 908 (en DPH)
Commentaires : Ce protocole est conçu pour une prise en charge efficace du transfert de données en vrac pour des applications telles que la surveillance et le contrôle d’hôtes ainsi que le chargement/déchargement et le débogage à distance. Le protocole est conçu comme simple à mettre en œuvre mais efficace aussi dans des environnements où il peut y avoir de longs délais de transmission et des pertes de segments de messages ou une livraison hors séquence. Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références :
Dépendances : protocole Internet
Contact: CWelles@BBN.COM
Statut : Expérimental
Spécification : RFC 938
Commentaires : Ce protocole est un protocole de niveau transport d’hôte à hôte conçu pour un environnement internet. Bien que les questions exposées ne soient pas directement pertinentes pour les problèmes de recherche de la communauté de l’Internet, ils peuvent intéresser un certain nombre de chercheurs et développeurs.
Autres références :
Dépendances : protocole Internet
Contact : Trudy@ACC.ARPA
Statut : Facultatif
Spécification : IEN 158 (en DPH)
Commentaires : Protocole de débogage, permet un accès au système distants pour le débogage. Cette spécification devrait être mise à jour et publiée comme RFC.
Autres références : RFC 643
Dépendances : protocole Internet
Contact: Postel@ISI.EDU
Statut : Expérimental
Spécification : IEN 90 (en DPH)
Commentaires : Définit une capacité de combiner plusieurs segments provenant de différents protocoles de niveau supérieur en un datagramme IP. Pas d’expérimentation actuelle en cours. Il y a des questions sur la façon dont le partage de ce protocole peut réellement avoir lieu. De plus, il y a des questions sur les informations capturées dans l’en-tête de multiplexage qui seraient (a) insuffisantes, ou (b) trop spécifiques. Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références :
Dépendances : protocole Internet
Contact : Postel@ISI.EDU
Statut : Expérimental
Spécification : IEN 119 (en DPH)
Commentaires : Protocole d’allocation de ressources de passerelles conçu pour être utilisé dans des applications multi hôtes en temps réel. La mise en œuvre de ce protocole a évolué et pourrait n’être plus cohérente avec cette spécification. Le document devrait être mis à jour et publié comme RFC. Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références :
Dépendances : protocole Internet
Contact : jwf@LL-EN.ARPA
Statut : Expérimental
Spécification : Mémoire interne ISI
Commentaires : Définit les procédures pour les conférences vocales en temps réel. La spécification est un mémoire interne ISI qui devrait être mis à jour et publié comme RFC. Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références : RFC 741 (en DPH)
Dépendances : protocole Internet, protocole Stream
Contact : Casner@ISI.EDU
Statut : Recommandé
Spécification : RFC 854 (en DPH)
Commentaires : Protocole pour l’accès à un terminal distant. Il a été révisé depuis IPTW. La RFC 764 de IPTW est maintenant obsolète.
Autres références : MIL-STD-1782 (en DPH) – Protocole Telnet
Dépendances : Protocole de commande de transmission
Contact : Postel@ISI.EDU
Statut : Facultatif
Spécification : Description générale des options : RFC 855 (en DPH)
Numéro |
Nom |
RFC |
NIC |
DPH |
Utilisation |
0 |
Transmission binaire |
856 |
---- |
oui |
oui |
1 |
Echo |
857 |
----- |
oui |
oui |
2 |
Reconnexion |
... |
15391 |
oui |
non |
3 |
Suppression d’avance |
858 |
----- |
oui |
oui |
4 |
Négociation de taille approx de message |
... |
15393 |
oui |
non |
5 |
Statut |
859 |
----- |
oui |
oui |
6 |
Marquage horaire |
860 |
----- |
oui |
oui |
7 |
Contrôle à distance de trans. et écho |
726 |
39237 |
oui |
non |
8 |
Largeur de ligne de sortie |
... |
20196 |
oui |
non |
9 |
Taille de page de sortie |
... |
20197 |
oui |
non |
10 |
Disposition du retour chariot de sortie |
652 |
31155 |
oui |
non |
11 |
Tabulation horizontale de sortie |
653 |
31156 |
oui |
non |
12 |
Disposition de tabulation horizontale de sortie |
654 |
31157 |
oui |
non |
13 |
Disposition de saut de page en sortie |
655 |
31158 |
oui |
non |
14 |
Tabulation verticale de sortie |
656 |
31159 |
oui |
non |
15 |
Disposition de tabulation verticale de sortie |
657 |
31160 |
oui |
non |
16 |
Disposition de saut à la ligne de sortie |
658 |
31161 |
oui |
non |
17 |
ASCII étendu |
698 |
32964 |
oui |
non |
18 |
Déconnexion |
727 |
40025 |
oui |
non |
19 |
Macro Byte |
735 |
42083 |
oui |
non |
20 |
Terminal d’entrée de données |
732 |
41762 |
oui |
non |
21 |
SUPDUP |
734, 736 |
42213 |
oui |
non |
22 |
Sortie SUPDUP |
749 |
45449 |
oui |
non |
23 |
Localisation d’envoi |
779 |
----- |
oui |
non |
24 |
Type de terminal |
930 |
----- |
oui |
non |
25 |
Fin d’enregistrement |
885 |
----- |
oui |
non |
26 |
Identification d’utilisateur TACACS |
927 |
----- |
oui |
non |
27 |
Marquage de sortie |
933 |
----- |
oui |
non |
28 |
Numéro de localisation de terminal |
946 |
----- |
non |
non |
255 |
Liste d’extension des options |
861 |
----- |
oui |
oui |
La colonne DHP indique si la spécification est incluse dans le Manuel des protocoles DDN. La colonne Utilisation du tableau ci-dessus indique quelles options sont d’utilisation générale.
COMMENTAIRES : Les options Transmission binaire (Binary Transmission), Echo, Suppression d’avance (Suppress Go Ahead), Statut (Status), Marquage horaire (Timing Mark), et Liste d’extensions des options (Extended Options List) ont récemment été mises à jour et republiées. Ce sont les options les plus fréquemment mises en œuvre. Les options restantes devaient être révisées et celles qui sont utiles seront révisées et republiées. Les autres devraient être éliminées. Les options suivantes sont recommandées : Transmission binaire, Echo, Suppression d’avance, Statut, Marquage horaire, et Liste d’extensions des options .
Autres références :
Dépendances : Telnet
Contact : Postel@ISI.EDU
Statut : Facultatif
Spécification : RFC 734 (en DPH)
Commentaires : Protocole spécial du genre de Telnet pour les terminaux d’affichage.
Autres références :
Dépendances : Protocole de commande de transmission
Contact : Crispin@SU-SCORE.STANFORD.EDU
Statut : Recommandé
Spécification : RFC 959 (en DPH)
Commentaires : Protocole pour déplacer des fichiers entre des hôtes Internet. Fournit le contrôle d’accès et la négociation des paramètres de fichier. Les nouvelles commandes facultatives suivantes sont incluses dans cette édition de la spécification : Change to Parent Directory (CDUP), Structure Mount (SMNT), Store Unique (STOU), Remove Directory (RMD), Make Directory (MKD), Print Directory (PWD), et System (SYST). Noter que cette spécification est compatible avec l’édition précédente (RFC 765). Une discordance a été découverte dans la spécification dans les exemples de l’Appendice II. À la page 63, un code de réponse de 200 est montré comme réponse à une commande CWD. Dans la liste des séquences de Command-Reply citée page 50, CWD est indiqué comme n’acceptant que le code de réponse 250. Donc, si on interprétait une commande CWD comme étant exclue de la catégorie fonctionnelle File System, on peut supposer que le code de réponse 200 est correct, car CDUP utilise effectivement 200 comme cas particulier de CWD.
Autres références :
RFC 678 (en DPH) – Norme de format de fichier de document
MIL-STD-1780 (en DPH) – Protocole de transfert de fichier
Dépendances : Protocole de commande de transmission
Contact: Postel@ISI.EDU
Statut : Facultatif
Spécification : RFC 783 (en IPTW)
Commentaires : Protocole très simple de déplacement de fichier, la commande de non accès est fournie. Elle est utilisée dans plusieurs réseaux locaux. Des ambiguïtés dans l’interprétation de plusieurs modes de transfert devraient être précisées, et des modes de transfert additionnels devraient être définis. Des codes d’erreur supplémentaires devraient être définis pour identifier plus clairement les problèmes.
Note : Le DPH contient l’IEN-133, qui est une version obsolète de ce protocole.
Autres références :
Dépendances : Protocole de datagramme d’utilisateur
Contact : Postel@ISI.EDU
Statut : Expérimental
Spécification : RFC 913 (en DPH)
Commentaires : SFTP est un protocole simple de transfert de fichier. Il satisfait aux besoins des gens qui veulent un protocole qui soit plus utile que TFTP mais plus facile à mettre en œuvre (et moins puissant) que FTP. SFTP prend en charge la commande d’accès d’usager, le transfert de fichier, la liste des répertoires, le changement de répertoire, le changement de dénomination et la suppression de fichier. SFTP peut être mis en œuvre avec tout protocole fiable orienté flux d’octets de 8 bits, ce document décrit sa spécification TCP. SFTP utilise seulement une connexion TCP ; alors que TFTP met en œuvre une connexion sur UDP, et que FTP utilise deux connexions TCP (une d’elles utilisant le protocole TELNET). Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références :
Dépendances : Protocole de commande de transmission
Contact: MKL@SRI-NIC.ARPA
Statut : Recommandé
Spécification : RFC 821 (en DPH)
Commentaires : La procédure pour la transmission de messagerie électronique entre des hôtes. Cela a été révisé depuis IPTW, elle figure dans le volume "Internet Mail Protocols" de novembre 1982. La RFC 788 (en IPTW) est obsolète. Il y avait beaucoup d’incompréhensions et d’erreurs dans les premières mises en œuvre. De la documentation sur ces problèmes se trouve dans le fichier [C.ISI.EDU]<SMTP>MAIL.ERRORS. Quelques différences mineures entre la RFC 821 et la RFC 822 devraient être résolues.
Autres références :
RFC 822 – Normes de format d’en-tête de messagerie
Elle a été révisée depuis IPTW, elle figure dans le volume "Internet Mail Protocols" de novembre 1982. la RFC 733 (en IPTW) est obsolète. Une autre révision de la RFC 822 est nécessaire pour corriger certaines erreurs mineures des détails de la spécification.
Note : La RFC 822 n’est pas incluse dans le DPH (par accident, elle aurait dû y être).MIL-STD-1781 (en DPH) – Protocole simple de transfert de messagerie (SMTP)
Dépendances : Protocole de commande de transmission
Contact: Postel@ISI.EDU
Statut : Expérimental
Spécification : RFC 977
Commentaires : NNTP spécifie un protocole pour la distribution, la recherche, la restitution, et l’envoi d’articles de nouvelles utilisant une transmission fiable fondée sur le flux de nouvelles parmi la communauté de l’Internet. NNTP est conçu de telle sorte que les articles sont mémorisés dans une base de données centrale permettant aux abonnés de choisir seulement les éléments qu’ils souhaitent lire. L’indexage, la référence croisée, et l’expiration des messages périmés sont aussi fournis.
Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références :
Dépendances : protocole Internet
Contact : Brian@SDCSVAX.UCSD.EDU
Statut : Expérimental
Spécification : RFC 937 (en DPH)
Commentaires : L’intention du protocole Post Office - Version 2 (POP2) est de permettre à la station de travail d’un usage d’accéder à ses messages à partir d’un serveur de messagerie. Il est prévu que la messagerie soit postée de la station de travail au serveur de messagerie via le protocole simple de transfert de messagerie (SMTP).
Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références : Rend obsolète la RFC 918
Dépendances : Protocole de commande de transmission
Contact: JKReynolds@ISI.EDU
Statut : Recommandé
Spécification : RFC 1001, 1002
Commentaires : Ces documents définissent une proposition de norme de protocole pour la prise en charge des services NetBIOS dans un environnement TCP/IP. Le fonctionnement du réseau local et de l’internet sont tous deux pris en charge. Divers types de nœuds sont définis pour s’accommoder des topologies locale et internet et permettre le fonctionnement avec ou sans l’utilisation de la diffusion IP. La RFC 1001 décrit les protocoles NetBIOS sur TCP d’une manière générale, en insistant sur les idées et techniques sous-jacentes. La RFC 1002 donne les spécifications détaillées des paquets et protocoles NetBIOS sur TCP, et définit les constantes et les variables.
Autres références :
Dépendances : Protocole de commande de transmission, Protocole de datagrammes d’utilisateur
Contact : Auerbach@CSL.SRI.COM
Statut : Expérimental
Spécification : RFC 951
Commentaires : Cette proposition de protocole fournit un protocole bootstrap IP/UDP qui permet à une machine de client sans disque de découvrir sa propre adresse IP, l’adresse d’un hôte serveur, et le nom d’un fichier à charger en mémoire et à exécuter.
Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références :
Dépendances : protocole Internet, Protocole de datagrammes d’utilisateur
Contact : Croft@SUMEX-AIM.STANFORD.EDU
Statut : Expérimental
Spécification : RFC 909
Commentaires : Spécifie un protocole pour charger, décharger et déboguer les machines cibles à partir des hôtes dans un environnement de réseau. Il est aussi conçu pour s’accommoder de divers types de CPU cibles. Il fournit un puissant ensemble de services de débogage, et il est structuré de telle sorte qu’on peut en même temps mettre en œuvre un simple sous-ensemble dans des applications comme le chargement d’amorce où l’efficacité et l’espace sont les premières préoccupations.
Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références :
Dépendances : Protocole de données fiable
Contact: Hinden@BBN.COM
Statut : Facultatif
Spécification : RFC 887 (en DPH)
Commentaires : Protocole de localisation de ressource à utiliser dans l’Internet. Ce protocole utilises le protocole de datagrammes d’utilisateur (UDP) qui à son tour invoque le protocole Internet pour livrer ses datagrammes.
Autres références :
Dépendances : Protocole de datagrammes d’utilisateur
Contact : Accetta@A.CS.CMU.EDU
Statut : Facultatif
Spécification : RFC 407 (en DPH)
Commentaires : Protocole général pour la soumission de tâches par lots et la restitution des résultats. Quelques changements sont nécessaires pour l’utilisation avec TCP. Pas de mise en œuvre active connue.
Autres références :
Dépendances : Protocole de transfert de fichier, Protocole de commande de transmission
Contact : Postel@ISI.EDU
Statut : Facultatif
Spécification : RFC 740 (en DPH)
Commentaires : Protocole spécial pour la soumission de tâches par lots et la restitution des résultats, utilisé avec le système d’exploitation IBM UCLA.
Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Révision en cours.
Autres références :
Dépendances : Protocole de commande de transmission
Contact : Braden@ISI.EDU
Statut : Facultatif
Spécification : RFC 818 (en DPH)
Commentaires : Donne un accès spécial à l’usager Telnet sur un système distant.
Autres références :
Dépendances : Telnet, Protocole de commande de transmission
Contact : Postel@ISI.EDU
Statut : Facultatif
Spécification : NIC 24308 (en DPH)
Commentaires : Protocole pour les graphiques vectoriels. Des changements très mineurs sont nécessaires pour une utilisation avec TCP. Pas de mise en œuvre active connue.
Note : Le DPH prétend que c’est la RFC 493, mais la RFC 493 est en réalité une spécification antérieure différente.
Autres références :
Dépendances : Telnet, Protocole de commande de transmission
Contact : Postel@ISI.EDU
Statut : Recommandé
Spécification : RFC 862 (en DPH)
Commentaires : Protocole de débogage, renvoie tout ce que vous lui envoyez.
Autres références :
Dépendances : Protocole de commande de transmission ou Protocole de datagrammes d’utilisateur
Contact : Postel@ISI.EDU
Statut : Facultatif
Spécification : RFC 863 (en DPH)
Commentaires : Protocole de débogage, élimine tout ce que vous lui envoyez.
Autres références :
Dépendances : Protocole de commande de transmission ou Protocole de datagrammes d’utilisateur
Contact : Postel@ISI.EDU
Statut : Facultatif
Spécification : RFC 864 (en DPH)
Commentaires : Protocole de débogage, vous envoie des données ASCII.
Autres références :
Dépendances : Protocole de commande de transmission ou Protocole de datagrammes d’utilisateur
Contact : Postel@ISI.EDU
Statut : Facultatif
Spécification : RFC 865 (en DPH)
Commentaires : Protocole de débogage, vous envoie un court message ASCII.
Autres références :
Dépendances : Protocole de commande de transmission ou Protocole de datagrammes d’utilisateur
Contact : Postel@ISI.EDU
Statut : Recommandé
Spécification : RFC 996
Commentaires : Cette RFC spécifie une norme pour la communauté de l’Internet. les hôtes et passerelles de l’Internet qui choisissent de mettre en en œuvre une facilité de surveillance à distance des statistiques peuvent utiliser ce protocole pour envoyer des données de statistiques sur demande d’une centre de surveillance ou d’un hôte de débogage.
Autres références :
Dépendances : protocole Internet
Contact : Mills@UDEL.EDU
Statut : Facultatif
Spécification : RFC 866 (en DPH)
Commentaires : Fait la liste des usagers actuellement en activité.
Autres références :
Dépendances : Protocole de commande de transmission ou Protocole de datagrammes d’utilisateur
Contact : Postel@ISI.EDU
Statut : Facultatif
Spécification : RFC 742 (en DPH)
Commentaires : Fournit des informations sur l’activité en cours ou la plus récente d’un utilisateur. Certaines extensions ont été suggérées. Quelques changements sont nécessaires pour TCP.
Autres références :
Dépendances : Protocole de commande de transmission
Contact : Postel@ISI.EDU
Statut : Facultatif
Spécification : RFC 954 (en DPH)
Commentaires : Accède à la base de données du répertoire ARPANET. Donne le moyen d’en savoir plus sur les gens, leur adresses, numéro de téléphone, organisation, et boîte aux lettres.
Autres références :
Dépendances : Protocole de commande de transmission
Contact : Feinler@SRI-NIC.ARPA
Statut : Expérimental
Spécification : CS-DN-2 (en DPH)
Commentaires : Donne accès à la base de données CSNET des usagers pour des informations sur les noms, affiliations, et boîtes aux lettres des usagers.
Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références :
Dépendances : Protocole de commande de transmission
Contact : Solomon@WISC.EDU
Statut : Recommandé
Spécification : RFC 881, RFC 882, RFC 883 (en DPH)
Commentaires :
Autres références :
RFC 920 – Exigences pour les domaines
RFC 921 – Programme de mise en œuvre des noms de domaine - révisé
RFC 973 – Changement au système des domaines et observations
RFC 974 – L’acheminement de la messagerie et le système des domaines
Dépendances : Protocole de commande de transmission ou Protocole de datagrammes d’utilisateur
Contact : Mockapetris@ISI.EDU
Statut : Facultatif
Spécification : RFC 953 (en DPH)
Commentaires : Accède à la base de données des hôtes Internet enregistrés (HOSTS.TXT). Donne le moyen de trouver un hôte sur l’Internet, son adresse Internet, et les protocoles qu’il met en œuvre.
Autres références :
RFC 952 – Spécification du tableau des hôtes
Dépendances : Protocole de commande de transmission
Contact : Feinler@SRI-NIC.ARPA
Statut : Expérimental
Spécification : IEN 116 (en DPH)
Commentaires : Fournit une procédure orientée machine pour traduire un nom d’hôte en adresse Internet. Cette spécification a des problèmes significatifs : 1) La syntaxe des noms est dépassée ; 2) Les détails du protocole sont ambigus, en particulier, l’octet de longueur tantôt s’inclut lui-même et le op code, tantôt ne s’inclut pas ; 3) Les extensions ne sont prises en charge par aucune mise en œuvre connue. Ce protocole est maintenant abandonné en faveur du protocole DOMAIN. Une nouvelle mise en œuvre de ce protocole est déconseillée.
Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références :
Dépendances : Protocole de datagrammes d’utilisateur
Contact : Postel@ISI.EDU
Statut : Facultatif
Spécification : RFC 867 (en DPH)
Commentaires : Donne le jour et l’heure en une chaîne de caractères ASCII.
Autres références :
Dépendances : Protocole de commande de transmission ou Protocole de datagrammes d’utilisateur
Contact : Postel@ISI.EDU
Statut : Expérimental
Spécification : RFC 958
Commentaires : Proposition de protocole pour synchroniser un ensemble d’horloges réseau en utilisant un ensemble distribué de clients et serveurs. (Rendue obsolète par la RFC 1305.)
Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références : RFC 778, RFC 891, RFC 956, et RFC 957.
Dépendances : Protocole de datagrammes d’utilisateur
Contact : Mills@UDEL.EDU
Statut : Facultatif
Spécification : RFC 868 (en DPH)
Commentaires : Donne l’heure en nombre de secondes depuis une référence horaire spécifiée.
Autres références :
Dépendances : Protocole de commande de transmission ou Protocole de datagrammes d’utilisateur
Contact: Postel@ISI.EDU
Statut : Expérimental
Spécification : RFC 778
Commentaires : Donne un mécanisme pour garder la synchronisation d’horloges.
Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références :
Dépendances : Protocoles de message de commande Internet.
Contact : Mills@UDEL.EDU
Statut : Expérimental
Spécification : RFC 931
Commentaires : Ce serveur donne le moyen de déterminer l’identité d’un usager sur une connexion TCP particulière. Étant donnée une paire de numéros d’accès TCP, il retourne une chaîne de caractères qui identifie le détenteur de cette connexion sur le système du serveur (Rendue obsolète par la RFC 1413, février 1993).
Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références : Se substitue à la RFC 912.
Dépendances : Protocole de commande de transmission
Contact : StJohns@SRI-NIC.ARPA
Statut : Expérimental
Spécification : RFC 1004
Commentaires : Cette RFC centre son exposé sur les problèmes d’authentification sur l’Internet et des méthodes de solution possibles.
Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références :
Dépendances :
Contact : Mills@UDEL.EDU
Statut : Expérimental
Spécification : RFC 759 (en DPH)
Commentaires : Protocole expérimental de transfert de messagerie multisupport. La mise en œuvre est appelée un module de traitement de message (MPM).
Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références :
RFC 767 – Formats de document structuré
Dépendances : Protocole de commande de transmission
Contact : Postel@ISI.EDU
Statut : Facultatif
Spécification : RFC 569 (en DPH)
Commentaires : Décrit un éditeur de ligne simple qui pourrait être fourni par chaque hôte Internet.
Autres références :
Dépendances :
Contact : Postel@ISI.EDU
Statut : Aucun
Spécification : RFC 997
Commentaires : Décrit les champs des numéros de réseau et les numéros de systèmes autonomes auxquels sont alloués des valeurs spécifiques pour l’utilisation réelle, et fait la liste des valeurs actuellement allouées. Publiée en mars 1987, remplaces la RFC 990, la RFC 790 en IPTW, et la RFC 960. (La dernière version publiée est la RFC 1166.)
Autres références :
Contact : Hostmaster@SRI-NIC.ARPA
Statut : Aucun
Spécification : RFC 1010
Commentaires : Décrit les champs de divers protocoles auxquels sont alloués des valeurs spécifiques pour l’utilisation réelle, et fait la liste des valeurs actuellement allouées. Publiée en mai 1987, elle remplace la RFC 990, la RFC 790 en IPTW, et la RFC 960. (La dernière version publiée est la RFC 1700, à laquelle se substitue une base de donnée en ligne à www.iana.org .)
Autres références :
Contact : JKREYNOLDS@ISI.EDU
Statut : Facultatif
Spécification : RFC 794 (en DPH)
Commentaires : Décrit comment effectuer la préemption des connexions TCP.
Autres références :
Contact : Postel@ISI.EDU
Statut : Aucun
Spécification : RFC 795 (en DPH)
Commentaires : Décrit la transposition du type IP du champ de service en paramètres d’un réseau spécifique. Pas à jour, une révision est nécessaire.
Autres références :
Contact : Postel@ISI.EDU
Statut : Aucun
Spécification : RFC 796 (en DPH)
Commentaires : Décrit la transposition entre les adresses Internet et les adresses d’un réseau spécifique. Pas à jour, une révision est nécessaire.
Autres références :
Contact : Postel@ISI.EDU
Statut : Aucun
Spécification : RFC 678 (en DPH)
Commentaires : Décrit les règles de format standard pour plusieurs types de documents.
Autres références :
Contact : Postel@ISI.EDU
Statut : Aucun
Spécification : RFC 1003
Commentaires : Identifie et explore les questions pour la définition d’une norme pour l’échange d’équations mathématiques.
Autres références :
Contact : Katz@ISI.EDU
Statut : Aucun
Spécification : RFC 797 (en DPH)
Commentaires : Décrit un format standard pour les données bitmap.
Autres références :
Contact : Postel@ISI.EDU
Statut : Aucun
Spécification : RFC 804
Commentaires : Décrit un format standard pour les données de facsimile.
Autres références : RFC 769 (en DPH)
Contact : Postel@ISI.EDU
Statut : Expérimental
Spécification : RFC 929
Commentaires : (Historique) Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références : RFC 928 (Historique)
Dépendances :
Contact : Padlipsky@ISI.EDU
Statut : Recommandé
Spécification : BBN Report 1822
Commentaires : Décrit l’interface entre un hôte et un IMP, et par conséquent la transmission des datagrammes IP sur ARPANET.
Autres références : RFC 851, RFC 852, RFC 878 (en DPH), RFC 979, RFC 1005
Contact : Malis@BBN.COM
Statut : Recommandé
Spécification : RFC 907 (en DPH) (STD 40, mise à jour par la RFC 1201, STD 46.)
Commentaires : Décrit un standard pour la transmission des datagrammes IP sur le réseau haut débit. Ce protocole spécifie les communications de niveau accès réseau entre un ordinateur arbitraire, appelé un hôte, et un réseau par satellite à commutation de paquets, par exemple, SATNET ou WBNET.
Note : Les mises en œuvre de HAP devraient être effectuées en coordination avec le personnel de développement et d’exploitation des réseaux par satellite.
Autres références :
Contact : Blumenthal@BBN.COM
Statut : Recommandé
Spécification : RFC 907 (en DPH) (STD 40, mise à jour par la RFC 1201, STD 46.)
Commentaires :Décrit un standard pour la transmission des datagrammes IP sur le WEBNET. Ce protocole spécifie les communications de niveau accès réseau entre un ordinateur arbitraire, appelé un hôte, et un réseau par satellite à commutation de paquets, par exemple, SATNET ou WBNET.
Note : Les mises en œuvre de HAP devraient être effectuées en coordination avec le personnel de développement et d’exploitation des réseaux par satellite.
Autres références :
Dépendances :
Contact : Schoen@BBN.COM
Statut : Recommandé
Spécification : RFC 877 (en DPH) (Rendue obsolète par la RFC 1356)
Commentaires : Décrit une norme pour la transmission des datagrammes IP sur les réseaux de données publics.
Autres références :
Contact : jtk@PURDUE.EDU
Statut : Facultatif
Spécification : RFC 891 (en DPH) (STD 44)
Commentaires :
Autres références : RFC 778 – Service d’horloge DCNET Internet
Contact : Mills@UDEL.EDU
Statut : Recommandé
Spécification : RFC 894 (en DPH) (STD 41)
Commentaires :
Autres références : RFC 893
Contact : Postel@ISI.EDU
Statut : Recommandé
Spécification : RFC 895 (en DPH) (STD 42)
Commentaires :
Autres références :
Contact : Postel@ISI.EDU
Statut : Recommandé
Spécification : voir les commentaires
Commentaires : Une approche d’une façon cohérente d’envoyer des datagrammes DOD IP et autres protocoles en rapport avec IP a été développée à une session ad hoc spéciale sur "Réseaux IEEE 802 et ARP" tenue pendant l’atelier de travail des fabricants de TCP (en août 1986). Du fait d’une certaine évolution des normes IEEE 802.2 et du besoin de fournir une façon normalisée de faire des protocoles supplémentaires se rapportant au DOD-IP (comme le protocole de résolution d’adresse (ARP)) sur les réseaux IEEE 802, la nouvelle politique suivante a été établie, qui va remplacer la politique actuelle (voir dans la RFC-990 le paragraphe sur les numéros intéressants de l’IEEE 802, et la RFC-948). La politique est que le DDN et la communauté de l’Internet utilisent l’encapsulation de IEEE 802.2 sur les réseaux 802.3, 802.4, et 802.5 en utilisant le protocole SNAP avec un code d’organisation indiquant que les seize bits suivants spécifient le code Ethertype (avec IP = 2048 (0800 hex), voir dans la RFC-1010 le paragraphe sur les numéros intéressants de l’Ethernet).
|
En-tête |
En-tête MAC |
Longueur |
802.{3/4/5} MAC |
Dsap=K1 |
Ssap=K1 |
contrôle |
802.2 SAP |
identifiant de protocole ou code org =K2 |
Ether Type |
802.2 SNAP |
La longueur totale de l’en-tête SAP et de l’en-tête SNAP est de 8 octets, ce qui fait que la redondance de protocole 802.2 tombe juste.
K1 est 170. L’IEEE aime parler des choses en termes d’ordre de transmission binaire et spécifie cette valeur comme étant 01010101. En ordre gros boutien, qui est utilisé dans les spécifications de l’Internet, cela devient le binaire 10101010, ou l’hexadécimal AA, ou le décimal 170.
K2 est 0 (zéro).
Note : La méthode décrite dans la RFC 948 (en DPH) n’est plus utilisée.
Autres références :
Contact : Postel@ISI.EDU
Statut : Exigé
Spécification : RFC 950 (STD 5)
Commentaires : C’est un dispositif très important qui doit être inclus dans toutes les mises en œuvre IP. Il spécifie les procédures à utiliser pour les sous réseaux, qui sont les sous-sections logiques d’un seul réseau Internet.
Autres références : RFC 940, RFC 917, RFC 925, RFC 932, RFC 936, RFC 922
Dépendances :
Contact : Mogul@SU-SCORE.STANFORD.EDU
Statut : Recommandé
Spécification : RFC 826 (en DPH) (STD 37)
Commentaires : C’est une procédure pour trouver l’adresse matérielle de réseau qui correspond à une adresse Internet.
Autres références :
Contact : Postel@ISI.EDU
Statut : Facultatif
Spécification : RFC 903 (en DPH) (STD 38)
Commentaires : C’est une procédure qui permet aux stations de travail de trouver de façon dynamique leur adresse de protocole (par exemple, leur adresse Internet), lorsque elle ne connaissent que leur adresse matérielle (par exemple, l’adresse de leur réseau physique de rattachement).
Autres références :
Contact : Mogul@SU-SCORE.STANFORD.EDU
Statut : Expérimental
Spécification : RFC 925
Commentaires : Exposé des divers problèmes et des solutions possibles pour les "sous-réseaux transparents" dans un environnement multi-LAN.
Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références : RFC 917, RFC 826
Dépendances :
Contact : Postel@ISI.EDU
Statut : Recommandé
Spécification : RFC 919 (STD 5)
Commentaires : Protocole de règles simples pour la diffusion des datagrammes Internet sur les réseaux locaux qui acceptent la diffusion, pour l’adressage des diffusions, et sur la façon dont les routeurs devraient les traiter. Recommandé dans le sens de "si vous faites de la diffusion, faites la de cette façon".
Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références : RFC 922
Dépendances :
Contact : Mogul@SU-SCORE.STANFORD.EDU
Statut : Recommandé
Spécification : RFC 922 (STD 5)
Commentaires : Protocole de règles simples pour la diffusion des datagrammes Internet sur les réseaux locaux qui acceptent la diffusion, pour l’adressage des diffusions, et sur la façon dont les routeurs devraient les traiter. Recommandé dans le sens de "si vous faites de la diffusion, faites la de cette façon".
Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références : RFC 919
Dépendances :
Contact : Mogul@SU-SCORE.STANFORD.EDU
Statut : Expérimental
Spécification : RFC 916
Commentaires : Ce document spécifie un protocole qui permet à deux programmes de communiquer de façon fiable sur une liaison de communication. Il s’assure que les données qui entrent à une extrémité de la liaison arrivent intactes et non altérées à l’autre extrémité. Cette proposition de protocole est conçue pour fonctionner sur une connexion point à point bidirectionnelle. Elle contient des disposition qui la taillent sur mesure pour les liaisons RS-232 utilisées actuellement.
Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références :
Dépendances : Protocole de commande de transmission
Contact : Finn@ISI.EDU
Statut : Expérimental
Spécification : RFC 914
Commentaires : Ce document expose un protocole Thinwire pour connecter les ordinateurs individuels à l’Internet. Il se concentre principalement sur les problèmes particulier de l’interconnexion à basse vitesse des ordinateurs individuels à l’Internet et des méthodes possibles de solution.
Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références :
Dépendances :
Contact : Farber@UDEL.EDU
L’Organisation internationale de normalisation (ISO) et le Comité consultatif international des télégraphes et téléphones (CCITT) définissent un ensemble de protocoles qui peuvent intéresser la communauté de l’Internet. Certains d’entre eux ont été publiés comme RFC pour des besoins d’information. Cette section donne la liste de ces protocoles.
Statut :
Spécification : RFC 995
Commentaires : Ce protocole fait partie d’un ensemble de normes internationales produites pour faciliter l’interconnexion des systèmes ouverts. L’ensemble de normes couvre les services et protocoles nécessaires pour réaliser une telle interconnexion. Ce protocole se positionne par rapport aux autres normes concernées par les couches définies dans le modèle de référence pour l’interconnexion des systèmes ouverts (ISO 7498) et par la structure définie dans l’organisation interner de la couche réseau (DIS 8648). En particulier, c’est un protocole de la couche Réseau. Ce protocole permet aux systèmes terminaux et aux systèmes intermédiaires d’échanger des informations de configuration et d’acheminement pour faciliter le fonctionnement à la couche Réseau des fonctions d’acheminement et de relais.
Autres références : RFC 994
Dépendances :
Contact : ANSI
Statut :
Spécification : RFC 994
Commentaires : Cette norme de protocole fait partie d’un ensemble de normes internationales produites pour faciliter l’interconnexion des systèmes ouverts. L’ensemble de normes couvre les services et protocoles nécessaires pour réaliser une telle interconnexion. Cette norme de protocole est positionnée par rapport aux autres normes concernées par les couches définies dans le modèle de référence pour l’interconnexion des systèmes ouverts (ISO 7498). En particulier, c’est un protocole de la couche Réseau. Ce protocole peut être utilisé entre des entités de réseau et des systèmes d’extrémité ou dans les systèmes de relais de couche Réseau (ou les deux). Il fournit le service réseau en mode sans connexion comme défini dans l’Addendum 1 à la définition de service réseau couvrant la transmission en mode sans connexion (ISO 8348/AD1).
Autres références : RFC 926
Dépendances :
Contact : ANSI
Statut :
Spécification : RFC 986 (rendue obsolète par la RFC 1069)
Commentaires : Cette RFC suggère une méthode permettant d’utiliser les adresses IP existantes, y compris le champ de protocole IP, pour le protocole réseau sans connexion (CLNP) de l’ISO. C’est un projet de solution à un des problèmes inhérents à l’utilisation des "ISO-grammes" dans le DoD Internet. Les questions qui en découlent seront exposées dans des RFC ultérieures. Cette RFC suggère une proposition de protocole pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration.
Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références :
Dépendances :
Contact : RCallon@BBN.COM
Statut :
Spécification : RFC 941
Commentaires : Cet addendum à la norme de définition du service réseau , ISO 8348, définit la syntaxe abstraite et la sémantique de l’adresse réseau (Adresse de point d’accès de service réseau). L’adresse réseau définie dans cet addendum est celle qui apparaît dans les primitives du service Réseau en mode connexion comme paramètres adresse appelante, adresse appelée, et adresse de réponse, et dans les primitives du service Réseau en mode sans connexion comme paramètres d’adresse de source et d’adresse de destination.
Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références :
Dépendances :
Contact : ISO
Statut :
Spécification : RFC 905
Commentaires : C’est la spécification actuelle du protocole de transport ISO. Ce document est le texte de la norme ISO/TC97/SC16/N1576 telle qu’amendée par la norme ISO/TC97/SC16/N1695. C’est la spécification actuellement adoptée par l’ISO comme projet de norme internationale (DIS, Draft International Standard).
Autres références : RFC 892
Dépendances :
Contact: ISO
Statut :
Spécification : RFC 1006 (STD 35)
Commentaires : Ce mémoire décrit une norme de protocole pour la communauté de l’Internet. Le CCITT et l’ISO ont défini diverses sessions, présentations, et recommandations d’application qui ont été adoptées par la communauté internationale et de nombreux fabricants. Il est souhaitable d’offrir dans la plus large mesure possible ces services de niveau supérieur directement à l’Internet, sans interrompre les facilités existantes. Cela permet aux usagers de développer une expertise avec les applications ISO et CCITT qui n’était pas précédemment disponible dans l’Internet. L’intention est que les hôtes au sein de l’Internet qui choisissent de mettre en œuvre les service TSAP ISO par dessus le protocole TCP adoptent et mettent en œuvre cette norme. Les suggestions d’amélioration sont les bienvenues.
Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références : RFC 983
Dépendances :
Contact : DCass@NRTC.NORTHROP.COM
Statut :
Spécification : RFC 987 (rendue obsolète par les RFC 1327 puis 2156)
Commentaires : Les protocoles de la série X.400 ont été définis par le CCITT pour fournir un service de messagerie inter personnelle (IMPS, Interpersonal Messaging Service), qui utilise un service de transfert de message à mémorisation et livraison indirecte. On s’attend à ce que ce standard soit très largement mis en œuvre. Ce document décrit un ensemble de transpositions qui permettent l’inter fonctionnement entre des systèmes exploitant les protocoles X.400 et ceux exploitant le protocole de messagerie de la RFC 822 ou des protocoles dérivés de la RFC 822.
Prière de discuter tout plan de mise en œuvre ou d’utilisation de ce protocole avec le contact.
Autres références :
Dépendances :
Contact : Kille@CS.UCL.AC.UK