I haven't been able to find any such promise in RFC3501.IMAP does not promise any sort of state in LIST. It does with SELECT.
RFC 3501 talks about mailbox state throughout the document.
RFC 3501, section 6.4.5, page 54:
Most data items, identified in the formal syntax under the
msg-att-static rule, are static and MUST NOT change for any
particular message. Other data items, identified in the formal
syntax under the msg-att-dynamic rule, MAY change, either as a
result of a STORE command or due to external events.This specifically outlaws the scenarios of:
a1 FETCH 1 RFC822.TEXT
* 1 FETCH RFC822.TEXT "foo"
a1 OK done!
a2 FETCH 1 RFC822.TEXT
* 1 FETCH RFC822.TEXT NIL
a2 OK done!
and
a1 FETCH 1 RFC822.TEXT
* 1 FETCH RFC822.TEXT "foo"
a1 OK done!
a2 FETCH 1 RFC822.TEXT
a2 NO can't fetch that text
since RFC822.TEXT is a msg-att-static.In theory, a msg-att-dynamic could behave in the way you suggest. A system of annotations, for example, might do that:
a1 FETCH 1 ANNOTATION
* 1 FETCH ANNOTATION "junk"
a1 OK done!
a2 FETCH 1 ANNOTATION
a2 NO that message doesn't have any annotations
This isn't the way that the IMAPEXT working group has actually defined annotations; this is just a strawman example to demonstrate the principles.
You could do a lot to win me over by pointing me to it, or by saying something like "This was an oversight; it is knowledge that an implementor needs, and it therefore should have gone into the RFC, but unfortunately didn't - it was one of those things that "Everyone knows, so we don't need to say it". It should go into the next update."
How would that help?
You have been saying in several messages, that you are right in your intepretation of IMAP, and that I am wrong.
If I were to change the document to declare a wrong interpretation to be the only right one, you would scream foul -- and with good reason!
-- Mark --
http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
