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

["Paul E. Jones" <[e-mail]>]

Pete,

On Thu, 13 Jun 2013 10:09:32 -0500, Pete Resnick wrote:
> Sorry for not hopping into this conversation much earlier. I'll
> try to be very responsive so we can make some progress on this.
> 
>  On 5/30/13 7:08 PM, Paul E. Jones wrote: 
> 
>> So, the first part of the issue seems to be one of "what URI do I
>> use and why?" The answer really is "whatever URI you have".
>>
>> The second paragraph goes into one area where I understand why one
>> might be confused. In the example, the client queried the acct URI
>> and just fabricated that by taking the email address (of the form
>> user@domain) and turning that into an account URI. That said, I
>> don't know I would call that a semantic gap. Humans do this. If you
>> see user@domain, you assume it's an email address.
> 
>  OK, so I'm the client. I've got an email address. What URI do I use
> if I want email configuration parameters? Do I use mailto:? Or smtp:?
> Or pop:? Does acct: get me email configuration parameters along with
> personal information about the user?

You're assuming WF defines how to provision an email client.  It doesn't.
There is an example in the text, but it is merely an example to illustrate
the kinds of things WF can be used.

In order for WF to be used in provisioning an email client, the specific
procedures would need to be spelled out in a document somewhere. 

>  I also think that email address is also a jabber ID (or maybe I'm
> wondering if it is)? Do I do a second query with jabber:user@domain?
> Or will acct: get me back jabber account info?

Each URI queried might return the same or different information.  The
specifications that rely on WebFinger would state explicitly what URI to
use.  As an example, the OpenID Connect specs state that
acct:[e-mail] would be used to issue a WebFinger query.

In general, it is expected that if one is looking for account information
related to an identifier in user@domain form, then acct: would be used.  For
example, if you are looking for a picture of me that I publish, a list of
mew ATOM feeds, or whatever else I might publish, that would be used.
Obviously, this does not necessarily get all information about me, nor might
the querying entity even be querying the correct account.

But we all have lots of accounts in lots of places.  We have picked on
Twitter a number of times, because it's an good example of why "acct:" is
needed.  There are no email addresses there.  So, let's say you know my
Twitter ID paul_e_jones.  You could issue a query to
acct:[e-mail].  At least that's the intent.  What might be
returned is whatever I publish via my account on the Twitter service.

The acct URI is not tied to any particular protocol, but is intended to
relate to a user account at the specified domain.

But, we do want to allow any URI to be queried.  It's even possible to query
the URI "http://www.packetizer.com/" via WebFinger.  That's a web page, not
a person or account.  Querying for that will return whatever information the
server wants to return.  This is what one could do with RFC 6415, so the
same functionality is carried forward.
 
>  My real concern here is that this document gives me no help as to
> what kind of information I get back from any given URI, and gives me
> no help in how to choose the right URI scheme to get me back the info
> I want. The assumption appears to be, "You client get to choose
> whatever URI scheme you think is interesting, and if I server have
> information about that URI, I'll tell you what it is. Otherwise, try
> again." That's not interoperable.

You are entirely right that it does not give guidance, except for "acct".
If you are querying for information related to a user's account at some
domain, then use "acct".

If I want to know information about a particular URI, query for that URI.

The problem is not knowing what URI to query, but knowing what set of links
will be returned as a result of using a particular URI.  That's not defined,
because we cannot specify in this spec how to provision an email client or
what kind of information one might want returned if querying for a Jabber
ID.

The expectation is that other documents would define link relations.  In
fact, we already have a laundry list of those that folks want to define.  As
those are defined and registered in the existing registry, then the URI to
use with WF would also be defined.  They might all end up under "acct" as
OpenID Connect specifies.  However, if the aggsrv group elects to use
WebFinger to bootstrap the discovery process, they might specify the use of
mailto: to get links to aggsrv documents.
 
>  I can come up with grand re-designs to address my concerns, but if
> you've got answers to the above questions, maybe that will help us
> figure out some easy stuff to add (an IANA registry, a "how to figure
> out URI semantics" section, etc.) that will make this protocol make
> sense.

I'm certainly willing to add more text to help make the point, but I'm not
sure what to add where.  Basically, use various URIs and the expected set of
links relation types (and, thus, links) is intended to be defined in other
specifications, not the base WebFinger spec.

Paul