On Mon, 13 Feb 2012, Bron Gondwana wrote:
And I'd rather do it in public than in secret right up until the IETF process bit.
You will never make much progress as long as the initial design process is burdened with that monkey on its back. The best way to destroy any project is to subject it to review at that stage.
Do you still have your un-"improved" specification and interoperable code sitting around somewhere that you can show us all how nice it was before the grandmothers improved it? I'd be interested to see so I can tell what I'm in for.
Knowledge of the original IMAP (before IMAP2) exists primarily in my mind as all the original IMAP specifications and implementations were replaced with IMAP2. The only substantial difference between original IMAP and IMAP2 was the introduction of tags in IMAP2. In original IMAP, a response started with one of "OK", "NO", "BAD", "BYE", or "*". That incompatibility is caused the "2". Since it was still possible to replace all the "old protocol" implementations, there was no attempt at IMAP/IMAP2 compatibility. A secondary effect was the much-maligned advent of untagged OK/NO/BAD responses. As it turned out, tags never were as important for pipelining as its advocates claimed. The vast majority of Internet protocols pipeline do just fine without tags, although I admit ManageSieve did it in a cool way. The motivation for tags was the quaint idea (which I never believed back then) that an IMAP server will routinely have requests blocked while waiting for the computer operator to mount a 9-track tape or optical disk. Thus it was purportedly important for responses to arrive out of order for the request, and all clients must be completely asynchronous. Of course, that never happened... Post-IMAP2, there are all the past IMAP RFCs. The ftp.cac.washington.edu FTP site still has many of the IMAP2bis drafts on the mail/old/ directory, as well as the RFC drafts. There is quite a lot to review there. The history of IMAP2bis is particularly important, as it explains a great deal of the process from RFC 1176 to RFC 1730 which would otherwise be an unbridgeable gap. In turn, RFC 1730 to RFC 2060 shows what happens when a set of last-minute additions (to RFC 1730) are put in without adequate thought and consideration. There is a BIG lesson to learn from that abortion. RFC 2060 is the RFC 1176 replacement protocol in more or less final form. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ imap5 mailing list [email protected] https://www.ietf.org/mailman/listinfo/imap5
