[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WG Review: Enhancements to Internet email to supportdiverse service environments (lemonade)

--On Wednesday, 29 January, 2003 13:28 -0600 Pete Resnick <presnick@qualcomm.com> wrote:

On 1/29/03 at 1:40 PM -0500, John C Klensin wrote:


Now we have a WG proposal which seems to have a major theme
of  adding more capabilities and options to IMAP

Before everyone ends up latching onto this: You quite
conveniently ignore something very important in the first
statement of purpose in the charter: "The goal is to provide a
set of enhancements AND PROFILES" (my emphasis). One of the
major themes, at least in my mind, is to profile down IMAP for
the purposes of these more limited environments.
...
But, Pete, for reasons you presumably understand, "profiles" (note plural) gives me as much anxiety as "lets add lots more excrement to this protocol". Granted that it would be harder to make a complete mess of a mail-retrieval protocol than of a transport one, but "we will develop a minimal profile for this specific/ limited environment" and then "we will develop a minimal profile for that other specific/ limited environment" are the traditional signposts along the route to profiles that don't interoperate and a need to reply to email by picking up the phone.

Yes, it is
certainly true that there are a couple of extensions to IMAP
being proposed, and I don't doubt that they should be met with
scrutiny. (More on this in my earlier response to kre and
below.)
One of them is potentially very heavyweight. As you point out, there are other solutions to it, but the charter doesn't appear to prevent the WG from inventing some wildly new, and complex, way to handle the issue. If it has already been decided that the WG won't go down that path, then the charter should say so. If it has been agreed that the WG isn't going to do that unless it turns out to be absolutely necessary, then the decision point about "absolutely necessary", and another opportunity for community review if it is determined to be necessary, should be reflected in the milestones.

But I think the more important thing for this group to
do is to find a way to avoid much of the huge complexity IMAP.
One of the sources of this complexity is that there are so
many optional extensions to IMAP that are implemented to such
varying degrees by servers (and with such huge impacts on
functionality) that no client has any reasonable chance of
interoperating without being terribly complex. One of the
primary outcomes of this working group should be a profile of
IMAP that is devoid of options, that removes features who's
primary purpose is to support particular implementations
choices at the expense of interoperability, and gives folks in
low-capability environments a chance to produce a decent
implementation.
Well, we agree, but it is hard to figure that out from the draft charter.

If this is what you mean by "IMAP Lite", I would contend that
this is the architectural choice that this particular proposed
WG has made.

See below.


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.

If I understand you correctly, at least one of the proposals
on the table (CHANNEL) does exactly this kind of thing:
Instead of providing some sort of specialized streaming in
IMAP, it instead introduces a referral mechanism, where a
client can ask the server for a referral to a different
protocol to stream the data. Whether this is a good idea or
not can be debated, but this particular item is not an example
of bloating IMAP with wild new features.
As the charter is written, it could be, even if it is your intent to avoid that particular path.

I think there should be a great deal of pressure on this group
to *not* bloat IMAP, and in fact rather to shrink it. However,
there is nothing in the proposed charter (or in the mind of
this particular member of that proposed WG) that should give
you the impression that the intention is otherwise.
Pete, my difficulty here is that there has been a lot of discussion the community in the last few months about basic IETF problems. Two of the issues that have come up many times involve the IESG second-guessing the outputs of WGs and our having significant architectural/design issues raised only after the WG thinks it is finished. I think there is general agreement that it is very bad situation if a WG goes off and produces a piece of work that falls within its charter, only to be confronted with arguments during Last Call that the result is just too complex and that the WG should be sent back to the drawing board.

The charter draft, as written, pretty clearly would permit the WG to consider and adopt some strategies that I won't find architecturally acceptable and that, I gather, you wouldn't either. If no one intends to go in those directions, let's rewrite the charter to make that clear. If the WG needs to look in those directions without expecting to go there, then let's put that in the charter, with provision for a plenary discussion or an IETF Last Call _before_ the in-depth protocol work has been done, so we don't end up with late-breaking "surprise" effects.

Finally, if the intent is really to prune, then I'd expect pruning to appear prominently in the description. Instead, both the title and the text seem to point mostly to enhancements. And, for whatever it is worth, I seem to recall discussions when the IMAPEXT WG was chartered that there would be no work on major enhancements until/unless there was a "strip it down" effort first. If the plan here were to emit a lighter-weight, fewer-options, version of IMAP (one, not a family of profiles) and then to start work on streaming and notification, I would be much happier than if --by intent or appearance-- the idea is to have some profiling emerge from an effort to move IMAP into previously untrod ground.

john