Mark Crispin (MRC@CAC.Washington.EDU)
Thu, 13 Dec 2001 08:52:01 -0800 (PST)
On Thu, 13 Dec 2001 13:46:34 +0200, Neystadt, John wrote:
> Marc, the SORT itself is a draft. Why do a separate effort and not include
> it straight in SORT?
That's "Mark". With a "K". Please.
There's the small matter of production code for the past 3 or 4 years.
Furthermore, it's a bad idea from an architecture design to put functionality
into a base protocol unless that protocol is generally useful.
> BTW: I've tried to look in archives and did not found a
> discussion of including a generic HEADER keyword discussion for SORT. Why
> not allow sorting by ANY header?
A proposed functionality has to justify its existence. The fact that a
functionality *can* be done does not mean that it *should* be done. Protocols
need to be implementable by mere mortals in finite time before the sun novas.
This is something that some IETFers seem to have forgotten. IMAP is not a
small protocol, but *everything* in IMAP has a use. There is *nothing* in
IMAP which can be "not implemented" by a server without breaking clients.
This is important. The history of RFCs is littered with good ideas that fell
victim to the "let's add everything plus the kitchen sink." Such protocols
invariably are overtaken by smaller, leaner protocols that do the job and are
implementable by mere mortals in real time.
Do you remember why SMTP is the Simple Mail Transport Protocol?
> Why? If we introduce a new UIDIDLE capability and syntax of
> tag UID IDLE
> with new untagged responses, like:
> S: * 44 UID EXPUNGE
> S: * 108 UID FETCH (FLAGS (\Seen))
> This will not affect existing clients.
Those responses would have to be something like
S: * 23 EXPUNGE (UID 44)
S: * 55 FETCH (FLAGS (SEEN) UID 108)
Nevertheless, this functionality has to justify its existence. It duplicates
existing functionality, for no reason other than to pretend that only UIDs,
not sequence numbers, exist in IMAP. I have seen wretched client behavior due
to that notion. I don't think that it should be encouraged.
> I do believe that this should be done with s single command. Overloading
> server with tens of STATUSes per tens (or hundreds) mailbox-es is a bad
> bahaviour on slow links.
Indeed. So it encourages clients not to do it, and it emphasizes that a
client that does it is a poorly-designed client.
I will vigorously oppose a functionality that gives the client the ability to
launch a denial of service attack on the server with a single command. This
includes LIST extensions unless it is made server-optional what data can be
returned.
> Opening tens of
> connections for tens of visible mailboxes seems to me impractical and will
> severe damage server scalability.
Why is use of the existing (20+ years) multiplexing protocol less scalable
than making an IMAP server multiplex mailboxes?
> With my proposal, server can have a
> special optimized provisions (like subscribe for file system changes
> notifications) and it will be much more efficiently.
And if the back end does not provide such optimized provisions the
multiplexing substantially increases the complexity of an already quite
complex protocol.
> Well, INBOX name is a part of IMAP standard.
And is the only name that has any justification from any other e-mail
protocols.
This archive was generated by hypermail 2.0b3 on Thu Dec 13 2001 - 19:22:52 IST