MBOX-Line: From markrcrispin at live.com  Mon Jul 14 20:12:45 2008
To: imap-protocol@u.washington.edu
From: Mark Crispin <markrcrispin@live.com>
Date: Fri Jun  8 12:34:42 2018
Subject: [Imap-protocol] More questions re IMAP RFCs
In-Reply-To: <487C1289.7000902@verizon.net>
References: <487C1289.7000902@verizon.net>
Message-ID: <BLU126-W35254E159F43B4B4DB4CAFB88C0@phx.gbl>


> 1. Is it required that there be a namespace consisting of ""?

No, although not having it is somewhat pointless.

> If not,
> then what are the implications for INBOX?

INBOX is not part of any namespace.  It is a special reserved name

> Which, if any, other commands imply a housekeeping update? I presume
> CLOSE and LOGOUT would have similar semantics, and another developer
> suggested that EXPUNGE might.

SELECT and EXAMINE would as well.

> Also, which data need not be saved?

Data should always be saved.  The whole point of CHECK is to assist mailbox formats such as the traditional UNIX mbox format in which saving a flag state involves a significant file rewrite.  CHECK should be equivalent to NOOP with superior mail stores.

> 3. For testing purposes, would it be better to:
> a) Return PREAUTH in the initial response
> b) Fail to support LOGINDISABLED as a capability without using TLS
> c) Blithely return OK to all AUTHENTICATE requests (again without TLS)

That's up to you, but relatively few IMAP clients support PREAUTH (it's used primarily with UW's rsh/ssh IMAP functionality).

> 4. How supported and/or stable is the EAI-IMAP-UTF8 spec?

IMHO, it is too knew to rely upon

> a) How does this interoperate with legacy modified UTF-7 mailbox names?

A server that implements EAI-IMAP-UTF8 is responsible for doing all the necessary conversions, for the benefit of a client that does not implement it.  That's a pretty heavy burden on a server.

> b) If a server treats mailbox names as case-insensitive, should it
> treat the UTF-8 names as case-insensitive only with respect to ASCII,
> similar to how the UTF-7 version treated it?

That's up to the server.

However, IMHO, a server that offers case-insensitive mailbox names and UTF-8 mailbox names should be case-insensitive for all of Unicode.  Note that a good IMAP server needs to suppose i;unicode-casemap, so that level of case-independent framework should already exist.

> c) What is the rational behind forbidding UTF-8 non-ASCII characters
> in "" strings?

Mostly legacy reasons, including the need to exterminate the unofficial ISO 8859-1 and Shift-JIS strings.  Quoted strings are of relatively little value except for short ASCII strings.

> d) Are literals assumed to be UTF-8 if not otherwise specified? (e.g.,
> C: 1 SELECT {6+}
> C: mail?
> should be considered a legal mailbox of the name "mail?" and not
> semantically invalid)

Literals have an undefined charset unless something defines it.  This is because there are legacy servers that transmit ISO 8859-1 and Shift-JIS.  There is a 12 year effort to exterminate all such usage.

-- Mark --

_________________________________________________________________
Need to know now? Get instant answers with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_messenger_072008
