I does feel uncomfortable to me too, but I don't think there are any
technical reasons that support this feeling.
> The renegotiation
>is trivial (just send the ID you generated), and a client doesn't need
>to implement it.
It is trivial to the client, not to the server. The possibility of
renegotiation by clients would make it impossible for servers to
encode session state information in the session-id itself.
Server support for renegotiation would require a `session-id ->
meaning of session id' database in each server, the exact database
that server-supplied session-id promises to do away with if the amount
of state to be kept for each session is small.
> Do you think the renegotiation shouldn't be there at
>all?
Yes, I think renegotiation by clients on session-ids proposed by
servers is an unnecessary complication. It should not be there.
In a server-supplied session-id scheme, renegotiation by servers, a
server saying
please change the session-id `pictures=y' I supplied earlier
to `pictures=n'
is a natural thing to have, and would make the life of some service
authors a bit easier. If we are to implement a server-supplied
session-id scheme, it should allow such renegotiation by servers.
> <mike
Koen.