I'd say "unfinished" rather than "obsolete". This is the reason the
format of the ID is explicitly unspecified - so the application
designer could do whatever they wanted with it. For instance:
> What I want to sketch here is how one might implement cookies
> without abusing HTTP headers. Moving the cookie out of a header and
> into a genuine HTTP object means first that the cookie can benefit
> from the existing linking, caching, and security mechanisms of HTTP.
Rather than using a "Link: URI; rel=cookie" header, you would use
"Session-ID: Cookie-<URI>" or something similar. If the client is
generating the IDs, you're done. If the server is generating the IDs,
you need to check for IDs chosen by the client and map those to a
session ID of the appropriate form.
Yes, it's not a complete, finished solution. It does session tracking
now, and provides a foundation on which pretty much anything can be
built. Working implementations - even kludged on top of this - provide
a much better base for designing a complex object system than what
we've got now.
<mike