I'd been hoping to cut a corner with the HTTP negotiate mechanism.  In
particular, I had been hoping that we could assume that all the round
trips would happen over a single HTTP connection.
I know, I know, HTTP doesn't work that way.
However I thought it was going to be fairly complicated to do something
else.

The more I think about this though,the more I believe that we're
actually going to need to support Leif's mechanism for partial context
export.



The main concern I have is what will happen with reverse proxies.  The
connection will be between the same endpoints, but the proxy can control
whether connections are persistent and may interleave requests from
different clients over the same connection.  So, I think we need to
implement some of Leif's draft on the enhanced negotiate mechanism.

This also means the Moonshot GSS mechanism will need to support partial
context export.  At least the RADIUS interaction is going to be fairly
simple.  The RADIUS server will send us a state attribute with its
response to our first EAP packet.  We need to echo that cookie back ind
the next packet, taking the state from that RADIUS message for the
following packet and so on.

So, at this point we need to carefully decide whether we want a
different mechanism name or whether we should continue to use the
negotiate mechanism.
We also need to carefully consider the backward compat story.

An important question to Daniel and Luke: is Leif's HTTP negotiate draft
sufficiently detailed to implement both the partial context export
functions and the  HTTP side of the above?

--Sam