Re: making progress on State-Info

At 6:52 PM 12/9/95, Ari Luotonen wrote:
>In order for the state-info to be useful, it has to be usable.  In
>theory it may seem great, but the moment you apply it in practice
>you'll bump into problems.  Those problems have for the most part
>already been thought of and solved in Netscape's Magic Cookies, and
>they've been proven to work in real-life applications.

I accept that cookies work (for providers, not for users) in real-life
situations.  I am not, however, convinced that all of the features
specified in the cookie proposal are necessary for state-maintenance to be
successful.

>I don't claim
>that there isn't be room for improvement, but I think time would be
>better spent in finding those improvements and adding them to cookies,
>rather than taking a step back and starting from scratch again with
>something that isn't all that much better.

I disagree that state-info "isn't all that much better."  Koen Holtman has
described a list of state-info proposal qualities that distinguish one from
another, and Dave Kristol has added that list to his proposal.  Two of the
qualities listed are:

>   + amount of privacy protection
>
>   + maximum complexity of stateful dialogs supported

As I and others have elaborated, cookies offer far less than state-info in
regards to privacy.  You are saying that cookies offer far more in the way
of complexity.  Fine, I agree with that statement, but:
        (1) that doesn't mean state-info "isn't all that much better"
            than cookies, it just has different strengths; and
        (2) I have yet to be convinced that cookies' complexity is
            necessary -- and certainly, you have a long way to go before
            convincing me that cookies' complexity is worth the
            trade-off in privacy protection that currently exists.

Also, I don't agree that state-info is "starting from scratch."  Dave's
proposal grew out of extensive conversations on this list, and incorporated
a number of ideas from Koen's parallel proposal.

All of that said, I am completely amenable to adding state-info concepts to
the cookie proposal rather than the other way around, if we can find common
ground between the two strengths described above.

>[...] a shortcoming in the state-info spec as opposed to the
>Cookie spec is that state identifiers cannot be shared between hosts
>(unless yet some more infrastructure is laid down on the server
>cluster side).

You consider this a shortcoming; I consider it a strength of state-info.
The tail-matching scheme proposed for sharing cookies between hosts is
insufficient.[1]  As a result, the cookie proposal opens the door for
sharing of cookies between arbitrary hosts -- in other words, the sharing
of information about a user between sites.[2]  If you feel that cookie
sharing between servers at one site is essential, you need to come up with
better language to ensure that information is contained to one site.

Two other areas I'd like to see addressed in regards to the cookie proposal:

        (1) Why is an expiration date necessary?  Why is it essential to
maintain
            state beyond the current execution of the user-agent?

        (2) How should the user agent indicate its actions to the user?  The
            state-info proposal has some specific recommendations -- would
            you be willing to add them to the cookie proposal?  Further, are
            the authors of the cookie proposal opposed to giving the user the
            ability to reset cookies or ignore set-cookie responses?

Marc Hedlund, Organic Online <marc@organic.com>

[1] Again, see
<URL:http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q4/0161.html>.
This is not just idle speculation -- all cookie-supporting versions of
Netscape before 2.0 implement the tail-matching problem I describe.  It
looks like the spec langauge on this point has changed recently, but it is
still insufficient: '.com.' is a legal domain setting under the language in
place.

[2] See
<URL:http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q4/0469.html>,
"DRAFT Minutes, HTTP-WG," for more comments on this issue.

Received on Sunday, 10 December 1995 12:09:33 UTC