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

On 6/22/12 6:47 PM, Schleiff, Marty wrote:
> Hi All,
>
> I don't fully understand what's required by WebFinger. I think they want identifiers that don't imply anything about resolution, that aren't confusing as to whether they represent some object or a web page describing the object, that don't imply anything about whether the identifier is persistent or not, that are unburdened by expectations like ability to send email to it or the transport is encrypted, that are just identifiers in a syntactic framework.
>
> If so, then I want that (or something close to it) too.
+1

Nice summation.

>
> Does the scheme have to be "acct:"? Does that imply it identifies an account? What if I want to identify things that don't have accounts? Would an even more generic-sounding scheme work? I think the mose generic-sounding scheme would be "uri:".

Once its not http: you will attract similar reactions to what you see 
here re. acct: .

Melvin asked about "urn:" in an earlier thread.

>
> I just wanted to chime in to let everyone know that someone unattached to WebFinger thinks such a proposal has merit.

It does.

Kingsley
>
> Marty.Schleiff@boeing.com
> Associate Technical Fellow; CISSP
> IdM & Cyber Security Services
> (206) 679-5933
>
>
>
> -----Original Message-----
> From: Henry Story [mailto:henry.story@bblfish.net]
> Sent: Friday, June 22, 2012 2:01 PM
> To: Kingsley Idehen
> Cc: www-tag@w3.org
> Subject: Re: Registration of acct: as a URI scheme has been requested
>
>
> 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</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.
>
>
> Henry
>
>> --
>>
>> 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
>>
>>
>>
>>
>>
> 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

Received on Saturday, 23 June 2012 19:24:48 UTC