>Would you mind reviewing for us the problems you see in the cookie
>approach to session ID? You allude to that in the draft but I think it
>would be helpful to go into more detail.
The bqasic problem with cookies are that they require the client to store data
on behalf of the server. Cookies are identifiers generated by the server. Each
client must in the worst case store one cookie per site visited.
Session IDs on the other hand provide tracking capabilities but cost only 16
bits of machine specific data.
The storage requirements are very onerous for clients on handheld equipment and
on low cost $500 weboxes which don't have external persistent storage. Arguments
such as "flash ram ois only $20 per Mb" cut no ice with such a crowd which spend
their time shaving 5cents off the connector cost. To make an item for $500 the
total component cost cannot exceed $100. This is a very low margin business. It
is probable that such devices will have a few K of flash ROM for storage of
persistent info like the TCP/IP setup.
The requirements for storage also mean that it is difficult to configure a
portable to have the same configuration as a workstation. I would like to be
able to access the web from my laptop as if I were continuing a session I
started on the workstation. With cookies this is simply not possible.
Cookies were never designed to be a demographic tracking method. They were a
hack to make a "shopping cart" application work. It was afterwards that people
started using them as a demographic tool.