Stéphane Bortzmeyer a écrit 664 commentaires

Problème connu (XMPP l'a expérimenté) : les spams dans les invitations.

Cela ne respecte pas le cahier des charges, qui est de permettre à un inconnu de vous écrire (sinon, la solution au problème du spam est trop facile).

Si quelqu'un sait comment faire un système de messagerie électronique simple pour un réseau mondial, sans chef, et qui permette à toute Alice de parler à tout Bob, les propositions sont les bienvenues :-)

Plus sérieusement, les gens font des sites Web alors que c'est certainement bien plus complexe que de gérer un serveur de courrier.

Le Tao est aussi une bonne lecture https://www.ietf.org/about/participate/tao/

On peut aussi préciser qu'OpenPGP est une norme ouverte, spécifiée dans le RFC 4880.

Oui, mais cette idée d'une « carte d'identité numérique pour toute la population » étant mauvaise (et je rappelle que la carte d'identité n'est pas obligatoire en France), qu'elle ne soit pas réalisée ne me gêne pas.

C'est un témoignage concernant un des fournisseurs d'identité qui peut utiliser FranceConnect (personnellement, j'ai utilisé Ameli et les impôts). Le principe de FranceConnect étant de séparer le service d'authentification du fournisseur d'identité, il me semble qu'un problème chez un des fournisseurs d'identité ne remet pas en cause FranceConnect.

La remarque sur FranceConnect est curieuse. En quoi a-t-il « échoué » ? Je trouve que c'est une bonne idée, bien mise en œuvre, et qui semble largement utilisée.

Ce n'est pas correct de mentionner uniquement FreeOTP. Il s'appuie sur des normes ouvertes (comme TOTP) donc si ça marche avec FreeOTP, ça marchera avec n'importe lequel des très nombreux logiciels qui font du TOTP. FreeOTP n'est qu'un logiciel, pas un protocole.

(Et TOTP n'utilise pas de clé publique, contrairement à ce qui est écrit.)

Bon, mais ils n'ont rien de "rogue", ces résolveurs.

Cela risque-t-il d'impacter les rogues DNS ?

Euh, il faudrait expliquer la question.

Il y a de nombreuses années (2013 !) qu'asso.fr est fermé (les noms existants continuent mais il n'y a plus de créations)

PS : l'article cité a plus de dix-huit ans…

Une bonne réputation ? Venue d'où ? Évaluée par qui ?

Ceci dit, une fois installé, un résolveur ne tombe que très rarement en panne. Il n'y a que DNSSEC qui nécessite du soin.

Ce qui est justement une mauvaise idée.

Ce problème a été remonté aux développpeurs de RIPE Atlas, et ils cherchent une solution.

Je ne suis pas convaincu qu'il y a un problème. C'est plutôt l'affichage Web d'Atlas qui est trompeur. Quand on regarde le JSON des résultats (https://atlas.ripe.net/api/v2/measurements/22766270/results/), on n'a au contraire que des succès.

Par exemple, la sonde 12774 est marquée comme "undefined" dans l'interface graphique alors que, dans le fichier JSON, on voit qu'elle a eu un résultat positif d'un de ses résolveurs.

Je soupçonne que l'affichage trompeur vient des erreurs de connexion vers les résolveurs IPv6. C'est en tout cas ce qu'on voit dans les résultats bruts :

     {
        "dst_name": "fe80::3e81:d8ff:fede:fbf8",
        "error": {
          "socket": "connect failed Invalid argument"
        },

Toujours se méfier des jolies affichages graphiques !

https://labs.ripe.net/Members/stephane_bortzmeyer/creating-ripe-atlas-one-off-measurements-with-blaeu

« Tout le monde n'a pas une machine qu'il contrôle sur internet (moi personnellement je n'en ai pas, je fais comment alors?) » OU BIEN VERS UNE MACHINE PRÉVUE POUR CELA, c'était écrit. Les ancres Atlas, par exemple. https://labs.ripe.net/Members/stephane_bortzmeyer/checking-your-internet-connectivity-with-ripe-atlas-anchors

« si ca marche, je teste un ping sur www.google.Fr » C'est très sommaire comme test :

• ping ne donnera pas de message d'erreur détaillé s'il y a un problème DNS (juste du binaire ça marche / ça marche pas). Pour tester le DNS, il vaut mieux utiliser dig.
• s'il y a une panne, comment savoir si elle est de la faute de Google, de l'AFNIC ou du résolveur ?

« si ca marche, je pinge le 8.8.8.8 » Et si Google vient de décider d'arrêter de répondre aux requêtes ICMP echo, ou bien de limiter le taux de réponse ?

Un test général de connectivité doit se faire vers une machine qu'on contrôle, ou bien vers une machine explicitement prévue pour cela (donc pas Google Public DNS).

Pascal Courtois avait également programmé en C le serveur HTTP du CNAM, à l'époque où il n'y avait que deux ou trois serveurs HTTP publics en France (1993), et où aucun logiciel publié n'avait les performances nécessaires (aujourd'hui, c'est banal, des serveurs HTTP qui servent des milliers de requêtes par seconde, mais à l'époque c'était tout nouveau et Pascal avait contribué à défricher ce domaine, et il avait passé beaucoup de temps à régler la machine Ultrix, puis OSF/1). Cf. le livre de Valérie Schafer, « En construction ».

ISO 8601, comme toutes les normes ISO, permet de tas de variantes et vous seriez bien embêté·e·s s'il fallait écrire du code pour gérer toutes les possibilités d'ISO 8601. Notamment, contrairement à une légende répandue, ISO 8601 ne garantit pas que le tri alphabétique soit également un tri chronologique.(Si quelqu'un ici a déjà lu la norme ISO 8601, qu'ielle lève la main.)

La bonne solution pour les dates est celle du RFC 3339.

Oui, enfin, il y a UNE virgule qui n'a pas d'espace après. Je suis impressionné par le niveau de rigueur typographique de certain·e·s mais, franchement, est-ce que cela gêne la lecture ?

Juste la flemme intellectuelle de ma part :-)

Ah, le premier vote est négatif. Un·e ami·e des GAFA qui ne veut pas les voir souffrir ? Ou bien un·e programmeu·r·se qui a essayé de mettre en œuvre ActivityPub et l'a trouvé trop compliqué ?