Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
Les registres de noms de domaine ont
parfois des périodes d'enregistrement spéciales, par exemple lors
de la phase de lancement d'un nouveau domaine d'enregistrement, ou
bien lorsque les règles d'enregistrement changent. Pendant ces
périodes, les conditions d'enregistrement ne sont pas les mêmes
que pendant les périodes « standards ». Les registres qui utilisent
le protocole EPP pour l'enregistrement
peuvent alors utiliser les extensions EPP de ce nouveau RFC pour
gérer ces périodes spéciales.
Un exemple de période spéciale est l'ouverture d'un tout
nouveau TLD à l'enregistrement. Un autre
exemple est une libéralisation de l'enregistrement, passant par
exemple de vérifications a priori strictes à un modèle plus
ouvert. Dans les deux cas, on peut voir des conflits se faire
jour, par exemple entre le titulaire le plus rapide à enregistrer
un nom, et un détenteur de propriété
intellectuelle qui voudrait reprendre le nom. Les
périodes spéciales sont donc définies par des privilèges
particuliers pour certains utilisateurs, permettant par exemple
aux titulaires d'une marque déposée d'avoir
un avantage pour le nom de domaine
correspondant à cette marque. La période spéciale est qualifiée de
« phase de lancement » (launch phase). Les extensions à
EPP décrites dans ce nouveau RFC permettent
de mettre en œuvre ces privilèges.
La classe (mapping) décrivant les domaines en EPP figure dans le
RFC 5731. Elle est prévue pour le
fonctionnement standard du registre, sans intégrer les périodes
spéciales. Par
exemple, en fonctionnement standard, une fois que quelqu'un a
enregistré un nom, c'est fini, personne d'autre ne peut le
faire. Mais dans les phases de lancement, il arrive qu'on accepte
plusieurs candidatures pour un même nom, qui sera ensuite attribué
en fonction de divers critères (y compris parfois une mise aux
enchères). Ou bien il peut y avoir des vérifications
supplémentaires pendant une phase de lancement. Par exemple,
certaines phases peuvent être réservées aux titulaires de
propriété intellectuelle, et cela est
vérifié via un organisme de validation, comme la TMCH (RFC 7848).
D'où ce RFC qui étend la classe domain
du RFC 5731. La section 2 du RFC décrit les
nouveaux attributs et éléments des domaines, la section 3 la façon de les
utiliser dans les commandes EPP et la
section 4 donne le schéma XML. Voyons
d'abord les nouveaux éléments et attributs.
D'abord, comme il peut y avoir plusieurs candidatures pour un
même nom, il faut un moyen de les distinguer. C'est le but de
l'identificateur de candidature (application
identifier). Lorsque le serveur EPP reçoit une commande
pour un nom, il attribue un
identificateur de candidature, qu'il renvoie au client, dans un
élément
, tout en
indiquant que le domaine est en état
pendingCreate
(RFC 5731, section 2.3) puisque le domaine n'a pas encore été
créé.
Au passage, launch
dans
est une
abréviation pour l'espace de noms XML
urn:ietf:params:xml:ns:launch-1.0
. Un
processeur XML correct ne doit évidemment pas tenir compte de
l'abréviation (qui peut être ce qu'on veut) mais uniquement de
l'espace de noms associé. Cet espace est désormais enregistré
à l'IANA (cf. RFC 3688).
Autre nouveauté, comme un serveur peut utiliser plusieurs
organismes de validation d'une marque
déposée, il existe désormais un attribut
validatorID
qui indique l'organisme. Par
défaut, c'est la TMCH (identificateur
tmch
). On pourra utiliser cet attribut
lorsqu'on indiquera un identificateur de marque, par exemple
lorsqu'on se sert de l'élément
du RFC 7848.
Les périodes spéciales ont souvent plusieurs phases, et notre
RFC en définit plusieurs (dans une ouverture réelle, toutes ne
sont pas forcément utilisées), qui seront utilisées dans l'élément
:
- Lever de soleil (sunrise), phase où les
titulaires de marques (le RFC ne mentionne pas d'autres cas,
comme le nom de l'entreprise ou d'une ville) peuvent seuls
soumettre des candidatures, la marque étant validée par exemple
via la TMCH,
- Prétentions (claims), où on peut
enregistrer si on n'a pas de marque, mais on reçoit alors une
notice disant qu'une marque similaire existe (elle est décrite
plus en détail dans
l'Internet-Draft
draft-ietf-regext-tmch-func-spec
),
et on peut alors renoncer ou continuer (si on est d'humeur à
affronter les avocats de la propriété intellectuelle), en
annonçant, si on continue « oui, j'ai vu, j'y vais quand même »,
- Ruée (landrush), phase immédiatement
après l'ouverture, quand tout le monde et son chien peuvent se
précipiter pour enregistrer,
- État ouvert (open), une fois qu'on a atteint le régime de croisière.
La section 2 définit aussi les états d'une
candidature. Notamment :
pendingValidation
(validation en
attente),
validated
(c'est bon, mais voyez plus
loin),
invalid
(raté, vous n'avez pas de
droits sur ce nom),
pendingAllocation
(une fois qu'on est
validé, tout n'est pas fini, il peut y avoir plusieurs
candidatures, avec un mécanisme de sélection, par exemple fondé
sur une enchère),
allocated
(c'est vraiment
bon),
rejected
(c'est fichu…)
Les changements d'état ne sont pas forcément synchrones. Parfois,
il faut attendre une validation manuelle, par exemple. Dans cas,
il faut notifier le client EPP, ce qui se fait avec le mécanisme
des messages asynchrones (
poll message) du RFC 5730,
section 2.9.2.3.
Comme toutes les extensions EPP, elle n'est utilisée par le
client que si le serveur l'indique à l'ouverture de la session, en
listant les espaces de noms XML des extensions qu'il accepte, par
exemple :
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
EPP beautiful server for .example
2018-02-20T15:37:20.0Z
1.0en
urn:ietf:params:xml:ns:domain-1.0
urn:ietf:params:xml:ns:contact-1.0
urn:ietf:params:xml:ns:rgp-1.0
urn:ietf:params:xml:ns:secDNS-1.1
urn:ietf:params:xml:ns:launch-1.0
Maintenant qu'on a défini les données, la section 3 du RFC
explique comment les utiliser. (Dans tous les exemples ci-dessous,
C:
identifie ce qui est envoyé par le client
EPP et S:
ce que le serveur répond.) Par exemple, la commande EPP
(RFC 5730,
section 2.9.2.1) sert à vérifier si on peut enregistrer un objet
(ici, un nom de domaine). Elle prend ici des éléments
supplémentaires, par exemple pour tester si un nom correspond à
une marque. Ici, on demande si une marque existe (notez
l'extension
) :
C:
C:
C:
C:
C: domain1.example
C:
C:
C:
C:
C:
C:
C:
Et on a la réponse (oui, la marque existe dans la TMCH) :
S:
S:
S:
S: Command completed successfully
S:
S:
S:
S:
S: domain1.example
S:
S: 2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001
S:
S:
S:
S:
S:
S:
Avec la commande EPP
, qui
sert à récupérer des informations sur un nom, on voit ici qu'un
nom est en attente (pendingCreate
), et on a
l'affichage de la phase actuelle du lancement, dans l'élément
:
C:
C:
C:
C:
C: domain.example
C:
C:
C:
C:
C: sunrise
C:
C:
C:
C:
Et le résultat, avec entre autre l'identificateur de candidature :
S:
S:
S:
S: Command completed successfully
S:
S:
S:
S: domain.example
S:
S: jd1234
S: sh8013
S: 2012-04-03T22:00:00.0Z
...
S:
S:
S:
S:
S: sunrise
S: abc123
S:
S:
S: ...
S:
S:
S:
S:
S:
C'est bien joli d'avoir des informations mais, maintenant, on
voudrait créer des noms de domaine. La commande EPP
(RFC 5730, section 2.9.3.1) sert à cela. Selon la phase de
lancement, il faut lui passer des extensions différentes. Pendant
le lever de soleil (sunrise), il faut indiquer
la marque déposée sur laquelle on s'appuie, dans
(il y a d'autres
moyens de l'indiquer, cf. section 2.6) :
C:
C:
C:
C:
C: domain.example
C: jd1234
...
C:
C:
C:
C:
C: sunrise
C:
C:
C: 49FD46E6C4B45C55D4AC
C:
C:
C:
C:
C:
On reçoit une réponse qui dit que le domaine n'est pas encore
créé, mais on a un identificateur de candidature (un numéro de
ticket, quoi) en
. Notez le code de retour 1001 (j'ai
compris mais je ne vais pas le faire tout de suite) et non pas
1000, comme ce serait le cas en régime de croisière :
S:
S:
S:
S: Command completed successfully; action pending
S:
S:
S:
S: domain.example
S: 2010-08-10T15:38:26.623854Z
S:
S:
S:
S:
S: sunrise
S: 2393-9323-E08C-03B1
S:
S:
S:
S:
S:
De même, des extensions permettent de créer un domaine pendant la
phase où il faut indiquer qu'on a vu les prétentions qu'avait un
titulaire de marque sur ce nom.
Le RFC décrit aussi l'extension à utiliser dans la phase de ruée
(landrush), mais j'avoue n'avoir pas compris
son usage (puisque, pendant la ruée, les règles habituelles
s'appliquent).
On peut également retirer une candidature, avec la commande EPP
qui, en mode standard, sert à
supprimer un domaine. Il faut alors indiquer l'identifiant de la
candidature qu'on retire :
C:
C:
C:
C:
C: domain.example
C:
C:
C:
C:
C: sunrise
C: abc123
C:
C:
C:
C:
Et les messages non sollicités (poll),
envoyés de manière asynchrone par le serveur ?
Voici un exemple, où le serveur indique que la candidature a été
jugée valide (le mécanisme par lequel on passe d'un état à un
autre dépend de la politique du serveur) :
S:
S:
S:
S: Command completed successfully; ack to dequeue
S:
S:
S: 2013-04-04T22:01:00.0Z
S: Application pendingAllocation.
S:
S:
S:
S: domain.example
S: ...
S:
S:
S:
S:
S: sunrise
S: abc123
S:
S:
S:
S:
S:
Voilà, vous savez l'essentiel, si vous voulez tous les détails,
il faudra lire la section 3 complète, ainsi que la section 4, qui
contient le schéma XML des extensions pour
les phases de lancement. Comme toutes les extensions à EPP, celle
de ce RFC est désormais dans le registre des
extensions EPP, décrit dans le RFC 7451.
Notez que ce RFC ne fournit pas de moyen pour indiquer au
client EPP quelle est la politique d'enregistrement pendant la période
spéciale. Cela doit être fait par un mécanisme externe (page Web
du registre, par exemple).
Quelles sont les mises en œuvre de ce RFC ? L'extension pour
les phases de lancement est ancienne (première description en
2011) et de nombreux registres offrent désormais cette
possibilité. C'est d'autant plus vrai que
l'ICANN impose aux registres de ses
nouveaux TLD de gérer les phases de
lancement avec cette extension. Ainsi :
- Le kit de développement de clients EPP de
Verisign a cette extension, sous une
licence libre.
- Logiquement, le système d'enregistrement de Verisign,
utilisé notamment pour
.com
et
.net
(mais également
pour bien d'autres TLD) gère cette
extension (code non libre et non public, cette fois).
- Le serveur REngin (non libre),
utilisé pour
.za
a
aussi cette extension.
- Le serveur de CentralNIC,
pareil.
- Le client EPP distribué par Neustar
est sous licence libre et sait gérer les phases de
lancement.
- Le serveur (non libre) de SIDN (qui
gère le domaine national
.nl
) fait partie de
ceux qui ont mis en œuvre ce RFC.
- Et côté client, il y a le logiciel libre Net::DRI
(extension ajoutée dans une scission nommée
tdw
, pas dans le logiciel originel de
Patrick Mevzek),
cf. LaunchPhase.pm
.