On 11/01/2011 08:35 AM, Paul Lesniewski wrote:
> 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.
capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev1"
*(SP capability)
; Servers MUST implement the STARTTLS, AUTH=PLAIN,
; and LOGINDISABLED capabilities
; Servers which offer RFC 1730 compatibility MUST
; list "IMAP4" as the first capability.
If you look at the imapproxy code before the XIMAPPROXY patch was added,
it would always output a CAPABILITY string with single spaces between
each token. Further, you'll notice that imapproxy itself expects the
CAPABILITY string to be SP separated tokens in the code that has to
parse the CAPABILITY response to strip out things that can't be supported.
hth!
Dave
------------------------------------------------------------------------------
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
