Introduction

Nous trouvons la proposition Meyer (Note #46) la plus acceptable à ce jour, pour exactement les raisons qu'il énumère, à savoir : simple, suffisante pour la plupart des usages prévus du réseau, facile à mettre en œuvre, extensible. Elle ne couvre pas tout ce qui a été suggéré récemment ; cependant, nous approuvons les éléments proposés et nous estimons que les fonctions manquantes ne valent probablement pas la peine de se battre et de retarder ainsi la spécification.

Nous formulons les commentaires suivants sur les sept questions soulevées dans la Note #47.

Nous sommes d'accord avec Steve pour dire que la reconnexion dynamique sera nécessaire plus tard pour des usages plus élaborés du réseau. Nous sommes également d'accord avec les gens du Project MAC pour dire qu'elle n'est pas nécessaire au début. Un meilleur travail peut être fait en matière de reconnexion dynamique, compte tenu de l'expérience du réseau et des besoins spécifiques de son usage.
INT est facile à mettre en œuvre et sert un objectif utile.
Nous sommes favorables à l'inclusion d'un sous-champ pour l'identificateur d'étiquette d'instance. Nous voyons la nécessité des deux cas : a) lorsque plusieurs processus doivent apparaître indiscernables, et b) lorsqu'un utilisateur donné possédant plusieurs processus doit les distinguer. Les parties de programme qui ne doivent pas distinguer les processus doivent simplement ignorer l'étiquette d'instance. La suggestion de Tom d'utiliser une partie du sous-champ du numéro d'utilisateur ne fait que réduire la longueur combinée des sous-champs de 32 bits à 24 bits ; le problème demeure.
Nous ne sommes d'accord ni avec Steve ni avec MAC sur le fait qu'aucune structure particulière ne devrait être imposée aux données transmises. Nous préférons le « message data type » mentionné par E. I. Ancona, Note #42, page 1. Un exemple de son usage a été cité dans la Note #39, page 2, transmit vs broadcast. En ce qui concerne un jeu de caractères standard, nous soutenons fermement l'adoption d'un tel jeu dès le départ, et en particulier ASCII. Nous avons observé que la plupart des sites avaient déjà suggéré ASCII. Y a-t-il quelqu'un qui s'y oppose ?
L'alignement sur les limites de mots est plus attrayant que le double remplissage.
La suggestion de Steve d'une mise en file d'attente à court terme des RFC est acceptable comme option.
Nous soutenons l'UCC de la Note #46 pour trois raisons principales :
1. En général, l'utilisateur ne devrait pas connaître le code de socket distant du processus avec lequel il souhaite communiquer.
2. La connexion duplex supplémentaire peut fournir un certain contrôle de supervision sur le comportement du processus, éventuellement en conjonction avec la procédure d'interruption.
3. La plupart des autres méthodes proposées exigent une mise en file d'attente.
Nous pensons qu'il doit exister un UCC standard, mais nous encourageons des UCC expérimentaux parallèles.

Nous formulons deux commentaires supplémentaires sur la Note #46 qui n'ont pas été repris dans la Note #47.

BLK et RSM sont plus simples que les suggestions précédentes et ils ne nient pas le multiplexage sur un lien donné. En ce qui concerne l'utilisation des liens, nous renvoyons à un exemple donné par Bob Kahn où un IMP intermédiaire tombe en panne et mange le RFNM de quelqu'un. Cela ne devrait pas nécessiter de reconnexion.

Dans la Note #46, page 6, l'affirmation selon laquelle l'UCC a la capacité de fermer les connexions vers un processus mort dépend de l'installation. Dans notre cas particulier, le NCP est averti directement de la défaillance d'un processus en raison de l'interface logicielle particulière par laquelle tous les processus, y compris le NCP, doivent communiquer.

JFH:hs

Note: Ce RFC a été mis sous forme lisible par machine pour être intégré aux archives RFC en ligne par Gary Okada 7/97.