Mon blog

La plupart des RFC contenant une grammaire formelle pour un format ou un protocole, utilisent le langage ABNF, normalisé dans le RFC 5234. Une des particularités d'ABNF, qui agace beaucoup de monde depuis le début, est le fait que les chaînes de caractères sont forcément insensibles à la casse. Si on veut les rendre sensibles à la casse, ce qui est une demande assez fréquente, il faut utiliser des trucs plus ou moins propres. D'où ce nouveau RFC qui fait sauter l'obstacle en permettant enfin d'indiquer qu'une chaîne de caractères est sensible à la casse.

Voici un exemple tiré du RFC 7208, qui décrit SPF :

mx  = "mx"     [ ":" domain-spec ] [ dual-cidr-length ]

Du fait de l'insensibilité à la casse, un enregistrement SPF peut inclure mx:example.net/26 mais aussi mX:example.net/26, MX:example.net/26 ou Mx:example.net/26. Ce comportement est souvent raisonnable mais, dans certains cas, il ne convient pas et on ne peut plus alors utiliser des chaînes de caractères, il faut (RFC 5234, section 2.3), indiquer explicitement les valeurs numériques de chaque caractère. Par exemple, dans le RFC 4997, les identificateurs sont forcément en majuscule et le littéral THIS doit donc être défini par :

   THIS         = %d84.72.73.83

Si on l'avait défini :

   THIS         = "THIS"

alors, il aurait pu être écrit en minuscules ou en mixte.

Donc, désormais, la règle est que les chaînes de caractères en ABNF peuvent être précédées de %i pour indiquer qu'elles sont insensibles à la casse ou %s pour dire qu'elles ne le sont pas. Comme %i est la valeur par défaut (pour préserver la compatibilité), elle sera souvent omise. La définition du RFC 4997 plus haut aurait donc pu être :

   THIS         = %s"THIS"

À ma connaissance, les différents outils ABNF en http://tools.ietf.org/ n'ont pas encore fait l'objet d'un examen systématique pour déterminer s'ils intégraient la nouvelle norme.