Mon blog

Ce RFC fait partie des RFC ancillaires, qui ne spécifient pas directement un protocole IETF mais fournissent des outils pour les "vrais" RFC. En l'occurrence, il normalise le mini-language pour écrire des grammaires.

Beaucoup de RFC doivent spécifier un langage, en général assez simple (jamais de la taille d'un langage de programmation) mais néanmoins suffisamment important pour que les descriptions informelles du langage soient risquées. Depuis longtemps, on utilise en informatique des notations dérivées du langage BNF pour spécifier formellement un langage. Le problème est qu'il existe plusieurs dialectes de BNF (comme EBNF) et que les RFC ont besoin d'une référence stable. À une époque, chaque RFC définissait approximativement sa grammaire formelle et l'utilisait ensuite. ABNF est issue d'un effort de Dave Crocker de regroupement de la définition de la grammaire en un seul RFC, le RFC 2234 en 1997, devenu ensuite le RFC 4234 en 2006. Notre RFC succède au fameux RFC 4234 (avec très peu de changements, le principal étant le passage au statut de norme IETF à part entière, Full Standard) et qui décrit ABNF, le dialecte IETF de BNF. Classique sur beaucoup de points, ce dialecte a quand même quelques variations, issues d'une histoire très ancienne. Par exemple, le signe | pour le choix est remplacé par /.

Quelques outils sont disponibles pour aider les auteurs de grammaires. Mais je trouve que c'est encore insuffisant. S'il existe deux vérificateurs (qui peuvent tester qu'une grammaire est cohérente), il n'existe guère de générateurs d'analyseurs syntaxiques. En revanche, à des fins de test, il existe au moins deux programmes, Eustathius et abnfgen, qui génèrent automatiquement des exemples à partir d'une grammaire. Vous trouverez de nombreux exemples de grammaires ABNF dans les sources d'Eustathius.

Notre RFC normalise non seulement le format des grammaires mais aussi une bibliothèque de productions prêtes à l'emploi comme HEXDIG pour les caractères utilisables pour écrire de l'hexadécimal ou ALPHA pour les lettres de l'alphabet latin. Baptisée Core, cette bibliothèque est décrite dans l'appendice B.

À titre d'exemple, voici la spécification de SPF (décrit dans le RFC 4408) en ABNF :

   record           = version terms *SP
   version          = "v=spf1"

   terms            = *( 1*SP ( directive / modifier ) )

   directive        = [ qualifier ] mechanism
   qualifier        = "+" / "-" / "?" / "~"
   mechanism        = ( all / include
                      / A / MX / PTR / IP4 / IP6 / exists )

   all              = "all"
   include          = "include"  ":" domain-spec
   A                = "a"      [ ":" domain-spec ] [ dual-cidr-length ]
   MX               = "mx"     [ ":" domain-spec ] [ dual-cidr-length ]
   PTR              = "ptr"    [ ":" domain-spec ]
   IP4              = "ip4"      ":" ip4-network   [ ip4-cidr-length ]
   IP6              = "ip6"      ":" ip6-network   [ ip6-cidr-length ]
   exists           = "exists"   ":" domain-spec

   modifier         = redirect / explanation / unknown-modifier
   redirect         = "redirect" "=" domain-spec
   explanation      = "exp" "=" domain-spec
   unknown-modifier = name "=" macro-string

   ip4-cidr-length  = "/" 1*DIGIT
   ip6-cidr-length  = "/" 1*DIGIT
   dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]

   ip4-network      = qnum "." qnum "." qnum "." qnum
   qnum             = DIGIT                 ; 0-9
                      / %x31-39 DIGIT       ; 10-99
                      / "1" 2DIGIT          ; 100-199
                      / "2" %x30-34 DIGIT   ; 200-249
                      / "25" %x30-35        ; 250-255
             ; conventional dotted quad notation.  e.g., 192.0.2.0
   ip6-network      = <as per [RFC 3513], section 2.2>
             ; e.g., 2001:DB8::CD30

   domain-spec      = macro-string domain-end
   domain-end       = ( "." toplabel [ "." ] ) / macro-expand
   toplabel         = ( *alphanum ALPHA *alphanum ) /
                      ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
                      ; LDH rule plus additional TLD restrictions
                      ; (see [RFC3696], Section 2)

   alphanum         = ALPHA / DIGIT

   explain-string   = *( macro-string / SP )

   macro-string     = *( macro-expand / macro-literal )
   macro-expand     = ( "%{" macro-letter transformers *delimiter "}" )
                      / "%%" / "%_" / "%-"
   macro-literal    = %x21-24 / %x26-7E
                      ; visible characters except "%"
   macro-letter     = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
                      "c" / "r" / "t"
   transformers     = *DIGIT [ "r" ]
   delimiter        = "." / "-" / "+" / "," / "/" / "_" / "="

   name             = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )

   header-field     = "Received-SPF:" [CFWS] result FWS [comment FWS]
                      [ key-value-list ] CRLF

   result           = "Pass" / "Fail" / "SoftFail" / "Neutral" /
                      "None" / "TempError" / "PermError"

   key-value-list   = key-value-pair *( ";" [CFWS] key-value-pair )
                      [";"]

   key-value-pair   = key [CFWS] "=" ( dot-atom / quoted-string )

   key              = "client-ip" / "envelope-from" / "helo" /
                      "problem" / "receiver" / "identity" /
                       mechanism / "x-" name / name

   identity         = "mailfrom"   ; for the "MAIL FROM" identity
                      / "helo"     ; for the "HELO" identity
                      / name       ; other identities

   dot-atom         = <unquoted word as per [RFC2822]>
   quoted-string    = <quoted string as per [RFC2822]>
   comment          = <comment string as per [RFC2822]>
   CFWS             = <comment or folding white space as per [RFC2822]>
   FWS              = <folding white space as per [RFC2822]>
   CRLF             = <standard end-of-line token as per [RFC2822]>

On notera qu'ABNF ne spécifie pas la représentation sous forme de bits, mais une structure abstraite. Ce point, qui n'était pas clair dans les premières versions de la norme, et qui est souvent oublié par les utilisateurs d'ABNF, est décrit dans la section 2.4. ABNF spécifie des caractères, pas des octets, et la production :

comment-start = %3b

décrit bien le caractère point-virgule, pas forcément qu'il sera représenté par un octet de valeur numérique 3B (59 en décimal). Un encodage d'Unicode comme UTF-32, par exemple, le codera différemment

L'un des rares changements par rapport à son prédécesseur, le RFC 4234, aura été l'ajout d'un avertissement à la production LWSP (Linear White SPace, qui permet des espaces en début de ligne). Cette production, décrite dans l'appendice B, qui définit la bibliothèque standard de productions, a en effet été critiquée comme trop puissante : des auteurs de RFC l'ont utilisée sans comprendre ses conséquences. La définition comprend désormais l'avertissement suivant, qui a été négocié à la virgule près, avec acharnement : Use of this linear-white-space rule permits lines containing only white space that are no longer legal in mail headers and have caused interoperability problems in other contexts. Do not use when defining mail headers and use with caution in other contexts.

Notons qu'il n'y a pas grand'chose d'obligatoire à l'IETF. Aucune autorité ne peut dire aux auteurs de RFC « Désormais, vous êtes obligés d'utiliser ABNF ». Ceux qui le font le choi­sissent volontairement. La principale « dissidence » vient du RFC 2616, qui normalise HTTP, et qui utilise un langage différent.

Notons aussi que, bien que l'un des principaux avantages des langages formels soit la possibi­lité de vérification automatique, cette possibi­lité n'est pas utilisée systématiquement. C'est ainsi que certains RFC ont été publiés avec des bogues dans leur grammaire ABNF...

