230 private links
2025-04-01
Un sujet fort pertinent pour la conception de technologies en général.
Ok interesting
Il s'agit d'une extension optionelle, compatible avec la gestion du temps en Java et généraliste.
La redéfinition du décalage à la fin des estampilles:
- Z indique qu'on utilise UTC comme référence, sans connaître l'heure locale (nouveau)
- -00:00 comme Z
- +00:00 indique qu'on utilise UTC comme référence
L'autre nouveauté de ce RFC 9557 est plus marquante, c'est le format étendu IXDTF (section 3). Il consiste à ajouter à la fin de l'estampille une série (facultative) de couples {clé, valeur}, entre crochets.
2022-07-08T12:14:37+02:00[Europe/Paris][u-ca=hebrew]
Les clés sont définies sur le nouveau registre https://www.iana.org/assignments/internet-date-time-format/internet-date-time-format.xml#timestamp-suffix-tag-keys.
Wow
Peut être utile un jour
Voir eTag, Cache-Control, Expires, max-age, Last-Modified pour gérer le cache d'une requête HTTP.
Le billet de blog détaille comment sont gérés les ressources du cache, avec le serveur.
Et encore, ici, j'ai indiqué le fuseau horaire de manière lisible, contrairement à ce que font la plupart des Étatsuniens, qui utilisent leurs sigles à eux comme PST, ou ce que font les Français qui n'indiquent pas le fuseau horaire, persuadés qu'ils sont que le monde entier est à l'heure de Paris.
🤣
Certains noms de domaines peuvent s'écrire de plusieurs manières différentes (en écrite traditionnelle ou simplifiée).
Ce RFC propose de grouper par lot certains noms de domaine, selon des règles.
Et pour savoir comment fonctionne une URN, il y a l'article Wikipédia 👍
Le canal de données WebRTC est une modélisation d'un tuyau virtuel entre les deux parties qui communiquent, tuyau dans lequel circuleront les données.
Le multimédia, lui, passe via SRTP, les données nécessitant une plus grande fiabilité passent par SCTP lui-même transporté sur DTLS (RFC 6347) lui même sur UDP.
Ce RFC décrit les généralités sur WebRTC.
Comme WebRTC laisse beaucoup de libertés pour implémenter les communications audio et vidéo entre deux navigateurs, ce RFC indique les bonnes pratiques à utiliser: lorsqu'il y a un serveur central, lors de fédération(s) de plusieurs serveurs de communication; les conditions d'accès à la caméra et au microphone; le consentement entre les pairs communicants; etc...
Il part du principe que le navigateur est un outil de confiance.
Un format a niveau binaire pour des machines limitées.