Subject: Re: [apps-discuss] WebFinger compromises

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 1 Nov 2012 01:02:31 +0100

On Thu, Nov 1, 2012 at 12:34 AM, Paul E. Jones <[email-masked]>wrote:

> Brad,
>
> > To everybody who recently saw me rant about WebFinger in person
> > recently, hello again.
>
> Oh, I wish I was there... ;-)
>

I'm happy to [video] chat any time.

> > -- 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)
>
> The current language actually isn't political compromise, but more my
> desire to not break backward-compatibility any more than we have to.
>  Current spec recognizes, for example, that Google's WF server serves up
> XML.

If I change it to CSV tomorrow, will the spec recognize that?

Seriously, don't regard at all what Google does today.  It can change on a
moment's notice if this thing every shows promise of stabilizing.  The only
reason it doesn't support JSON today is that I got bored of this process.

>  Clients expecting XML will still work.

How?? The spec says only JSON is required?

>  So long as any WF server wants to support both, those clients will work.
>

I might advocate for our webfinger implementation to only return
XML-as-requested 25% of the time.  That would be more hilarious than the 0%
as required by the spec.

Going forward, XML is optional and JSON is mandatory.  I wanted to mandate
> both, but lost that argument.  (Still, supporting both is simple.  My
> server does both and will honor the Accept header.  It's trivial to do.)
>
> At some point, I will publish my server code.  It's just a simple Perl
> script, but shows how trivial it is to implement a WF server.  It does both
> XML and JSON and I do wish we would continue with both.
>

Do not even talk about implementations.  Implementations are always easy.
 I made that mistake in the past, trying to convince people how easy things
are by showing code.

What is harder is winning mindshare, and overly large, schizophrenic specs
don't instill confidence in would-be supporters.

Further, I accept the preference for JSON and only putting the requirement
> there.  But the fact is that any web resource can return ANY format.  This
> is a basic part of HTTP and the reason the Accept header exists.

So why don't you document the image/gif response type in the spec?
 (Because it would be noise.)

Just as I can file my own RFC entitled "Recommendations for serving
image/gif response payloads in Content-Type-negotiated WebFinger queries",
so can the XRD community.

The WebFinger spec is only required to document the requirements, not
ponies.

> So we should design the service such that we can support whatever the next
> hot format is.
>

I do not object to you clarifying that "WebFinger MAY return alternate
response types, if requested by the client with an HTTP Accept header blah
blah blah in the absence of an such a header, the default is JSON etc etc"

>
> So, my position is:
> 1) Let's not just kill XML because we decided we do not like it this week
> (killing all hope for backward-compatibility)
>

Let's kill it because it's not required.  I neither like nor dislike it.  I
also neither like nor dislike JSON.  I just think it's stupid for a spec to
not decide.

I'm entering this mailing list again because it has no deciders.  Everybody
just keeps saying "yes, sure, we'll add that to" (as far as I can tell).

> 2) Let's have a web service that could serve XML or JSON or next-hot-thing
> (i.e., future-proof it)
>

Don't disagree.

> 3) Let's use HTTP the way it is supposed to be used and allow the "Accept"
> header to work via /.well-known/host-meta.
>

Don't disagree.

