Re: [webfinger] [appsawg] #12: Semantic gap for the client side

[Melvin Carvalho <[e-mail]>]

On 4 June 2013 02:34, Paul E. Jones <[e-mail]> wrote:

> On Sat, 1 Jun 2013 16:40:11 +0200, Melvin Carvalho wrote:
>
>> On 31 May 2013 02:08, Paul E. Jones wrote:
>>
> [snip]
>
>  scheme. Even if there were, the intent of the acct URI is to
>>> represent user accounts and the expectation is that the form would
>>> "look like" email addresses. So, what can we add to the
>>> document to make this clearer?
>>>
>>
>> There are heuristics, but heuristics tend to associate user@host with
>> mailto. I think it valid to ask the question "how would a machine
>> make this determination?"
>>
>
> Would not not be valid to simply take the email address on the From line
> and attach acct: to the front of it?  In practice, I would expect that is
> what people will do.  That's what I've seen already in practice, so I feel
> fairly confident in saying that.
>
> Granted, it will not always work.  There may not be an "account"
> associated with the email address.  And some email addresses might be
> unusual.  (Any uucp still in use today?)  But, a quick inspection to see if
> it looks like the usual user@domain is fairly common.
>
>
>  Ideally you may need a preflight lookup service that will tell a
>> machine which identifier to use. And this relation would also be
>> confirmed when you got back the JRD record. Or you need an out of
>> band (ie in the spec) translation service that can be coded into a
>> client. From the perspective of a machine, another possibility is to
>> have it cached.
>>
>
> I would think that is only true if one wants to map the email address to
> some other identifier that is very different (e.g., mapping
> [e-mail] to [e-mail]).
>
>
>  Im not a huge fan of the acct: URI scheme. It seems to me that
>>
>> /.well-known/acct/bob
>>
>> Would work just as well. Now consider a hypothetical scenario that we
>> had these two "synonyms" for a "user account". How can a machine
>> know what to translate a mailto: address into.
>>
>
> Do note that the example we're discussing is an email message.  It does
> not contain a "mailto:" URI.  Rather, it contains an email address,
> usually of the form user@domain.  (Also, it is just an example, not
> something intended to be normative.)
>
> Using the above well-known URI would certainly work vs. the WebFinger URI.
>  But then any well-known URI could work.
>
> The reason for using WebFinger is because this is the WebFinger service
> and we want to have the ability to give it any URI and the server return a
> JRD for that URI.
>
>  I would prefer to use mailto URIs instead as an indirect identifier,
>>
>> and not need acct: at all. I know some say this is problematic
>> because semantically an email address does not have a name or avatar
>> etc. However, you can also make the argument, that an account is not
>> a user, either. My bank account has a name, but it is not *my* name,
>> yet I own my bank account. In truth the distinction between user vs
>> agent vs account vs email vs representation tends to be something of a
>> grey area. It amount to striking the balance between semantic
>> rectitude, interoperability and ease of use.
>>
>
> In truth, one could use any kind of identifier.  One reason (and perhaps
> not the only reason) for not using a mailto URI is that it is not
> appropriate for some services.  I mentioned this before, but it's worth
> saying again: Twitter user accounts do not have email addresses associated
> with them.  The same used to be true of Facebook, but no longer.  There was
> a desire to have some kind of account identifier that identifies an account
> at a service.  Other kinds of services include photo sharing web sites or
> even identity management sites.  I have an account at Amazon and many other
> places where I do not have email service.  The "acct" URI can be used to
> identify the account.  In the case of your bank account, perhaps your
> account might be acct:<acct#>@<bankname.com>.  (I doubt a bank would ever
> implement WF for customer accounts, and surely would not advise it.
>  Nonetheless, that's the form of the identifier I would expect to be used
> against a WF service at the bank.
>
> So, where does this leave us?  We should either decide to make some small
> changes to the example to get rid of the discussion point about the email
> address and the leap to the acct URI, or remove the example entirely.  I
> rather like having the example, as it helps illustrate the utility of WF.
>  But, we can remove it or change it.  I don't want to go back and rehash
> the necessity of the acct URI scheme.
>

Given that the original motivation for Web Finger was the email use case
(in fact in it's first drafts it was the ONLY use case), IMHO, keeping that
example would be important.

I'm unsure how to word it, but it seems to me that user@host is most
naturally translated to mailto:user@host as a URI.  Now this will either be
the primary key of the data structure (subject) or the foreign key to the
data structure (object).  The webfinger query is asking something like
either 1) give me all key / values pairs where mailto:user@host is the
subject OR 2) give me all "sibling" key value pairs where
mailto:user@hostis the email value, in which case the subject could be
anything including
an acct: URI.


>
> Paul
>
>
>
>