RFC 6764 bootstrapping order

[dilyanpalauzov]

According to RFC 6764 Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV), the WebDAV client shall first check for SRV/TXT records and if these fail, try domain/.well-known/caldav/ (or /carddav/) . When I setup Advanced account: base address aegee.org, no username, no password, and inspect the logs, I see that DAVx⁵ 4.2.2 uses the SRV/TXT records as last resort.

In this case, following the bootstriping order from RFC 6764 (first SRV/TXT record, then PROPFIND /.well-known/caldav/) will lead to faster setup.

[rfc2822]

DAVx5 currently alwayss checks both the SRV/TXT records and well-known URLs. Sometimes the SRV/TXT records are not set up correctly, or only set up correctly for one service, or there are temporary problems etc. We want to detect everything that is possible even for incorrect setups.

Is there a specific time problem (setup takes too long - how long?) when setting up the account?

[dilyanpalauzov]

As far as I can see from the logs, DAVx⁵ reads first the .well-known/ addresses, and then the SRV/TXT records. My point was to reverse the order in the implementation: first read the SRV/TXT records and then the .well-known/ addresses. In case DAVx⁵ lookups up anyway both .well-known/caldav/ addresses and SRV/TXT records and evaluates the results of both, independent of each other, reversing the order will not make a difference.

The setup completes within a easonable time.

For the record, DAVx⁵ logs “Looking up SRV records for …”, but does not write “ Looking up TXT records for …”, nevertheless it uses the value from TXT.