Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
Ce nouveau RFC marque le cinquantième anniversaire des
RFC. Le RFC 1 avait en effet été publié le 7
avril 1969. Ce RFC 8700, publié
avec un certain retard, revient
sur l'histoire de cette exceptionnelle série de documents.
Il y avait déjà eu des RFC faisant le bilan de la série, à
l'occasion d'anniversaires, comme le RFC 2555 pour le trentième RFC, et le RFC 5540 pour le quarantième. La série a évidemment commencé
avec le RFC 1, cinquante ans auparavant, et
donc dans un monde très différent. À l'époque, les RFC méritaient
leur nom, ils étaient été en
effet des « appels à commentaires », prévus non pas comme des
références stables, mais comme des étapes dans la discussion. En
cinquante ans, les choses ont évidemment bien changé, et les RFC
sont devenus des documents stables, intangibles, et archivés
soigneusement. Logiquement, le processus de création des RFC a
également évolué, notamment vers un plus grand formalisme (on peut
même dire « bureaucratie »).
Plus de 8 500 RFC ont été publiés (il existe quelques trous
dans la numérotation ; ainsi, le RFC 26 n'a
jamais existé…) Les plus connus sont les normes techniques de
l'Internet. La description précise de HTTP, BGP ou IP est dans un RFC. Mais d'autres RFC ne
normalisent rien (c'est le cas du RFC 8700, sujet de cet
article), ils documentent, expliquent, suggèrent… Tous les RFC ont
en commun d'être publiés puis soigneusement gardés par le
RFC
Editor, une fonction assurée par plusieurs
personnes, et aujourd'hui animée par Heather Flanagan, auteure de
ce RFC 8700, mais qui a annoncé son départ.
Cette fonction a elle aussi une histoire : le premier
RFC Editor était Jon Postel. À l'époque c'était une fonction
informelle, tellement informelle que plus personne ne sait à
partir de quand on a commencé à parler du (ou de la) RFC
Editor (mais la première mention explicite est dans le
RFC 902). Postel assurait cette fonction en plus de ses
nombreuses autres tâches, sans que cela n'apparaisse sur aucune
fiche de poste. Petit à petit, cette fonction s'est
formalisée.
Les changements ont affecté bien des aspects de la série des
RFC, pendant ces cinquante ans. Les premiers RFC étaient
distribués par la poste ! Au
fur et à mesure que le réseau (qui ne s'appelait pas encore
Internet) se développait, ce mécanisme de
distribution a été remplacé par le courrier électronique et le FTP anonyme. Autre changement,
les instructions aux auteurs, données de manière purement orales,
ont fini par être rédigées. Et l'équipe s'est étoffée : d'une
personne au début, Postel seul, le RFC Editor a
fini par être une tâche assurée par cinq à sept
personnes. Autrefois, la fonction de RFC Editor
était liée à celle de registre des noms et numéros, puis elle a
été séparée (le registre étant désormais PTI). Puis la fonction de
RFC Editor a été structurée, dans le RFC 4844, puis RFC 5620,
enfin dans le RFC 6635. Et l'évolution
continue, par exemple en ce moment avec le changement vers le
nouveau format des documents (voir RFC 7990). Dans le futur, il y aura certainement d'autres
changements, mais le RFC Editor affirme son
engagement à toujours prioriser la stabilité de la formidable
archive que représentent les RFC, et sa disponibilité sur le long
terme (RFC 8153).
La section 2 du RFC rappelle les grands moments de l'histoire
des RFC (je n'ai pas conservé toutes ces étapes dans la liste) :
- Avril 1969, premier RFC, le RFC 1,
- 1971, premier RFC distribué via le réseau, le RFC 114,
- 1977, premier RFC publié le premier avril, le RFC 748,
- 1986, création de l'IETF,
- 1998, début du projet de récupération et de restauration
des vieux RFC perdus,
- 1998, mort de Jon Postel, le « père
de la série des RFC » (cf. RFC 2441),
- 2009, publication du RFC 5620, qui
décrit à peu près le modèle d'aujourd'hui,
- 2010, les RFC ne sont plus gérés à
l'ISI, mais chez une organisation spécialisée,
- 2011, une des nombreuses réformes des RFC, l'abandon des
trois niveaux de normalisation, documenté dans le RFC 6410,
- 2013, début du projet de changement du format (RFC 6949) et d'abandon
du texte brut,
- 2017, passage au zéro papier (RFC 8153).
Dans la section 3 de ce RFC, plusieurs personnes ayant vécu de
l'intérieur l'aventure des RFC écrivent. Steve Crocker, dans la section 3.1, rappelle
les origines des RFC (qu'il avait déjà décrites dans le RFC 1000). Il insiste sur le fait que les débuts
étaient… peu organisés, et que la création de la série des RFC
n'était certainement pas prévue dés le départ. Elle doit beaucoup
aux circonstances. Le réseau qui, après bien des évolutions,
donnera naissance à l'Internet a été conçu
vers 1968 et a commencé à fonctionner en
1969. Quatre machines, en tout et pour
tout, le constituaient, un Sigma
7, un SDS
940, un IBM 360/75 et un PDP-10. Le point important est qu'il
s'agissait de machines radicalement différentes, un des points
distinctifs de l'Internet, qui a toujours dû gérer
l'hétérogénéité. Un byte
n'avait pas la même taille sur toutes ces machines. (Le terme
français octet est apparu bien plus tard,
lorsque la taille de huit bits était devenue standard.)
Crocker décrit la première réunion de ce qui allait devenir le
Network Working Group puis, très longtemps
après l'IETF. Rien n'était précisement
défini à part « il faut qu'on fasse un réseau d'ordinateurs » et
persone ne savait trop comment le faire. La principale conclusion
de la réunion avait été « il faudrait faire une autre
réunion ». Dès le début, le réseau qui allait permettre de
travailler à distance était donc un prétexte à des réunions
AFK. (L'ironie continue aujourd'hui, où
l'IETF réfléchit à avoir des réunions entièrement en ligne.)
L'espoir des étudiants comme Crocker était qu'un
monsieur sérieux et expérimenté vienne expliquer ce qu'on allait
devoir faire. Mais cet espoir ne s'est pas matérialisé et le futur
Network Working Group a donc dû se
débrouiller.
Parmi les idées les plus amusantes, le groupe avait réfléchi à
la création d'un langage portable permettant d'envoyer du code sur
une autre machine qui l'exécuterait. Ce lointain prédécesseur de
JavaScript se nommait DEL (pour
Decode-Encode Language) puis NIL
(Network Interchange Language). Mais en
attendant le travail matériel avançait, la société BBN ayant obtenu le
contrat de construction des IMP (à peu près ce qu'on appelerait plus
tard routeurs). La
répartition des tâches entre le NWG et BBN n'était pas claire et
le groupe a commencé de son côté à documenter ses réflexions,
créant ainsi les RFC. Le nom de ces documents avait fait l'objet
de longs débats. Le Network Working Group
n'avait aucune autorité officielle, aucun droit, semblait-il, à
édicter des « normes » ou des « références ». D'où ce titre
modeste de Request for Comments ou « Appel à
commentaires ». Cette modestie a beaucoup aidé au développement du
futur Internet : personne ne se sentait intimidé par l'idée
d'écrire des documents finaux puisque, après tout, ce n'était que
des appels à commentaires. C'était d'autant plus important que
certains des organismes de rattachement des participants avaient
des règles bureaucratiques strictes sur les publications. Décréter
les RFC comme de simples appels à commentaires permettait de
contourner ces règles.
Le premier « méta-RFC » (RFC parlant des RFC) fut le RFC 3, qui formalisait cette absence de
formalisme. De la même façon, il n'existait pas encore vraiment de
RFC Editor, même si Crocker attribuait les
numéros, et que le SRI gardait une archive
non officielle. Mais deux principes cardinaux dominaient, et sont
toujours vrais aujourd'hui : tout le monde peut écrire un RFC, nul
besoin de travailler pour une grosse entreprise, ou d'avoir un
diplôme ou un titre particulier, et tout le monde peut lire les
RFC (ce qui n'a rien d'évident : en 2019,
l'AFNOR ne distribue toujours pas librement
ses normes.)
Dans la section 3.2, Vint Cerf décrit
les changements ultérieurs. En 1971,
Jon Postel est devenu RFC
Editor (titre complètement informel à cette
époque). Cette tâche était à l'époque mélée à celle d'attribution
des numéros pour les protocoles, désormais séparée. Postel
s'occupait à la fois du côté administratif du travail (donner un
numéro aux RFC…) et de l'aspect technique (relecture et révision),
tâche aujourd'hui répartie entre diverses organisations comme
l'IESG pour les RFC qui sont des
normes. C'est pendant cette « période Postel » que d'autres
personnes sont venues rejoindre le RFC Editor
comme Joyce
Reynolds ou Bob Braden. Jon Postel est
décédé en 1998 (cf. RFC 2468).
Leslie Daigle, dans la section 3.3 de notre RFC, rappelle la
longue marche qu'a été la formalisation du rôle de RFC
Editor, le passage de « bon, qui s'en occupe ? » à un
travail spécifié par écrit, avec plein de règles et de
processus. (Daigle était présidente de
l'IAB au moment de la transition.) Le
travail était devenu trop important en quantité, et trop critique,
pour pouvoir être assuré par deux ou trois volontaires opérant
« en douce » par rapport à leurs institutions. Une des questions
importantes était évidemment la relation avec
l'IETF. Aujourd'hui, beaucoup de gens
croient que « les RFC, c'est l'IETF », mais c'est faux. Les RFC
existaient bien avant l'IETF, et, aujourd'hui, tous les RFC ne sont pas issus de
l'IETF.
Parmi les propositions qui circulaient à l'époque (début des
années 2000) était celle
d'une publication complètement automatique. Une fois le RFC
approuvé par l'IESG, quelqu'un aurait cliqué sur
Publish, et le RFC se serait retrouvé en ligne,
avec un numéro attribué automatiquement. Cela aurait certainement
fait des économies, mais cela ne réglait pas le cas des RFC
non-IETF, et surtout cela niait le rôle actif du RFC
Editor en matière de contenu du RFC. (Témoignage
personnel : le RFC Editor a joué un rôle
important et utile dans l'amélioration de mes RFC. C'est vrai même
pour les RFC écrits par des anglophones : tous les ingénieurs ne
sont pas des bons rédacteurs.) D'un autre côté, cela résolvait le
problème des modifications faites de bonne foi par le RFC
Editor mais qui changeaient le sens technique du
texte.
La solution adoptée est décrite dans le RFC 4844, le premier à formaliser en détail le rôle du
RFC Editor, et ses relations complexes avec les
autres acteurs.
Nevil Brownlee, lui, était ISE, c'est-à-dire
Independent Submissions Editor, la personne
chargée de traiter les RFC de la voie indépendante (ceux qui ne
viennent ni de l'IETF, ni de l'IAB, ni de l'IRTF.) Dans
la section 3.4, il revient sur cette voie indépendante (d'abord
décrite dans le RFC 4846). En huit ans, il a été responsable de
la publication de 159 RFC… Avant, c'était le RFC
Editor qui décidait quoi faire des soumissions
indépendantes. Comme le rappelle Brownlee, le logiciel de gestion
de cette voie indépendante était un simple fichier texte, tenu par
Bob Braden.
Le principal travail de l'ISE est de coordonner les différents
acteurs qui jouent un rôle dans ces RFC « indépendants ». Il faut
trouver des relecteurs, voir avec l'IANA
pour l'allocation éventuelle de numéros de protocoles, avec
l'IESG pour s'assurer que ce futur RFC ne
rentre pas en conflit avec un travail de l'IETF (cf. RFC 5742), etc. Ah, et c'est aussi l'ISE qui gère
les RFC du premier avril.
Puis c'est la RFC Editor actuelle, Heather
Flanagan qui, dans la section 3.5, parle de son expérience,
d'abord comme simple employée. La charge de travail atteignait de
tels pics à certains moments qu'il a fallu recruter des personnes
temporaires (au nom de l'idée que la publication des RFC devait
être un processus léger, ne nécessitant pas de ressources
permanentes), ce qui a entrainé plusieurs accidents quand des
textes ont été modifiés par des employés qui ne comprenaient pas
le texte et introduisaient des erreurs. L'embauche d'employés
permanents a résolu le problème.
Mais il a fallu aussi professionnaliser l'informatique. Le
RFC Editor qui travaillait surtout avec du
papier (et un classeur, le
fameux « classeur noir ») et quelques outils bricolés (la file d'attente
des RFC était un fichier HTML édité
à la main), a fini par disposer de
logiciels adaptés à la tâche. Finies, les machines de Rube
Goldberg !
Dans le futur, bien sûr, les RFC vont continuer à changer ; le
gros projet du moment est le changement de format canonique, du
texte brut à XML. Si
l'ancien format avait de gros avantages, notamment en terme de
disponibilité sur le long terme (on peut toujours lire les anciens
RFC, alors que les outils et formats à la mode au moment de leur
écriture sont depuis longtemps oubliés), il avait aussi des
inconvénients, comme l'impossibilité d'utiliser d'autres
caractères que l'ASCII. Le RFC 7990 décrit le nouveau format, actuellement en cours de déploiement.
Autres lectures :