From: Dave Crocker <dhc(_at_)dcrocker(_dot_)net> <dhc(_at_)dcrocker(_dot_)net>
Reply: dcrocker(_at_)bbiw(_dot_)net <dcrocker(_at_)bbiw(_dot_)net>
<dcrocker(_at_)bbiw(_dot_)net>
Date: 7 February 2017 at 14:21:10
To: Gren Elliot <fatkudu(_at_)gmail(_dot_)com> <fatkudu(_at_)gmail(_dot_)com>
Cc: jmap(_at_)ietf(_dot_)org <jmap(_at_)ietf(_dot_)org>
<jmap(_at_)ietf(_dot_)org>, iesg <iesg(_at_)ietf(_dot_)org>
<iesg(_at_)ietf(_dot_)org>, ietf(_at_)ietf(_dot_)org <ietf(_at_)ietf(_dot_)org>
<ietf(_at_)ietf(_dot_)org>
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