#rfc

  • RFC 8700: Fifty Years of RFCs | Blog @stephane Bortzmeyer
    https://www.bortzmeyer.org/8700.html

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

    #histoire

    https://seenthis.net/messages/819299 via tbn


  • Ce que peut faire votre Fournisseur d’Accès à l’Internet
    https://framablog.org/2018/11/29/ce-que-peut-faire-votre-fournisseur-dacces-a-linternet

    Nous sommes ravis et honorés d’accueillir Stéphane Bortzmeyer qui allie une compétence de haut niveau sur des questions assez techniques et une intéressante capacité à rendre assez claires des choses complexes. Nous le remercions de nous expliquer dans cet article … Lire la suite­­

    #Claviers_invités #G.A.F.A.M. #Internet_et_société #Chiffrement #FAI #FFDN #GAFA #https #Internet #neutralité #Réseau #RFC #Snowden #Surveillance


  • RFC 8280 : Research into Human Rights Protocol Considerations

    Ce #RFC très politique est le premier du groupe de recherche #IRTF #HRPC, dont le nom veut dire « Human Rights and Protocol Considerations ». À première vue, il n’y a pas de rapport entre les #droits_humains et les protocoles réseau. Les premiers relèvent de la politique, les seconds de la pure technique, non ? Mais, justement, le groupe HRPC a été créé sur la base de l’idée qu’il y a de la politique dans le travail de l’#IETF, que les protocoles ne sont pas complètement neutres, et qu’il était nécessaire de creuser cette relation complexe entre protocoles et droits humains. Le premier RFC analyse le problème de base : « #TCP/IP est-il politique ? »

    http://www.bortzmeyer.org/8280.html

    #droits_de_l_homme #DUDH

    https://seenthis.net/messages/641927 via Stéphane Bortzmeyer


  • RFC 8153 : Digital Preservation Considerations for the RFC Series

    La #préservation_numérique, sur le long terme, des documents qui ne sont jamais passés par une forme papier, est un défi important de notre époque. Nous pouvons relire aujourd’hui toute la correspondance du ministère des affaires étrangères de Louix XV, pourrons-nous, dans un siècle ou deux, relire les documents numériques du vingtième siècle ? Pourrons-nous relire les #RFC ? C’est le but de ce document que d’explorer les pistes permettant de donner aux RFC une meilleure chance de conservation.

    http://www.bortzmeyer.org/8153.html

    #archivage

    https://seenthis.net/messages/597102 via Stéphane Bortzmeyer


  • RFC 8117 : Current Hostname Practice Considered Harmful

    « Je suis l’iPhone de Jean-Luc ! » Traditionnellement, les ordinateurs connectés à l’Internet ont un nom, et ce nom est souvent annoncé à l’extérieur par divers protocoles. Cette pratique très répandue, dont l’origine remonte à l’époque où on n’avait que quelques gros serveurs partagés, et fixes, est dangereuse pour la #vie_privée, dans un monde de mobilité et de machines individuelles. Comme le note ce nouveau #RFC, « c’est comme si on se promenait dans la rue avec une étiquette bien visible portant son nom ». Ce RFC dresse l’état des lieux, fait la liste des protocoles problématiques, et suggère, lorsqu’on ne peut pas changer le protocole, d’utiliser des noms aléatoires, ne révélant rien sur la machine.

    http://www.bortzmeyer.org/8117.html

    https://seenthis.net/messages/577286 via Stéphane Bortzmeyer