Subject: Re: [apps-discuss] WebFinger compromises

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 31 Oct 2012 09:52:50 -0600

[ +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)
> 
> -- Dick
> 
> 
> On Oct 31, 2012, at 12:45 AM, Brad Fitzpatrick <[email-masked]
> <mailto:[email-masked]>> 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
>> [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)
>>
>> -- 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/

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 31 Oct 2012 19:34:55 -0400

Brad,

> To everybody who recently saw me rant about WebFinger in person

Oh, I wish I was there... ;-)
 
> conferences for years before it sorta became a thing. I think I even

Cool! Always wondered where the name came from.
 
> (https://groups.google.com/group/webfinger/msg/e8df6402708841ea)

That also answers questions kept asking when I mentioned Google had support for it.
 
> [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.

That WF has done.
 
> (trying to establish that I'm a friend here)

(gulp)
 
> -- this is the slowest moving community ever (I accept part of the blame
> here)

No kidding.  Some I-Ds take 8 or more years in the IETF.  By the time we make it perfect, the "opportunity has set sail"... I've seen that happen several times.  Then people ask why we don't standardize some things.  It's the process sometimes.  Standardization is not always worth it.
 
> -- 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.  Clients expecting XML will still work.  So long as any WF server wants to support both, those clients will work.

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.

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 we should design the service such that we can support whatever the next hot format is.

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)
2) Let's have a web service that could serve XML or JSON or next-hot-thing (i.e., future-proof it)
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.
4) Since host-meta.json is already defined (and I would have argued against it, but it's there), let's fully embrace it.
 
> 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.
 
> 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.

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.

And both are trivially implemented, so simple it can be done via static files with an Apache server:
http://www.packetizer.com/webfinger/server.html
 
> 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'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.
 
> 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]

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

Paul

---

From: Tim Bray <[email-masked]>
Date: Wed, 31 Oct 2012 18:04:49 -0700

At this point, the XML is a distraction and an irritant and offers
zero benefit to implementers.  Just. Drop. It.  Not optional, just
gone.

 -T

On Wed, Oct 31, 2012 at 4:34 PM, Paul E. Jones <[email-masked]> wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: William Mills <[email-masked]>
Date: Wed, 31 Oct 2012 19:45:07 -0700 (PDT)

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

FYI the link relations for OAuth are defined and have been accepted in the ISE publication track as an informational RFC.

>________________________________
> From: Paul E. Jones <[email-masked]>
>To: [email-masked]; [email-masked] 
>Cc: [email-masked] 
>Sent: Wednesday, October 31, 2012 4:34 PM
>Subject: Re: [apps-discuss] WebFinger compromises
> 
>Brad,
>

---

From: William Mills <[email-masked]>
Date: Wed, 31 Oct 2012 19:45:19 -0700 (PDT)

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 1 Nov 2012 00:16:19 -0400

Brad,

Comments in green:

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?

PEJ: The spec does not say that explicitly, but it says that /.well-known/host-meta defaults to XML. If a different format is desired (and the only one mentioned is JSON), it must be requested using the Accept header.  That’s the way web interfaces are supposed to work, after all.  So while I don’t have any expectation of a new format being introduced soon, this allows the possibility and I do think we should allow for that possibility.  Within an enterprise environment, perhaps there is a CSV format preferred and it’s selected using Accept. 

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.

PEJ: Google is just one implementation.  There are others and I’ve been asked to try to not break them.  The way the spec is written, what works continues to work.  More importantly, it trivial as hell to maintain that backward-compatibility.  One might even view it as forward-compatibility, too.  I do think we should definitely design for use of other data formats in the future, and that is built in.

 Clients expecting XML will still work.

How?? The spec says only JSON is required?

PEJ: I was referring to existing clients and servers.  Any new JSON-only servers will not work with XML-only clients.  That’s to be expected and that’s OK. There is no loss of existing functionality. 

 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.

PEJ: Now that would be ugly.  At least consistently work or fail… ;-) 

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.

PEJ: I’ve seen it go both ways.  Sometimes, if you just build it people ignore it, because it’s not a standard. Sometimes if you write the standard, then people open their eyes.  A useful demo might help, such as having Chrome respond to “acct” URIs and display a “profile” page in the browser, pulling info from the WF server and following the links.  Such highly visual demonstrations work better than code in a server or specs on paper.

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.

PEJ: The spec does only list the requirements (and procedures). There’s no point documenting how to send any other format than those that actually exist in practice.  My only point is that I think we should try to ensure the protocol aligns with the intent of HTTP and support other types should ever a day come.  It may never happen, but we should not box ourselves into a corner, either, especially when the HTTP spec explains how it should work.

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"

PEJ: That’s what is says for host-meta.json. Strictly because there are some existing implementations, it says the default for host-meta is XML.  I can change that, but I feel like the guy in the middle with people on one side yelling “to hell with XML” and people on the other side saying “we already have that implemented!”  Leaving the text as it is addresses every concern, except for those who hate seeing the word XML or XRD. ;-) Because I even uttered the word – introduced no requirements on new servers – it is said to be complex.  If I change the text, it does not change the implementation requirements in the least if one only implements JSON. 

So, my position is:

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.

PEJ: But it is decided.  Requirement is JSON. People writing code tomorrow ONLY have to worry about JSON, both client-side and server side.  *If* people want to use XML, then the spec explains how that is done, but it is not a mandatory feature, thus it will not be universally implemented.

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).

PEJ: We’ve not added any new features in a long time.  We have moved XML to the “optional” status, we removed the “acct” URI scheme to a separate document, and next on the list (IMO) should be the “acct” link relation (moving to a separate doc).  It has only gotten simpler, in other words.

Don't disagree.

Don't disagree.

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

[snip]

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?

PEJ: The “resource” parameter (allowing one round trip) is mandatory in the spec currently.  I originally introduced it (at Eran Hammer-Lahav’s request) as “optional”.  The group was fairly keen on making that mandatory, pushing for the requirement even before the text was adopted as a WG item.  So, the de facto standard you fear is the standard (per the current text).  Do you not want to mandate the “resource” parameter? It has been mandatory since the draft published in May this year.

> 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.

PEJ: Aggressive?  You’re mild compared to some others. :-)  People feel passionate about different things.  I also just want this to work.  I see a lot of potential with WF for enriching social networking, enterprise applications, etc.

   curl https://packetizer.com/.well-known/host-meta.json?
        resource=acct:[email-masked] <mailto:[email-masked]> 

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

PEJ: That one isn’t static: it’s pulling data from a live database and formatting is per the client’s request. But to your point, many people on this list could build that server code, too.  The reason I wrote that was to demonstrate its functionality and to help those who cannot build one themselves.  I do want to ensure anyone with a domain can throw up a WF server.

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

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)

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

·         Servers must support the “resource” parameter

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

Personally, I think we have the solution in hand. If I change one thing, there is somebody who will not be happy.  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.

Paul