Suport technique et veille technologique
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.
- Janvier 2017 -
Deux protocoles utilisés dans l'industrie des noms de domaine,
EPP
et RDAP, ont la
notion d'état d'un nom de domaine,
indiquant, par exemple, que ce nom est verrouillé et ne doit pas
être modifié. Mais les états de EPP et de RDAP sont différents,
et pas toujours évidents à rapprocher. Ce nouveau RFC précise la
correspondance entre les états EPP et les états RDAP, établissant
la liste comparée.
EPP (protocole d'avitaillement d'objets
dans un registre, par exemple un registre de noms de
domaine) est normalisé dans divers RFC (STD 69), ceux qui décrivent les états sont
les RFC 5731 (section 2.3), RFC 5732 (section 2.3), RFC 5733
(section 2.2) et RFC 3915 (section 3.1). Les états
RDAP (protocole d'information sur les objets
d'un registre, qui vise à remplacer whois) sont
normalisés dans le RFC 7483 (section 10.2) qui crée un
registre
IANA des états possibles. Pourquoi des états
différents dans ces deux protocoles ? Disons qu'ils ont été conçus
pour des buts différents, et que la nécessité de faire
correspondre les états de l'un avec ceux de l'autre n'est
devenue évidente qu'après. Le but de ce nouveau RFC est justement
d'établir une correspondance univoque entre les états d'EPP et de
RDAP.
La section 2 de notre RFC commence par une liste des états
EPP, avec leur équivalent RDAP (quand il existe). Par exemple, il
est assez évident que le pendingDelete d'EPP
(RFC 5731) correspond au pending
delete de RDAP. De même, le ok
d'EPP est clairement l'équivalent du active
de RDAP. Mais les addPeriod (RFC 3915, durée après l'enregistrement d'un nom de domaine
pendant laquelle on peut annuler l'enregistrement gratuitement) ou
clientHold (RFC 5731,
le client a demandé que ce nom de domaine ne soit pas publié dans
le DNS)
d'EPP n'ont pas d'équivalent RDAP. L'inverse existe aussi, le
delete prohibited de RDAP n'a pas un
équivalent simple en EPP, qui a deux états pour cela, selon que
l'interdiction a été posée par le client EPP ou par le
serveur.
La section 2 du RFC se continue donc avec ce qui est désormais
la liste officielle des correspondances, en tenant compte des
nouveaux états ajoutés, par exemple dans le registre
RDAP. C'est ainsi qu'un add period et
un client hold ont été ajoutés (section 3 du RFC), ainsi qu'un
client delete prohibited et un
server delete prohibited, pour préciser le
delete prohibited.
Pour les TLD gérés par
l'ICANN, il va sans doute être obligatoire
d'utiliser ces nouveaux états.
