Hi Marc,
--On Friday, June 20, 2003 1:10 PM +0200 Marc Groot Koerkamp
<[EMAIL PROTECTED]> wrote:
|> Mark statement implies that UIDVALIDITY should increase UIDVALIDITY on
|> select rather than when the UIDNEXT goes out of scope.
|>
|> Which is correct?
|>
|
| Your implementation. If you increase
Richard Bang zei:
> Hi,
>
> I've been following this thread with interest and now I cant decide if
> my implementation is compliant or not.
>
> Mark Crispin wrote:
> -
> You could keep track of STATUS vs.
> SELECT, and only increase the UIDVALIDITY on SEL
L PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Jason Munro
> Sent: 18 June 2003 06:35
> To: [EMAIL PROTECTED]
> Subject: [UbeBlock Hit] Re: RFC3501 clarifications
>
>
> On June 17, 11:43 pm Mark Crispin <[EMAIL PROTECTED]> wrote:
> > On Tue, 17 Jun 2003, Jason Mun
On June 17, 11:43 pm Mark Crispin <[EMAIL PROTECTED]> wrote:
> On Tue, 17 Jun 2003, Jason Munro wrote:
> > solution I know of to get around this problem for a client written in
> > a language unable to maintain a stateful connection is an imap proxy
> > type solution which presents its own set
On Tue, 17 Jun 2003, Jason Munro wrote:
> I am getting
> ready to release a PHP based webmail IMAP client which falls in this
> category, however it only connects once per page load. The only solution I
> know of to get around this problem for a client written in a language
> unable to maintain a s
On June 17, 10:09 am "Vladimir A. Butenko" <[EMAIL PROTECTED]>
> (i.e. it does not matter what STATUS returns for UIDNEXT), but believe
> me or not, there are too many clients that connect, check the mailbox
> status (some use STATUS, some even use SELECT), and disconnect - and do
> this VERY oft
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 some position as to
wheth
On Tue, 17 Jun 2003, Vladimir A. Butenko wrote:
> I have nothing against that - I'd just ask you to add this to the next
> edition of IMAP protocol. Something like "interpretation of the word INBOX
> when it is a part of a hierarchical name or a part of namespace'd mailbox
> name is server-specific
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, Vladimir A. Butenko wrote:
> And it's not a useless scholastic exercise, as - AFAIR - all IMAP-related
> changes we did in CommuniGate Pro during the last 24 months were caused by
> the fact that our interpretation and, hmm, "proper" interpretation of the
> IMAP standard were d
On Tue, 17 Jun 2003, Vladimir A. Butenko wrote:
> These syntax constructs just specify the syntax of UID *REFERENCES*. They do
> not say anything about their *values*. It's not a client that assigns UIDs
> to messages, but the server. So the syntax just says that you would have
> problems accessing
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 semantics part of the standar
No, Cyrus.
Speaking about syntax constructs, one that really matters is this one:
uniqueid= nz-number
These syntax constructs just specify the syntax of UID *REFERENCES*. They do
not say anything about their *values*. It's not a client that assigns UIDs
to messages, but the server. So
Hi Vladimir,
--On Tuesday, June 17, 2003 4:50 AM -0700 "Vladimir A. Butenko"
<[EMAIL PROTECTED]> wrote:
|
| It does not say that the "32-bit" value is supposed to be non-negative
| (unsigned). We've just met a client mailer that does this:
Yes it does! Look at the formal syntax definition for th
On Tue, 17 Jun 2003, Vladimir A. Butenko 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, not for my brain.
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
On Tue, 2003-06-17 at 17:08, Mark Crispin wrote:
> Of course, the client command:
> zz UID FETCH 10:4294967295
> is valid, although I wonder why the client went to that trouble instead
> of the more straightforward:
> zz UID FETCH 10:*
Probably because client is trying to fetch only ne
Vladimir -
Thank you. I agree that there should be a specific definition for
UIDVALIDITY, and that the text should clarify that these are unsigned as
well as non-zero.
For better or worse, the syntax rules define semantics in IMAP. I agree
that it is not a good thing to depend upon this; and th
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
19 matches
Mail list logo
