- From: Joe Gregorio <joe@bitworking.org>
- Date: Wed, 31 Oct 2012 12:20:36 -0400
- To: webfinger@googlegroups.com
- Cc: Dick Hardt <dick.hardt@gmail.com>, public-fedsocweb@w3.org, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
On Wed, Oct 31, 2012 at 11:52 AM, Peter Saint-Andre <stpeter@stpeter.im> wrote: > [ +cc apps-discuss@ietf.org given that the spec is now an > Internet-Draft... ] > > On 10/31/12 9:48 AM, Dick Hardt wrote: >> +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) Agreed, +1 to everything he said. -joe >> >> -- Dick >> >> >> On Oct 31, 2012, at 12:45 AM, Brad Fitzpatrick <bradfitz@google.com >> <mailto: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 <mailto: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.) >>> >> > > > -- > Peter Saint-Andre > https://stpeter.im/ > > -- Joe Gregorio http://bitworking.org
Received on Wednesday, 31 October 2012 16:21:04 UTC