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 the syntax just says that you would have problems accessing (or referring to) messages with negative UIDs, but it does not [explicitly] say that the server cannot create them.
Speaking less formally, my note can be re-formulated this way:
If UIDs are 32-bit numbers, then how can I refer to the message with UID -23?
I.e. the syntax serves semantics, not vice versa. Syntax can always be extended, preserving the compatibility with the existing semantics. All modern mailers expect that the UIDs are strictly positive integers, and this fact should be specified in the semantics part of 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. 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 those numbers. You will see that they ultimately resolve to either of these:
number = 1*DIGIT ; Unsigned 32-bit integer ; (0 <= n < 4,294,967,296)
nz-number = digit-nz *DIGIT ; Non-zero unsigned 32-bit integer ; (0 < n < 4,294,967,296)
I think that is pretty clear! One could argue the textual description of the protocol could make that clear, but the formal syntax is always where you should look when the text is not clear.
-- Cyrus Daboo
