Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity

[Gren Elliot <fatkudu@xxxxxxxxx>]

From: Dave Crocker <dhc@xxxxxxxxxxxx>
Reply: dcrocker@xxxxxxxx <dcrocker@xxxxxxxx>
Date: 7 February 2017 at 14:21:10
To: Gren Elliot <fatkudu@xxxxxxxxx>
Cc: jmap@xxxxxxxx <jmap@xxxxxxxx>, iesg <iesg@xxxxxxxx>, ietf@xxxxxxxx <ietf@xxxxxxxx>
Subject:  Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity 

On 2/7/2017 3:26 AM, Gren Elliot wrote: 
> Just to add my voice to the call for easier configuration where we don’t 
> force users to configure countless different things. Trying to setup a 
> new device for use with open protocols is a complete nightmare - you end 
> up needing to configure 2 things for mail (IMAP and SMTP) 
... 
> It would be nice to see config dialogs where user’s are asked for 
> minimal information (user name, perhaps server name) and then the device 
> discovers what is available there (Mail/Contacts/Calendar/…) and offers 
> the user a way to select them and 


This issue is for user interface design, not underlying protocol design. 
Hence while it is extremely important in terms of usability, it is 
outside the scope of the IETF. 

With the current standards landscape, there is no way round the fact that users (often not tech savvy ones) need to specify separate hostnames and ports for IMAP and message submission, plus potentially URLs for CalDAV / CardDAV (the latter 2 could reasonably be combined without IETF help but sadly seldom are).  Without further standardisation, no wonderful interface design can escape from that.  I certainly think that it should be within the scope of the IETF to improve the standards to the point where good interface design is possible.  That doesn’t actually require moving to a single protocol.  As mentioned before in relation to aggregated service discovery, this could be achieved by standardising a bootstrapping mechanism where the user only provides minimal information which points to a store of detailed configuration information that the user never needs to be aware of.  Alternatively, or perhaps in addition, having a single protocol would achieve most of the same aims - much as ActiveSync achieves and I hope JMAP will achieve.

Having these functions embedded into a single protocol implicitly 
requires that these different functions share the same configuration 
data. While such sharing might be common practice, requiring the 
sharing limits operational choices. 

Requiring sharing would indeed limit operational choices - so it shouldn’t be required.  I think it is important that a JMAP service should be able to offer (and advertise) whatever subset of full services it wants to.  In the most common situation, a single JMAP service would provide mail access, mail submission, contacts access, calendar access etc, but there is no reason why multiple, dedicated JMAP services couldn’t be used, one just doing mail access, one doing mail submission etc.  In the most common situation, you would be much better off than you are now.  In the other case, you would be no worse off than you are currently and at least there would be consistency in how you configure each service.

Regards,

Gren Elliot