Re: UID EXPUNGE

[Ned Freed <[e-mail]>]

> > 	We are suffering badly from creeping featurism ("just add this
> > 	one more thing") and never getting anywhere.  We are being
> > 	criticized for this.  Some of the critics are labelling IMAP4
> > 	as a "failure" because POP3 will reach Standard status
> > 	imminently.

> This is a tremendously important point, folks.  I've been following the
> UID EXPUNGE argument, and I think it is more important to look at the
> implications of this discussion, than the subject itself.  Are we
> saying that IMAP4 isn't ready to go to Standard?  I did not feel that
> was an issue at the conference, but now.....

OK, let's take a quick look at the RFC list for POP:

0918        J. Reynolds, "Post Office Protocol", 10/01/1984. (Pages=5) 
           (Format=.txt) (Obsoleted by RFC0937) 

0937  H     M. Butler, D. Chase, J. Goldberger, J. Postel, J. Reynolds, "Post  
           Office Protocol - version 2", 02/01/1985. (Pages=24) (Format=.txt) 
           (Obsoletes RFC0918) 

1081  PS   M. Rose, "Post Office Protocol - version 3", 11/01/1988. 
           (Pages=16) (Format=.txt) (Obsoleted by RFC1225) 

1082  H    M. Rose, "Post Office Protocol - version 3: Extended service  
           offerings", 11/01/1988. (Pages=11) (Format=.txt) 

1225  DS   M. Rose, "Post Office Protocol - Version 3", 05/14/1991. 
           (Pages=16) (Format=.txt) (Obsoletes RFC1081) (Obsoleted by 
           RFC1460) 

1460  DS   M. Rose, "Post Office Protocol - Version 3", 06/16/1993. 
           (Pages=19) (Format=.txt) (Obsoletes RFC1225) (Obsoleted by 
           RFC1725) 

1725  DS   J. Myers, M. Rose, "Post Office Protocol - Version 3", 
           11/23/1994.  (Pages=18) (Format=.txt) (Obsoletes RFC1460) 

And then for IMAP:

1064  H    M. Crispin, "Interactive Mail Access Protocol: Version 2", 
           07/01/1988. (Pages=26) (Format=.txt) (Obsoleted by RFC1203, 
           RFC1176) 

1176  E    M. Crispin, "Interactive Mail Access Protocol - Version 2", 
           08/20/1990. (Pages=30) (Format=.txt) (Obsoletes RFC1064) 

1203  H    J. Rice, "Interactive Mail Access Protocol - Version 3", 
           02/08/1991. (Pages=49) (Format=.txt) (Obsoletes RFC1064) 

1730  PS   M. Crispin, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4", 
           12/20/1994. (Pages=77) (Format=.txt) 

1731  PS   J. Myers, "IMAP4 Authentication mechanisms", 12/20/1994. (Pages=6) 
           (Format=.txt) 

1732  I    M. Crispin, "IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS", 
           12/20/1994. (Pages=5) (Format=.txt) 

1733  I    M. Crispin, "DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4", 
           12/20/1994. (Pages=3) (Format=.txt) 

So what does this tell us? We have one 18 page protocol, one that does performs
a single very simple, obvious, and straightforward function, that was initially
described in 1984, started on the standards track in 1988, and it still hasn't
reached full standard. That's 12 years elapsed, 6 on the standards track.

And then we have another 77 page protocol, one that performs a number of
different, complicated functions, some of which we have little if any
operational experience to access, that was initially described in 1988 and
started on the standards track in 1994. That's six years elapsed but only a
little more than one the standards track.

Folks, this data tells us that if rapid process on the standards track is
somehow a criteria for success, POP has to be total dismal failure. 6 years on
the track after 6 years in the field? Please!

Now, we all know that POP is not a failure. Far from it. It is very popular and
it is widely used. So what this means is that time spent either reaching the
standards track or spent on the track is not a useful metric for measuring a
protocol's success. In fact it's the opposite: Protocols that move through the
process rapidly are inherently suspect. Every specification has it's flaws,
flaws which only turn up once the protocol has been implemented by a variety of
different constituencies. And this is especially true if the protocol is
complex. A protocol that moves through the process rapidly either is simple and
exceptionally well specified or it isn't being widely implemented by
different constituences who then feed back their assessments into the process.

The inescapable conclusion is that anyone who considers IMAP a failure because
POP is about to become a standard simply doesn't understand the history or the
nature of the process we're involved in. 

IMAP is currently a proposed standard. Proposed standards always describe
protocols the IETF feels are worthy of implementation but are still being
refined. Nothing is certain for a proposed standard: Substantial changes may be
made and the protocol may recycle at proposed. The protocol may also fail and
fall off the standards track.

The next step in the process is draft standard. Draft is quite different from
proposed -- draft means that the IETF believes the protocol to be substantially
complete. Changing a draft standard protocol is hard, and usually involves a
reset to proposed. Recycles at draft are also common when substantive
prose polishing is done (this is going to happen in the case of MIME). This is
a *major* change in status for a protocol.

Standard status is the last step, and is really not much more than confirmation
than the protocol merited the trust involved in moving it to draft.

Back to IMAP. My assessment is that move to draft at this time is premature.
This is a large and complex protocol, there are aspects of it that are not
widely implemented, and the community is still revising the protocol in the
light of operational experience. The UID EXPUNGE discussion is a case in point. 
We need to finish the discussions of these various things, decide what to do,
update the specifications, and if the result has to be recycled at proposed, so
be it.

But this doesn't mean IMAP is a failure. On the contrary, IMAP is obviously
being deployed by a variety of different groups and their assessments are
coming back to the process and causing changes in the protocol. This is good.
This is how the process is supposed to work.

I realize that the Internet is hot shit nowadays and the pressure is on to get
it all done no matter what. But if anything this should make us more cautious:
We cannot afford to advance an email protocol that is broken in any substantial
way. IMAP plays in one of the oldest protocol niches around -- email -- one
where people have set expectations as to how things have to be. You can play
fast and loose in, say, VRML, and nobody will notice because they have nothing
to compare it to. Email isn't like that. It's nothing but comparisons.

				Ned