Breaking changes between version 1.1 and 1.2 (and the future of AutoConfig)

[ben221199]

When comparing my schemas, this are the changes between 1.1 and 1.2:

1. Add <url> inside <incomingServer>
2. Make <hostname>, <port>, <password> and <socketType> inside <incomingServer> optional
3. Add http-basic as value for <authentication> inside <incomingServer>
4. Add jmap, ews and activesync to the enum for the type attribute on <incomingServer>
5. Make <password> inside <outgoingServer> optional
6. Add <addressBook>, <calendar>, <fileShare>, <mAuth>, <enable>, <clientConfigUpdate> on <clientConfig>
7. Add <inputField> on <clientConfig>

There may be more changes that I missed, but I will go with these for now.

---

By the way that ThunderBird is implemented, I assume that extended enums (change 3 and 4) will break the code. Also, in change 1, <url> is used instead of <hostname> and <port>, which likely breaks many clients that expect an hostname and port. Change 7 seems to me like a mistake, because <inputField> was inside <emailProvider> before. And last, I don't like change 6.

In my conclusion, we can minimalize the breaking changes problem to introduce a new 1.2 URL instead of building on the same URL.

---

Also, I don't think we should add all those other types of services in this AutoConfig. Currently, the 1.1 URL is http://autoconfig.$DOMAIN/mail/config-v1.1.xml?emailaddress=$EMAILADDRESS (or http://$DOMAIN/.well-known/autoconfig/mail/config-v1.1.xml?emailaddress=$EMAILADDRESS). Notice the mail part in the URL, so let this be AutoConfig Mail, and lets make an AutoConfig Calendar and AutoConfig Contacts seperately. We may link those URLs in some general AutoConfig file.

For now, XML is fine for 1.2, but when developing 2.0, the switch to JSON seems pretty straight forward.

[ben221199]

Example of my idea:

AutoConfig 1.*

The XML versions.

AutoConfig (new spec):

<clientConfigList version="1.0">
  <clientConfig url="https://autoconfig.mozzila.com/mail/config-v1.1.xml" type="mail" version="1.1"/>
  <clientConfig url="https://autoconfig.mozzila.com/mail/config-v1.2.xml" type="mail" version="1.2"/>
  <clientConfig url="https://autoconfig.mozzila.com/calendar/config-v1.0.xml" type="calendar" version="1.0"/>
  <clientConfig url="https://autoconfig.mozzila.com/contacts/config-v1.0.xml" type="contacts" version="1.0"/>
</clientConfigList>

AutoConfig Mail (this spec):

<clientConfig version="1.0, 1.1 or 1.2">
  <emailProvider>
    ...
  </emailProvider>
</clientConfig>

AutoConfig Calendar (new other spec):

<clientConfig version="1.0">
  <calendarProvider>
    ...
  </calendarProvider>
</clientConfig>

AutoConfig Contacts (new other spec):

<clientConfig version="1.0">
  <contactsProvider>
    ...
  </contactsProvider>
</clientConfig>

AutoConfig 2.*'

The JSON versions.

AutoConfig (all specs in one):

{
  "providers" : [
    ...
  ]
}

[benbucksch]

When comparing my schemas, this are the changes between 1.1 and 1.2:

Add <url> inside <incomingServer>
Make <hostname>, <port>, <password> and <socketType> inside <incomingServer> optional

Does XSD support something like "subclasses"? That you can define <incomingServer> more generally, and then specifically for each protocol?

In 1.2 (the current spec), a config

<incomingServer type="imap">
  <url>https://example.com</url>
</incomingServer>

is not valid. And a JMAP server without URL and with hostname and port is not valid.

Version 1.1 supported only IMAP and POP3 and therefore the problem didn't appear.

Add `http-basic` as value for `<authentication>` inside `<incomingServer>` 

Ditto. Not valid for IMAP, but only for configs with a URL.

Make `<password>` inside `<outgoingServer>` optional

Password was always optional for both incomingServer and outgoingServer

Add `<addressBook>, <calendar>, <fileShare>, <mAuth>, <enable>, <clientConfigUpdate>`
Add `<inputField>`

<enable>, <clientConfigUpdate>, <inputField> were already there in 1.1 spec, but are not used by Thunderbird.

https://wiki.mozilla.org/index.php?title=Thunderbird:Autoconfiguration:ConfigFileFormat&oldid=1227306 (revision from 2020)

[benbucksch]

By the way that ThunderBird is implemented, I assume that extended enums (change 3 and 4) will break the code. Also, in change 1, is used instead of and , which likely breaks many clients that expect an hostname and port.

hm, interesting. I checked. From how I wrote the Thunderbird code back then, and how I read it now, there is a try/catch around the processing of an <incomingServer> element. Yes, type="jmap" would throw, it would be cause inside the for loop, and the code would start reading the next <incomingServer>. After the loop, there's a check whether any valid <incomingServer> was found. If so, that config is used and the "invalid" (actually not yet supported) config is simply ignored. If no config at all is found (if (!d.incoming.hostname)), then it would throw the error and stop.

So, effect is: Thunderbird would ignore an <incomingServer type="jmap"> as if it doesn't exist, and continue reading the rest of the config. So, I don't see a problem.

Would you concur with my reading of the code?

You have a good point, though: The spec should mandate clients to ignore config parts that the client cannot understand, but process the rest. This is the only way that we can continue evolving the spec. Otherwise we're completely stuck.

[benbucksch]

Example of my idea:

<clientConfigList version="1.0">
  <clientConfig url="https://autoconfig.mozzila.com/mail/config-v1.1.xml" type="mail" version="1.1"/>
  <clientConfig url="https://autoconfig.mozzila.com/mail/config-v1.2.xml" type="mail" version="1.2"/>
  <clientConfig url="https://autoconfig.mozzila.com/calendar/config-v1.0.xml" type="calendar" version="1.0"/>
  <clientConfig url="https://autoconfig.mozzila.com/contacts/config-v1.0.xml" type="contacts" version="1.0"/>
</clientConfigList>

Thanks for the idea. But I disagree here.

1. All services that hosters provide to users and that mail apps may reasonably implement should be in the config. Even chat and video conference accounts. The mail client should have to read only this one file to set up this email account with all associated services.

2. Creating multiple separate autoconfig protocols or URLs creates more burden for implementors, and we'll need to make even more URL queries. We already have many URL queries, to cover different scenarios and providers. I don't want to multiply by 4 or 6. It would also increase the possibilities to fail.

3. An email client should also sync contacts, otherwise it's hard to send mail. If it does calendar, and the email account supports calendar sync, why would you not have that set up? If you do, why not do it in the same doc?

4. The separation makes even less sense for protocols like JMAP, EWS, ActiveSync, MS Graph. Basically all modern mail protocols come with contact and calendar sync already built in, on the very same server connection. Why artifically separate it for autoconfig, when it's already united in the server protocols?