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

On Mon, Jun 25, 2012 at 2:40 PM, Melvin Carvalho
<melvincarvalho@gmail.com>wrote:

>
>
> On 25 June 2012 14:28, Harry Halpin <hhalpin@ibiblio.org> wrote:
>
>> On Fri, Jun 22, 2012 at 10:35 PM, Kingsley Idehen <kidehen@openlinksw.com
>> > 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...
>>
>>
>> Just to be clear, WebFinger is optimizing around Linked Data
>> "follow-your-nose" pattern? Somehow I find this unlikely at this stage in
>> the game, but you never know.
>>
>
>> I thought it was just using the email address to track down a domain to
>> some info about capabilities supported by the domain, and thus was never
>> actually dereferencing the email address in a web-browser.
>>
>
> The ideas and authors have changed slightly in 3 years since its original
> form.  WebFinger started by addressing a gap that additional information
> about an email address was not easily obtainable.  More recently it has
> become a general discovery app.
>
> It uses a combination of "follow your nose" and the "well known" pattern.
>
> It's possible to use webfinger with any URI, e.g. mailto: http: etc. but
> the new scheme acct: is recommended.  acct: at this point (and probably
> going forward) will be playing catchup to those that use HTTP (eg
> facebook).  And there will be those caught in the world where they now will
> have two identifiers both acct: and http: to represent the subject of an
> email address.  But Web Arch handles this already with owl : sameAs.
>
>
>>
Again, what behavior is acct: supposed to invoke on the client-side? For
general purpose discovery, again, please stick to HTTP and well-known. From
De Jong's earlier posts, it seems the sole reason for the existence of this
URI scheme is to avoid a "host@domain BNF OR URI" and just have "a URI"
without a prescribed transformation into the a HTTP URI.

In general, it sounds like folks on this mailing list, consisting mostly of
Linked Data aficionados,  are mushing up a simple (albeit likely
wrong-headed solution) for specifying "account@domain") URI scheme with
general ideas of follow-your-nose in HTTP with a browser. Go figure.

The meta-point is that unless a *new behavior* is specified, there should
not be a new URI scheme. That is why URNs are a failure, as is replicating
URN-like URI schemes for domain-specific purposes. There seems to be no
prescribed behavior with the accnt other than its usage as a parameter on
the server side to discover capabilities, which are then returned as JSON
(SWD) or XRD (Webfinger).

Again,  the idea that someone will somehow cut and paste an "accnt:" URI
into their browser is unlikely, just as unlikely as someone entering an
account of "account@domain" into a user-facing interface will somehow want
to follow-their-nose on that particular string, regardless of whether it is
a mailto or the more mysterious accnt URI scheme. This argument is just
flawed. Server side components will simply resolve accnt into a http URI
for discovery purposes, or have to invent a whole new protocol. In which
case, good luck!


>>
>>>
>>>
>>>
>>> --
>>>
>>> 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<https://plus.google.com/112399767740508618350/about>
>>> LinkedIn Profile: http://www.linkedin.com/in/**kidehen<http://www.linkedin.com/in/kidehen>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>

Received on Monday, 25 June 2012 12:53:52 UTC