>> It is odd that lines 1081 and 1082 both add a space, but I didn't code >> that. I'm hoping Dave or whoever did can speak up, but we won't rush >> out and change this too quickly without understanding the >> implications, especially when it's commonly accepted that you parse >> whitespace without looking for a single space character. > > I'd say the extra space in 1081/1082 is a bug. If you read the formal > syntax section in RFC 3501 (Section 9), it seems to clarify that the > CAPABILITY response should be single-space separated. > > First, the RFC clarifies exactly what SP means in the BNF. > > "(2) In all cases, SP refers to exactly one space. It is NOT permitted > to substitute TAB, insert additional spaces, or otherwise treat SP as > being equivalent to LWSP." > > Then where capability-data is later defined we can see that it is SP > separated tokens.
Perfect. Thanks, Dave, for taking the time to do what I should have done before replying. We'll remove the space. -- Paul Lesniewski SquirrelMail Team Please support Open Source Software by donating to SquirrelMail! http://squirrelmail.org/donate_paul_lesniewski.php ------------------------------------------------------------------------------ RSA® Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ----- squirrelmail-imapproxy mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: [email protected] List archives: http://news.gmane.org/gmane.mail.squirrelmail.imapproxy List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-imapproxy
