Les RFC sont forcément écrits en anglais,
qui restera la langue officielle (cf. ). L'anglais peut s'écrire avec
uniquement les caractères ASCII (avec quelques
exceptions : resume et résumé ne
sont pas le même mot). Mais on pourra désormais inclure des caractères
non-ASCII, par exemple pour le nom des auteurs (chic, je pourrais
écrire correctement mon prénom dans les RFC). Cette
possibilité permettra aussi aux exemples de protocoles Internet
utilisant Unicode (la grande majorité) d'être plus lisibles.
Cette nouvelle possibilité fait partie de celles qu'offre le
nouveau format des RFC, décrit dans le . Il n'y a quand même pas d'autorisation générale d'inclure n'importe quel
caractère Unicode dans les RFC, à n'importe
quel endroit. Le RFC
Editor pourra toujours refuser tel ou tel caractère, par
exemple parce qu'il n'existe pas de police
permettant de l'afficher. Et le « non-ASCII » n'est autorisé que dans
certains cas, décrits plus loin. La grande majorité du texte sera donc du pur
ASCII ().
L'encodage de ces caractères sera bien sûr
UTF-8.
Il ne suffit pas de proclamer « on a droit à Unicode ». Il faut
aussi adapter les outils. Par exemple, notre RFC impose (section 2) que les outils
de recherche dans les RFC gèrent correctement la recherche
Unicode. (C'est pour traiter le cas des outils imparfaits que le RFC
demande aussi que les noms d'auteurs en Unicode soient accompagnés
d'une version en ASCII.) Et
que le RFC soit affichable correctement sur un bon nombre de
plate-formes (d'où la possibilité de rejeter les caractères les plus
rares).
Ce problème du repli (vers une version en ACSII pur) est souvent
cité dans le RFC. Ainsi, lorsqu'on veut mentionner un caractère
Unicode (mettons le thorn
islandais), le RFC permet désormais de l'afficher
proprement, mais il demande qu'on l'accompagne du numéro du point de
code, et, si possible, de son nom Unicode. Cela donnerait, par
exemple « For instance, U+00FE, "LATIN SMALL LETTER THORN",
þ, is interesting because... ». Notez que cette
façon de désigner des caractères Unicode que tout le monde
n'arrivera pas forcément à afficher n'est pas vraiment
standardisée. Dans les RFC actuels, on trouve des variantes (voir
cette
discussion). Le RFC contient plusieurs exemples sur la façon
d'écrire la phrase « Temperature changes in the Temperature
Control Protocol are indicated by the U+2206 character (∆,
"INCREMENT") », tous acceptés (le nom Unicode n'est pas
obligatoire, il peut être placé avant ou après le caractère
lui-même, etc.) Autre cas, ce texte du , « For example, the characters U+13DA U+13A2
U+13B5 U+13AC U+13A2 U+13AC U+13D2 from the Cherokee block look
similar to the ASCII characters "STPETER" » deviendrait
« For example, the characters U+13DA U+13A2 U+13B5 U+13AC
U+13A2 U+13AC U+13D2 (ᏚᎢᎵᎬᎢᎬᏒ) from the Cherokee block look similar
to the ASCII characters "STPETER" ». Des tables comme
celles des identificateurs et mots de passe Unicode légaux () seraient ainsi bien plus lisibles.
Pour les noms, par
exemple ceux des auteurs. On aurait du « non-ASCII » et un texte de
repli, comme (en utilisant le vocabulaire XML
du ) :
]]>
Cela permettra enfin d'écrire correctement les noms des auteurs de
RFC.
La bibliographie d'un RFC est également un
bon endroit où mettre des caractères Unicode, par exemple lorsqu'on
cite des textes non-anglo-saxons. Ainsi, la bibliographie du pourrait inclure :
[GOST3410] "Information technology. Cryptographic data security.
Signature and verification processes of [electronic]
digital signature.", GOST R 34.10-2001, Gosudarstvennyi
Standard of Russian Federation, Government Committee of
Russia for Standards, 2001. (In Russian)
"Информационная технология. Криптографическая защита
информации. Процессы формирования и проверки
электронной цифровой подписи", GOST R 34.10-2001,
Государственный стандарт Российской Федерации, 2001.
Le second texte étant l'original russe.
Les règles exactes figurent dans la section 3. D'abord, on peut
mettre du « non-ASCII » comme on veut quand il fait partie d'un
exemple. Ainsi, la communication XMPP
pourrait être décrite de manière plus naturelle. Au lieu de cet
exemple de communication en tchèque () :
Wherefore art thou, Romeo?
PročeŽ jsi ty, Romeo?
]]>
On pourra écrire la forme lisible :
Wherefore art thou, Romeo?
PročeŽ jsi ty, Romeo?
]]>
Ensuite, on peut utiliser le « non-ASCII » pour les cas cités plus
haut (noms d'auteurs, textes non-anglophones dans la bibliographie,
etc). Pour les exemples utilisant un langage de programmation, notre
RFC spécifie qu'il faut suivre les règles du langage en
question. Ainsi, Python 3 autorisant l'Unicode
même dans les noms de variables, on peut écrire :
Enfin, un petit mot sur la normalisation
Unicode, pour rappeler que le format des RFC ne garantit
rien à ce sujet (on aurait pu décider que NFC
serait systématiquement utilisée...) et que les auteurs de RFC ne
doivent donc pas compter dessus.
Le premier RFC publié avec des caractères Unicode a été le , en septembre 2017.