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

Harry Halpin wrote:
> 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).

Exactly, so make it a variable:
     https://gmail.com/.well-known/host-meta?acct=joe@gmail.com

as RFC6415 allows under 3.1.1.1 instead of creating a new scheme. It 
delivers the functionality, and avoids the need for that BNF or creating 
a new acct: scheme.

Or, as Melvin pointed out, "Simple Web Discovery" would handle the 
needed functionality also.

Best,

Nathan

Received on Monday, 25 June 2012 13:07:51 UTC