On Wed, 3 Dec 2003, Richard Bang wrote:
> Given that it appears logical that a range should be defines as
> lower:upper and that's the way the examples were written, that's how I
> wrote my server.
It is "logical" until you consider the effect of "*", particularly with
UIDs.
> After all when asked how many months are there between
> July and April I would answer 9 rather than 3.
The exact phrase in RFC 2060 was "between two numbers inclusive". Thus,
10 is a better answer than 9.
However, when you refer to months, you are referring to a restarting
cycle. You can say that there are "10 months between July and April
inclusive" since there is an April which occurs after July.
In the case of numbers, the cycle does not start. The numbers
"between 5 and 3 inclusive" can only be 3, 4, 5.
> I agree that it doesn't explicitly state that anywhere but there are
> lots of things that are not explicitly stated in the RFC's. That's one
> of the reasons these problems arise.
RFC 3501 made this point explicit:
seq-range = seq-number ":" seq-number
; two seq-number values and all values between
; these two regardless of order.
; Example: 2:4 and 4:2 are equivalent and indicate
; values 2, 3, and 4.
; Example: a unique identifer sequence range of
; 3291:* includes the UID of the last message in
; the mailbox, even if that value is less than 3291.
If you believe that there are ambiguities in the RFC, then please call the
IMAP mailing list's attention to it. Problems don't get fixed if nobody
reports them.
There were repeated announcements of document revisions and last calls
over the years. These weren't done to increase the spam in your INBOX.
> Again. This brings up the point that we need a test suite produced by
> the IMAP community that can be used to validate servers. It will resolve
> these issues for once and for all and we will all know that our servers
> are compliant or not.
I am not aware of such a test suite for any existing Internet protocol.
That doesn't mean that there shouldn't be test suites. It does however
indicate that it's hard to do in a useful manner. Generally when people
screw up, they do so in ways that test suites don't catch.
> I believe my server is compliant in that it works as I think it should
> with the clients I have tested.
That's the problem. You (like many others) made the mistake of judging
"compliant" by "works with the clients I have tested."
What clients did you test? Did you test with clients that use IMAP
extensively and are fussy about syntax, such as Pine?
Did you rigorously check your software's parser and generator against the
formal syntax? Many people don't, and do what seems "logical"; that is
the source of many bugs.
> The sequence ranges are a case in point, I
> have never seen a reversed sequence so I have never coded for it and the
> RFC doesn't tell me either way, thus my server was, until today
> "Compliant" as being "as to the best of our knowledge".
You never encountered a UID client that does <lastuid+1>:* to get new mail
and identify the highest existing UID?
> If anyone can tell me how I can test my server to ensure 100% compliance
> with the IMAP RFC's I would be very grateful.
Rigorously check your software's parser and generator against the
formal syntax. Every rule in the formal syntax is there for a reason; if
you can't identify (and verify!) the code that implements each rule then
you have a problem.
UW imapd and UW c-client library are the reference server and client
implementations against which all others are judged. Cyrus imapd is also
an important implementation with near-reference status. Study these
closely.
However, never resolve a protocol question by empirical testing of what
some other implementation does. When in doubt, *ask*.
This is particularly the case with questions of syntax. IMAP requires
that syntax errors not be generated; it does not require that a compliant
implementation reject all possible syntax errors. Thus, it is not an
excuse to generate a syntax error on the grounds that "UW imapd accepted
that syntax."
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