Le RFC 2234 était « Proposition de norme », le RFC 4234 était « Projet de norme ». Pour franchir l'étape supplémentaire menant au statut de « Norme » tout court, ABNF a dû subir tout un processus, mal­gré l'extrême ancienneté de cette norme. Notamment, ABNF a dû subir l'examen des programmes qui le mettent en œuvre, examen décrit en http://ietf.org/IESG/Implementations/RFC4234_implem.txt.

Le langage de filtrage du courrier électronique Sieve repose sur un socle minimum, que doivent comprendre toutes les implémentations de Sieve, et un certain nombre d'extensions, couvrant des besoins supplémentaires. Ce RFC déclare l'extension vacation, qui permet de mettre en place un répondeur automatique.

La section 4 du RFC détaille l'extension et son mode d'emploi. Comme toute extension Sieve, elle doit être introduite par un require. Elle prend comme paramètre une chaîne de caractères qui sera envoyée à l'expéditeur et diverses options comme :addresses qui indique les adresses de destinataire que le script Sieve considérera comme locales (car un répondeur automatique ne doit pas répondre à n'importe quel message, seulement ceux où son maître est listé dans les champs comme To:, cf. section 4.5). Voici un exemple :

   require "vacation";
   vacation :addresses ["stephane@bortzmeyer.org",
                        "bortzmeyer@gmail.com"]
        "Je suis parti, je lirai avec plaisir votre message plus tard.";

Comme l'avertit le RFC 3834, un répondeur automatique est un programme dangereux, et tout le monde a déjà reçu des réponses stupides, par exemple alors qu'on avait écrit à une liste de diffusion, pas directement au destinataire. Ou bien des réponses multiples alors qu'on avait déjà été prévenu. D'où la section 4.2 qui précise qu'une mise en œuvre de vacation doit se souvenir de qui a déjà été prévenu, pendant au moins sept jours (valeur modifiable par l'option :days). Cette section est très détaillée car la règle exacte est plus complexe, elle doit prendre en compte le résultat des autres tests Sieve.

La section 5 décrit le message de réponse lui-même, les en-têtes qu'il doit avoir (comme In-Reply-To, section 5.8).

Ces messages de réponse étant destinés à des humains, la question de leur internationalisation est cruciale. L'expéditeur qui écrit en zazaki à un zazakophone serait surpris de recevoir un message en anglais ! C'est l'objet de la section 7 qui précise comment utiliser les en-têtes du RFC 3282 comme Content-Language :

    if header :contains ["accept-language", "content-language"] 
              "fr"
   {
       vacation "Je ne suis pas là.";
   } else {
       vacation "I am away.";
   }

L'utilisation massive du courrier électronique fait que, même sans compter le spam, chaque utilisateur professionnel reçoit désormais des dizaines et souvent des centaines de messages quotidiens dans sa boîte aux lettres. Il n'est donc plus question de les gérer entièrement à la main, il faut disposer d'un mécanisme de filtrage automatique.

On n'imagine plus aujourd'hui d'utiliser le courrier au bureau sans un tel mécanisme, permettant de mettre les messages dans des dossiers séparés selon, par exemple, la liste de diffusion concernée. Il en existe plusieurs, certains bâtis sur une interface graphique, d'autres autour d'un langage. Ces derniers, bien plus riches et puissants, sont variés. Le plus connu est procmail, célèbre pour son pouvoir expressif (on peut tout faire en procmail) mais aussi pour sa difficulté.

Sieve, l'objet de ce RFC, est nettement moins riche que procmail, ce qui peut être un inconvénient pour les utilisateurs avancés mais un avantage pour l'administrateur : permettre aux utilisateurs de configurer procmail revient à leur donner un accès shell alors que Sieve est plus contrôlable. Comme le note bien notre RFC, Sieve n'est pas un langage de Turing (par exemple, il ne connait pas les boucles). Ses capacités sont limitées, il est sandboxable, c'est-à-dire que l'administrateur système peut facilement limiter les choses que risquent de faire les auteurs de scripts Sieve.

Autre avantage par rapport à procmail, Sieve est normalisé et il en existe plusieurs mises en œuvre, dans Cyrus, dans Dovecot, dans GNU mailutils, dans Archiveopteryx...

Les scripts Sieve sont écrits par l'utilisateur avec un éditeur ordinaire ou bien via une interface graphique. Ils sont installés sur le serveur de messagerie via FTP ou bien par le protocole spécifique Manage Sieve (actuellement à l'état d'Internet-Draft). Le programme de webmail SquirrelMail, par exemple, dispose d'une interface d'édition de scripts Sieve, qui gère le protocole Manage Sieve.

Voici un exemple de script Sieve inspiré du RFC et amélioré par Mathieu Arnold :

             if header :contains "from" "jfc" {
                discard;
             } elsif header :contains ["subject"] ["money", "viagra"] {
                discard;
             } else {
                fileinto "INBOX";
             }

Sieve lui-même est très limité mais le langage dispose d'un mécanisme d'extensions (qui doivent être déclarées dans le script avec require). Certaines sont définies dès notre RFC (comme fileinto), d'autres sont définies via d'autres RFC, par exemple pour utiliser des tests anti-spam ou antivirus (RFC 5235), ou bien pour tester sur des sous-adresses (RFC 5233).

Notre RFC est la mise à jour du RFC 3028, qui avait été le premier à normaliser Sieve. Les principaux changements (section 15) sont :

• Retrait de l'action reject, qui migrera vers un RFC séparé, pas encore publié.
• Le mécanisme de comparaison de chaînes de caractères, dans la section 2.7.3, auparavant défini spécifiquement pour Sieve, est désormais dans une famille de RFC séparée, introduite par le RFC 4790, qui décrit le registre des algorithmes de collation. Seuls les algorithmes i;octet et i;ascii-casemap sont directement dans Sieve, les autres sont des extensions (et doivent donc être déclarées avec require).
• La grammaire formelle a été corrigée. Un des traditionnels talons d'Achille des RFC est que les parties en langage formel, comme les grammaires en ABNF ou les MIB ne sont pas testées par un programme avant publication et que des RFC peuvent donc être publiés avec du code invalide. Notons aussi que notre RFC (section 8) est un des très rares RFC où les structures lexicales (les tokens) et syntaxiques sont séparées. La règle la plus fréquente dans les RFC est au contraire que la grammaire décrive les deux types de structure ensemble.

ROHC est un mécanisme de description des compressions possibles des en-têtes des paquets IP. Ce RFC décrit les profils de compression qui peuvent être utilisés pour un certain nombre des protocoles les plus courants (la définition de ROHC lui-même étant dans le RFC 4995, la section 3 de notre RFC fait quelques rappels).

Mettant à jour les RFC précédents, le RFC 3095, mais aussi les RFC 3843 et RFC 4019, ce RFC est l'état de l'art en ce qui concerne la compression d'en-têtes. La principale innovation est l'utilisation du langage formel ROHC-FN du RFC 4997 (la section 4.2 résume les principaux changements).

Le gros du RFC commence avec la section 5 qui expose les principes de chaque profil. Un canal ROHC relie un compresseur et un décompresseur. Le compresseur indique les changements par rapport aux prévisions, l'absence de changements signifiant au décompresseur qu'il peut appliquer la règle par défaut. Les systèmes de compression en réseau doivent toujours faire un compromis entre la robustesse (qui nécessite de la redondance, donc de ne pas trop comprimer) et l'efficacité (qui impose de supprimer toute la redondance). Voir par exemple la section 5.1.2, qui discute ce compromis.

