On Thu, 27 May 2004, Pete Maclean wrote:One element seems wrong but I am not 100% certain. This server (which I cannot identify since it has not been identified to me) claims IMAP4Rev1 compliance by virtue of its initial response (* OK IMAP4rev1 Service Ready).
IMAP4rev1 compliance is indicated by "IMAP4REV1" appearing in the CAPABILITY list.
I stand corrected. Thank you!
But when sent a SELECT command that succeeds, it does not return a UIDVALIDITY response.
Unless that server is IMAP2, it is broken.
There is no CAPABILITY response in the session so I will have to find out what the server thinks it is. (It is clear from other things that it's seriously broken no matter what version of IMAP it is pretending to operate.)
Now RFC 3501 states that, "If [the UIDVALIDITY response] is missing, the server does not support unique identifiers."
Please read a few paragraphs higher in RFC 3501: Note that earlier versions of this protocol only required the FLAGS, EXISTS, and RECENT untagged data; consequently, client implementations SHOULD implement default behavior for missing data as discussed with the individual item.
In other words, if UIDVALIDITY is missing, the server is an IMAP2 server.
May I suggest that, for implementers who have no knowledge of IMAP2 and no requirement to provide backward compatibility, this could be made clearer.
Pete Maclean
