Mon blog

Dans toute organisation qui s'occupe de technique, le choix du format de fichiers pour la documentation est une question délicate et souvent polémique. L'IETF n'y échappe pas et ce RFC, qui tentait de normaliser un format XML pour l'écriture des RFC n'a pas été un succès complet. (Depuis, il a été remplacé par le RFC 7749.)

Contrairement à beaucoup d'organisations de normalisation, qui produisent des normes dans des formats spécifiques d'un traitement de textes commercial, au mépris des besoins et intérêts des lecteurs, l'IETF a toujours insisté sur l'importance de publier dans un format ouvert. Pour des raisons historiques, les RFC sont publiés en texte brut, encodé en ASCII (ce qui ne permet pas d'afficher correctement les noms des auteurs non anglo-saxons). Toujours pour des raisons historiques, l'éditeur des RFC (qui est indépendant de l'IETF) utilise nroff comme format d'entrée (décrit dans le RFC 2223). Si cela peut sembler archaïque, il faut se rappeler que l'IETF a des exigences bien particulières et qu'un RFC n'est pas une note de service, qui sera jetée au bout de quelques semaines : étant (souvent) une norme, le RFC doit pouvoir être lu par tous, pas seulement par les clients de Microsoft, et il doit être pérenne (le RFC sur IP, le RFC 791 date de septembre 1981 ; quel traitement de textes à forts effets visuels pourrait durer aussi longtemps ?).

Ce format antédiluvien pose néanmoins de plus en plus de problèmes et des alternatives ont été proposées. Il est intéressant de noter qu'aucune n'a fait l'objet d'un consensus et, l'IETF n'ayant aucun moyen de trancher ce genre de querelles, les auteurs de RFC continuent à utiliser plusieurs formats.

Les deux formats les plus utilisés sont le gabarit MS-Word, décrit dans le RFC 3285 et un format XML, décrit dans notre RFC.

Compte-tenu des avantages de XML (portabilité, ouverture du format, possibilité d'édition avec n'importe quel éditeur et possibilité de produire facilement des formats d'affichage comme HTML), le choix semblait évident. Notre RFC décrit, grâce à une DTD, les éléments XML autorisés (au nombre de 42, ce qui rend ce langage bien plus simple que DocBook ou OpenDocument). On trouve des outils de conversion (par exemple vers nroff) de ce format, un index en XML des RFC (je l'utilise pour créer automatiquement le point de départ des articles RFC de ce blog), et des documents d'exemple sur http://xml.resource.org/.

Notre RFC apparait donc ainsi en HTML et le source XML commence avec :

<rfc number="2629" category="info">
<title>Writing I-Ds and RFCs using XML</title>
<author initials="M.T." surname="Rose" fullname="Marshall T. Rose">
<email>mrose@not.invisible.net</email>
</author>
<date month="June" year="1999"/>
<section title="Introduction" toc="default">
<t>This memo describes how to write a document for the I-D and RFC series
using <xref target="XML" format="default" pageno="false">the Extensible Markup L
anguage</xref> (XML).
This memo has three goals:
<list style="numbers">
<t>To describe a simple XML Document Type Definition (DTD) 

Notre RFC souffre de son âge par exemple en utilisant toujours une DTD, technique désormais dépassée. Et la principale transformation, celle en texte, n'est pas faite avec XSLT mais avec un script TCL ad hoc. Une nouvelle version de notre RFC est à l'étude depuis un certain temps.

Comme l'a montré encore récemment une longue discussion à l'IETF, il ne manquait plus à ce format que l'adoption généralisée... Peut-être que son successeur, le RFC 7749 réussira mieux.