diff options
Diffstat (limited to '')
-rw-r--r-- | RFC_7994_Requirements_for_PlainText_RFCs.txt | 75 |
1 files changed, 75 insertions, 0 deletions
diff --git a/RFC_7994_Requirements_for_PlainText_RFCs.txt b/RFC_7994_Requirements_for_PlainText_RFCs.txt new file mode 100644 index 0000000..6b7be8c --- /dev/null +++ b/RFC_7994_Requirements_for_PlainText_RFCs.txt @@ -0,0 +1,75 @@ +Titre: RFC 7994: Requirements for Plain-Text RFCs +Auteur: +Date: Fri 16 Dec 2016 01:00:00 +0100 +Lien: https://www.bortzmeyer.org/7994.html + +Dans la grande série des nombreux RFC spécifiant le nouveau format de ces +documents (avec XML étant désormais la référence), ce court RFC décrit le +format de publication « texte brut » des RFC. + +En effet, si le format « texte brut » n'est plus la référence[1] des RFC, ce +format reste toujours utile. Dans le nouveau mécanisme (RFC 7990), il y a +désormais plusieurs formats de publication, obtenus à partir du format +canonique (celui qui est en XML). Le texte brut est l'un d'eux. Ce format, +historiquement le seul utilisé par les RFC, ne disparait pas, mais perd de son +importance. Il n'est plus qu'un des formats de publication parmi d'autres +(comme HTML, voir le RFC 7992). Le RFC 6949 expliquait ce choix. + +À noter que les RFC produits avant ce changement ne sont pas affectés : leur +format de référence reste le texte brut (et en ASCII seul). + +Bon, désormais, on aura un format de sortie (parmi d'autres) en « texte seul » +ou « texte brut ». Mais c'est quoi, le texte brut ? Notre RFC reprend la +définition du consortium Unicode : « du texte encodé pour les ordinateurs +composé uniquement de points de code d'une norme donnée, sans instructions de +format ou de structure ». Bref, les caractères indiqués ne valent que pour +eux-mêmes, ils n'indiquent jamais de formatage ou de style. Selon cette +définition, HTML, LaTeX et Markdown (RFC 7763) ne sont donc pas du texte brut. +(La définition n'est pas 100 % parfaite. La norme Unicode, par exemple, inclut +des caractères qui influencent le format.) Le texte brut est donc ce qui est le +plus portable : tous les acteurs qui connaissent la norme de jeu de caractères +sous-jacente (aujourd'hui, quasiment toujours Unicode) peuvent lire et écrire +du texte brut. C'est d'ailleurs une des raisons pour lesquelles les RFC ont si +longtemps gardé ce format[2] comme format canonique. + +Mais si le texte brut n'est pas idéal comme format de référence, il reste un +format de sortie très utile, notamment pour son interopérabilité, ou en raison +de l'existence de nombreux outils qui peuvent le traiter (à commencer par +grep...) Désormais, donc, le format canonique est le XML décrit dans le RFC +7991 et le texte brut sera produit automatiquement par les nouveaux outils. +Mais ce texte brut a des règles qui sont légèrement différentes du texte brut +original (« RFC canal historique ») et notre RFC 7994 les décrit. Il est très +court, car le format « texte brut » est un format simple. + +D'abord, le jeu de caractères (section 2). Ce sera bien sûr Unicode, mais avec +les restrictions indiquées dans le RFC 7997. En pratique, là où les caractères +non-ASCII ne sont pas autorisés, il faudra utiliser l'ASCII équivalent, donné +dans les attributs XML prévus à cet effet (ascii, RFC 7991 en section 2.23.1, +asciiFullname en 2.7.1, etc). L'encodage sera obligatoirement UTF-8 (RFC 3629). +Curieusement, il est prévu de mettre une BOM au début du document. + +Que faire avec les graphiques, désormais autorisés par le RFC 7990, et écrits +en SVG (RFC 7996) ? Ces graphiques sont, dans le source XML, à l'intérieur d'un +élément <>artwork>. Comment les rendre dans du texte brut (section 3 de notre +RFC) ? D'abord, si le graphique n'est pas en SVG mais dans le traditionnel art +ASCII (indiqué par type=ascii-art), on utilise cet art ASCII. Autrement, notre +RFC ne propose pas de solution générale. Il est recommandé aux auteurs de +diagrammes et schémas de prévoir une alternative en art ASCII, même quand ils +font du SVG. + +Enfin, la section 4 du RFC couvre le problème de la « mise en page ». Un +caractère de fin de page (U+000C) sera inclus automatiquement toutes les 58 +lignes (les outils auront probablement une option pour ne pas inclure de telles +marques). L'outil devra gérer le délicat problème des veuves et des orphelines. +Les lignes feront 72 caractères, suivies de deux caractères marquant la fin +(U+000D U+000A). + +Les textes de début du RFC (RFC 5741) seront automatiquement mis comme avant, +mais les en-têtes et pieds de page disparaissent. Autre disparition, il n'y +aura plus, dans le format de sortie en texte brut, de numéros de pages dans la +table des matières (dommage, je trouve, mais c'est au nom de la cohérence avec +les autres formats de sortie). + +Liens: +[1]: http://www.rfc-editor.org/pipermail/rfc-interest/2013-May/005584.html (lien) +[2]: http://www.bortzmeyer.org/rfc-en-texte-brut.html (lien) |