76 lines
2.8 KiB
Plaintext
76 lines
2.8 KiB
Plaintext
MBOX-Line: From mrc at CAC.Washington.EDU Mon Apr 10 11:14:08 2006
|
|
To: imap-protocol@u.washington.edu
|
|
From: Mark Crispin <mrc@CAC.Washington.EDU>
|
|
Date: Fri Jun 8 12:34:37 2018
|
|
Subject: [Imap-protocol] LIST Clarification
|
|
In-Reply-To: <web-35034698@mail.stalker.com>
|
|
References: <443A7A2D.2070708@consilient.com> <web-35034698@mail.stalker.com>
|
|
Message-ID: <Pine.OSX.4.64.0604101053530.2906@pangtzu.panda.com>
|
|
|
|
Vladimir's interpretation is valid. The LIST argument is definitely not a
|
|
mailbox name.
|
|
|
|
However, I disagree about it being useful or desirable compared to other
|
|
interpretations. In particular, I do not think that it is useful or
|
|
desirable for a server to respond to
|
|
tag LIST "" inbox
|
|
with no data because of case-mismatch with INBOX.
|
|
|
|
The case of
|
|
tag LIST "" In%B%
|
|
is less clear, particularly given that the specification says "uppercase
|
|
string" instead of "case-insensitive" string.
|
|
|
|
However, the kicker is that (as Vladimir notes) INBOX may be included in
|
|
the output with a case-insensitive server. I disagree with Vladimir's
|
|
interpretation that the specification forces INBOX to be case-sensitive in
|
|
LIST even on a case-insensitive server, as well as the notion of a
|
|
"regular mailbox named INBOX" vs. a "special name INBOX" (that is an
|
|
implementation detail).
|
|
|
|
Fortunately, though, this discussion is more academic than practical, for
|
|
the following reasons:
|
|
|
|
The specification uses "INBOX" throughout as the canonical form of the
|
|
name, and hammers on the point that this is case-insensitive. Postel's
|
|
robustness principle (this being a correct use!) says that clients should
|
|
always send the name as "INBOX", and servers should always do a
|
|
case-insensitive match even when the specification allows a loophole.
|
|
|
|
In the case of a client sending
|
|
tag LIST "" inbox
|
|
and getting nothing back, the primary onus is on the client for not using
|
|
the canonical form. The server, arguably, is being naughty too; but the
|
|
loophole exists.
|
|
|
|
Although the In%B% case is more troubling, I observe it is not something
|
|
that generally occurs in real life. A client which actually uses such a
|
|
pattern is probably looking for names other than INBOX; but I don't think
|
|
that I've ever seen a client use such a pattern.
|
|
|
|
I think that, although a server should match INBOX to In%B%, Vladimir is
|
|
correct that it does not have to. Even with Vladimir's interpretation, it
|
|
is ambiguous (due to underlying implementation details) whether or not the
|
|
server would return it. So a client should not depend upon the behavior
|
|
either way.
|
|
|
|
I think that we all agree that the following patterns all match INBOX:
|
|
*
|
|
%
|
|
INBOX
|
|
INBOX%
|
|
INBOX*
|
|
and the following patterns do NOT match INBOX:
|
|
%/%
|
|
foo
|
|
foo/%
|
|
INBOX/*
|
|
INBOX/%
|
|
|
|
-- Mark --
|
|
|
|
http://panda.com/mrc
|
|
Democracy is two wolves and a sheep deciding what to eat for lunch.
|
|
Liberty is a well-armed sheep contesting the vote.
|
|
|