> My view:
> 1. Categorically not allowing PPs to be set on URLs is arguing that
> the posted use cases are not valuable. If we need to rehold that
> discussion, lets plan time on an agenda, but I think they are
> valuable. If they are allowed on URLs, we do have to make sure they
> would not break the contract associated with an HTTP GET of a URL.
> 2. It has been questioned whether we have essentially defined a
> Consumer-hosted shared session concept and ought to define it as such.
> There has been resistance to such a concept in the past (including
> from me) and I know I am not ready to expand PPs in this manner.
> However, I am willing to listen to arguments suggesting such an
> expansion.
I agree that the the use cases and the current discussion definitely
point to a consumer-hosted shared session, and the current semantics of
public parameters fall short of that notion. The idea of a shared
session will solve a broader range of use cases than can be solved by
public parameters today. Since we have some momentum build up, it may be
worthwhile to get back to the drawing board and see where the gaps are,
leaving public params aside for a while.
Subbu
