Since we are on the subject of url's as id's. Here is something that has puzzled me. I hope somebody can shed some light on this.
If I were a average user here is the order of preference i would have liked for an OpenID. I am sure most people will agree with me. 1) Santosh Rajan 2) santosh.rajan 3) santosh.rajan.myopenid.com 4) http://santosh.rajan.myopenid.com 5) http://myopenid.com/santoshrajan Now (1) and (2) are not practical so we will eliminate that. (3) is the best option as I see it. I know you will say that there is no difference between (3) and (4). But if you are an average user it makes a huge difference. Because (3) looks more like a name, while (4) looks like a location. So the puzzle is why wasn't (3) chosen as the Openid instead of (4) and (5) ? SitG Admin wrote: > > I thought the idea with generation fragments was that the user would > enter 'site.net/myname' and the OP would use Directed Identity to > turn that into 'site.net/myname#2' (for the second user to have that > name), not that the user would enter said generation fragments > themself. That said, I just experimented with appending '#generation' > manually, and confirmed that this was treated as a different URI > (which was only to be expected, since the specs permit any string > that would be a legal URL). > > I was *hoping* to find a character that would be ignored ('#' seemed > most likely, since Directed Identity doesn't rely on it being entered > as part of the original URI), one that I could use to parse out > additional parameters such as '#SecretAccessCode0123' and '#WML' - > these would be stored on my server's side, then used as preferences > when the user returned. But since it's conceivable that a user might > have an actual URI ending in (for example) '#WML', *removing* these > from the input before my RP decides to treat the whole string as a > URI and performs discovery on it, may inadvertently mangle the user's > URI. > > I'm inclined to go ahead with this method for now, since I doubt many > users *will* have a URI like that, and I doubt many users will be > browsing the site where this is implemented in any case (so it's not > like I'll be giving millions of users the wrong idea about permitted > characters). But if any of you currently planning future updates to > the specs have a better idea for what character to use as a > delimiter, I'd love to hear it :) > > -Shade > _______________________________________________ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > ----- Santosh Rajan http://santrajan.blogspot.com http://santrajan.blogspot.com -- View this message in context: http://www.nabble.com/Directed-Identity-and-the-%27-%27-symbol-tp23238071p23239599.html Sent from the OpenID - Specs mailing list archive at Nabble.com. _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
