Lien RFC 1925: The Twelve Networking Truths
Lien Pegasus Mail et Gmail, le problème OAUTH2
Lien Le bon vieux temps du HOSTS.TXT
Forum Programmation.web Filtrage d'une adresse électronique
Bonjour,
Avec une expression rationnelle (régulière ?), je cherche à filtrer un tant soit peu des adresses électroniques saisies dans un formulaire. Pour l'instant, je me base sur les RFC 5321 sections 4.1.2 and 4.1.3 + Errata :
email address = local-part@domain ou local-part@address-literal
local-part = (?:[a-zA-Z0-9!#$%&'*+\-/=?^_\x60{|}~]+(?:\.[a-zA-Z0-9!#$%&'*+\-/=?^_\x60{|}~]+)*)|(?:"[\x20-\x21\x23-\x5B\x5D-\x7E]*")|(?:"(?:\\[\x20-\x7E])*")
domain = (?:[A-Za-z0-9](?:[A-Za-z0-9\-]*[A-Za-z0-9])?(?:\.[A-Za-z0-9](?:[A-Za-z0-9\-]*[A-Za-z0-9])?)*(?:\.)?)
Pour address-literal, ça devient folklorique, j'ai laissé tomber après avoir tenté un truc pourri du style :
(?:\[([0-9]|([1-9][0-9])|(1[0-9][0-9])|(2[0-5][0-5]))(?:\.([0-9]|([1-9][0-9])|(1[0-9][0-9])|(2[0-5][0-5]))){3}\])|(?:\[IPv6:[0-9A-F]{1,4}(?::[0-9A-F]{1,4}){7}\])|(?:\[IPv6:(?:[0-9A-F]{1,4}(?::[0-9A-F]{1,4}){0,5})?::(?:[0-9A-F]{1,4}(?::[0-9A-F]{1,4}){0,5})?\])|(?:\[IPv6:[0-9A-F]{1,4}(?::[0-9A-F]{1,4}){5}:([0-9]|([1-9][0-9])|(1[0-9][0-9])|(2[0-5][0-5]))(?:\.([0-9]|([1-9][0-9])|(1[0-9][0-9])|(2[0-5][0-5]))){3}\])|(?:\[IPv6:(?:[0-9A-F]{1,4}(?::[0-9A-F]{1,4}){0,3})?::(?:[0-9A-F]{1,4}(?::[0-9A-F]{1,4}){0,3}:)?([0-9]|([1-9][0-9])|(1[0-9][0-9])|(2[0-5][0-5]))(?:\.([0-9]|([1-9][0-9])|(1[0-9][0-9])|(2[0-5][0-5]))){3}\])|(?:\[[A-Za-z0-9\-]*[A-Za-z0-9]:[\x21-\x5A\x5E-\x7E]+\])
Donc si je me cantonne à local-part@domain, ça donne :
/^((?:[a-zA-Z0-9!#$%&'*+\-/=?^_\x60{|}~]+(?:\.[a-zA-Z0-9!#$%&'*+\-/=?^_\x60{|}~]+)*)|(?:"[\x20-\x21\x23-\x5B\x5D-\x7E]*")|(?:"(?:\\[\x20-\x7E])*"))@(?:[A-Za-z0-9](?:[A-Za-z0-9\-]*[A-Za-z0-9])?(?:\.[A-Za-z0-9](?:[A-Za-z0-9\-]*[A-Za-z0-9])?)*(?:\.)?)$/
Je (…)
FFV1, un format vidéo sans perte et libre, normalisé à l'IETF
Si la compression vidéo sans perte est moins tendance que celle avec perte, elle reste utile dans certains domaines (par exemple l’archivage, que ce soit pour son stockage ou sa transmission, qu’il concerne des enregistrements de procès importants pour l’histoire ou le dernier blockbuster à la mode).
L’Internet Engineering Task Force (IETF) avait déjà normalisé des formats de compression avec perte (Opus, pour l'audio), mais pas encore de format sans perte : c'est à présent chose faite, cette fois-ci en matière de vidéo, avec la normalisation de FFV1 sous le doux nom de RFC 9043.
Lien Le protocole QUIC désormais normalisé
Lien RFC 8890: The Internet is for End Users
Journal Appel à commentaires concernant la lettre d'information XMPP
Nour jarchel,
Je reprends ici mon commentaire laissé sous la dernière traduction de la lettre d'information XMPP. Je vous laisse le soin d'aller consulter les quelques réponses qui y ont été partagées.
Néanmoins, j'espérais plus de réactions: je me permets donc cette métensomatose pour relancer les personnes qui seraient susceptibles d'avoir manqué ta première incarnation.
Si, par ailleurs, tu avais le même succès que la précédente, je te promets de ne pas récidiver.
Sur ce, bon vent.
En préambule (…)
Journal Du XML, du HTML et du SVG dans les RFC
L'IETF a pour très longue tradition de fournir ses RFC en mode texte (du pur ASCII 7-bit).
Mais bon, les technologies évoluent, et IETF touche maintenant bien plus que des octets simplement ordonnés, il touche de nos jours autant à la crypto qu'aux formats de compression audio et vidéo. Et du coup, ça pourrait être sympa de présenter les principes mathématiques sous-jacents et autres en autre chose que de l'ASCII.
En 2016 l'IETF a sorti une RFC "HTML Format (…)
Journal [ma vie] Parfois, il est préférable de ne rien faire
Je lisais une Request For Comment et la lecture du fichier texte brut ne me satisfaisait pas : il serait tellement agréable d'avoir une version HTML, avec des liens dans la table des matières vers les sections, un style qui ferait moins mal aux yeux, etc.
Ce n'est pas la première fois que je n'étais pas enthousiaste face à ce qui s'affichait devant mes yeux. Mais cette fois-ci, ma réflexion fut de me dire que je pourrais écrire un greffon (…)
Joyce Reynolds est morte :-(
Joyce Reynolds vient de mourir, de maladie. Elle était l’auteure de nombreux RFC (demande de commentaires), dont ceux sur le protocole telnet. Elle était aussi co-éditrice des RFC à la grande époque (celle de Jon Postel). Comme elle signait « J. K Reynolds », des tas de gens qui cherchaient à contacter « l’auteur de telnet » étaient surpris en la voyant « mais non, je cherche un technicien ». Elle avait aussi travaillé sur plein d’autres trucs des débuts de l’Internet (comme le TLD .us) et de l’IETF.
Journal Joyce Reynolds est morte :-(
Joyce Reynolds vient de mourir, de maladie. Elle était l’auteur de nombreux RFC, dont ceux sur telnet. Elle était aussi co-éditeur des RFC à la grande époque (celle de Jon Postel). Comme elle signait « J. K Reynolds », des tas de gens qui cherchaient à contacter « l’auteur de telnet » étaient surpris en la voyant « mais non, je cherche un technicien ». Elle avait aussi travaillé sur plein d’autres trucs des débuts de l’Internet (comme le TLD .us) et de l’IETF.
Une fameuse (…)
Publication de la RFC « DNS et vie privée »
La demande de commentaires (RFC) 7626, « DNS Privacy Considerations », a été publiée fin août par l'IETF (entité qui élabore les standards d'Internet). Elle est issue des travaux du « groupe de travail IETF sur DNS et vie privée » évoqué précédemment. Ce document se focalise sur les risques encourus par les usagers pour leur vie privée, dans l'usage actuel des services de résolutions de noms.
Les groupes de travail IETF sont maintenant bien occupés aux futures solutions (minimisation des données envoyées et chiffrement).
Le risque d'une surveillance particulière pour un titulaire de zone est discuté via les RFC 5936 & 5155. Les risques autres que ceux concernant la vie privée (comme du cache poisoning) sont hors-sujet ici. Nous considérons ici les risques pour la vie privée d'une surveillance générale ou plus précise.
« Ce[tte] RFC est en fait à la croisée de deux activités. L'une d'elles consiste à documenter les problèmes de vie privée, souvent ignorés jusqu'à présent dans les RFC. Cette activité est symbolisée par le RFC 6973 (…). Et la seconde activité qui a donné naissance à ce RFC est le projet d'améliorer effectivement la protection de la vie privée des utilisateurs du DNS, en marchant sur deux jambes : minimiser les données envoyées (…) et les rendre plus résistantes à l'écoute, via le chiffrement. ».
Journal Marque Page sur Markdown et RFC
Salut Nal !
Rapide marque page à propos de 2 RFCs à propos d'un nouveau type de format text/markdown
et de ses differentes variantes.
N'hésitez-pas à y participer si vous voyez des choses à améliorer !
Après le récent sondage sur la réception et l'envoi de courriels en texte brute ou html, on pourrait très bien imaginer envoyer du markdown qui serait rendu à la réception en html, auquel on pourrait répondre en markdown :)