rfc6764 describes a mechanism for caldav service providers to expose exactly where their server is located while requiring minimal input from the user.
The main intent here is that if you are hosting your email and calendar for
example.com, your users only need to provide their calendar application with
the domain example.com and it can automatically figure out exactly where the
caldav server is located. Let’s assume, for this example, that the caldav
service is located at https://dav.example.com/caldav/.
First of all, a DNS record indicates the domain where the server runs. This can be another domain, or a subdomain:
_caldavs._tcp SRV 0 1 443 dav.example.com.
And a separate record that indicates the path at which the caldav server runs on that host:
_caldavs._tcp TXT path=/caldav
This prevents the user from having to figure out the exact path and port to provide to the calendar application.
Some real life examples:
_caldavs._tcp.posteo.de. 300 IN SRV 0 0 8443 posteo.de.
_caldavs._tcp.posteo.de. 300 IN TXT "path=/"
_caldavs._tcp.fastmail.com. 2923 IN SRV 0 1 443 d277161.caldav.fastmail.com.
Fastmail doesn’t have a TXT record. Instead it uses another approach specified
in the RFC: the well-known path /.well-known/caldav redirects to the real
path where the caldav server runs.
There’s nothing extremely complicated here, and this mechanism makes life a lot easier for end users. Without it, users would have to dig through their provider’s documentation to find the exact URL and port and copy-paste all that into their calendar application. It’s not terrible, but far from a pleasant experience.
If you are hosting a public caldav service and don’t have discovery set up, I encourage you to look into it. It’s a one-time kind of setup that will make life easier for many of your users (and even yourself when configuring new devices).