> It could be argued that what I really want is your third goal:
>
> JP> 3) freely pass data as first class objects between client/servers
>
> but I think this is incorrect. I don't really want to passing the state
> information back and forth all the time. This information could get rather
> large, and if I have CPU cycles to burn, I'm willing to store the state
> server-side since it will improve performance, and that's of added value to
> my customers.
I think we agree. If the 'From:' field is widely used, you'd have what
you wanted(1). My point is that the protocol does not need to be changed to
handle session(1) &/or user identification(2) - WWW browsers/interfaces need
to pass the right information. Either way, the passing of an ID still needs
to accompany each connection & this is exactly the reason I split this thread
into three issues. State information(3) is not just session(1) or ID(2)
information and needs to be handled differently. Again, I think we agree, but
until the interfaces do things as the protocol specifies, we are left with hacks.
Modified from my previous post:
1) identify sessions (esp. from firewalled domains)
2) enable unique, but changeable user identifications
3) freely pass data as first class objects between client/servers