La publication d'un RFC se fait uniquement
sous forme de texte brut, encodé en
ASCII. Il y a d'excellentes raisons pour cela,
notamment la nécessité de ne s'appuyer que sur des formats
ouverts et également l'importance de la pérénnité des
spécifications (si le sur IP avait été écrit avec la version de
Microsoft Word de l'époque, il serait
complètement illisible aujourd'hui). Mais ce choix du RFC
editor ne concerne que la publication. Les auteurs sont
libres des outils qu'ils utilisent pour produire cette version en
texte. La plupart, en bons techniciens, utilisent le format
XML du mais
quelqu'uns sont attachés aux obésiciels de
Microsoft et c'est pour eux qu'est écrit ce
document. (Les durs de durs, eux, utilisent encore le traditionnel
système nroff.)
Ce décrit en effet un
gabaritMS Word pour
écrire des RFC. Ce gabarit au format .dot permet
de fixer les principaux paramètres qui feront que le document sera
accepté par le RFC Editor. Le gabarit est
disponible en .
La section 1 justifie le choix de Word en insistant sur l'édition
en mode WYSIWYG mais aussi sur les capacités de
Word d'afficher uniquement le squelette du document, cachant ou
affichant au choix le contenu des paragraphes. La section 2 donne le
mode d'emploi du gabarit et les bonnes pratiques d'édition en
utilisant celui-ci (par exemple, utiliser uniquement les styles et pas
les possibilités de changer directement l'apparence du texte ; un très
bon conseil de toute façon, pour tout document complexe). Le gabarit
utilise, outre les styles standard comme Normal
quelques styles spécifiques aux RFC comme RFC
Title. En 2.4 se trouvent les instructions pour générer le
résultat, en passant par l'imprimante virtuelle « Texte seul » de
Windows (bien que Word tourne sur d'autres
systèmes que Windows, ce n'est pas le cas de la méthode décrite dans
le RFC : si on vend son âme à Bill Gates, il
faut le faire jusqu'au bout et utiliser uniquement Windows). Le
résultat est ensuite traité par un programme Perl, fourni en annexe B, et qui assure les
tâches que Word ne sait pas faire comme de remplacer les guillemets
dits « typographiques » comme U+201C,
“ et U+201D, ”, par leur équivalent
ASCII, U+0022, ".
Le est d'ailleurs une lecture intéressante, au
delà de la tâche pratique de l'écriture de RFC, car il a vraiment
fallu insister pour obtenir de Word le résultat parfait. Une bonne
partie des possibilités techniques de ce logiciel ont été utilisées (voir le détail dans l'annexe A).
Il s'agit d'une mise à jour du premier gabarit, qui avait été
publié dans le . Les changements sont assez profonds
et sont détaillés dans la section 3. Le principal (section 3.1) est qu'au lieu de
créer des styles spécifiques pour tout, le gabarit désormais utilise,
dans la mesure du possible, les styles standards comme
Normal ou Heading1. C'est la pratique que suivent d'autres
organisations qui créent des gabarits pour leurs auteurs, comme
l'IEEE ou bien l'ACM. Un autre changement est la possibilité d'utiliser désormais des références bibliographiques par mnémonique et plus seulement par numéro (section 3.2).
Le gabarit semble fonctionner avec
OpenOffice 2.4 mais, sans les capacités
d'impression virtuelle, cela ne sert pas à grand'chose. Ce RFC est
donc bien pour les admirateurs de Bill Gates seulement.