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

[John C Klensin <[e-mail]>]

--On Saturday, April 14, 2012 01:11 +0200 Carsten Bormann
<[e-mail]> wrote:

> 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*. (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.)

Carsten,

Just a quick personal opinion, related to your more general
comment above but almost unrelated to the specific OAUTH
parameter.

We (that is IETF and W3C) made a decision (a very long time ago
as these things go) to not establish an explicit terminator for
the end of a URI tail.  If we had such a terminator, we would
now have a place, post-terminator, for putting "stuff" that is
important but that would not foul up comparison of URIs.  If we
were smart about it, we might even establish a keyword registry
for things hung off  the end, thereby eliminating one of the
other problems that people are concerned about.

I don't know if it would be possible to revisit that decision at
this point.  Certainly it would be painful if it were even
possible.  But it seems to me that it, or something like it (an
equally difficult possibility might be to figure out a way to
hide qualifying information in the vicinity of the Method field)
are, I think, the only ways that one can both insert information
that is relevant to aspects of URIs generally without
compromising either the ability to compare them of the
assumption that anything that falls into the tail belongs to the
target server and gets interpreted pretty much as it desires.

regards,
    john