Re: WebFinger compromises

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

On Thu, Nov 1, 2012 at 12:47 PM, Blaine Cook <romeda@gmail.com> 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 <paulej@packetizer.com> wrote:
>
>> Dick,****
>>
>> ** **
>>
>> Comments in this color:****
>>
>> ** **
>>
>> ** **
>>
>> *From:* webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] *On
>> Behalf Of *Dick Hardt
>> *Sent:* Thursday, November 01, 2012 1:35 AM
>> *To:* webfinger@googlegroups.com
>> *Cc:* public-fedsocweb@w3.org; apps-discuss@ietf.org
>> *Subject:* Re: WebFinger compromises****
>>
>> ** **
>>
>> ** **
>>
>> On Oct 31, 2012, at 9:16 PM, "Paul E. Jones" <paulej@packetizer.com>
>> wrote:****
>>
>>
>>
>> ****
>>
>> Brad,****
>>
>>  ****
>>
>> 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****
>>
>> ** **
>>
>
>