Hello,
If FETCH 2:2 is legal for a mailbox that contains one message, I do not
understand why Fetch 1:1 is illegal in an empty mailbox, or why FETCH 1:* is
illegal in an empty mailbox. Since the 17th century the number zero is
considered to be a regular plain number, LEGAL, not much different
On Wed, 25 Sep 2002 08:34:10 -0700 (PDT)
Mark Crispin <[EMAIL PROTECTED]> wrote:
> On Wed, 25 Sep 2002 07:39:40 -0700, Vladimir A. Butenko wrote:
> > If FETCH 2:2 is legal for a mailbox that contains one message, I do not
> > understand why Fetch 1:1 is illegal in an empty
On Thu, 26 Sep 2002 09:15:34 -0700
"Larry Osterman" <[EMAIL PROTECTED]> wrote:
> The critical word here is "such". The text doesn't indicate that BAD
> can ONLY be returned for unrecognized commands or syntax errors, the
> text indicates that AMONG the reasons for returning a BAD response is
On Thu, 26 Sep 2002 08:47:08 -0700 (PDT)
Mark Crispin <[EMAIL PROTECTED]> wrote:
> If a judgement most be made, I would contend that since the command-ending
> CRLF was sent AFTER the EXISTS arrived, the value of * would be 2. But I
> wouldn't be at all surprised if many servers treated it as
Larry, my 20+ years wasted in this boring computer design field resulted in
- guess what? - exactly the same opinion about the explicitly specified
error codes, esp. when they are placed into the manuals (OS manuals ARE the
specs, the same as standards) where they can be read by those who would
On Thu, 26 Sep 2002 12:21:37 -0700
"Larry Osterman" <[EMAIL PROTECTED]> wrote:
> I feel obliged to toss out that when you select a mailbox when you are
> unauthenticated, the Exchange IMAP server does:
> * OK Microsoft Exchange 2000 IMAP4rev1 server version 6.0.6249.0
> (DF-BOWWOW.platinum.corp.
In serveral places the following phrase is being used:
\Recent can not be used as an argument in a
STORE command, and thus can not be changed at all
Actually, "flag"s can be used as an argument of the APPEND command, too - so
probably the APPEND command should be mentioned there, too.
Th
PAGE 6:
--
Note: The next unique identifier value is intended to
provide a means for a client to determine whether any
messages have been delivered to the mailbox since the
previous time it checked this value. It is not intended to
provide any guaran
PAGE 8
--
A flag can be permanent or session-only on a per-flag basis.
Permanent flags are those which the client can add or remove from the
message flags permanently; that is, subsequent sessions will see any
change in permanent flags. Changes to session flags are valid only
3.2.Authenticated State
In authenticated state, the client is authenticated and MUST select a
mailbox to access before commands that affect messages will be
permitted. This state is entered when a pre-authenticated connection
starts, when acceptable authentication credentials
PAGE 20
The state of a connection is only changed by successful commands
which are documented as changing state. In particular, a failed (NO
response) or rejected (BAD response) command does not change the
state of the connection.
---
A failed SELECT command definitely changes
On Tue, 01 Oct 2002 14:48:16 -0700
Chris Newman <[EMAIL PROTECTED]> wrote:
> Does this imply that concurrent sessions see flag change notifications in
> response to the next command they issue (as Outlook assumes)? Or are lazy
> notifications permissible (where concurrent sessions may get del
On Tue, 1 Oct 2002 15:19:42 -0700 (Pacific Daylight Time)
Mark Crispin <[EMAIL PROTECTED]> wrote:
> On Tue, 1 Oct 2002, Vladimir A. Butenko wrote:
> > In serveral places the following phrase is being used:
> >\Recent can not be used as an argument in a
> >STOR
Hello,
On Thu, 24 Oct 2002 12:35:32 -0700 (PDT)
Mark Crispin <[EMAIL PROTECTED]> wrote:
Hello Vladimir -
Once again, I would like to thank you for your thoughful analysis and
comments.
The pleasure is all mine.
b) It was intended that RENAME should preserve UIDVALIDITY and UIDs.
However,
There is one "small" thing missing in the RFC3501 (or I could not find it,
then it's still bad :-):
---
2.3.1.1.Unique Identifier (UID) Message Attribute
A 32-bit value assigned to each message, which when used with the
unique identifier validity value (see below) fo
On Tue, 17 Jun 2003 07:08:00 -0700 (PDT)
Mark Crispin <[EMAIL PROTECTED]> wrote:
If UIDs do not persist in a mailbox, then STATUS should return a higher
UIDVALIDITY value than any previous UIDVALIDITY returned for that mailbox
(including a previous STATUS command).
It's not that obvious. At least
f the standard. The fact
that negative UIDs would have problems with the current syntax is [almost]
irrelevant.
Sincerely,
Vladimir
On Tue, 17 Jun 2003 11:52:50 -0400
Cyrus Daboo <[EMAIL PROTECTED]> wrote:
Hi Vladimir,
--On Tuesday, June 17, 2003 4:50 AM -0700 "Vladimir A. B
On Tue, 17 Jun 2003 10:42:27 -0700 (Pacific Daylight Time)
Mark Crispin <[EMAIL PROTECTED]> wrote:
On Tue, 17 Jun 2003, Vladimir A. Butenko wrote:
> All
> modern mailers expect that the UIDs are strictly positive integers, and
>this
> fact should be specified in the sem
On Tue, 17 Jun 2003 14:53:28 -0700 (Pacific Daylight Time)
Mark Crispin <[EMAIL PROTECTED]> wrote:
On your question about case-independence of INBOX, my view is that only
a 5-octet token with first octet "I" or "i", second octet "N" or "n",
third octet "B" or "b", forth octet "O" or "o", and final
On Tue, 17 Jun 2003 15:41:45 -0700 (Pacific Daylight Time)
Mark Crispin <[EMAIL PROTECTED]> wrote:
On Tue, 17 Jun 2003, Vladimir A. Butenko wrote:
Hmm. This is yet another thing that is implied from the syntax (note the
definition of "mailbox". 5.1 should probably take som
RFC2425 and RFC2426 already exist.
There is nothing special about storing the vCard data - as there is nothing
special about storing iCalendar data - as long as there are well-defined
Content-Types for them. Note: the RFCs above are talking about the vCard
3.0, vCard 2.1 has the text/x-vcard co
On Sat, 11 Oct 2003 00:41:15 +0200
Holger Mauermann <[EMAIL PROTECTED]> wrote:
ok, let us begin ;-)
The Subject: should be set to the vCard FN type.
I doubt there is any doubt...
IMHO it is better to use From: for the primary mail address, because it
is more compatible with mail software which
On Fri, 10 Oct 2003 16:10:41 +0200
Arnt Gulbrandsen <[EMAIL PROTECTED]> wrote:
The problem usually is to follow the unstated restrictions when writing to >such stores.
For example, I might be able to read all the vcards. But what if I want to >write a new address for an existing name, what should
On Tue, 28 Oct 2003 11:00:01 -0800 PST
"Jeff Stephenson" <[EMAIL PROTECTED]> wrote:
[skipped]
Jeff Stephenson
Software Developer
Microsoft Outlook
Aha! :-)
Jeff, it's a bit off-topic, but could you please verify that the Outlook
SMTP code is fixed (the bug definitely existed in Outlook Express)
On Thu, 30 Oct 2003 09:43:57 -
"Richard Bang" <[EMAIL PROTECTED]> wrote:
Could this not be resolved cleanly and made a little more general
purpose in the next revision of imap.
The SELECT could have a TYPE response
TYPE = MAILSTORE | ICARD | ICAL | DOCUMENT
Thus
SELECT addressbooks/fred
Cou
On Sat, 1 Nov 2003 09:21:35 +0200
Timo Sirainen <[EMAIL PROTECTED]> wrote:
On Fri, Oct 31, 2003 at 12:36:25PM -0800, Vladimir A. Butenko wrote:
> * LIST (\Class("IPF.Appointment") \UnMarked) "/" Calendar
> * LIST (\Class("IPF.Contact") \UnMarked) &qu
26 matches
Mail list logo