> 4) Since host-meta.json is already defined (and I would have argued
> against it, but it's there), let's fully embrace it.
>

That's fine.  I'm not against supporting that.

> -- 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*.
>
> I'd prefer not to for the above-stated reasons.  Note that only JSON is
> required.
>
> > -- 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.
>
> We support both.  RFC 6415 defined the base for 2 round trips.  The
> current WF spec adds that extension to allow for one round trip.
>

Please acknowledge my argument, even if you don't agree with it.  Do you
understand my description of how I fear it will become a de-facto
requirement?

> And both are trivially implemented, so simple it can be done via
>
[snip]

Again, I don't care about implementations.

> I will continue to fight for Google's WebFinger support, but I'm not the
> > only one losing patience.
>
> You're right there, which is why I'm serving the role of editor.

I thank you for that, because it's a largely thankless job.  I'm coming
across as aggressive, but I really want this to work, and I view everybody
on these mailing lists as friends.  I just think we all need a reality
check.

>  I'm personally pretty happy with the way things are currently defined.
>  Aside from the vast number of comments regarding privacy, I'm not hearing
> a lot in the way of technical issues.  I'd like to move forward.
>

As would I.

> > Everybody please hurry up, simplify, then hurry up.  I'll help however I
> > can.  I'm not sure whether this was helpful.
>
> It's doesn't get much simpler than this:
>
>    curl https://packetizer.com/.well-known/host-meta.json?
>         resource=acct:[email-masked]

 Again, implementation.  Everybody on this mailing list can write a static
webserver.

Now we need to just move on to agreeing on some useful link relations for
> WF.

I will stay out of your way there.  I just want a simple base to build upon.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 1 Nov 2012 13:58:28 +0100

On Thu, Nov 1, 2012 at 6:34 AM, Dick Hardt <[email-masked]> wrote:

>
> On Oct 31, 2012, at 9:16 PM, "Paul E. Jones" <[email-masked]>
> wrote:
>
> Brad,****
>
> Comments in green:
>
>
> that is fairly random!
>

First green, then red.  I think he's pointing out that this spec is a
bikeshed and he can also pick colors.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 1 Nov 2012 15:53:10 +0100

I agree with Blaine entirely, but I'll add some commentary:

On Thu, Nov 1, 2012 at 12:47 PM, Blaine Cook <[email-masked]> wrote:

> This is great. It seems like there's largely consensus on ditching XML
> (what do we need to do to convince you, Evan? My take is that the installed
> base is easily converted as code is updated). Paul's new draft is vastly
> simpler for it. The only thing I can imagine to simplify things further
> (and possibly help the backwards compatibility question) would be to drop
> the requirement for Accept headers altogether, and just use host-meta.json.
>
> Since others (Brad, Dick) are advocating for the resource-less approach,
> I'll reiterate my support for that approach. Failing that, we should have
> only one approach.
>

Totally agreed,

> The big problems as it stands:
>
> 1. Too much complexity in the spec. A casual reader, implementing
> webfinger for the first time, will be confused.
> 2. Too many conditionals required in fully-functional clients. A webfinger
> client should ideally be implementable in just a few lines of code (i.e.,
> HTTP request, parse JSON, go).
>

An explicit example, mentioned elsewhere, is I don't think we
should mention two host-meta endpoints in the webfinger spec.  Pick one.
 Since we're saying only JSON is required and host-meta.json is already
defined, let's just pick that one.  Do not mention bare host-meta anywhere.

If a server wants to implement all of RFC 6415 independently, that's fine.
 But WebFinger should use only a subset of 6415:  just host-meta.json (a
static document, without query parameters).

> 3. Hosting is more complicated with "resource=". Ideally, server setup for
> a redirecting server could be:
>
> $ mkdir /var/www/.well-known
> $ cd /var/www/.well-known; curl -O
> http://myprovider.com/help/host-meta-template.json
>
> and done. At this point, I'd really like for Mike Jones or someone else
> who was advocating for the resource parameter to reiterate why it's
> necessary?
>
> Honestly, I don't care either way (resource or no), but would prefer *one*
> option to reduce overall complexity. I know it's not *much* complexity to
> us, since we're all very familiar with the issues, but the reality is that
> every extra feature reduces our chances of adoption significantly.
>

Yes, it should go.

host-meta isn't a search interface.  Its sole eponymous feature is
providing metadata about the host.

Yes, that means two round-trips for the cold cache case.  But it'll be just
one or two-in-parallel in practice.

- Brad

>
> On 1 November 2012 06:52, Paul E. Jones <[email-masked]> wrote:
>
>> Dick,****
>>
>> ** **
>>
>> Comments in this color:****
>>
>> ** **
>>
>> ** **
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *Dick Hardt
>> *Sent:* Thursday, November 01, 2012 1:35 AM
>> *To:* [email-masked]
>> *Cc:* [email-masked]; [email-masked]
>> *Subject:* Re: WebFinger compromises****
>>
>> ** **
>>
>> ** **
>>
>> wrote:****
>> ****
>>  ****
>> Comments in green: ****
>> ** **
>> that is fairly random!****
>>
>>
>>
>> ****
>>
>> PEJ: Yeah, so how do we get to that thing we can build on?  Current
>> requirements … bare bone … are:****
>>
>> ·         Servers must support JSON, may support XRD (or TLV or whatever)
>> ****
>>
>> ** **
>>
>> Only one.****
>>
>> ** **
>>
>> PEJ: Only one is required. I’m not pushing for requiring another, but we
>> should be forward-looking and plan for the possibility that another format
>> might be preferred one day, especially since two already exist today.  We
>> go forward with JRD, but always ask for it by name via Accept and specify
>> the Content-Type clearly.****
>>
>>
>>
>> ****
>>
>> ·         Servers must make /.well-known/host-meta and
>> /.well-known/host-meta.json resources accessible****
>>
>> ** **
>>
>> Only one.****
>>
>> ** **
>>
>> PEJ: This is historical (last year) and I’d prefer one, too.  If nobody
>> is using host-meta.json, then perhaps we get rid of it now?  But, can we
>> agree to write code properly and use the Accept header and Content-Type?*
>> ***
>>
>>
>>
>> ****
>>
>> ·         Servers must support the “resource” parameter****
>>
>> ** **
>>
>> Discuss.****
>>
>> ** **
>>
>> PEJ: Discuss what, exactly?  This allows a single request/response, which
>> some argue makes or breaks WF.****
>>
>>
>>
>> ****
>>
>> More than one has expressed a desire to be able to cache
>> /.well-known/host-meta to speed processing of resource-specific queries.*
>> ***
>>
>> ** **
>>
>> Early optimization in my opinion.****
>>
>> ** **
>>
>> PEJ: This has all been defined for years now.  This optimization is some
>> of the oldest stuff defined.****
>>
>>
>>
>> ****
>>
>>  ****
>>
>> Personally, I think we have the solution in hand. If I change one thing,
>> there is somebody who will not be happy. ****
>>
>> ** **
>>
>> Trying to please everyone leads to a mediocre standard. Have we not
>> learned anything from Apple? Not having a keypad on a phone was going to
>> make some people unhappy. Worked out well at the end of the day.****
>>
>> ** **
>>
>> PEJ: Yeah, but the problem is that I’m not the CEO who can just dictate
>> what gets done.  Standards don’t work that way :-)
>>
>> ****
>>
>> As compromises go, I think we’ve done pretty well.  I say that, because I
>> know one can build both a client and server implementation quite easily and
>> only one format they need to consider.****
>>
>> ** **
>>
>> Not true. The server needs to know both.****
>>
>> ** **
>>
>> PEJ: Server does not need to support anything other than JRD.  That’s
>> stated more than once.****
>>
>> ** **
>>
>> Paul****
>>
>> ** **
>>
>
>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 31 Oct 2012 22:34:51 -0700

