Re: WebFinger compromises

On Thu, Nov 1, 2012 at 12:34 AM, Paul E. Jones <paulej@packetizer.com>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:paulej@packetizer.com


 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.