883082 - Support for full auto discovery of calendars

Status: RESOLVED DUPLICATE of bug 306495

(Calendar :: Lightning Only, defect)

Description

[Daniël van Eeden]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.22 (KHTML, like Gecko) Ubuntu Chromium/25.0.1364.160 Chrome/25.0.1364.160 Safari/537.22

Steps to reproduce:

This is how full auto discovery of calendars could work:

1. The users enters:
username: [e-mail]
password: testpassword

2. The the server uses DNS SRV to locate the calendar server, port, tls/ssl settings 
it does a lookup for _caldavs._tcp.example.com (and also _cladav._tcp). The result can be a list of calendar servers (with priority and weight):
Server: caldavs://cal.example.com:443

3. Then DNS TXT or well-known URIs can be used to find the calendar path
caldavs://cal.example.com:443/.well-known/caldav (often a http redirect to where the real caldav path)

4. Then the client then uses PROPFIND to fetch a list of calendars.





Actual results:

Auto discovery is currently not supported.


Expected results:

1. The UI should ask for email address and password instead of calendar type (WCAP, CalDAV, et) and URI.

2. DNS SRV/TXT and well-known URIs should be used for auto discovery

3. A list with calendars and/or task lists should be fetched from the server.

Comment 1

[Daniël van Eeden]

An alternative method would be to re-use the ISPDB/ConfigServer which is used for email autoconfiguration.

https://developer.mozilla.org/en-US/docs/Thunderbird/Autoconfiguration

This bug is geared towards CalDAV. 
For the other protocols:
iCalendar: Doesn't support autodiscovery as far as I known
WCAP: I don't known about autodiscovery, but this protocol is mainly used by Oracle CommSuite and they also support CalDAV and auto discovery (since Calendar Server 7 Update 1)

https://wikis.oracle.com/display/CommSuite/Calendar+Server+7+Administration+Guide#CalendarServer7AdministrationGuide-SettingupCalDAVandCardDAVAutodiscovery

Comment 2

[Jesse Thompson]

In order to avoid the vulnerability whereby DNS poisoning could be used to harvest end-user passwords, lookup of the calendar server using DNS requires enforcement of DNSSEC (which isn't widely deployed). https://bugzilla.mozilla.org/show_bug.cgi?id=672239  Otherwise, a .well-known scheme (similar to ConfigServer) will be necessary (even though .well-known schemes aren't always perfect or desirable)

This would be a good opportunity to take a look at the evolving standards for frameworks for secure delegation and strong domain name associations (DNA).  For example: POSH
http://tools.ietf.org/html/draft-miller-xmpp-posh-prooftype-03

Comment 3

[Philipp Kewisch [:Fallen][☁️📆]]

Sorry for marking both of your bugs duplicate to the same bug, but I think its best to get started with bug 306495 first. Depending on who solves it, there may be support for both well-known and DNS queries. Once that bug is fixed we can figure out what remaining bugs need to be filed.