71 lines
3.2 KiB
Plaintext
71 lines
3.2 KiB
Plaintext
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
|