Mastodawn

Smart #SIP experts and myself are currently considering whether it is compatible with #RFC 5658 to specify two record-route lines with identical host parts and different transports. This is what it looks like in the request:
INVITE sip:+49...421@tel.t-online.de;user=phone SIP/2.0
Record-Route: <sip:192.168.5.205:5061;transport=tls;r2=on;lr;did=c4d.4a52;lr>
Record-Route: <sip:192.168.5.205:5060;transport=UDP;r2=on;lr;did=c4d.4a52;lr>
Provider Deutsche #Telekom responds with a 400 Reject.
Now we asking us whether double Record-Routing logic as mentioned in the #RFC5658 is supported by DT provider that way or who can clarify that question. Comments welcome.

thefishofdeath 15h ago

I scored 14/21 on https://e-mail.wtf and all I got was this lousy text to share on social media.

#rfc #mail

Email is Easy

Everyone knows what an email address is, right?

e-mail.wtf

Fabio Alessandro "Fale" Locati 19h ago

Today I discovered the RFC 9460 and therefore the SVCB and HTTPS resource records. Very interesting and useful innovation :)

https://www.rfc-editor.org/rfc/rfc9460

#RFC9460 #RFC #DNS #SVCB #HTTPS

RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)

This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy.

Markus Henn 19h ago

I scored 14/21 on https://e-mail.wtf and all I got was this lousy text to share on social media.

#EMail #WTF #Standard #RFC

Email is Easy

Everyone knows what an email address is, right?

e-mail.wtf

Jef 1d ago

I scored 9/21 on https://e-mail.wtf and all I got was this lousy text to share on social media.

#email #internet #rfc

Email is Easy

Everyone knows what an email address is, right?

e-mail.wtf

Show thread

T_X 2d ago

@Natanox @librecast @EU_Commission @dentangle regarding big, "fundamental" hurdles: I stumbled over the following 2 issues:
https://issuetracker.google.com/issues/149630944
And: https://mailarchive.ietf.org/arch/msg/pim/ULFLgUK2tBTGkFu6lv9jjknaMsk/
The former finally seems to have a fix but it will need some years until people have updated or replaced their Android phones.
The latter does not seem to have a solution yet, someone needs to write an #IETF #RFC for that.
(and stumbled over many issues with the Linux bridge over 15yrs, but they are hopefully solved now)

Google Issue Tracker

ede@kakam:~#3d ago

GuMo #Fedi,
ich habe eine Herausforderung. Ich möchte ein GastWiFi mit Disclaimer bauen. In dem WiFi soll der Disclaimer aufgehen, wenn sich mit dem WLAN verbindet. Laut #RFC soll das der #rfc8910 (?) sein. Ich auch im #ipv4 Option 114 mit https://example.com konfiguriert. Aber der Disclaimer wird nicht auf mobilen Endgeräten angezeigt. Was mache ich falsch? Muss ich anders vorgehen? Gibt es irgendwo eine Anleitung wie es korrekt sein muss?