that is fairly random!

> PEJ: Yeah, so how do we get to that thing we can build on?  Current requirements … bare bone … are:

Only one.

> ·         Servers must make /.well-known/host-meta and /.well-known/host-meta.json resources accessible

Only one.

> ·         Servers must support the “resource” parameter

Discuss.

> This means the vanilla client on the Internet will query only for JSON.  Client developers have mostly said they want the simplest possible solution, which means most will send requests with the “resource” parameter. 

As a resource developer, I want a simple solution as well.

> More than one has expressed a desire to be able to cache /.well-known/host-meta to speed processing of resource-specific queries.

Early optimization in my opinion.

>  
> Personally, I think we have the solution in hand. If I change one thing, there is somebody who will not be happy. 

Trying to please everyone leads to a mediocre standard. Have we not learned anything from Apple? Not having a keypad on a phone was going to make some people unhappy. Worked out well at the end of the day.

> As compromises go, I think we’ve done pretty well.  I say that, because I know one can build both a client and server implementation quite easily and only one format they need to consider.

Not true. The server needs to know both.

-- Dick

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 31 Oct 2012 12:20:36 -0400

On Wed, Oct 31, 2012 at 11:52 AM, Peter Saint-Andre <[email-masked]> wrote:
> [ +cc [email-masked] 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 <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>> 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
>>> [email-masked] <mailto:[email-masked]> 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)
>>>
>>> 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*.
>>>
>>> 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)
>>> 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