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 -
Un très (vraiment très court) RFC
purement bureaucratique, pour un très léger (vraiment très léger)
changement des règles concernant les références d'un RFC à un
autre RFC.
Le problème était simple : un RFC
situé sur le Chemin des Normes est dans une étape donnée. Au
nombre de trois au début (RFC 2026), ces
étapes sont désormais deux (RFC 6410) : Proposition de norme et
Norme. D'autre part, un RFC a des références à d'autres RFC, dans
sa bibliographie, et ces références peuvent être normatives (il
faut avoir lu et compris les RFC cités) ou informatives (elles
sont juste là pour compléter et éclairer). Une règle de
l'IETF est qu'un RFC ne peut pas avoir de
référence normative à un RFC situé à une
étape inférieure. Le but était d'éviter
qu'une norme ne dépende d'un texte de maturité et d'adoption inférieurs.
Le RFC 3967
introduisait une exception à cette règle, mais en imposant un
processus jugé désormais trop rigide. On pouvait donc, quand c'était nécessaire, déroger à la règle
« pas de références vers le bas [du chemin des normes,
downward reference en anglais] » mais il
fallait le documenter dans le Last Call
(dernier appel avant adoption). Si quelque chose changeait dans
les références d'un RFC, il pouvait donc y avoir à refaire le
Last Call.
C'était d'autant plus gênant que la question se pose plus
souvent maintenant. En effet, les groupes de travail de
l'IETF qui bossent sur un sujet compliqué
font souvent un document « de base », définissant les concepts, la
terminologie, etc, et ces documents ne sont pas sur le chemin des
normes (ils sont juste « pour information »). Impossible donc de
mettre une référence « vers le bas ».
La nouvelle règle figure en section 2 du RFC : le RFC 3967 est légèrement mis à jour. Désormais,
il n'est plus nécessaire de mentionner l'existence d'une référence
« vers le bas » au moment du dernier appel. En cas de changement
des références, il ne sera donc plus obligatoire de répéter le
dernier appel. C'est donc entièrement à
l'IESG de déterminer si une référence à un
RFC « inférieur » est acceptable ou non.
RFC 9562: Universally Unique IDentifiers (UUIDs)
- 12 mai -
Ce RFC normalise les UUID, une famille d'identificateurs uniques, obtenus sans registre central. Il remplace l'ancienne norme, le RFC 4122, avec (...)
RFC 9490: Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN)
- 9 mai -
Aujourd'hui, l'essentiel du trafic sur l'Internet est chiffré, et pour d'excellentes raisons. Pas question de revenir là-dessus, mais, ceci dit, il (...)
RFC 9557: Date and Time on the Internet: Timestamps with Additional Information
- 29 avril -
Ce RFC modifie légèrement le format des estampilles temporelles du RFC 3339, changeant à la marge une définition et, surtout, permettant d'y attacher (...)
RFC 9567: DNS Error Reporting
- 27 avril -
Lorsqu'un résolveur DNS détecte un problème avec une zone, l'empêchant de résoudre les noms dans cette zone, il n'avait pas de moyen simple et (...)
RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
- 8 avril -
Ces deux nouveaux types d'enregistrement DNS, SVCB et sa variante HTTPS, permettent de donner des informations supplémentaires à un client réseau (...)
