Re: Adding user@ to HTTP[S] URIs

[Rick van Rein <[e-mail]>]

Hi James,

Thanks for your cautious response.

> If I understood correctly, what is being proposed is instead of (using
> prev response examples):

Not instead of, but in addition to.  I have no quarrel with existing
habits, I just want also be able to express things with more semantics,
with broader validity.

The treatment of user identities does not add something that cannot also
be done under other conventions.  However, these other conventions are
local, and tighten the relations between parties and reduce the
opportunity for automation, for being systematic, for solving things
over a broad range.

My angle on this is from architecting an identity model that spans more
protocols than just the web.  Every time I look at HTTP, it seems to
have invented its own wheels and not be willing to mingle with the other
protocols.  That is the kind of problem for which I would like to have
handle bars, instead of being forced into local conventions that are
meaningful to a server but leave the client unaware of meaning.

> what a URI can and cannot be (or should be) is a minefield with
> respect to specifications vs what we have in the 'real world'

I suppose the question is if there is any concrete mine below the lines
I've written.  There are surely problems but I wonder if any apply here.

> I think I completely understand the rationale for your proposal ...
> just 'old man cranky' on the reality of adopting such a change.

I think a proposal that creates new corners for use of HTTP is helpful
on its own.  The risk, if we only look at overall domination, is that we
enslave ourselves to a few very large corporations and basically give up
our control over Internet technology.  Said the innovator, who also
happens to be old :)

> The userinfo section is optional with scope and context related to the
> denoted host ... as prev mentioned should not be transmitted.

Should not be transmitted as part of the Host header, indeed.  I also
found that everyone is welcome to define a new header :)

> Then I wonder what should happen when User: Mary1 has an authorisation
> with user="mary" ... having such drift may confuse things.

In the example I gave, they are identities from different name spaces;
and they are linked by the server, presumably through some kind of ACL.
That ACL would say things like "Mary1" is the resource being addressed,
and it accepts/rejects users who authenticated as "mary".  ACLs tend to
be pretty accurate in linking resources and users ;-)

This decoupling is at the heart of my reasoning.  It makes sense in most
of the protocols, but HTTP has, probably due to Basic/Digest
authentication, gotten them mixed up.

> It is not obvious how this change might affect idempotency eg. what
> happens when Mary gets a different document then John based on routing
> with the new User: header.

Idempotency means that doing the same thing again has no added effect.
What does that mean here?

> Existing servers, clients, cache (middle
> box or otherwise) may have to cater for this change.

Please let me know if the cache solution in the proposal is incomplete.
 Please let me know if the statement that a server may ignore the User:
header (and presumably present a fallback page) is insufficient.  Please
let me know whatever concrete issue you are seeing that I missed!

> URI's are 'forever' and used in a lot (a lot) of different places ...

I think this is your assumption that I would abolished existing
patterns.  Far be it from me to stop anyone from doing anything that
they have grown accustomed to, or fallen in love with.  I would however
like to have an alternative path that offers more semantics, and that
may very well be an alias to the existing practice.  (I actually coded
the User: header into Apache's mod_userdir as an alias.)

> (no doubt due to my own ignorance) I struggle to see the benefits over
> using existing 'machinery' and there maybe 'dragons' ...

Please introduce me to any dragons you encounter; this caution alone
does not seem cause for action yet.

Thanks,
 -Rick