Re: Registration of acct: as a URI scheme has been requested

On 6/23/12 4:57 AM, Melvin Carvalho wrote:
>
>
> On 22 June 2012 23:01, Henry Story <henry.story@bblfish.net 
> <mailto:henry.story@bblfish.net>> wrote:
>
>
>     On 22 Jun 2012, at 22:35, Kingsley Idehen wrote:
>
>     > On 6/22/12 1:02 PM, Harry Halpin wrote:
>     >> It seems like it would be better to use just mailto: (i.e., the
>     original WebFinger design was around *email addresses*, not
>     accounts per se) or a http: URI rather than mint a whole new scheme.
>     > Here's why mailto: won't work. Most user agents will invoke an
>     email client app. Remember, this is about using the URI as a name
>     rather than data locator or access mechanism. That's the reason my
>     acct: is required. Basically, follow-your-nose linked data
>     traversal (with alternative URI resolvers hooked in via
>     host-metadata pattern usage) without unintended consequences i.e.,
>     de-reference the next chunk of data etc...
>     >
>
>     Yes, though one wonders why they don't just put a URL in there: it
>     could be
>
>     http://google.com/.wellknown?id=joe@gmail.com
>
>     or whatever. All the accnt: url is is a short cut for something
>     like the above, because inevitably the account URI has to be
>     resolved in some way such as that. The confusion comes from not
>     being able to distinguish between human readable names and uris.
>
>     <a
>     href="http://google.com/.wellknown?id=joe@gmail.com">Joe@gmail.com
>     <mailto:Joe@gmail.com></a> is the way we usually differentiate
>     between human readable names and URLs.  The machine readable url
>     is hidden from view of the user, and the human readable one is a
>     string that the user can read.
>
>     I don't think that user will find the "accnt:" string in front of
>     their e-mail in any way intuitive. And if they were asked to
>     distinguish between that and an e-mail url it would get even more
>     confusing.
>
>     Furthermore the accnt uri then imposes a set of conventions such
>     as .well-known on the web where web architecture tries to avoid
>     such conventions as much as possible - essentially because there
>     is no way to impose such conventions on the whole web.
>
>
> +1
>
> And where does it end?  By exactly the same logic, should we also make 
> a user: URI to represent a user ... if not, why not?  etc. etc.

That's why you let people choose. Let them do the cost vs benefits 
analysis for themselves. Mandates don't work. Invalidating other ideas 
that are alternatives to common preference is always doomed to failure 
and endless arguments. There is really more to the Web than the myopia 
inherent in today's crop of Web Browsers.

Kingsley
>
>
>
>     Henry
>
>     >
>     > --
>     >
>     > Regards,
>     >
>     > Kingsley Idehen
>     > Founder & CEO
>     > OpenLink Software
>     > Company Web: http://www.openlinksw.com
>     > Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>     <http://www.openlinksw.com/blog/%7Ekidehen>
>     > Twitter/Identi.ca handle: @kidehen
>     > Google+ Profile: https://plus.google.com/112399767740508618350/about
>     > LinkedIn Profile: http://www.linkedin.com/in/kidehen
>     >
>     >
>     >
>     >
>     >
>
>     Social Web Architect
>     http://bblfish.net/
>
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen