Re: [apps-discuss] Looking at Webfinger

[Phillip Hallam-Baker <[e-mail]>]

IETF Working Group process is not just a documentation effort. If all
that is required is to document what exists then an independent
submission is more appropriate.

In this case we have a protocol that engages in what many of us feel
is a weird, inefficient and convoluted approach with no apparent
motivation. It would be bad even if XRI was not tainted from an IPR
standpoint (and will remain tainted unless the rights holders release
the right to run a registry).


Finger was the simplest protocol, so why is WebFinger complex. Why is
it anything more than a single HTTP lookup to request the relevant
data? That is what Web servers are designed to support after all.

I can see that it might be appropriate to make use of the HTTP
authentication capability to return different profiles depending on
who is asking. But that is also well established.



On Wed, Jul 4, 2012 at 11:23 PM, Paul E. Jones <[e-mail]> wrote:
> Mark,
>
> WebFinger has been around now for a few years.  This most recent effort is
> one of formally documenting it.  The plan for a long time has been that
> discovering information about users or entities on the Internet would be via
> host-meta and, more specifically, Link-based Resource Descriptor Documents
> (LRDD).  XRD was created for this purpose, which is why we see it used in
> this document.  JRD was subsequently introduced as RFC 6415 was developed.
> While LRDD is still present on the server side, the most recent version of
> the WebFinger spec effectively hides that via the "resource" parameter.  So,
> it's not really that we're building upon host-meta, but really that we're
> formally documenting the procedures that were laid down long ago.  WebFinger
> and host-meta was moving along together.
>
> What I find most attractive about the approach taken is the consistency and
> the fit with the web linking work that you did, essentially serving up a set
> of link relations related to the entity that is queried.  WebFinger will
> serve up an XRD or JRD document, as desired by the client, that contains a
> list of link relations that allow one to convey through those relations all
> sorts of information about the entity being queried.  That might be a vCard,
> portable contacts, OpenID identifier, mail server configuration, or other.
>
> Another thing I find attractive is the consistency in the approach to
> discovery. Regardless of the URI, I can query for information in precisely
> the same way.  It might be an acct URI, a mailto URI, an HTTP URI, etc.  If
> I want to discover information about acct:[e-mail] or
> http://www.packetizer.com/people/paulej, I can use the same discovery
> mechanism.  In this case, the server might even be configured to return the
> same set of information of both identifiers refer to the same entity.  In
> any case, it is important to allow for discovery of entities on the Internet
> that are not necessarily users, but any URI.
>
> Paul
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> On Behalf Of Mark Nottingham
>> Sent: Tuesday, July 03, 2012 1:47 AM
>> To: IETF Apps Discuss
>> Subject: [apps-discuss] Looking at Webfinger
>>
>> I've pretty much ignored the whole webfinger / acct: / SWD discussion (too
>> much!). However, since it's apparent it may soon become Real, I had a
>> look.
>>
>> In a nutshell, my initial reaction is "It's Not Nearly As Bad As I Thought
>> It Would Be." :)
>>
>> With that in mind, a few questions / comments (I'll resist going into
>> editorial matters, for the time being):
>>
>> * First and foremost, why use host-meta? What value does adding this extra
>> step to the dance bring, beyond "We've defined it, therefore we must use
>> it?"
>>
>> As I think I've said many times before, the whole point of a .well-known
>> URI is to group like uses together, to avoid having a "dictionary"
>> resource that gets bloated with many application's unrelated data, thereby
>> overburdening clients with too much information (especially when they're
>> constrained, e.g., mobile).
>>
>> As such, host-meta is a spectacularly bad example of a well-known URI.
>> Defining a end-all-be-all well-known-URI kind of removes the point of
>> having a registry, after all...
>>
>> Instead, why not just define a NEW well-known URI for user data? That has
>> a more constrained scope, and saves one round trip (or more). E.g.,
>>
>> GET /.well-known/webfinger?user=bob%40example.com HTTP/1.0
>> Host: example.com
>>
>> I.e., let webfinger define the URI template to use. Yes, some
>> implementations might want to come up with crazy URIs, but is that really
>> a problem we want to solve?
>>
>> Astute observers will notice that this approach removes the need for an
>> ACCT URI scheme (at least here).
>>
>>
>> * What's the fascination with XRD and JRD? These specifications seem to be
>> creeping into IETF architecture; first it was in a pure security context,
>> but now folks are talking about using them in a much more generic way, as
>> a cornerstone of what we do. As such, I think they deserve a MUCH closer
>> look, especially since we're defining things with "Web" in their name when
>> the W3C has already defined solutions in this space.
>>
>> Thanks,
>>
>>
>> --
>> Mark Nottingham   http://www.mnot.net/
>>
>>
>>
>> _______________________________________________
>> apps-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss



-- 
Website: http://hallambaker.com/