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.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 IMAPBefore 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. ...
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.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.)
Well, we agree, but it is hard to figure that out from the draft charter.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.
See below.
As the charter is written, it could be, even if it is your intent to avoid that particular path.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.
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.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.
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