Create accountLogin

Recent searches

No recent searches

Search options

Only available when logged in.
101010.pl is one of the many independent Mastodon servers you can use to participate in the fediverse.
101010.pl czyli najstarszy polski serwer Mastodon. Posiadamy wpisy do 2048 znaków.

Administered by:

Server stats:

526
active users

101010.pl: AboutStatusProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.4.0-alpha.5

#rfc

3 posts3 participants0 posts today
blainsmithWrote up an <a href="https://snac.rblgk.sh?t=rfc" class="mention hashtag" rel="nofollow noopener" target="_blank">#RFC</a> to get feedback on adding <a href="https://snac.rblgk.sh?t=activitypub" class="mention hashtag" rel="nofollow noopener" target="_blank">#ActivityPub</a> support to <a href="https://apply.coop" rel="nofollow noopener" target="_blank">https://apply.coop</a> soon after we launch. If anyone else has feedback it is certainly welcome! It does require a Codeberg account to comment, but we're open to email feedback as well.<br><br>I am not an ActivityPub expert so a lot of this was learning while planning this out.<br><br><a href="https://codeberg.org/limeleaf/apply.coop/issues/213" rel="nofollow noopener" target="_blank">https://codeberg.org/limeleaf/apply.coop/issues/213</a><br><br><a href="https://snac.rblgk.sh?t=coop" class="mention hashtag" rel="nofollow noopener" target="_blank">#Coop</a> <a href="https://snac.rblgk.sh?t=jobboard" class="mention hashtag" rel="nofollow noopener" target="_blank">#JobBoard</a> <a href="https://snac.rblgk.sh?t=buildinpublic" class="mention hashtag" rel="nofollow noopener" target="_blank">#BuildInPublic</a><br>
Stéphane Bortzmeyer<p>RFC 9771: Properties of AEAD Algorithms</p><p>Aujourd'hui, sur l'Internet, on n'utilise plus que des algorithmes de <a href="https://mastodon.gougere.fr/tags/chiffrement" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>chiffrement</span></a> <a href="https://mastodon.gougere.fr/tags/AEAD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>AEAD</span></a>. Ils assurent confidentialité et intégrité des données. Mais on peut être gourmand et vouloir en plus d'autres propriétés. Ce nouveau <a href="https://mastodon.gougere.fr/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a> classe ces propriétés et définit la terminologie. <br> <br><a href="https://www.bortzmeyer.org/9771.html" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">bortzmeyer.org/9771.html</span><span class="invisible"></span></a></p>
Stéphane Bortzmeyer<p>RFC 9292: Binary Representation of HTTP Messages</p><p>Un message <a href="https://mastodon.gougere.fr/tags/HTTP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>HTTP</span></a> est traditionnellement représenté comme du texte mais ce <a href="https://mastodon.gougere.fr/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a> spécifie une alternative, une représentation binaire d'un message. </p><p><a href="https://www.bortzmeyer.org/9292.html" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">bortzmeyer.org/9292.html</span><span class="invisible"></span></a></p>
Stéphane Bortzmeyer<p><a href="https://mastodon.gougere.fr/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a><br>On le sait, un des problèmes stratégiques de l'Internet est l'absence d'un protocole de messagerie instantanée standard et largement répandu. Il n'y a pas de solution simple à ce problème mais le système <a href="https://mastodon.gougere.fr/tags/MLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>MLS</span></a> (Messaging Layer Security) vise à au moins fournir un mécanisme de sécurité pour les groupes, mécanisme qui peut ensuite être utilisé par un protocole complet, comme XMPP.</p><p><a href="https://www.bortzmeyer.org/9750.html" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">bortzmeyer.org/9750.html</span><span class="invisible"></span></a></p>
RFC Editor<p>RFC 9750: The Messaging Layer Security (MLS) Architecture, B. Beurdouche, et al., <a href="https://www.rfc-editor.org/info/rfc9750" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9750</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a> The Messaging Layer Security (MLS) protocol (RFC 9420) provides a group key agreement protocol for messaging applications. MLS is designed to protect against eavesdropping, tampering, and message forgery, and to provide forward secrecy (FS) and post-compromise 1/4</p>
:atari: :neovim: :terminal:<p><span class="h-card" translate="no"><a href="https://fosstodon.org/@mconley" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>mconley</span></a></span> yeah, I worked on one of those solutions back in my day :-). Even though it does not look like something difficult, it's a pretty complex thing to design. Multiplexing audio and video can be often very resource intensive task not talking about supported/unsupported codecs. Signalization is another story. <a href="https://fosstodon.org/tags/SIP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>SIP</span></a> being utilized everywhere brings another challenge because every company creates their own standards and ignores/extends existing <a href="https://fosstodon.org/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a> .. it's a hell :-)</p>
Max Resing<p>Just wanted to share some thoughts on <a href="https://infosec.exchange/tags/RFC9715" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC9715</span></a> - an <a href="https://infosec.exchange/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a> that defines standards on reducing the <a href="https://infosec.exchange/tags/DNS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>DNS</span></a> issue of IP fragmentation over <a href="https://infosec.exchange/tags/UDP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>UDP</span></a>. It's not a long read, but a good one for everyone who understands the issues of large UDP responses on the <a href="https://infosec.exchange/tags/Internet" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Internet</span></a>. A great leap forward to (hopefully) reduce the reflection/amplification <a href="https://infosec.exchange/tags/DDoS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>DDoS</span></a> potential of DNS.</p><p>Just today I learned that <a href="https://infosec.exchange/tags/Google" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Google</span></a> will share their public DNS resolvers to limit to ~1400 bytes (smaller adjustments expected while figuring out the sweet spot in production). From now on, DNS responses which exceed this limit will have the truncated flag set instructing the client to resolve back to <a href="https://infosec.exchange/tags/TCP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TCP</span></a>. </p><p><a href="https://infosec.exchange/tags/ipv4" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ipv4</span></a> <a href="https://infosec.exchange/tags/ipv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ipv6</span></a> <a href="https://infosec.exchange/tags/ietf" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ietf</span></a></p>
RFC Editor<p>RFC 9692: RIFT: Routing in Fat Trees, T. Przygienda, Ed., et al., <a href="https://www.rfc-editor.org/info/rfc9692" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9692</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a> This document defines a specialized, dynamic routing protocol for Clos, fat tree, and variants thereof. These topologies were initially used within crossbar interconnects and consequently router and switch backplanes, but their characteristics make them ideal for constructing IP 1/2</p>
RFC Editor<p>RFC 9759: Unified Time Scaling for Temporal Coordination Frameworks, K. Kuhns, <a href="https://www.rfc-editor.org/info/rfc9759" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9759</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a> Estimating time requirements for tasks, both critical and mundane, remains a challenge in engineering, business, and everyday communication. Existing models fail due to inherent unpredictability and inconsistencies in human estimation. This document introduces the 1/2</p>
Stéphane Bortzmeyer<p>RFC 9726: Operational Considerations for Use of DNS in IoT Devices</p><p>Les objets connectés sont une source de risques de sécurité. Pour les limiter, le RFC 8250 normalisait le format <a href="https://mastodon.gougere.fr/tags/MUD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>MUD</span></a>, pour que le fournisseur du machin connecté documente les accès au réseau de l'objet. Dans un fichier MUD, les services avec lesquels l'objet communique sont indiqués par un nom de domaine. Le <a href="https://mastodon.gougere.fr/tags/DNS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>DNS</span></a> a quelques subtilités, décrites dans ce <a href="https://mastodon.gougere.fr/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a>.</p><p><a href="https://www.bortzmeyer.org/9726.html" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">bortzmeyer.org/9726.html</span><span class="invisible"></span></a></p>
RFC Editor<p>RFC 9726: Operational Considerations for Use of DNS in Internet of Things (IoT) Devices, M. Richardson, et al., <a href="https://www.rfc-editor.org/info/rfc9726" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9726</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a> This document details considerations about how Internet of Things (IoT) devices use IP addresses and DNS names. These concerns become acute as network operators begin deploying Manufacturer Usage Descriptions (MUD), as specified in RFC 1/2</p>
RFC Editor<p>RFC 9776: Internet Group Management Protocol, Version 3, B. Haberman, Ed., <a href="https://www.rfc-editor.org/info/rfc9776" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9776</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a> The Internet Group Management Protocol (IGMP) is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP (IGMPv3) adds support for source filtering, that is, the ability for a system to report 1/3</p>
RFC Editor<p>RFC 9725: WebRTC-HTTP Ingestion Protocol (WHIP), S. Garcia Murillo, et al., <a href="https://www.rfc-editor.org/info/rfc9725" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9725</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a> This document describes a simple HTTP-based protocol that will allow WebRTC-based ingestion of content into streaming services and/or Content Delivery Networks (CDNs). This document updates RFCs 8840 and 8842. This document is a product of the WebRTC Ingest Signaling over 1/2</p>
Stéphane Bortzmeyer<p>RFC 9724: Randomized and Changing MAC Address State of Affairs</p><p>Dans le contexte de la surveillance massive qui s'exerce contre les utilisateurices de l'Internet, tout identifiant un peu stable peut être utilisé pour pister quelqu'un. On en laisse, des traces ! C'est par exemple le cas avec l'<a href="https://mastodon.gougere.fr/tags/adresseMAC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>adresseMAC</span></a>. Ce nouveau <a href="https://mastodon.gougere.fr/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a> décrit les mécanismes existants pour diminuer le risque de pistage par l'adresse MAC. Il ne spécifie pas un protocole, il liste les solutions.</p><p><a href="https://www.bortzmeyer.org/9724.html" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">bortzmeyer.org/9724.html</span><span class="invisible"></span></a></p>
Edorian<p>My first <a href="https://phpc.social/tags/PHP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PHP</span></a> <a href="https://phpc.social/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a> with a lot richer discussion passed today :)</p><p><a href="https://wiki.php.net/rfc/marking_return_value_as_important" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">wiki.php.net/rfc/marking_retur</span><span class="invisible">n_value_as_important</span></a></p><p>48 Mails all in all: <a href="https://externals.io/message/126232" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="">externals.io/message/126232</span><span class="invisible"></span></a> with some additional feedback on social media.</p><p>Thanks to everyone :) </p><p>What to do next now 🤔</p>
Stéphane Bortzmeyer<p>RFC 9694: Guidelines for the Definition of New Top-Level Media Types</p><p>Vous savez que les types de médias comportent un type de premier niveau et un sous-type. Dans image/gif, image est le type de premier niveau et gif le sous-type. La création du type haptics (données haptiques), qui a été faite dans le <a href="https://mastodon.gougere.fr/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a> 9695, a été l'occasion de formaliser un peu plus le processus de création de types de médias.</p><p><a href="https://www.bortzmeyer.org/9694.html" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">bortzmeyer.org/9694.html</span><span class="invisible"></span></a></p>
Stéphane Bortzmeyer<p>RFC 9695: The 'haptics' Top-level Media Type</p><p>L'enregistrement d'un nouveau type de média de premier niveau est plutôt rare (le dernier avait été font/ en 2017). Notre <a href="https://mastodon.gougere.fr/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a> introduit le type haptics/, pour les formats de fichier des interfaces haptiques, celles qu'on touche et qui vous touchent (une manette de jeu vidéo à retour d'effort, par exemple). </p><p><a href="https://www.bortzmeyer.org/9695.html" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">bortzmeyer.org/9695.html</span><span class="invisible"></span></a></p><p><a href="https://mastodon.gougere.fr/tags/haptique" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>haptique</span></a> <a href="https://mastodon.gougere.fr/tags/haptics" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>haptics</span></a></p>
RFC Editor<p>RFC 9695: The 'haptics' Top-Level Media Type, Y. K. Muthusamy, et al., <a href="https://www.rfc-editor.org/info/rfc9695" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9695</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a> This memo registers and documents the 'haptics' top-level media type, under which subtypes for representation formats for haptics may be registered. This document also serves as a registration for a set of subtypes, which are representative of some existing subtypes already in 1/2</p>
RFC Editor<p>RFC 9694: Guidelines for the Definition of New Top-Level Media Types, M.J. Dürst, <a href="https://www.rfc-editor.org/info/rfc9694" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9694</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a> This document defines best practices for defining new top-level media types. It also introduces a registry for top-level media types, and contains a short history of top-level media types. It updates RFC 6838. This document is a product of the Media Type Maintenance 1/2</p>
Stéphane Bortzmeyer<p>RFC 9745: The Deprecation HTTP Header Field</p><p>Ce nouveau champ de l'en-tête <a href="https://mastodon.gougere.fr/tags/HTTP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>HTTP</span></a> sert à indiquer que la ressource demandée va être (ou a été) abandonnée et qu'il faut penser à migrer. Il sert surtout pour les <a href="https://mastodon.gougere.fr/tags/API" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>API</span></a> HTTP. </p><p><a href="https://mastodon.gougere.fr/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a> </p><p><a href="https://www.bortzmeyer.org/9745.html" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">bortzmeyer.org/9745.html</span><span class="invisible"></span></a></p>
ExploreLive feeds
About