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. 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.) 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.
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.
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.
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.
pr
--
Pete Resnick <mailto:presnick(_at_)qualcomm(_dot_)com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102