Enfin, la section 6 contient les profils eux-mêmes, exprimés en partie en ROHC-FN. Cette section contient des fonctions de compression et les règles ROHC-FN qui les utilisent. Parmi les fonctions primitives, qui ne sont pas en ROHC-FN, la section 6.6.6 (fonction inferred_ip_v4_length) dit comment comprimer la champ Length d'IPv4. Étant déductible de la longueur du datagramme, il n'est pas indispensable et peut donc être comprimé à une taille de... zéro bits. La section 6.6.9 décrit une méthode bien plus complexe (fonction timer_based_lsb) pour les champs dont la valeur change approximativement en fonction linéaire du temps (elle nécessite donc que les horloges du compresseur et du décompresseur ne dérivent pas trop l'une par rapport à l'autre).

Un exemple en ROHC-FN est au contraire la définition de la fonction scaled_ts_lsb (qui sert pour RTP), qui s'exprime ainsi :

scaled_ts_lsb(time_stride_value, k)
{
  UNCOMPRESSED {
    timestamp [ 32 ];
  }

  COMPRESSED timerbased {
    ENFORCE(time_stride_value != 0);
    timestamp =:= timer_based_lsb(time_stride_value, k,
                                  ((2^k) / 2) - 1);
  }

  COMPRESSED regular {
    ENFORCE(time_stride_value == 0);
    timestamp =:= lsb(k, ((2^k) / 4) - 1);
  }
}

L'annexe A est une excellente étude des en-têtes de divers protocoles, avec une classification de leur comportement, selon qu'il permet la compression ou pas. C'est une lecture recommandée pour tous ceux qui s'intéressent à la compression d'en-têtes mais n'ont pas envie de relire le RFC original du protocole. Ils trouveront résumées de façon claire les caractéristiques de chaque champ de l'en-tête. Par exemple, pour IPv6 (annexe A.2) :

• Version is STATIC-KNOWN c'est-à-dire constante pour toute la durée du flot et à une valeur « bien connue », en l'occurrence 6.
• Hop Limit est RACH (RArely CHanging), c'est-à-dire changeant rarement (ce nombre ne bouge que lorsque les routes sont modifiées)
• Source Address est STATIC-DEF, c'est-à-dire constant pour toute la durée du flot et pouvant d'ailleurs servir à définir le flot.

Il n'existe apparemment pas d'implémentation libre de ROHC. Mais plein de déploiements sont déjà faits dans les téléphones portables. La thèse d'Ana Minaburo contient une bonne introduction à ROHC.

Le protocole HIP n'avait pas encore de mécanisme pour trouver l'identificateur d'une machine distante. C'est désormais chose faite grâce à ce RFC qui permet de trouver l'identificateur dans le DNS.

HIP fait partie de la famille des protocoles qui visent à séparer l'identificateur du localisateur. Les identificateurs HIP se nomment les HI (Host Identifier) et, jusqu'à présent, le seul moyen de trouver l'HI d'une autre machine était d'attendre qu'elle vous contacte, ou bien de le configurer manuellement. Désormais, avec ce RFC, on peut trouver l'HI, comme une adresse IP, dans le DNS.

Notre RFC crée donc un nouveau type d'enregistrement DNS, nommé logiquement HIP, qui stocke, en échange d'un nom de domaine, le HI, son résumé cryptographique - le HIT (Host Identifier Tag) - et les éventuels serveurs de rendez-vous, serveurs qui, dans le protocole HIP, servent d'intermédiaires facultatifs lorsqu'on veut contacter une machine distante (cf. RFC 5204).

Notre RFC permet de trouver l'identificateur à partir du nom mais pas le localisateur ; les serveurs de rendez-vous sont une solution possible pour cela ; une autre est d'utiliser les traditionnels enregistrements A et AAAA du DNS, le localisateur HIP étant une adresse IP.

Curieusement (pour moi), le HIT est donc stocké dans les données DNS, alors que celles-ci n'offrent aucune sécurité au point que le RFC exige en section 4.1 de recalculer le HIT qui vient d'être obtenu dans le DNS.

Le tout ressemble donc aux enregistrements IPSECKEY du RFC 4025, ce qui est normal, le HI étant une clé cryptographique publique.

Voici un exemple d'enregistrement HIP tel qu'il apparaitrait dans le fichier de zone de BIND. On y trouve l'algorithme cryptographique utilisé (2 = DSA), le HIT (en hexadécimal), le HI (encodé en Base64) et les éventuels serveurs de rendez-vous (ici, deux, indiqués à la fin) :

www.example.com.      IN  HIP ( 2 200100107B1A74DF365639CC39F1D578
                                AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p
9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ
b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D
                                rvs1.example.com.
                                rvs2.example.com. )

L'ensemble du RFC est assez court, ce mécanisme d'annuaire qu'est le DNS étant simple et bien connu.

HIP, par défaut, nécessite que l'initiateur d'une association connaisse le localisateur, l'adresse IP du répondeur. Si celui-ci bouge souvent, et qu'il n'est donc pas pratique de mettre cette adresse dans le DNS, une solution est d'utiliser le mécanisme de rendez-vous, décrit par ce RFC, où l'initiateur contacte un serveur de rendez-vous qui relaie vers le répondeur.

Le schéma est clairement expliqué dans la section 3 du RFC. En fonctionnement habituel de HIP, l'initiateur trouve l'identificateur et le localisateur du répondeur (typiquement, dans le DNS, cf. RFC 5205), puis le contacte directement. Si le localisateur n'est pas connu (ce qui est fréquent si le répondeur est un engin mobile, changeant souvent d'adresse IP), l'initiateur envoie le premier paquet (I1) au serveur de rendez-vous, qui le relaie au répondeur. Les autres paquets (R1, I2 et R2) seront transmis directement entre les deux machines HIP. Le mécanisme est détaillé dans la section 3.3 (il faut notamment procéder avec soin à la réécriture des adresses IP, en raison entre autre du RFC 2827).

Et comment l'initiateur trouve t-il le serveur de rendez-vous ? En général dans le DNS, via les enregistrements de type HIP. Et comment le répondeur avait-il fait connaitre au serveur de rendez-vous son adresse IP ? Via le protocole d'enregistrement du RFC 5203, comme l'explique la section 4.

HIP, décrit dans ce RFC, est un protocole très ambitieux, puisqu'il vise à compléter IP en fournissant une séparation de l'identificateur et du localisateur, permettant d'améliorer la sécurité (notamment la résistance aux DoS) et de mieux gérer la mobilité et le multi-homing.

L'architecture générale de HIP est décrite dans le RFC 4423. Notre RFC normalise, lui, le protocole concret. HIP repose d'abord sur la séparation entre un nouvel identificateur, le HI (Host Identifier) et un localisateur, plus concret, qui sera simplement l'adresse IP, réduite à un rôle moins visible, sans exigence de stabilité. Par exemple, HIP permettra le changement de localisateur (d'adresse IP) en cours de connexion, sans rompre celle-ci, ce qui sera précieux pour la mobilité.

HIP est donc déployable uniquement en modifiant les machines terminales du réseau (si les coupe-feux le laissent passer), sans toucher aux routeurs . Il en existe des mises en œuvres pour FreeBSD et Linux. Le projet OpenHIP adapte également des logiciels comme Wireshark pour qu'ils aient un support HIP. InfraHIP travaille également à l'infrastructure HIP. L'article HIP Implementation for FreeBSD donne des détails intéressants sur la mise en œuvre de HIP, notamment sur les questions liées à l'API.

Si on ne veut pas lire le RFC 4423, on peut néanmoins avoir une bonne introduction à HIP en lisant les sections 1 et 2 de ce RFC. Elles expliquent le vocabulaire (par exemple, HIP, étant un protocole situé en haut de la couche 3 n'utilise pas le terme de connexion mais celui d'association), le nouvel espace de nommage et les principes du protocole.

