Re: WebFinger compromises

+1 on everything. 

A simple, easy to understand spec that solves the major use cases released soon is far superior to kitchen sink spec that solves all use cases that is released in a year.

JSON only (if that is not obvious, you need to write some code this decade)

1 round trip vs 2 round. Pick one that is simple to implement. Let's not get caught up in optimization. Brad's comments below seem sane (as usual)

-- Dick


On Oct 31, 2012, at 12:45 AM, Brad Fitzpatrick <bradfitz@google.com> wrote:

> To everybody who recently saw me rant about WebFinger in person recently, hello again.
> 
> To everybody else, a brief summary:
> 
> -- I was an early WebFinger evangelist. I remember discussing it at conferences for years before it sorta became a thing. I think I even named it?
> 
> -- I added Google's WebFinger support (https://groups.google.com/group/webfinger/msg/e8df6402708841ea)
> 
> -- I think it's critically important for the Internet to preserve user@host.com hierarchical identifiers before email gets too passe and we're stuck with single-namespaced walled gardens.  It's on us to make email-looking identifiers more useful to compete with all the latest proprietary silo hotness, before the people of the internet no longer recognize them.
> 
> (trying to establish that I'm a friend here)
> 
> That said,
> 
> -- this is the slowest moving community ever (I accept part of the blame here)
> 
> -- can we please stop changing things?
> 
> -- JSON, XRD, great, whatever.  But let's just pick one.  If JSON is now the hotness, let's pick *only* JSON.  Specs that say "X is required but you can maybe do Y if you want to" just reek of political compromise to gain a certain party's favor.  Look at OpenID 2.0.  (I remember being sad about those political moves too, but I had lost the energy to fight)
> 
> -- My recommendation: just remove all mention of XRD from the latest WebFinger spec.  Yes, this is counter to my "please stop changing things" bullet earlier.  But WebFinger has a better chance of success if it's a simple spec.  And you're not breaking compatibility with anybody because *nobody uses WebFinger*.
> 
> -- 1 round trip, 2 round trips. Don't really care. 2 round trips keeps the spec simpler and the 1st will be highly cacheable (Expires: weeks), so it's 1 round trip in practice, but I won't fight (too much) *optional* parameters in the 1st request to possibly skip the 2nd request.  It worries me, though.  I'd rather see that optimization added in a subsequent version of the spec, so all 1.0 implementations have then shown that they're capable of performing the base algorithm.  I worry that too many servers will implement the optimization and then lazy clients will become pervasive which only do one round trip, thus making the "optional" optimization now de facto required for servers.  So I'd really rather drop that from the spec too.  Let's add it only later, once it's shown to be needed.  As is, clients could even fire off two HTTP requests in parallel to reduce latency, one for host-meta and one optimistically for the presumed host-meta location in cases of big hosts that rarely change, or expired cached host-meta documents.
> 
> I will continue to fight for Google's WebFinger support, but I'm not the only one losing patience.
> 
> Everybody please hurry up, simplify, then hurry up.  I'll help however I can.  I'm not sure whether this was helpful.
> 
> - Brad
> 
> (If any of the above is offensive to my employer, I'm speaking as myself.)
>