wasm-demo/demo/ermis-f/imap-protocol/cur/1600095129.22883.mbox:2,S

36 lines
1.4 KiB
Plaintext

MBOX-Line: From janssen at parc.com Sun Jan 27 17:18:42 2008
To: imap-protocol@u.washington.edu
From: Bill Janssen <janssen@parc.com>
Date: Fri Jun 8 12:34:41 2018
Subject: [Imap-protocol] updated table of IMAP client capabilities
In-Reply-To: <alpine.OSX.1.00.0801271630280.21314@pangtzu.panda.com>
References: <08Jan27.162746pst."58696"@synergy1.parc.xerox.com>
<alpine.OSX.1.00.0801271630280.21314@pangtzu.panda.com>
Message-ID: <08Jan27.171846pst."58696"@synergy1.parc.xerox.com>
> Yes: STARTTLS, SASL (GSSAPI, CRAM-MD5, PLAIN, LOGIN, EXTERNAL),
> SSL, NAMESPACE, MULTIAPPEND, UIDPLUS, CHILDREN, SORT, THREAD
>
> No: SASL-IR, ESEARCH, IDLE, LITERAL+, LEMONADE
> ;;; For the purposes of Pine/Alpine:
> ;;;
> ;;; SASL-IR adds complexity just to save one RTT. We have
> ;;; enough problems with servers getting SASL right as it is.
> ;;; ESEARCH has no constituency within our user community.
> ;;; IDLE is unnecessary except for mobile devices, and has
> ;;; problems when NAT is in use.
> ;;; LITERAL+ is not needed since MULTIAPPEND is used instead,
> ;;; and MULTIAPPEND solves problems that LITERAL+ does not.
> ;;; LEMONADE support is under consideration.
>
Thanks, I've updated the table.
> UW imapd implements all of the above except for LEMONADE. LEMONADE
> support is under consideration.
It would be interesting to do another table for servers, I suppose.
Bill