Suport technique et veille technologique

Le protocole d'avitaillement EPP, normalisé dans le RFC 5730, est extensible : on peut rajouter des éléments afin de gérer des politiques locales. Jusqu'à présent, ces extensions n'étaient pas collectées en un endroit unique, ce qui pouvait mener à des duplications d'efforts inutiles. Ce nouveau RFC crée un registre d'extensions EPP, géré souplement (y mettre une extension est simple et ne nécessite pas d'accord formel de l'IETF) et qui permettra aux développeurs d'extensions de vérifier facilement si quelqu'un a déjà fait un travail analogue.

EPP est surtout connu pour son utilisation par les registres de noms de domaine. C'est ce protocole qui est utilisé par le titulaire du nom, ou par son bureau d'enregistrement, pour créer un nom, le modifier ou le supprimer. Chaque registre ayant sa propre politique d'enregistrement, le schéma EPP standard ne peut donc pas convenir à tout le monde (« one size does not fit all »). Voilà pourquoi beaucoup de registres ont créé des extensions. Le RFC 3735 les guide dans cette tâche, mais n'indique guère comment publier ces extensions (cf. la section 2.1 du RFC 3735). On a vu ainsi plusieurs registres développer des extensions différentes, et incompatibles, pour le même problème (comme d'indiquer les informations à propos de la TVA sur les objets créés en EPP).

Notre RFC crée donc un registre IANA des extensions EPP. La section 2 du RFC spécifie les détails de ce registre, et des mécanismes d'enregistrement d'une extension. La politique est « norme nécessaire » (cf. RFC 5226, section 4.1), ce qui impose qu'une spécification publique de l'extension soit disponible, et qu'elle soit évaluée par un expert nommé par l'IANA.

Les éventuelles discussions sur la nouvelle extension, ou la qualité de sa documentation, se feront sur la liste de l'actuel groupe de travail IETF EPPEXT, eppext@ietf.org. Même lorsque le groupe de travail sera dissous, la liste continuera donc.

Parmi les critères d'évaluation, outre ceux du RFC 3735, notre RFC rappelle l'importance d'évaluer les conséquences de l'extension pour la vie privée. Une préoccupation qui était absente du RFC 3735 mais qui a bien plus d'importance aujourd'hui. Autrement, notre RFC recommande aux experts évaluateurs d'être souples : si l'extension à EPP a été documentée et est effectivement déployée, elle mérite d'être enregistrée, même si l'expert a des objections techniques. Ainsi, ce n'est pas un problème si plusieurs extensions proches sont enregistrées : cela reflète la réalité. Si quelqu'un veut déposer une extension très proche d'une extension existante, on lui fera remarquer (et il pourra alors choisir d'utiliser plutôt l'extension existante) mais on ne le bloquera pas. (Ce point est celui qui avait fait l'objet des plus chaudes discussions dans le groupe de travail EPPEXT : certains auraient préféré une politique d'enregistremet plus stricte, limitant les doublons.)

Et comment fait-on pour enregistrer ? On envoie à l'IANA un formulaire (un gabarit se trouve dans la section 2.2.2 et des exemples réels dans la section 3) informant du nom de l'extension, de l'endroit où se trouve sa spécification (un URL suffit), des coordonnées de la personne ou de l'organisation qui enregistre, du TLD auquel elle s'applique (ou « N'importe lequel » si elle est d'usage général), ainsi que d'informations sur les éventuels boulets juridiques, par exemple un brevet sur ladite extension (cf. RFC 3979 et RFC 4879). Voici un exemple de formulaire d'enregistrement rempli (IPR = Intellectual Property Rights) :

   -----BEGIN FORM-----
   Name of Extension:
   "An Example Extension for the .example Top-Level Domain"

   Document Status:
   Informational

   Reference:
   http://www.example.com/html/example-epp-ext.txt

   Registrant Name and Email Address:
   John Doe, jdoe@example.com

   TLDs: .example

   IPR Disclosure:
   http://www.example.com/ipr/example-epp-ext-ipr.html

   Status: Active

   Notes: None
   -----END FORM-----

Et un exemple réel, l'enregistrement de l'extension « période de rédemption » du RFC 3915. La spécification étant un RFC, le contact est l'IESG :

      -----BEGIN FORM-----
      Name of Extension:
      "Domain Registry Grace Period Mapping for the
      Extensible Provisioning Protocol (EPP)"

      Document Status:
      Standards Track

      Reference:
      http://tools.ietf.org/html/rfc3915

      Registrant Name and Email Address:
      IESG, 

      TLDs: Any

      IPR Disclosure: None

      Status: Active

      Notes: None
      -----END FORM-----

Cette extension est une des quatre premières du registre IANA.