Re: [kitten] OAUTH/SASL... to HTTP or not to HTTP, that is the question...

[Simon Josefsson <[e-mail]>]

William Mills <[e-mail]> writes:

> The major question remaining for my draft is HTTP(like) or not for the
> SASL message format?  Please select one of the following:
>
>
> A)    The current message format is fine.
> B)    HTTP-like is OK as long as we limit the insanity.
> C)    HTTP in any form is a deal breaker for me.  Give me something simple.
> D)    None of the above, and I have a possible solution of my own to propose.
>
> For B above it's likely that we'd say something like "The server MUST
> parse the Host, User, and Authorization headers and the server MAY
> discard anything else.  The client MUST NOT use any HTTP extensions
> such as compression and pipelining, and SHOULD NOT use line
> continuations."
>
> Thanks in advance for the input,

To get informed answers, I think we need to understand the implications
of each answer.  Let's say we invent a new format for SASL OAUTH.  How
much of a problem would that really be?  Where would the complexity
related to HTTP have to be implemented?  Is it the server that would
need to parse HTTP and transform it to something simpler?  Is the client
completely shielded?

Looking at history, I believe one of the main reasons DIGEST-MD5 didn't
quickly replace CRAM-MD5 was that DIGEST-MD5 was so complicated to
implement interoperable, and that was primarily because it re-used HTTP
syntax.  So I don't think this is just a pet issue, it seems that if
SASL wire syntax is too complicated, things won't get implemented.

If I were to express a preference now I would lean towards B).  However,
if the implications of C) are not severe, I think it would make sense to
use a simpler format.  Then it becomes much easier to implement and
analyse what goes on over the SASL wire.  Without a good rationale, I
would be strongly opposed to free-form HTTP as the SASL syntax.

/Simon