L'espace de nommage fait l'objet de la section 3. On distingue les HI (Host Identifier), qui sont des clés publiques d'un couple clé privée / clé publique et qui sont de taille variable, et les HIT (Host Identifier Tag, décrits dans la section 3.1), qui sont un résumé cryptographique des HI. Ils sont de taille fixe (donc plus faciles à traiter), 128 bits, la taille d'une adresse IPv6. Un préfixe ORCHID (RFC 4843), le 2001:10::/28, sert à éviter toute collision avec les « vraies » adresses IPv6. Avec OpenHIP, la clé peut être générée par le programme hitgen qui fabrique un fichier XML ressemblant à ceci :

<?xml version="1.0" encoding="UTF-8"?>
<my_host_identities>
  <host_identity alg="RSA" alg_id="5" length="128" anon="no" incoming="yes" r1count="10">
    <name>horcrux-1024</name>
    <N>C6EBA2894C33A1312B38853A8ECC0D7967496237A65529807EDF23C4DA753EE88F8FBF71BE38B6910181D5B75DB075B9962326D9BB50C65121DBFD712F1B7F4E2B035953AD650EB5C96B56295FE2731B3B36E8AFED7FB5CD48B73C31A224D4CE4F097D84888EC2E3CA8F3A78939D89B7BCFC5E6DEEAF670695349BFFFE8445F1</N>
    <E>010001</E>
    <D>383A51165838DBDE872611DACC94775692D09677BE87A214954843D7181D3E2C04B0905FF9721481069909AD2C497DED78B7F4FA64CD5F517DADAE8538D89FF21B0498A72F1132545328ABD371B1BAC8ED46441D900921523B78BA55F3FC227F432F2061C92CE9665CB99C1CF425AA90CFC6345FA4E7DA43E477EAF69F86A801</D>
    <P>FF03F93454C9C2D8EC47FE8C9DBF0D82F05E13905F304A5ACA42C45E579F917B4C8CEFEF6B06AAB9BCB7A911D5514B7AEE685DA91E7CC60DDC4C37BA94A22E71</P>
    <Q>C7B0394EB5506B2B75E19E5654262E843659BB76A465C2A7AC47A430749944378E3161FF805B4C6CB037B5CB111F0EF49FF03047FB1CFC51DC0D72DEDAD64F81</Q>
    <dmp1>7426C128DEBD8EEBF2A2D004080D6F0006AF32C5FD352788B6BB3669AA0B59DE08FDE082F202755C67E25735722DB6ED650D502BA961376C34BCDA5D3739AF61</dmp1>
    <dmq1>1B97DE5361FA9AD4869586ABA7351F78658A40BD443A4B8B9FE2C66D6BAF421DEB2827C2869A17156DC444FAAA83002E0D6BC3402F12F24ADD7D7E420D3B5001</dmq1>
    <iqmp>7499A27F59CA1746F1A6E5DE832592F8ACF80B814DD511C490614C44DC92B5CD1650AC944ED5751F28846487C221E8C17E68264DFEF748B86E38EB1F238D94A9</iqmp>
    <HIT>2001:1f:cd4:7125:2427:f77c:d1b6:e15f</HIT>
    <LSI>1.182.225.95</LSI>
  </host_identity>
</my_host_identities>

