Create accountLogin

Recent searches

No recent searches

Search options

Only available when logged in.
veganism.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
Veganism Social is a welcoming space on the internet for vegans to connect and engage with the broader decentralized social media community.

Administered by:

Server stats:

260
active users

veganism.social: AboutStatusProfiles directoryPrivacy policy

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

#rfc

1 post1 participant0 posts today
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>
RFC Editor<p>RFC 9721: Extended Mobility Procedures for Ethernet VPN Integrated Routing and Bridging (EVPN-IRB), N. Malhotra, Ed., et al., <a href="https://www.rfc-editor.org/info/rfc9721" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9721</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 specifies extensions to the Ethernet VPN Integrated Routing and Bridging (EVPN-IRB) procedures specified in RFCs 7432 and 9135 to enhance the mobility mechanisms for networks based on EVPN-IRB. The proposed 1/3</p>
RFC Editor<p>RFC 9711: The Entity Attestation Token (EAT), L. Lundblade, et al., <a href="https://www.rfc-editor.org/info/rfc9711" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9711</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> An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service 1/2</p>
RFC Editor<p>RFC 9742: A YANG Data Model for Syslog Management, J. Clarke, Ed., et al., <a href="https://www.rfc-editor.org/info/rfc9742" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9742</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 YANG data model for the management of a syslog process. It is intended that this data model be used by vendors who implement syslog collectors in their systems. This document is a product of the Network Modeling Working Group of the IETF.</p>
RFC Editor<p>RFC 9766: Extensions for Weak Cache Consistency in NFSv4.2's Flexible File Layout, T. Haynes, et al., <a href="https://www.rfc-editor.org/info/rfc9766" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9766</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 specifies extensions to NFSv4.2 for improving Weak Cache Consistency (WCC). These extensions introduce mechanisms that ensure partial writes performed under a Parallel NFS (pNFS) layout remain coherent and correctly tracked. The 1/3</p>
RFC Editor<p>RFC 9728: OAuth 2.0 Protected Resource Metadata, M.B. Jones, et al., <a href="https://www.rfc-editor.org/info/rfc9728" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9728</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 specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. This document is a product of the Web Authorization Protocol Working Group of the IETF.</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 9767: Grant Negotiation and Authorization Protocol Resource Server Connections, J. Richer, Ed., et al., <a href="https://www.rfc-editor.org/info/rfc9767" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9767</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 Grant Negotiation and Authorization Protocol (GNAP) defines a mechanism for delegating authorization to a piece of software (the client) and conveying the results and artifacts of that delegation to the software. This extension defines 1/2</p>
RFC Editor<p>RFC 9765: RADIUS/1.1: Leveraging Application-Layer Protocol Negotiation (ALPN) to Remove MD5, A. DeKok, <a href="https://www.rfc-editor.org/info/rfc9765" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9765</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 Application-Layer Protocol Negotiation (ALPN) extensions for use with RADIUS/TLS and RADIUS/DTLS. These extensions permit the negotiation of an application protocol variant of RADIUS called "RADIUS/1.1". No changes are 1/2</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>
RFC Editor<p>RFC 9753: Extension for Stateful PCE to Allow Optional Processing of Path Computation Element Communication Protocol (PCEP) Objects, C. Li, et al., <a href="https://www.rfc-editor.org/info/rfc9753" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9753</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 introduces a mechanism to mark some of the Path Computation Element Communication Protocol (PCEP) objects as optional during PCEP message exchange, so the stateful Path Computation Element 1/2</p>
Al Zheimer<p><a href="https://framapiaf.org/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a> <a href="https://framapiaf.org/tags/internet" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>internet</span></a> <a href="https://framapiaf.org/tags/tcp" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>tcp</span></a> <a href="https://framapiaf.org/tags/ip" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ip</span></a></p>
RFC Editor<p>RFC 9761: Manufacturer Usage Description (MUD) for TLS and DTLS Profiles for Internet of Things (IoT) Devices, T. Reddy.K, et al., <a href="https://www.rfc-editor.org/info/rfc9761" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9761</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 extends the Manufacturer Usage Description (MUD) specification to allow manufacturers to define TLS and DTLS profile parameters. This allows a network security service to identify unexpected (D)TLS usage, 1/2</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>
Kriptofoni<p>🔎 <a href="https://mastodon.social/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a> Token Yatırımcısı 20 Kat Getiri Elde Etti</p><p>🔸 Yatırımcı, 12 milyon adet RFC token ile büyük bir pozisyon koruyor. <br>🔸 Küçük satışlar yaparak yükseliş beklentisini sürdürdüğünü gösteriyor. </p><p><a href="https://ift.tt/xsKlTFb" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="">ift.tt/xsKlTFb</span><span class="invisible"></span></a></p>
Feu d'jais 🥑<p>Les gens qui lisent des RFC, coment je peus retrouver à quoi se réfère [TLS-CERTS] dans la frase :</p><p> Certain terms related to certificates, domains, and application<br> service identity are to be understood in the sense defined in<br> [TLS-CERTS];</p><p>Sur une autre ligne du chapitre sur la terminologie, il y a la même chose mais avec un numéro de RFC donc c'est plus simple à retrouver. Là je ne comprends pas ce que c'est.</p><p>Merci !</p><p><a href="https://eldritch.cafe/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</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" target="_blank">@<span>bogdan</span></a></span> anything that mandates <a href="https://infosec.space/tags/2FA" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>2FA</span></a> and doesn't provide <a href="https://infosec.space/tags/TOTP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TOTP</span></a> or <a href="https://infosec.space/tags/HOTP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>HOTP</span></a> support as per <a href="https://infosec.space/tags/RFC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC</span></a> but demand something like <a href="https://infosec.space/tags/PhoneNumbers" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PhoneNumbers</span></a> that are <a href="https://infosec.space/tags/PII" class="mention hashtag" rel="nofollow noopener" 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" target="_blank">#<span>PGP</span></a>-based 2FA as a compromise...</li></ul>
RFC Editor<p>RFC 9752: Conveying Vendor-Specific Information in the Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE, C. Li, et al., <a href="https://www.rfc-editor.org/info/rfc9752" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9752</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 specifies extensions to the Path Computation Element Communication Protocol (PCEP) that enable the inclusion of vendor-specific information in stateful Path Computation Element (PCE) 1/3</p>
RFC Editor<p>RFC 9764: Bidirectional Forwarding Detection (BFD) Encapsulated in Large Packets, J. Haas, et al., <a href="https://www.rfc-editor.org/info/rfc9764" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">rfc-editor.org/info/rfc9764</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 Bidirectional Forwarding Detection (BFD) protocol is commonly used to verify connectivity between two systems. BFD packets are typically very small. It is desirable in some circumstances to know not only that the path between two systems is 1/3</p>
VegansExploreLive feeds
About