toad.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
Mastodon server operated by David Troy, a tech pioneer and investigative journalist addressing threats to democracy. Thoughtful participation and discussion welcome.

Administered by:

Server stats:

363
active users

#rfc

2 posts2 participants0 posts today
:atari: :neovim: :terminal:<p><span class="h-card" translate="no"><a href="https://fosstodon.org/@mconley" class="u-url mention" rel="nofollow noopener noreferrer" 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 noreferrer" 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 noreferrer" 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 noreferrer" target="_blank">#<span>RFC9715</span></a> - an <a href="https://infosec.exchange/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" 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 noreferrer" target="_blank">#<span>DNS</span></a> issue of IP fragmentation over <a href="https://infosec.exchange/tags/UDP" class="mention hashtag" rel="nofollow noopener noreferrer" 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 noreferrer" 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 noreferrer" 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 noreferrer" target="_blank">#<span>Google</span></a> will configure 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 noreferrer" target="_blank">#<span>TCP</span></a>. </p><p><a href="https://infosec.exchange/tags/ipv4" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>ipv4</span></a> <a href="https://infosec.exchange/tags/ipv6" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>ipv6</span></a> <a href="https://infosec.exchange/tags/ietf" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>ietf</span></a></p>
Kevin Karhan :verified:<p><span class="h-card" translate="no"><a href="https://suya.place/users/bogdan" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>bogdan</span></a></span> anything that mandates <a href="https://infosec.space/tags/2FA" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>2FA</span></a> and doesn't provide <a href="https://infosec.space/tags/TOTP" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>TOTP</span></a> or <a href="https://infosec.space/tags/HOTP" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>HOTP</span></a> support as per <a href="https://infosec.space/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> but demand something like <a href="https://infosec.space/tags/PhoneNumbers" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PhoneNumbers</span></a> that are <a href="https://infosec.space/tags/PII" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PII</span></a> should be outlawed.</p><ul><li>I can accept <a href="https://infosec.space/tags/PGP" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PGP</span></a>-based 2FA as a compromise...</li></ul>
mkj<p>Ahh, here it is. Maybe the IETF should publish a list or something including the publication date, so they can be found more easily.</p><p>RFC 9759, Unified Time Scaling for Temporal Coordination Frameworks</p><p><a href="https://datatracker.ietf.org/doc/html/rfc9759" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">datatracker.ietf.org/doc/html/</span><span class="invisible">rfc9759</span></a></p><p><a href="https://social.mkj.earth/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> <a href="https://social.mkj.earth/tags/RFC9759" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC9759</span></a> <a href="https://social.mkj.earth/tags/TwoWeekPrinciple" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>TwoWeekPrinciple</span></a></p>
Tim Hergert<p>Was really looking forward to an April 1 IETF RFC this year - but it appears i will be disappointed this year. </p><p>Instead - I guess I'll have to share some of my favorites from years past </p><p>RFC 3514 "The Security Flag in the IPv4 Header"<br><a href="https://datatracker.ietf.org/doc/html/rfc3514" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">datatracker.ietf.org/doc/html/</span><span class="invisible">rfc3514</span></a></p><p>RFC 1149 "A Standard for the Transmission of IP Datagrams on Avian Carriers"</p><p><a href="https://datatracker.ietf.org/doc/html/rfc1149" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">datatracker.ietf.org/doc/html/</span><span class="invisible">rfc1149</span></a></p><p><a href="https://infosec.exchange/tags/IETF" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>IETF</span></a> <a href="https://infosec.exchange/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> <a href="https://infosec.exchange/tags/AprilFools" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>AprilFools</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 noreferrer" 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 noreferrer" 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>
Edorian<p>My first <a href="https://phpc.social/tags/PHP" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PHP</span></a> <a href="https://phpc.social/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" 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 noreferrer" 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 noreferrer" 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>
RFC Editor<p>RFC 9775: IRTF Code of Conduct, C. S. Perkins, <a href="https://www.rfc-editor.org/info/rfc9775" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9775</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> This document describes the code of conduct for participants in the Internet Research Task Force (IRTF). The IRTF believes that research is most effective when done in an open and inclusive forum that encourages diversity of ideas and participation. Through this code of conduct, the IRTF continues to 1/2</p>
RFC Editor<p>RFC 9724: State of Affairs for Randomized and Changing Media Access Control (MAC) Addresses, JC. Zúñiga, et al., <a href="https://www.rfc-editor.org/info/rfc9724" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9724</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> Internet users are becoming more aware that their activity over the Internet leaves a vast digital footprint, that communications might not always be properly secured, and that their location and actions can be tracked. One of the main 1/3</p>
RFC Editor<p>RFC 9743: Specifying New Congestion Control Algorithms, M. Duke, Ed., et al., <a href="https://www.rfc-editor.org/info/rfc9743" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9743</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> RFC 5033 discusses the principles and guidelines for standardizing new congestion control algorithms. This document obsoletes RFC 5033 to reflect changes in the congestion control landscape by providing a framework for the development and assessment of congestion control 1/2</p>
Daniel Supernault<p>Pixelfed Friend Discovery ✨</p><p>Check your contacts to see if they are on Pixelfed, without compromising their privacy, or sharing their info by using the k-Anonymity algo:</p><p>- Your address book/contact list stays on your device<br>- We only send anonymized, partially-hashed data<br>- k-Anonymity ensures no individual can be identified<br>- Discovery service operated by the Pixelfed Foundation, and opt-in per user</p><p>We would love your feedback! </p><p><a href="https://mastodon.social/tags/pixelfed" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>pixelfed</span></a> <a href="https://mastodon.social/tags/onboarding" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>onboarding</span></a> <a href="https://mastodon.social/tags/FindYourFriends" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>FindYourFriends</span></a> <a href="https://mastodon.social/tags/PrivacyMatters" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PrivacyMatters</span></a> <a href="https://mastodon.social/tags/rfc" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>rfc</span></a></p>
Grzegorz Surmann :verified:<p>BGP als Königs-Routingprotokoll <a href="https://blog.funil.de/2514/sinuspl/deutsch/netzwerk-und-internet/bgp-als-konigs-routingprotokoll/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">blog.funil.de/2514/sinuspl/deu</span><span class="invisible">tsch/netzwerk-und-internet/bgp-als-konigs-routingprotokoll/</span></a> <a href="https://mstdn.funil.de/tags/bgp" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>bgp</span></a> <a href="https://mstdn.funil.de/tags/internet" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>internet</span></a> <a href="https://mstdn.funil.de/tags/policy" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>policy</span></a> <a href="https://mstdn.funil.de/tags/protocol" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>protocol</span></a> <a href="https://mstdn.funil.de/tags/rfc" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>rfc</span></a> <a href="https://mstdn.funil.de/tags/routing" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>routing</span></a></p>
RFC Editor<p>RFC 9748: Updating the NTP Registries, R. Salz, <a href="https://www.rfc-editor.org/info/rfc9748" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9748</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> The Network Time Protocol (NTP) and Network Time Security (NTS) documents define a number of registries, collectively called the NTP registries.</p>
Stéphane Bortzmeyer<p>RFC 9583: Application Scenarios for the Quantum Internet</p><p>Peut-être, dans le futur, nous aurons un <a href="https://mastodon.gougere.fr/tags/InternetQuantique" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>InternetQuantique</span></a>, où les communications utiliseront à fond les surprenantes propriétés de la physique <a href="https://mastodon.gougere.fr/tags/quantique" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>quantique</span></a>. Ce <a href="https://mastodon.gougere.fr/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> se penche sur les applications que cela pourrait avoir, et les utilisations possibles. </p><p><a href="https://www.bortzmeyer.org/9583.html" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">bortzmeyer.org/9583.html</span><span class="invisible"></span></a></p>
Stéphane Bortzmeyer<p>L'Internet est aujourd'hui un service indispensable à toutes les activités humaines. Un accès correct à ce réseau est donc crucial. Mais plusieurs problèmes limitent l'accès à l'Internet ou à plusieurs de ses services. L'<a href="https://mastodon.gougere.fr/tags/IAB" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>IAB</span></a> avait organisé en janvier 2024 un atelier sur cette question, atelier dont ce <a href="https://mastodon.gougere.fr/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> 9707: "Barriers to Internet Access of Services (BIAS) Workshop Report" est le compte-rendu.</p><p><a href="https://www.bortzmeyer.org/9707.html" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">bortzmeyer.org/9707.html</span><span class="invisible"></span></a></p><p><a href="https://mastodon.gougere.fr/tags/fractureNum%C3%A9rique" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>fractureNumérique</span></a></p>
RFC Editor<p>RFC 9707: Report from the IAB Workshop on Barriers to Internet Access of Services (BIAS), M. Kühlewind, et al., <a href="https://www.rfc-editor.org/info/rfc9707" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9707</span><span class="invisible"></span></a> <a href="https://mastodon.online/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> The "Barriers to Internet Access of Services (BIAS)" workshop was convened by the Internet Architecture Board (IAB) from January 15-17, 2024 as a three-day online meeting. Based on the submitted position papers, the workshop covered 1/2</p>
Karsten Schmidt<p>Anyone knows why the HTML versions of IETF RFCs are insisting on replicating the (unnecessary) page breaks from the plain text version? Also apart from being able to jump to bibliography and to document sections from the TOC, why aren't the HTML versions making proper use of internal hyperlinking? Feels like a grand missed opportunity to make these specs a lot more usable? Especially hard to use when trying to implement vs just using an RFC for a quick consult/check...</p><p><a href="https://mastodon.thi.ng/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> <a href="https://mastodon.thi.ng/tags/IETF" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>IETF</span></a> <a href="https://mastodon.thi.ng/tags/HyperText" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>HyperText</span></a></p>
Stéphane Bortzmeyer<p>RFC 9535: JSONPath: Query Expressions for JSON</p><p>Le langage <a href="https://mastodon.gougere.fr/tags/JSONPath" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>JSONPath</span></a> sert à désigner une partie d'un document <a href="https://mastodon.gougere.fr/tags/JSON" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>JSON</span></a>. Il est donc utile pour, par exemple, extraire des valeurs qui nous intéressent. </p><p><a href="https://mastodon.gougere.fr/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> </p><p><a href="https://www.bortzmeyer.org/9535.html" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">bortzmeyer.org/9535.html</span><span class="invisible"></span></a></p>
ignace nyamagana butera<p>I have an RFC in preparation for a year now to add a function to PHP but because of lack of time and my small knowledge of internals I have not yet finished it. Most is done, the text, the stub and testing files, a polyfill for older PHP version and I have a partial implementation. If someone with better knowledge of PHP could step in and help me finish the implementation that would be great <a href="https://phpc.social/tags/PHP" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PHP</span></a> <a href="https://phpc.social/tags/RFC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RFC</span></a> <a href="https://phpc.social/tags/help" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>help</span></a> just ping me and we can discuss it</p>
Edorian<p>#[RFC(Voting::started(...))]<br> <br><a href="https://externals.io/message/126310" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">externals.io/message/126310</span><span class="invisible"></span></a></p><p><a href="https://wiki.php.net/rfc/fcc_in_const_expr" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">wiki.php.net/rfc/fcc_in_const_</span><span class="invisible">expr</span></a></p><p>There's a first time for everything, and for me, that was sending an email to internals@ announcing an RFC vote.</p><p>As with many things, it's only daunting until you do it. And with <span class="h-card" translate="no"><a href="https://phpc.social/@timwolla" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>timwolla</span></a></span> support, both code and process wise, it was rather approachable to contribute an <a href="https://phpc.social/tags/rfc" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>rfc</span></a> to <a href="https://phpc.social/tags/php" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>php</span></a> </p><p>Thanks to <a href="https://phpc.social/tags/Tideways" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Tideways</span></a> and <span class="h-card" translate="no"><a href="https://phpc.social/@beberlei" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>beberlei</span></a></span> for supporting us in doing this.</p>