Notez bien que le fait d'utiliser XML est un choix de OpenHIP, qui n'est utilisé qu'en local. Il n'est pas imposé par la norme qui, sur le câble, n'utilise que du binaire. Les éléments comme P, Q ou iqmp sont les éléments d'une clé RSA (HIP peut utiliser d'autres formats que RSA). Le HIT est représenté en utilisant la syntaxe des adresses IPv6, puisqu'il a la même taille et a été conçu pour être stocké comme une adresse par les applications.

La section 3.2 explique comment générer un HIT à partir du HI. Étant un résumé cryptographique (fait avec SHA-1), il est sûr, on ne peut pas fabriquer facilement un HI qui aurait le même HIT.

Pour signer les paquets, les deux machines utiliseront au début un échange de Diffie-Hellman.

La section 4 donne une vision générale du protocole, qui sera ensuite détaillée dans les sections ultérieures. HIP a reçu le numéro de protocole 139.

La section 4.1 décrit comment former une association entre deux machines HIP. Celle qui demande l'association est nommée l'initiateur, celle qui l'accepte le répondeur. Le protocole d'association nécessite quatre paquets. En effet, avec seulement trois paquets, comme le fait TCP (RFC 793) lors de l'établissement d'une connexion (Three-way handshake), on ne peut pas à la fois se protéger contre les DoS et permettre des options par connexion. Se protéger contre les DoS nécessite de ne pas garder d'état tant que le pair n'est pas authentifié, même faiblement. Les techniques qui permettent à TCP de ne pas garder d'état sur le « répondeur », telles que les SYN cookies du RFC 4987 sont incompatibles avec les options TCP.

Voici pourquoi les protocoles plus récents comme SCTP (RFC 3286) ou comme HIP nécessitent quatre paquets.

Dans HIP, ils sont nommés I1, R1, I2 et R2. Les paquets I sont envoyés par l'initiateur et les paquets R par le répondeur.

L'établissement d'une association se passe donc comme ceci :

• L'initiateur envoie I1 au répondeur. Le paquet contient l'identificateur (le HIT) du répondeur et (optionnellement) celui de l'initiateur. Aucun état n'est créé chez le répondeur.
• Le répondeur envoie R1. Ce paquet contient un puzzle cryptographique que l'initiateur devra résoudre. Il contient également les paramètres de la session Diffie-Hellman. Et ce paquet est signé.
• L'initiateur envoie I2, qui contient la solution du puzzle. les paramètres Diffie-Hellman de l'initiateur. Ce paquet est signé.
• Le répondeur envoie R2 pour accepter l'association. Ce paquet est signé.

Le puzzle, détaillé en section 4.1.1, est un petit problème de calcul que l'initiateur doit résoudre pour montrer qu'il est près à « payer », à faire un effort pour que l'association soit acceptée. La difficulté du puzzle peut être réglée par le répondeur. En pratique, il est très difficile d'imaginer un puzzle qui soit dissuasif contre des attaquants disposant d'un botnet entier, tout en étant soluble par des appareils simples, genre téléphone portable, ne possédant guère de puissance de calcul. (La section 4.1.1 détaille ce problème et les solutions possibles.)

La section 4.1.3 détaille l'utilisation du Diffie-Hellman.

Une des grandes forces de HIP est la possibilité de mettre à jour une association existante (section 4.2). À tout moment, pendant la session, un paquet de type UPDATE peut être envoyé pour changer certains paramètres de la session, comme les localisateurs (les adresses IP) utilisées. La signature des paquets permet de s'assurer que le paquet UPDATE est authentique.

La section 5 est longue car elle détaille le format, bit par bit, de tous les paquets échangés. Il y a huit types de paquets (section 5.3) comme I1, R1, I2, R2 ou comme UPDATE, présenté plus haut.

Enfin, la section 6 détaille le traitement des paquets, ce qu'il faut faire en les recevant, les erreurs et la façon de les gérer (règle simple : ne pas renvoyer de paquets HIP en cas d'anomalie, seulement des ICMP, et avec un débit limité, car on ne peut pas être sûr du pair s'il y a une erreur), etc.

Il ne reste plus beaucoup de normes Internet qui soient limitées à l'ASCII et elles tombent une à une. Un des problèmes rencontrés pour éliminer les dernières est que certains protocoles transmettent du texte et que « texte », à l'IETF, voulait toujours dire seulement ASCII. Voici que ce RFC introduit un nouveau type de texte, utilisant Unicode.

Pendant longtemps, plusieurs normes comme le RFC 959 sur FTP faisaient référence à des données de type texte, c'est-à-dire sans formatage, avec des lignes terminées par la séquence CRLF (Carriage Return puis Line Feed). Cette définition du texte, souvent nommé « NVT », datant du RFC 854, limitait le texte au jeu de caractères ASCII, jeu de caractères qui ne permet pas de représenter toutes les écritures du monde. Où est le problème ? peut-on se demander. Pourquoi ne pas simplement remplacer ASCII par Unicode partout dans le texte ? C'est en effet la bonne solution mais le diable est dans les détails et, Unicode étant beaucoup plus riche qu'ASCII et n'étant pas figé, traiter ces détails a pris du temps. (Et ce RFC a fait l'objet de nombreuses controverses.) Unicode a plusieurs encodages, plusieurs façons de représenter une fin de ligne et même plusieurs façons de représenter le même caractère.

Le RFC pose donc comme règles (section 2) :

• Jeu de caractères Unicode.
• Utilisation de l'encodage UTF-8, normalisé dans le RFC 3629.
• Normalisation obligatoire avec le mécanisme NFC, qui combine le plus possible les caractères.
• Utilisation de la séquence CRLF pour les sauts de ligne.

Le choix d'UTF-8 provient de sa large utilisation dans beaucoup de protocoles Internet, due en partie au fait qu'il est un sur-ensemble de l'encodage ASCII.

Le choix du CRLF comme indicateur d'une fin de ligne est également dû à sa large utilisation aujourd'hui. Bien qu'Unicode aie des caractères plus adaptés (Line separator, U+0028 et Paragraph separator, U+0029), ils sont très peu utilisés. La passionnante annexe C discute en détail ce choix.

La normalisation fait l'objet d'une section 3 détaillée. Elle est nécessaire car Unicode permet de représenter un caractère de plusieurs façons. Ainsi, U+2126, Ohm sign, Ω, a une forme canonique qui est U+03A9, Greek capital letter omega , Ω, (les symboles scientifiques ne sont normalement pas codés séparément dans Unicode et ceux qui le sont sont normalisés dans une lettre ordinaire). Cas plus connu, deux caractères peuvent se combiner par exemple U+0061 U+0300 se combinent, par le mécanisme NFC, en U+00E0 (la première séquence est faite d'un petit a et de l'accent grave combinant, la seconde est donc juste un à). L'obligation de normalisation rendra donc plus facile la comparaison des textes (la section 6 sur la sécurité note toutefois que le pare-feu prudent ne doit pas supposer que l'envoyeur respectera la norme).

La section 4 couvre un autre problème délicat, celui des versions d'Unicode. Contrairement à ASCII, qui était figé dès le début, des nouveaux caractères sont ajoutés dans Unicode régulièrement, ainsi que de nouvelles règles de normalisation. Si on ne fait pas attention, une nouvelle version d'Unicode pourrait rendre invalides (car non normalisés) des textes auparavant valables. Pour éviter cela, notre RFC interdit l'utilisation des points de code non affectés. Les politiques de stabilité du consortium Unicode garantissent que, dans ce cas, la normalisation NFC est stable (la section 5.2 discute également ce choix).

La section 5 explique quelles normes pourrait tirer profit de ce nouveau RFC. Celles qui utilisent déjà UTF-8, comme LDAP, ne sont pas concernées. Mais, outre FTP, déjà cité, cette nouvelle référence pourrait intéresser des protocoles comme whois (dont le RFC 3912 note que, en théorie, il est limité à ASCII).

Cas rare chez les RFC, il se termine par des annexes traitant d'histoire. L'excellente annexe A revient sur l'histoire tourmentée des jeux de caractères dans Internet, du RFC 20, qui imposera ASCII, au RFC 318 qui sera le premier à mentionner le « NVT » (Network Virtual Terminal). L'annexe B, elle, extrait de différents RFC, ce qui est à ce jour la définition la plus complète et la plus correcte de la norme NVT... que notre RFC remplace. Bel hommage du présent au passé.

Appliquant le cahier des charges qui avait été défini dans le RFC 4058, le protocole PANA vient d'être normalisé dans le RFC 5191 et notre RFC accompagne cette spécification, pour décrire les caractéristiques de haut niveau du protocole.

PANA sert à transporter un protocole d'authentification, typiquement EAP (RFC 3748), entre une machine qui veut accéder à un réseau (la PaC, PANA Client) et une machine d'authentification, le PAA (PANA Authentication Agent). (Ces rôles sont expliqués dans la section 2 du RFC, la section 3 détaillant les différentes communications entre eux.) Après le succès de l'authentification, le PAA indiquera à l'EP (Enforcement Point, typiquement un routeur ou un commutateur) qu'il peut laisser passer le trafic du client, du PaC.

Ces rôles peuvent être situés sur des machines différentes ou pas. Par exemple, en ADSL, le PAA et l'EP seront typiquement situés dans le même BRAS. Le protocole PANA ne spécifie que la communication entre le PaC et le PAA.

À noter que, pour prendre sa décision, le PAA pourra être lui-même client d'un protocole d'AAA comme Radius (RFC 2865) ou Diameter.

PANA a été conçu pour s'adapter à des environnements très différents, notamment du point de vue de la sécurité (section 4 du RFC). Par exemple, il peut y avoir un canal sûr entre le PaC et le PAA, avant même que PANA ne tourne ou pas. S'il existe un tel canal sûr (cas du WiFi avec WPA ou bien cas où la liaison physique entre le PaC et le PAA est considérée comme sûre), PANA est très simple. Dans le cas contraire, il est important d'utiliser des méthodes EAP résistantes à l'espionnage ou à la modification des paquets.

Régulièrement, un nouveau RFC vient enrichir la grande famille des URN (RFC 2141 et RFC 3406, qui décrit les règles d'enregistrement), ces identificateurs prévus pour être stables et pérennes. Cette fois, les URN ogc viennent s'ajouter, pour stocker les normes et schémas de l'Open Geospatial Consortium.

Ce consortium produit des normes utilisés dans le monde de la géographie comme le format GML et qui servent à communiquer des informations spatiales, utilisées dans de nombreux secteurs (sections 1 et 5 du RFC).

Les URN de l'OGC utiliseront le NID (Namespace IDentifier) ogc. Ce NID sera suivi d'un type de ressource et des coordonnées de la ressources (section 2). L'OGC mettra en place un résolveur permettant de transformer ces URN en URI, à l'adresse http://urn.opengis.net/. Le reste de la section décrit les procédures de l'OGC, notamment pour garantir l'unicité de ces URN.

Un exemple des nouveaux URN (section 3) est urn:ogc:specification:gml:doc-is(02-023r4):3.0.0 qui identifiera une version particulière de la norme GML (d'où l'utilisation de la ressource « specification »).

Un certain nombre de préfixes IPv6 ont une signification spéciale et ce RFC les documente, pour éviter aux lecteurs de devoir fouiller dans les nombreux RFC originaux.

Normalement, les préfixes des réseaux IPv6 sont attribués par l'IANA aux RIR qui les allouent ensuite aux LIR (qui sont en général des FAI). Ces allocations et les affectations aux utilisateurs finaux sont enregistrées par les RIR et sont publiquement accessibles via des protocoles comme whois.

Mais certains préfixes sont spéciaux et échappent à ce mécanisme. Ils ont été réservés par tel ou tel RFC et sont donc dispersés à plusieurs endroits. Notre RFC, écrit par l'IANA, rassemble toutes ces réservations en un seul endroit. (Il existe un RFC équivalent pour IPv4, le RFC 3330.)

Voici quelques exemples de préfixes ainsi documentés :

• 2001:DB8::/32 (section 2.6), réservé pour la documentation par le RFC 3849 (par exemple pour rédiger des manuels, sans craindre que les adresses IP d'exemple soient utilisées),
• FE80::/10, réservé pour les adresses locales au lien par le RFC 4291,
• 2001:10::/28, réservé pour créer des identificateurs (et non de simples adresses) sous le nom d'ORCHID (RFC 4843),
• Et bien d'autres, énumérés dans la section 2. Par contre, on ne trouvera pas les adresses site-local, FEC0::/10, celles-ci ayant été abandonnées par le RFC 3879.

L'enregistrement NSEC3 permet de résoudre un problème agaçant de DNSSEC, le fait que ce dernier permette l'enumération de tous les noms de domaine d'une zone signée. NSEC3 permet donc d'établir la non-existence d'un domaine sans rien révéler sur les autres domaines.

DNSSEC (RFC 4033) authentifie les enregistrements DNS en ajoutant un enregistrement RRSIG (RFC 4034) qui contient une signature des enregistrements qu'on veut authentifier. Le problème est que, si le nom de domaine demandé n'existe pas (réponse NXDOMAIN pour No Such Domain), il n'y a pas d'enregistrement à signer. Ce problème est connu sous le nom de preuve de non-existence et c'est un des points les plus difficiles de DNSSEC (section 5.4 du RFC 4035). Le RFC 4034, section 4, le traitait en introduisant un enregistrement NSEC, signé par un RRSIG, qui indiquait le domaine suivant celui demandé. En vérifiant que ce domaine suivant était bien situé après celui demandé (et que le domaine demandé était situé après le nom en partie gauche du NSEC), le résolveur pouvait être sûr de la non-existence du nom qu'il avait demandé.

Mais le gros problème de NSEC est qu'il permet l'énumération. Une fois qu'on a découvert le nom de domaine suivant, on peut passer au suivant, puis à celui d'après et ainsi de suite, on a récupéré toute la zone, même si son administrateur ne le voulait pas.

Le registre de .uk, Nominet, a clairement indiqué que c'était inacceptable pour eux et qu'ils ne déploieraient pas DNSSEC sans une solution à ce problème politico-légal.

Le nouvel enregistrement NSEC3 résoud le problème en ne donnant pas le nom du domaine suivant mais son résumé cryptographique, son empreinte.

Le principe de NSEC 3 est le suivant. Les résumés de tous les noms sont classés par ordre alphabétique (c'est arbitraire, l'important est que cela soit reproductible). La partie gauche (owner name) de l'enregistrement NSEC3 n'est pas un nom de domaine mais un résumé. Idem pour la partie droite.

L'enregistrement contient aussi quelques autres paramètres comme l'algorithme de calcul du résumé (section 3.1.1, les sections suivantes décrivant les autres paramètres). Voici un enregistrement NSEC3 au format suggéré section 3.3 :

2t7b4g4vsa5smi47k61mv5bv1a22bojr.example.              NSEC3   1 1 12 aabbccdd (
                          2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )

Le résolveur qui reçoit un NXDOMAIN peut calculer le résumé du nom qu'il a demandé (la méthode de calcul est détaillée en section 5) et, si l'enregistrement NSEC3 est correct, ce résumé doit tomber entre les deux résumés du NSEC3 (celui de gauche et celui de droite). Ainsi, si la question est le nom D1, et que le résolveur reçoit :

... NXDOMAIN
H0     NSEC3   H2 ...
H0     RRSIG   ...

il doit calculer H1, le résumé de D1 et vérifier que H0 < H1 < H2 (et naturellement vérifier le RRSIG, la signature). Ne connaissant que H0 et H2, il ne peut pas retrouver D0 et D2. Notez bien que l'ordre ne concerne que H0, H1 et H2, D0, D1 et D2 sont situés dans un ordre complètement différent. Comme avec NSEC, tout repose sur l'existence d'un ordre des éléments sauf que, avec NSEC3, ce sont les résumés cryptographiques qui sont ordonnés.

NSEC3 contient plein d'autres fonctions intéressantes, par exemple la section 6 décrit un mécanisme de retrait (opt-out) permettant aux enregistrement NSEC3 de « sauter » par dessus les zones non signées (dans un TLD, comme .se, il est clair que la majorité des zones ne seront pas signées, au moins au début).

Les détails sont très complexes (et couverts dans les sections 7 et 8 du RFC) ce qui explique que certains auteurs de logiciels DNS comme Bert Hubert, auteur de PowerDNS, aient estimé qu'il serait difficile de faire du NSEC3 en pratique (voir aussi son bon article sur DNSSEC).

Mais NSEC3 est aujourd'hui mis en œuvre dans plusieurs logiciels comme BIND, NSD ou le résolveur UNBOUND. NSEC3 sera probablement plus complexe et plus lent que NSEC mais c'est le prix à payer pour garder le contrôle de ses données.

Merci à Kim Minh Kaplan pour son aide à m'aider à comprendre ce difficile protocole et pour sa relecture.

Les URI disposent depuis longtemps d'un moyen de désigner une partie d'un document, par les biais des « identificateurs de fragments », précédés d'un dièse, comme par exemple http://www.example.org/foobar.html#section3. Entièrement interprétés par le client Web, ces identificateurs étaient définis seulement pour XML et HTML et notre RFC ajoute le texte brut.

La façon classique d'utiliser ces identificateurs est de modifier le document cible pour y ajouter un élément à viser, par exemple :

<p id="avertissement-sante">Fumer est dangereux pour la santé.</p>

fera qu'un navigateur pourra, lorsqu'on lui demandera http://www.example.org/document.html#avertissement-sante, aller directement à ce paragraphe. On peut aussi utiliser, au lieu d'un simple nom comme avertissement-sante, utiliser une expression XPath, si le navigateur accepte XPointer. En outre, avec XLink, on peut même pointer vers un document qu'on ne peut ou ne veut modifier, ce qui évite de devoir ajouter des attributs id ou name.

Le texte brut (normalisé dans MIME par le RFC 2046) n'étant pas, lui, structuré, on ne pouvait pas compter sur des « marques » particulières. D'où le choix de notre RFC de compter les caractères ou bien les lignes.

C'est ainsi que les URI de ce RFC ressembleront à http://library.example/2007/11/5311.txt#char=6234 (le curseur du navigateur ira sur le 6234ème caractère) ou bien http://library.example/2004/03/228.txt#line=534,580 (le navigateur affichera le texte compris entre la 534ème ligne et la 580ème).

Mais les documents accessibles sur le Web tendent à changer. De tels identificateurs de fragments sont clairement moins robustes que ceux utilisant un attribut du document XML (comme avertissement-sante plus haut), ou bien que ceux utilisant une expression XPath. Comment détecter le cas où un paragraphe a été ajouté, faussant ainsi les liens ? Cette norme permet d'ajouter à l'URI un mécanisme de contrôle d'intégrité, en indiquant la longueur ou bien la somme de contrôle MD5 (RFC 1321) du document. Si elles ne correspondent pas, le navigateur sait qu'il ne doit pas utiliser l'identificateur de fragment. Ainsi, http://www.myblog.example/2006-12/mespensees.php#line=50;length=19576,UTF-8 amènera le navigateur à compter le nombre de caractères du document et à ignorer l'identificateur de fragment s'il ne trouve pas 19576 caractères.

Notre RFC doit aussi traiter des problèmes plus subtils comme la façon de compter les fins de ligne du document (il existe plusieurs façons de les représenter, et la norme décide qu'une fin de ligne compte toujours pour un caractère).

Un autre problème subtil est la nécessité de tenir compte de l'encodage des caractères. En effet, char= compte bien le nombre de caractères, pas le nombre d'octets.

Deux implémentations existent, une dans Amaya et une en Python, incomplète mais quand même utile: TextFrag.py.

À noter aussi une présentation par un des auteurs et un amusant et intéressant article de Tim Bray, Matthew-6:9.txt#line=,1.

Notre RFC propose un profil d'IRIS pour répondre à une question simple : ce domaine est-il libre ou pas ?

Aujourd'hui, l'enregistrement d'un nom de domaine commence souvent par une recherche de sa disponibilité. L'utilisateur final va sur le site Web du registrar de son choix, tape le nom convoité, le registrar interroge le registre et renvoie la réponse à l'utilisateur. Mais comment le registrar contacte t-il le registre ? Il existe une solution à moitié standard, le protocole whois (RFC 3912). En analysant le résultat de la requête, on peut trouver si le domaine est libre (ici, avec .fr) :

% whois vraimentnimportequoi.fr 
...
domain:      vraimentnimportequoi.fr
status:      AVAILABLE

whois a quelques défauts. Le format de sortie n'est pas normalisé, donc il faut trouver une expression indiquant la disponibilité, et la trouver pour chaque registre. Ce manque de normalisation est encore plus gênant si le domaine n'est pas libre et qu'on veut trouver pourquoi. Est-il déjà réservé ? Est-ce un terme interdit ? Ensuite, whois nécessite un traitement assez importante du côté du serveur, puisqu'il doit extraire de la base de données du registre beaucoup d'informations, beaucoup plus que ce qu'on désirerait pour simplement connaitre la disponibilité d'un domaine.

Cette lourdeur des traitements d'un serveur whois fait que les registres mettent en général en place des limitations strictes à son usage, par exemple en limitant le rythme d'accès.

Quelles sont les solutions propres, donc ? Pour le cas des registrars, les registres proposent en général des outils spécifiques comme un service EPP, dont la commande <epp:check> permet de récupérer des informations utiles (section 2.9.2.1 du RFC 4930). Souvent, ces outils utilisent un protocole privé, par exemple, pour .fr, ce programme Python utilisant SOAP trouve la disponibilité d'un domaine :

import SOAPpy # In some versions, a bug prevents authentication, you have to
# add "import base64" yourself
import sys, os, string

SOAPpy.Config.debug = False
hostname = "XXXXXX.nic.fr"
path = ""
user = "REGISTRAR-NAME"
password = "REGISTRAR-PASSWORD"
namespace = 'http://soap.nic.fr/Domain'
action = 'check_domain'

if len(sys.argv) > 1:
    domain = string.lower(sys.argv[1])
else:
    print "Usage: %s domain-name" % sys.argv[0]
    sys.exit(1)

server = SOAPpy.SOAPProxy("https://%s:%s@%s/%s" %
                          (user, password, hostname, path),
                          namespace=namespace,
                          soapaction = namespace + '#' + action)

domain_reply = server.check_domain (domain);
if domain_reply["free"]:
    print "%s is available" % domain
else:
    print "%s is NOT available because \"%s\" (%s)" % (domain,
                                                       domain_reply["message"],
                                                       domain_reply["reason"])

Mais, si on n'est pas registrar ? Quelles sont les solutions pour le public, surtout s'il veut pouvoir effectuer un grand nombre de requêtes, à des fins plus ou moins légitimes ?

Une première solution est de proposer une version réduite de whois. C'est ce que fait .nl, avec l'option is :

% whois "is amsterdam.nl"     
amsterdam.nl is active
% whois "is certainlynonexistent.nl"
certainlynonexistent.nl is free

Ne fournissant qu'une information limitée, ce service charge moins le serveur et est donc disponible avec des limites plus larges.

Et enfin, une autre solution fait l'objet de ce RFC 5144 : utiliser le protocole IRIS (RFC 3981) et un sous-ensemble de son schéma de données pour les domaines, DREG, au dessus d'un transport le plus léger possible. DCHK est donc un sous-ensemble de DREG (RFC 3982), limité à quelques informations, la disponibilité, bien sûr, mais aussi la date d'enregistrement, le statut, etc. Voici un exemple de réponse à une requête DHCK (ici, le domaine n'est pas libre) :

 <domain>
     <domainName>example.org</domainName>
     <status><active/></status>
 </domain> 

Le registre qui déploie DCHK le rendra typiquement plus accessible (limites moins strictes) que son service IRIS/DREG complet ou bien que son service whois.

Le protocole de transport recommandé, section 3.3, pour sa légèreté, est LWZ (RFC 4993), basé sur UDP.

Denic annoncé la disponibilité de ce service, cf. http://www.ietf.org/mail-archive/web/crisp/current/msg00475.html.

Un nouveau venu dans la famille des NID (Namespace identifier), les autorités qui gèrent un groupe d'URN, l'ISO, organisme international de normalisation, qui pourra ainsi enfin donner à ses textes, notamment aux normes, un identifiant unique et automatiquement analysable.

La section 1 du RFC présente l'ISO et ses procédures. Cette présentation est un peu idéalisée et oublie de signaler que l'ISO est renommée pour sa fermeture. Il est difficile d'en faire partie (l'ISO est une fédération d'organismes nationaux comme l'AFNOR en France, eux-mêmes en général tout aussi fermés), les processus sont compliqués et sans transparence.

Les normes produites ne sont pas distribuées sur Internet, sauf exceptions. Cette mentalité a beaucoup contribué à l'échec des protocoles OSI par rapport à ceux de l'Internet, normalisés dans des RFC librement accessibles. Outre les exceptions citées plus haut, parfois, les auteurs ou les agences de maintenance de la norme distribuent une version non officielle de la norme à partir de leur site (par exemple, Schematron, norme n° 19757 , est distribuée par son auteur en http://www.schematron.com/spec.html.) La section 4 du RFC parle entre autres de cette question, en faisant porter la responsabilité de cet état de fait sur les organisations membres de l'ISO ou associées, tout en prétendant que la disponibilité de la norme n'est finalement pas une question si importante (« Only the product engineer or software tool builder actually needs access to the text »).

Comme le détaille cette section, le vote à l'ISO est par pays. Ce ne sont pas les participants aux groupes de travail (souvent de vrais experts, comme cela a été le cas pour le groupe qui a donné à RelaxNG le statut de norme ISO) qui votent mais les représentants officiels de chaque pays. Ces votes étant non publics, le citoyen français n'a aucun moyen de savoir ce qu'a voté son pays. Par exemple, la rumeur dit que la France avait voté NON à ISO 639-3 mais on ne peut pas le vérifier, les votes n'étant pas connus.

Le cahier des charges de ces identificateurs ISO apparait dans l'excellente section 3 du RFC. Il s'agit d'avoir des identificateurs uniques, stables dans le temps, lisibles par des humains (d'autres critères figurent dans cette section). Chacun de ces choix est justifié en détail et on ne peut que recommander la lecture de cette section à tous ceux qui travaillent sur un projet de famille d'identificateurs. L'annexe A contient un examen d'autres identificateurs qui avaient été envisagés et rejetés, comme les OID du RFC 3061.

Avec la section 2 commence la description de ce nouveau groupe d'URN (RFC 2141). Le NID (Namespace Identifier) sera iso et le reste de l'URN identifiera le texte (pas forcément une norme), son statut, l'édition actuelle, la langue, etc.

Par exemple, la norme C, d'origine ANSI (l'ANSI est le membre états-unien de l'ISO), développée avec l'IEC et portant le n° 9899, seconde édition, en anglais, sera urn:iso:std:iso-iec:9899:ed-2:en (elle n'est apparemment pas disponible en ligne mais on peut la trouver sur eDonkey sous le nom ISO-C99-final-ISO9899-ed2.pdf). La norme ISO 15924 sur les écritures pourrait, elle, se noter urn:iso:std:iso:15924:en,fr (on notera qu'elle est disponible en deux langues, français et anglais et elle fait partie des normes distribuées par son agence de maintenance, le consortium Unicode).

La section 2.8 décrit une correspondance entre ces URN et des URI http, ce qui permettrait de résoudre les URN, grâce à une passerelle que l'ISO envisage de déployer (apparemment, elle n'est pas encore en service). (Cela ne veut pas dire qu'on aura accès à la norme, mais seulement aux méta-données sur celle-ci.) Ainsi, la norme « Codes de représentation des sexes humains » (1 pour les hommes et 2 pour les femmes) dont l'URN serait urn:iso:std:iso-iec:5218:ed-1:en,fr aurait un URL de http://standards.iso.org/iso-iec/5218/ed-1/en,fr.

Idéalement, aujourd'hui, tous les protocoles Internet devraient être complètement internationalisés et notamment devraient accepter que les données soient exprimées dans un des encodages classiques d'Unicode, comme UTF-8. Mais ce n'est pas encore le cas. Ce RFC propose une approche pour utiliser des caractères Unicode dans les derniers protocoles dinosauriens qui n'acceptent normalement que l'ASCII.

La section 1.1 explique bien que ce RFC ne s'applique pas aux protocoles qui acceptent déjà un ou plusieurs encodages Unicode, ce qu'ils feront tous dans le futur, espérons-le. Mais, en attendant ce jour, ce RFC s'applique aux vieux protocoles. Actuellement, ceux-ci acceptent presque tous une forme d'échappement qui leur permet de transporter plus ou moins d'Unicode. L'idée est de mettre un peu d'ordre dans ces formes, sans aller jusqu'à les standardiser complètement (ce que tentaient de faire les premières versions de l'Internet-Draft qui a donné naissance à ce RFC).

Le cas de textes parlant de caractères Unicode (« Les citations en français doivent commencer par un demi-cadratin, le U+2013 ») n'est pas non plus couvert : de tels textes, conçus pour les humains et non pour les programmes, doivent utiliser la notation Unicode traditionnelle U+nnnn comme ci-dessus (section 3).

Notre RFC recommande donc finalement deux formes pour les caractères Unicode dans les fichiers conçus pour être lus par des programmes. En prenant l'exemple du И cyrillique (U+0418, grand I), les deux formes recommandées sont :

• \u'0418' (section 5.1), une forme qui a été conçue spécialement pour ce RFC,
• И (section 5.2), la forme traditionnelles de XML et HTML.

Pourquoi ces deux formes ? Comme l'explique la section 2, il existe de nombreuses solutions. Un premier principe qui a guidé celle choisie est qu'il fallait encoder des points de code Unicode (les index dans la table Unicode comme le 418 hexadécimal ci-dessus) et surtout pas des octets d'un encodage particulier comme le font, malheureusement, les URI (section 2.1 du RFC 3986).

Un deuxième principe est d'utiliser des délimiteurs explicites, pour éviter toute ambiguïté, sans forcer les caractères à être représentés par un nombre fixe de chiffres (section 4).

Plusieurs formes couramment recontrées dans la nature sont discutées dans le RFC et rejetées (section 6 et annexe A) :

• Celle de Java, \u0418 qui viole le premier principe (c'est un sur-encodage d'UTF-16, ce qui n'est pas gênant pour notre grand I cyrillique, qui fait partie du Plan Multilingue de Base d'Unicode, mais complique les choses pour les caractères en dehors de ce plan),
• Celle de C, \u0418, mais qui utilise un grand U et huit chiffres pour les caractères en dehors du Plan Multilingue de Base, une astuce bien dans la ligne de ce langage,
• Celle de Perl, \x{418}, qui avait personnellement ma préférence, notamment par ses délimiteurs symétriques, mais qui a été écartée car certains craignaient une ambiguïté possible due à la possibilité en Perl d'utiliser d'autres encodages.

Enfin, on notera que le RFC ne spécifie pas d'échappement standard si on veut écrire, par exemple \u'0418' sans qu'il soit interprété comme un caractère Unicode. Le truc classique du \\ est recommandé mais pas imposé.

Ce RFC définit un concept important en matière de métrologie du réseau, le concept de capacité qui remplace celui, ambigü, de bande passante.

Le groupe de travail IP Performance Metrics de l'IETF continue à ajouter au savoir commun d'intéressants RFC normalisant notamment les concepts utilisés, afin que des comparaisons puissent être faites entre les mesures effectuées par des équipes différentes. Ce RFC s'attaque au concept de capacité (capacity), qui a vocation à remplacer celui, flou et peu exact, de bande passante.

Une des raisons du flou est la volontée délibérée par certains acteurs de présenter des chiffres plus favorables. On voit ainsi souvent, sur le marché de l'accès Internet par ADSL des chiffres donnés en débit de la couche physique, pas en débit des couches plus hautes, pourtant les seules qui intéressent les utilisateurs. Le concept de bande passante avait aussi d'autres défauts, comme son origine dans le monde de l'analogique qui faisait que, même utilisé correctement, son étymologie était source de confusion. Ainsi, la section 3.4 donne l'exemple d'un lien 802.11b où l'électronicien annoncera une « bande passante » de 25 Mhz, l'ingénieur réseaux une « bande passante » de 11 Mbps, alors que l'utilisateur final ne pourra pas obtenir plus de 8 Mbps de débit.

La section 1 de notre RFC donne d'autres exemples des différences de capacité selon les couches. Par exemple, le codage Manchester de l'Ethernet classique fait perdre une bonne partie de la capacité théorique. Tout mécanisme de somme de contrôle consomme également des bits qui sont perdus pour les couches hautes. Les mécanismes d'accès au réseau peuvent encore réduire la capacité théorique. C'est ainsi que le CSMA/CD de l'Ethernet classique ne permet pas d'utiliser toute la capacité théorique. Des chiffres de 35 % d'utilisation maximale de l'Ethernet avaient circulé à une époque mais ils ne reposaient, ni sur un calcul théorique, ni sur des expériences ; et ils étaient totalement faux. Ceci dit, on ne peut pas atteindre les 100 %.

Bref, la capacité ne peut être sérieusement définie que pour une couche donnée.

La section 2 s'attaque aux définitions proprement dites. Reprenant les notions de lien et de chemin du RFC 2330, ainsi que la notion de « paquets de type P » (paquets d'un type donné, pour tenir compte du fait que le débit mesuré peut dépendre du type de paquets, TCP plutôt que UDP, par exemple) notre RFC définit :

• La capacité physique théorique du lien (Nominal physical link capacity). Elle est mesurée à la couche 1 et vaut donc, par exemple, 155,52 Mbps pour un OC-3.
• La capacité IP du lien (IP-type-P link capacity ). Elle est mesurée à la couche 3 et elle inclus donc dans son calcul les bits de l'en-tête des paquets IP. Les applications, dans les couches plus hautes, ne pourront donc pas utiliser toute cette capacité.
• La capacité IP du chemin (IP-type-P Path Capacity).
• L'utilisation du lien (IP-type-P Link Usage et IP-type-P Link Utilization) qui indique l'usage effectif qui est fait du lien.
• La capacité disponible (IP-type-P Available Link Capacity et IP-type-P Available Path Capacity), qui est simplement la capacité moins l'utilisation.

La section 3 est ensuite consacrée à discuter de cette terminologie et des difficultés de mesure. C'est là par exemple qu'est traité le cas de la compression (par exemple avec ROHC, RFC 3095) ou bien le rapport entre la capacité et les grandeurs définies par le RFC 3148.