Re: WG Review: Enhancements to Internet email to support diverse ser

--On Tuesday, 28 January, 2003 18:12 -0500 Jacqueline Hargest 
<jhargest(_at_)ietf(_dot_)org> wrote:
> A new IETF working group has been proposed in the Applications
> Area.  The IESG has not made any determination as yet.
>
> The following description was submitted, and is provided for
> informational purposes only.
>
>
> Enhancements to Internet email to support diverse service
> environments (lemonade)
> --------------------------------------------------------------
> ----
>
> Current Status: Proposed Working Group
>
> Description of Working Group:
>
> Lemonade brings together a body of work related to Internet
> messaging, in particular work done by the VPIM, FAX, IMAPEXT<
> and other IETF working groups. The goal is to provide a set of
> enhancements and profiles of Internet email submission,
> transport, and retrieval protocols to facilitate operation in
> environments which use Internet-based technologies but which
> have link characteristics, device characteristics, or service
> environments that are significantly different from those
> common on the Internet.  A primary goal of this work is to
> ensure that those profiles and enhancements continue to
> interoperate with the existing Internet email protocols in use
> on the Internet, so that these environments and more
> traditional Internet users have access to a seamless service.
> ...
Hi.

I'm finding this proposal deeply troubling and have been 
wondering whether to speak up.  Kre's note convinced me that I 
should.
There is a rather fundamental architectural question underlying 
this proposal.  The proposed charter assumes a particular answer 
to that question.  I believe that the community has reviewed the 
general question on a number of occasions and that it has 
usually come to the opposite answer.  It would be good, I think, 
to address that architectural question seriously in this case 
and to be sure that the solution-set proposed is the one we 
want.  And I don't think that can be done by a WG, or proto-WG, 
that is anxious to charge ahead on a particular path: I think it 
has to be an IAB or IESG task, or one delegated by them and 
responsible to them.
Details:  It has long been the conventional wisdom in the 
community that protocols that are low-complexity and that have 
few options will generally deploy more rapidly and widely, 
interwork better, and cause fewer problems than protocols that 
are highly complex in operation or that have very extensive or 
complex combinations of options and variations.  We have 
believed that principle strongly enough to include it explicitly 
in a number of Standard-level protocol documents (e.g., see the 
introduction to STD10/RFC1869), so there is reason to assume 
community consensus about it.   It has also been the 
conventional wisdom, backed by considerable bad experience, that 
adding functionality that is not obviously relevant to a 
protocol, simply because that protocol is there and available, 
is not a good idea.
It is widely believed that IMAP is already too complex, that it 
has too many options and variations, and that those factors have 
contributed to a shortage of implementations.  While it is hard 
to quantify that belief in protocol terms, it has often been 
observed that there are many implementations of POP3 servers 
that are suitable for use on home or small business servers. 
While there are a number of IMAP implementations that are 
suitable for enterprise use, with multiple server complexes and 
dedicated and/or expert support staff, estimates of the number 
of conforming servers suitable for SOHO situations and with any 
conforming client range between zero and one.  That is not a 
good situation, and there have been discussions within the IETF 
about starting "IMAP lite" efforts.
Now we have a WG proposal which seems to have a major theme of 
adding more capabilities and options to IMAP, including some 
capabilities (like streaming) that are not obviously connected 
with IMAP's core purpose or definition.  Architecturally, there 
are many other options for accomodating those capabilities, 
including designing a multi-protocol framework that would permit 
specialized protocols for streaming to interwork well with IMAP 
but without adding significant complexity or options to IMAP 
itself.  I am not sure whether one of those approaches would be 
better than proposals for additional IMAP capabilities.  But I 
believe that we should address those possibilities --and the 
costs of add more bulk and complexity to IMAP-- in a serious way 
before launching a WG to figure out how to put these things into 
IMAP.
As part of that effort, I think we should make a definite 
decision about the "IMAP Lite" discussions. If we want, or need, 
to move in that direction, than "IMAP-even-bigger" is not 
rational; if "IMAP Lite" would be a good idea (or is necessary 
to get serious deployment), then a proposal like this one is 
nearly incomprehensible.
    john