On Sun, 4 Jan 2004, David Harris wrote: > What I want to know now is "why is the Exchange server using this > extension?".
It is "not incorrect" for Exchange to send it without client permission. flag-extension is part of the rule of mbx-list-flags (via mbx-list-oflag) in RFC 3501, thus a server *may* send unilaterally and a client is obliged to handle it. Note that there are other places in the base specification which permit the server to do unilateral extended things without client permission. The most notable examples are system flags (another flag-extension) and BODYSTRUCTURE (body-extension). Response codes are arguably another example. More to the point, though that's what RFC 3348 requires; there is no client-based trigger for the CHILDREN extension. RFC 3348 choose to go this route rather than have a separate command to enable it. I did not like this for a different reason: \HasChildren and \HasNoChildren are expensive to calculate in a UNIX filesystem based server, and thus I would not want to do the work unless I knew that the client cared. This is one of the things that has lead to the listext work in IMAPEXT. Clearly we did not want to add CLIST and CLSUB and CRLIST and CRLSUB, but that is where we were heading if we insist upon a client trigger for CHILDREN. > Or am I simply misunderstanding this issue? Is it in fact legal for a > server to issue any response it wants in this case? Yes, you misunderstood; but no, it isn't legal for the server to issue just "any response it wants". However, it should be noted that there *is* some extensibility in certain server responses that the base specification requires all clients to accept, even if it doesn't say what those responses mean. The idea is that such things as flags and BODYSTRUCTURE and response codes can be extended and a compliant client will just ignore the extended data rather than barfing. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
