Andy,
Sorry to bring this up again but as I was filling out a very detailed report for opera erroneously issuing a CLOSE command after a LOGIN command (which it does when network connectivity is lost) I had to reread parts of RFC 2060 very carefully and I am beginning to come to the conclusion that Binc does not always do the right thing.
When Binc sees a CLOSE after a LOGIN it issues a "* NO The command "CLOSE" is not supported.". In section 6.4.2 of the RFC it says "NO - close failure: no mailbox selected". Note that nowhere in the section does it say that the NO should be tagged (or not).
I accepted the statement that it was Opera's fault for not interpreting Binc's response correctly and was proceeding to include such statements in my bug report along with the relevant sections from the RFC. In fact, I found that the RFC did not support my position.
Section 7. "Server Reponses" says:
Status responses can be tagged or untagged. Tagged status responses indicate the completion result (OK, NO, or BAD status) of a client command, and have a tag matching the command.
Some status responses, and all server data, are untagged. An untagged response is indicated by the token "*" instead of a tag. Untagged status responses indicate server greeting, or server status ^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ that does not indicate the completion of a command (for example, an ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ impending system shutdown alert). For historical reasons, untagged server data responses are also called "unsolicited data", although strictly speaking only unilateral server data is truly "unsolicited".
Now, Binc recognizes CLOSE as a command yet issues a "* NO" which (according to the marked passage) is for statuses that do not indicate the completion (or error) of a command. Is my understanding of the RFC correct here? Should Binc be issuing a "<tag> NO" in this situation?
Does the following patch an appropriate fix?
*** bincimapd-orig.cc Tue May 25 13:18:58 2004 --- bincimapd.cc Tue May 25 13:19:53 2004 *************** *** 129,135 ****
Operator *o = broker->get(request.getName());
if (!o) {
! com << "* NO The command \""
<< (request.getUidMode() ? "UID " : "") << request.getName()
<< "\" is not supported." << endl;
recovery = true;
--- 129,136 ---- Operator *o = broker->get(request.getName());
if (!o) {
! com << request.getTag()
! << " NO The command \""
<< (request.getUidMode() ? "UID " : "") << request.getName()
<< "\" is not supported." << endl;
recovery = true;This patch seems to work for my specific problem situation. But does it break other things?
Similarly, I suspect that bincimap-up.cc needs the following patch:
*** bincimap-up-orig.cc Tue May 25 13:30:13 2004 --- bincimap-up.cc Tue May 25 13:31:14 2004 *************** *** 142,148 ****
Operator *o = broker->get(request.getName());
if (!o) {
! com << "* NO The command \""
<< (request.getUidMode() ? "UID " : "")
<< request.getName()
<< "\" is unsupported in this state. "
--- 142,149 ---- Operator *o = broker->get(request.getName());
if (!o) {
! com << request.getTag()
! << " NO The command \""
<< (request.getUidMode() ? "UID " : "")
<< request.getName()
<< "\" is unsupported in this state. "<ASIDE>
bincimap-up.cc contains the following snippet:
if (!o) {
com << "* NO The command \""
<< (request.getUidMode() ? "UID " : "")
<< request.getName()
<< "\" is unsupported in this state. "
<< "Please authenticate." << endl;
recovery = true;
continue;
}
bincimapd.cc contains the following snippet:
if (!o) {
com << "* NO The command \""
<< (request.getUidMode() ? "UID " : "") << request.getName()
<< "\" is not supported." << endl;
recovery = true;
continue;
}
Do these two snippets do the same thing? The "is not supported" in bincimapd.cc does not seem as clear to me as does the "is unsupported in this state" in bincimap-up.cc. Should they be the same? Or is there a reason for the more ambiguous error message in bincimapd.cc?
</ASIDE>
Henry:) -- Henry Baragar Instantiated Software Inc. http://www.instantiated.ca
