Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer

[Ned Freed <[e-mail]>]

> On Apr 12, 2012, at 18:34, Tim Bray wrote:

> > Well, it would claim it as a reserved paramater name if there a way to
> > do such a thing, which there explicitly isn’t in RFC3986.  URIs are
> > for most application purposes opaque strings; this breaks that and is
> > a hideous architectural botch.

> I would like to turn this observation around.

> People put stuff like this into the URI because there are applications where it would be useful to combine information such as what we'd prefer to put into HTTP header fields with URI information into one *thing*.

This is clearly true, and there are all sorts of hacks out there to do this.

There are just too many places where you have only one slot, so you have to
combine stuff into one, as you say, thing.

That said, the rules are what they are, and comparison of URIs has to be taken
into account.

> (Or they put stuff into Cookies because this URI munching doesn't always work
> very well either.)

> Independent from the specific subject here (where there is little point in
> further invention), I think it would be useful to explore a little more the
> reasons for this and maybe find a better way to carry around information that
> is ancillary to a resource access.  The recent http+aes brouhaha is another
> (somewhat different, as it is client-side only) example for this need, I think. 
> (The way mailto: has evolved is an example where this need could be met within
> the URI scheme.)

I think this is an excellent idea, but of course it's far outside the purview
of the present document.

				Ned