------------------- 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) forms .... -------------------
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:
zz UID FETCH 10:4294967295
So, if the server uses signed 32-bit numbers for UIDs, this would either fail as a syntax error or it would produce a rather strange result (equivalent to UID FETCH 10:-1 equivalent to UID FETCH 1:10)
Yes, the syntax rules do not allow for negative (and even zero) values in seq-numbers and/or UIDs, but syntax rules do not define the semantics.
So, the suggestion is to add the words: "positive integer" or "unsigned non-zero":
A 32-bit positive integer value assigned to each message, which when used
with the unique identifier validity value (see below) forms ....
The second thing:
The "UIDVALIDITY" thing needs similar addition. The language for UIDVALIDTY definitely needs some improvement, as it does not even contain the term definition:
-- RFC3501-- The unique identifier validity value is sent in a UIDVALIDITY response code in an OK untagged response at mailbox selection time. If unique identifiers from an earlier session fail to persist in this session, the unique identifier validity value MUST be greater than the one used in the earlier session. --
Should be something like this:
The unique identifier validity (UIDVALIDITY) is a [unique?] positive integer
value assigned to each mailbox.
This value is sent in a UIDVALIDITY response code in an OK untagged
response at mailbox selection time.
If unique identifiers from an earlier session fail to persist in this
session, the unique identifier validity value MUST be greater than
the one used in the earlier session.
The mailbox UIDVALIDITY value can be retreived using the STATUS
command (...which value should the STATUS command retrieve if
UIDs fail to persist, and the mailbox is not currently selected?).
--------
Sincerely,
Vladimir
--
-----------------------------------------------------------------
For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html
-----------------------------------------------------------------
