Date: Mon, 15 Sep 2003 14:13:30 -0700 (Pacific Daylight Time)
From: Mark Crispin <[EMAIL PROTECTED]>
[...]
> Where in RFC3501 does it say that the server needs to maintain
> this trailing-hierarchy-separator convention?
The semantics of hierarchy vis a vis % were discussed in great
Date: Thu, 3 Apr 2003 12:00:46 -0800 (Pacific Standard Time)
From: Mark Crispin <[EMAIL PROTECTED]>
On Thu, 3 Apr 2003, Timo Sirainen wrote:
> Suppose I have:
> * NAMESPACE (("" "/")) NIL (("shared/" "/"))
This seems like a poor namespace, since the public namespace name
("sh
Date: 04 Mar 2003 19:34:46 +0200
From: Timo Sirainen <[EMAIL PROTECTED]>
[...]
Say I want to open one message in a mail client that first shows a list
of messages:
1 FETCH 1:30 ENVELOPE (fetch a screenful)
2 FETCH 20 BODYSTRUCTURE
3 FETCH 20 BODY[1]
Now why would you have
--On Monday, February 03, 2003 11:28 AM -0500 Cyrus Daboo
<[EMAIL PROTECTED]> wrote:
The domain-in-userid already provides the same benefits with the added
advantage of not having to change clients. I'm afraid I still don't see
the benefit of VHOST. Perhaps other server vendors can explain existi
Date: Thu, 30 Jan 2003 11:30:34 -0500
From: Cyrus Daboo <[EMAIL PROTECTED]>
[...]
That's not all that is necessary. First clients need a way to discover the
name of a mailbox with an associated ID. Second, it would be more useful if
commands that currently take mailbox names could
Date: Wed, 29 Jan 2003 10:01:57 -0800 (PST)
From: Mark Crispin <[EMAIL PROTECTED]>
On Tue, 28 Jan 2003, Timo Sirainen wrote:
> Sure. And I don't think I've said anything that would indicate otherwise.
> The keyword in my comment above was *LESS* resource intensive. Using
> multip
Date: Tue, 21 Jan 2003 10:38:04 -0800 (Pacific Standard Time)
From: Mark Crispin <[EMAIL PROTECTED]>
[...]
I believe the only safe implementation of RENAME is one that creates a new
mailbox, copies all messages to that new mailbox, and then deletes the
source mailbox. The client can
--On Saturday, January 11, 2003 10:41 AM -0800 Mark Crispin
<[EMAIL PROTECTED]> wrote:
On Sat, 11 Jan 2003 13:39:16 -0500, Cyrus Daboo wrote:
[proposed improved algorithm]
This should probably be done as a
separate THREAD=XXX option.
To make things unambiguous:
I strongly support this. My op
--On Friday, January 10, 2003 7:54 PM -0800 Mark Crispin
<[EMAIL PROTECTED]> wrote:
On Fri, 10 Jan 2003, Lawrence Greenfield wrote:
If this is what people want (and I think I've heard it enough that it is)
I disagree with this claim.
Is there anyone who wants to speak up in fav
--On Friday, January 10, 2003 6:59 PM +0100 Arnt Gulbrandsen
<[EMAIL PROTECTED]> wrote:
Cyrus Daboo writes:
However, I will again voice my annoyance with the fact that the
THREAD=REFERENCES extension does any kind of grouping based on
subject.
Seconded!
THREAD=REFERENCES is its name, so why c
Date: Wed, 27 Nov 2002 10:18:32 -0800 (PST)
From: Mark Crispin <[EMAIL PROTECTED]>
On Wed, 27 Nov 2002 13:14:54 -0500, Lawrence Greenfield wrote:
>Note: a server implementation MUST implement a
>configuration
Although that weasel-wording he
Date: Wed, 27 Nov 2002 08:58:38 -0800 (PST)
From: Mark Crispin <[EMAIL PROTECTED]>
[...]
Server implementations which allow unencrypted plaintext logins are now
non-compliant; and to make UW imapd be compliant I had to change it so that
plaintext logins are not allowed in unencrypted
Date: Wed, 25 Sep 2002 09:57:35 -0700 (PDT)
From: Mark Crispin <[EMAIL PROTECTED]>
[...]
If that is the case, would there be any objection to folding the MULTIAPPEND
draft into the base specification? Unlike other extensions, MULTIAPPEND is
not a new command; it is an obvious compa
The references section has been split (which I think makes sense).
The normative part of the references:
The following documents contain definitions or specifications which
are necessary to understand this document properly:
contain references to
[IMAP-IMPLEMENTATION] Leiba, B. "IMAP I
Date: Wed, 29 May 2002 20:13:24 -0700 (Pacific Daylight Time)
From: Mark Crispin <[EMAIL PROTECTED]>
On Wed, 29 May 2002, Lawrence Greenfield wrote:
> Servers: Cyrus. iPlanet and/or Netscape has demonstrated it---I don't
> know if the latest shipping versio
Date: Wed, 29 May 2002 19:43:38 -0700 (Pacific Daylight Time)
From: Mark Crispin <[EMAIL PROTECTED]>
[...]
> (2) Require implementation of DIGEST-MD5.
> This is not as widely deployed
AFAIK it is completely undeployed in the IMAP world.
I took a look at DIGEST-MD5 and was horri
Note that we already can do a per-message EXPUNGE using "UID EXPUNGE",
part of the UIDPLUS extension (RFC 2359).
Larry
17 matches
Mail list logo
