diff options
Diffstat (limited to 'RFC_7990_RFC_Format_Framework.txt')
| -rw-r--r-- | RFC_7990_RFC_Format_Framework.txt | 204 |
1 files changed, 204 insertions, 0 deletions
diff --git a/RFC_7990_RFC_Format_Framework.txt b/RFC_7990_RFC_Format_Framework.txt new file mode 100644 index 0000000..6599750 --- /dev/null +++ b/RFC_7990_RFC_Format_Framework.txt @@ -0,0 +1,204 @@ +Titre: RFC 7990: RFC Format Framework +Auteur: +Date: Fri 16 Dec 2016 01:00:00 +0100 +Lien: https://www.bortzmeyer.org/7990.html + +Voici enfin la série de RFC décrivant le nouveau format des RFC. Ce projet a +commencé il y a plusieurs années, mais les discussions ont été longues. Ce +nouveau RFC et les huit autres qui l'accompagnent, marquent un changement +important dans ces « textes sacrés » de l'Internet : l'ancien format « texte +brut » n'est plus le format de référence. Désormais, tout RFC sera fait en XML, +format d'où seront produits automatiquement des versions texte brut, HTML, PDF, +etc. + +Les RFC sont des documents cruciaux pour l'Internet. C'est sous forme de RFC +que sont publiées les normes techniques de la famille de protocoles TCP/IP. Et +il y a bien d'autres RFC qui ne sont pas forcément des normes (cf. RFC 1796). +Librement disponibles en ligne (contrairement aux normes techniques des +organisations traditionnelles du mésozoïque), dans un format ouvert, la +disponibilité des RFC est l'une des raisons du succès de l'Internet. + +Parlons de format, justement. Les RFC, jusqu'à maintenant, étaient sous forme +de texte brut, et en ASCII seul. (Certes, des versions PDF et HTML +non-officielles étaient diffusées mais on voyait bien qu'elles avaient été +produites à partir du texte brut... Certes, il était possible depuis dix ans +d'écrire les RFC en XML, cf. RFC 2629, mais ce n'était pas le format de +référence.) Pourquoi donc[1] se limiter à ce format ? Il y avait plusieurs +bonnes (et d'autres moins bonnes) raisons mais il ne faut pas de cacher qu'une +des raisons les plus importantes était qu'il est difficile de faire changer un +processus de production bien établi, même s'il comprend des archaïsmes, comme +l'utilisation de troff pour traiter des documents. L'actuelle éditrice des RFC, +Heather Flanagan, a donc eu bien du mérite à faire aboutir ce projet de +changement. Il a fallu beaucoup de discussions, dans une communauté souvent +divisée. (Que les informaticiens pensent aux grands débats du genre « vi ou +emacs ? ») + +Le projet de réforme des RFC avait sérieusement commencé en 2013 avec le RFC +6949, le véritable cahier des charges du nouveau format. La décision formelle +de migrer vers le nouveau format, et donc de décider que le format de référence +serait désormais le XML et non plus le texte brut a été prise en mai 2013[2]. +Avant et pendant cette décision, d'innombrables messages ont été échangés sur +la liste de diffusion rfc-interest[3]. + +Il est important de noter que cette discussion portait sur le processus de +publication des RFC terminés. L'élaboration des Internet-Drafts, la décision de +les publier ou pas (qui dépend de chaque voie, cf. RFC 4844) ne sont pas +concernées. + +La section 2 de notre RFC résume le problème que veut résoudre le nouveau +format. Le monde a bien changé depuis que seuls une poignée de Californiens +anglophones venait aux réunions IETF. Les participants viennent aujourd'hui de +45 pays, situés dans le monde entier, les lecteurs des RFC sont plus divers que +jamais, utilisent des engins très variés, et il est toujours aussi crucial que +les RFC soient largement disponibles et accessibles, et sur une très longue +période (mon favori est le RFC 768, publié en 1980 et toujours d'actualité). Le +format de référence en texte ASCII brut ne permettait clairement pas cela. + +Mais choisir un successeur n'était pas facile : notre RFC insiste sur le fait +qu'il y a aujourd'hui plusieurs groupes qui utilisent les RFC (pas seulement +des techniciens, juristes et chefs accèdent aujourd'hui à des RFC), et sur le +fait qu'il fallait un compromis entre les besoins actuels et l'importance d'une +disponibilité à long terme (par exemple, adopter le format à la mode du moment +pourrait se payer cher plus tard lorsque ce format n'intéressera plus +personne). + +Un peu de terminologie (section 3) est nécessaire pour bien comprendre le choix +effectué : + + * Format canonique : le format de référence, archivé, utilisé en cas de + conflit (XML, donc). Il est important d'en avoir un, au cas où une bogue + dans les logiciels change une partie d'un RFC. + * Formats de publication : les divers formats sous lesquels est publié le RFC + (détaillés en section 7). Peu de gens liront le RFC en XML (quoique cela + soit possible, une propriété qui est importante pour la conservation à long + terme). Ils liront de l'HTML, du PDF, voire du texte seul pour les + traditionnalistes. Tous ces formats seront produits (de préférence + automatiquement) à partir du format canonique. Chacun a ses avantages et + inconvénients (section 5). Par exemple, HTML avec JavaScript fournit des + capacités de navigation bien meilleures que le texte brut. + * Format révisable : le format que le RFC Editor utilisera pour son travail + interne. Ce sera XML. + * Format de soumission : le format sous lequel le texte sera transmis + initialement par les auteurs au RFC Editor. Aujourd'hui, le texte brut est + obligatoire, le XML autorisé en prime. Demain, ce sera du XML, mais avec + des exigences moins strictes que pour le format canonique. + +Et aussi un terme important : texte réagencable (ou réajustable, reflowable +text). C'est du texte qui s'ajuste automatiquement à la largeur du dispositif +de lecture. C'est banal dans le monde HTML, où c'est fait automatiquement +depuis toujours. Mais c'était un des principaux inconvénients de l'ancien +format des RFC : le texte avait une largeur fixe. + +Quel sera donc exactement le format canonique ? La section 6 répond à cette +question : + + * Le langage sera du XML avec le vocabulaire spécifié dans le RFC 7991 (nommé + « v3 »). Il est normalement meilleur que les précédents vocabulaires + utilisés depuis le RFC 2629. + * Les auteurs pourront envoyer leur draft en suivant le format dit « v2 » + (celui du RFC 7749), voire en texte brut, mais il sera ensuite converti + dans le format v3 ci-dessus. + * Le SVG sera autorisé dans le source XML. + * Comme en v2, DTD est abandonné, la description officielle du schéma XML est + en Relax NG. + * Les textes obligatoires (RFC 5741) seront automatiquement insérés. + * Le source XML du format canonique sera autonome. Cela veut dire qu'il + n'aura pas de références à des sources extérieures. Ainsi, si un auteur + référence un code source externe avec <>sourcecode src="[un URI + externe]"... (RFC 7991, section 2.48), le code en question sera inclus dans + la version canonique. Idem si l'auteur a utilisé XInclude. + * Il n'y aura pas de commentaires ou de processing instructions dans le + source XML. Si l'auteur en a mis, ils seront retirés. + +Notez donc que les images (en SVG) seront désormais possibles (voir le RFC +7996). + +Le guide du style des RFC (RFC 7322) avait été révisé pour tenir compte de ce +nouveau format. Notamment, il se concentre désormais sur le contenu du texte, +ne demandant plus aux auteurs des efforts de présentation. (La section 5 résume +les changements importants pour les auteurs.) + +Enfin, la section 7 décrit les formats de publication. À partir du source XML, +seront automatiquement produits HTML, PDF, texte brut et peut-être plus tard +d'autres. Le HTML est évidemment la cible évidente. Son utilisation pour les +RFC est décrite dans le RFC 7992. Le résultat sera certainement bien meilleur +que les versions HTML non-officielles actuelles, qui sont produites à partir du +texte brut, qui ne contient pas assez de structure pour faire du bon HTML. La +mise en page sera évidemment assurée par CSS (RFC 7993), il y aura une feuille +de style standard, que chacun sera bien sûr libre de remplacer. Le SVG sera +inclus dans l'HTML (il faudra donc un navigateur qui gère bien SVG). Il y aura +même du JavaScript mais avec de sévères restrictions. Notamment, le code +JavaScript ne devra pas changer le texte, ou supprimer du texte. + +PDF, quant à lui, est spécifié dans le RFC 7995. Il devra suivre le profil +PDF/A-3, spécialement prévu pour de l'archivage à long terme, et pour pouvoir +être relu par des logiciels PDF n'ayant pas tous les derniers gadgets. + +Naturellement, le texte brut n'est pas abandonné. Comme indiqué dans le RFC +7994, il y aura une version en texte brut produite automatiquement à partir du +XML, même si elle ne sera plus la version canonique. Parmi les nouveautés par +rapport à l'ancien format, UTF-8 sera désormais autorisé, même si c'est de +façon limitée (voir les limitations dans le RFC 7997). Il pourra y avoir une +variante non découpée en pages. + +Dans le futur, il est possible que le format EPUB soit ajouté à cette liste. + +Au passage, comment a été décidé cet important changement dans le format des +RFC ? La section 4 résume cette histoire. Comme indiqué plus haut, cela a pris +très longtemps et nécessité beaucoup de discussions, qui ont notamment eu lieu +sur la liste de diffusion rfc-interest[3], et au cours des réunions physiques +de l'IETF. Le cahier des charges a été formalisé en 2013 dans le RFC 6949. Une +fois le cahier des charges décidé, une équipe spécialisée a été désignée par le +RFC Editor pour mettre au point les détails, notamment en adaptant le langage +XML utilisé, partant de la dernière version (RFC 7749), pour arriver au futur +langage, RFC 7991. Des éditeurs professionnels ont également été consultés, +ainsi d'autres SDO et même des juristes (oui, car aux États-Unis, rien n'est +désormais à l'abri d'actions en justice, même pas les RFC, le choix du format +de sortie PDF/A-3 venait en partie de la nécessité de répondre aux subpoenas). +Le tout était bien sûr fait sous la supervision du RFC Series Oversight +Committee[4]. Certaines décisions furent consensuelles, les autres tranchées +par le RFC Editor (cf. RFC 6635). Le tout a été approuvé par l'IAB en août 2016[5] +. + +Après ce tour du passé, le futur. Comment se fera la transition vers le nouveau +système (section 10) ? C'est qu'il va falloir créer de nouveaux outils (cf. RFC +7998). L'appel d'offres pour leur développement a été fait en septembre 2016[6] +. La description des outils est une très intéressante lecture[7] (l'appel +d'offres formel est sur la page des Request For Proposal[8]). L'appel d'offres +a été gagné par les sociétés SeanTek et Elf Tools. + +Pendant une période intermédiaire, le texte seul sera toujours utilisé comme +format canonique, mais les nouveaux RFC passeront également par le nouveau +workflow, pour vérifier que tout se passe bien et que le résultat est correct. +Double travail, donc, mais nécessaire pour s'assurer que tout est en place. + +Notez que, même une fois la transition finie, les auteurs ne seront pas forcés +de soumettre leur document sous forme d'un fichier XML (ils seront simplement +très fortement encouragés à le faire). S'ils envoient le texte seul comme +avant, le RFC Editor devra produire le XML lui-même, et c'est ce XML qui sera +la version canonique. Rappelez-vous que beaucoup de RFC sont des documents +normatifs et que chaque mot, voire chaque virgule peut compter ! Voici pourquoi +il faudra s'assurer que tout est parfait, même si, au début, cela entrainera +certainement des retards dans la publication. + +Dans le cas où l'auteur envoie du XML suivant le RFC 7991, il y aura moins de +travail pour le RFC Editor, juste convertir ce XML au XML canonique (résoudre +les références extérieures, par exemple) et passer ce XML canonique dans les +nouveaux outils. + +Notez que le RFC Editor maintient une FAQ très utile[9] sur toutes les +questions que pose le nouveau format. Et la RFC Editor avait fait un très drôle +Pecha Kucha à Séoul en novembre 2016, sur le cahier des charges du nouveau +format[10]. + +Liens: +[1]: http://www.bortzmeyer.org/rfc-en-texte-brut.html (lien) +[2]: http://www.rfc-editor.org/pipermail/rfc-interest/2013-May/005584.html (lien) +[3]: https://www.rfc-editor.org/mailman/listinfo/rfc-interest (lien) +[4]: https://www.iab.org/activities/programs/rfc-editor-program/ (lien) +[5]: https://www.iab.org/2016/08/06/iab-approves-rfc-format-related-drafts-for-publication/ (lien) +[6]: https://mailarchive.ietf.org/arch/msg/ietf-announce/pC618gbTXrLIIAcAhOUCuahfjCI (lien) +[7]: http://www.nostrum.com/~rjsparks/rfced/ (lien) +[8]: https://iaoc.ietf.org/rfps.html (lien) +[9]: https://www.rfc-editor.org/rse/format-faq/ (lien) +[10]: http://snaggletooth.akam.ai/Seoul-videos/7-heather-8.mp4 (lien) |