Re: SASL-IR (draft-siemborski-imap-sasl-initial-response-05.txt)

[Mark Crispin <mrc@xxxxxxxxxxxxxxxxxx>]

To my horror, I discovered that UW imapd was in violation of the following 
in the SASL-IR draft:

    As with any other client response, this initial client response MUST
    be encoded as defined in Section 3 of [RFC3548].  It also MUST be
    transmitted outside of a quoted string or literal.  To send a zero-
    length initial response, the client MUST send a single pad character
    ("=").  This indicates that the response is present, but is a zero-
    length string.

UW imapd simply parsed the initial response token as an astring, meaning 
that it would accepted it as a quoted-string or literal.  UW imapd also 
did not implement "=" for zero-length initial response.

Fortunately, this doesn't actually affect anything for a compliant client. 
Nothing should send a quoted-string or literal; and although UW imapd 
supports EXTERNAL, nothing enables it yet so there's no worry about 
zero-length initial responses.  So I just fixed the problems.

Although I understand why SASL-IR prohibits quoted-string or literal, I 
think that the concern was misplaced.  The initial response token should 
just have been an astring; the protocol is pretty clear what happens with 
a literal.

Failing that, it should have been an atom.  The problem is that as matters 
currently stand, the BNF requires base64 in the IMAP command syntax. 
This is a new requirement, and serves no good purpose.  I hope that nobody 
seriously intends to allows an alternative second argument to AUTHENTICATE 
that is a valid atom albeit with at least one non-BASE64 character.

This is the difference between saying that
	tag AUTHENTICATE FOO BAR=ZAP
is a command syntax error ("BAR=ZAP" does not match the rule) vs. an 
invalid argument.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.