Re: [webfinger] Simplifying and unjamming WebFinger

In that case, how about a deadline?

On Fri, Jun 14, 2013 at 9:50 PM, Gonzalo Salgueiro <gsalguei@cisco.com>wrote:

> Finally, a voice of reason has spoken.  Thanks, Mike!
>
> When we are in the process of clearing the final two DISCUSSes in IESG
> review is not the time to start over from scratch.  We spent years of very
> long discussion coming to consensus on the document we have now....one, I
> might add, that we were all supportive of.  Pete Resnick is asking some
> reasonable questions regarding the document providing enough client
> instruction on URI selection for the purposes of information retrieval.
>  Let's just decide if we need additional text and,when possible, offer it
> concretely to speed things along.
>
> Gonzalo
>
>
> On Jun 14, 2013, at 2:19 PM, Mike Jones <Michael.Jones@microsoft.com>
> wrote:
>
> > Tim, I’m not sure where the feeling of despair comes from, other than
> finishing things always seems to take longer than it should.  (I agree with
> you there.)
> >
> > That said, I can’t support changes to WebFinger that restrict it’s
> applicability to only e-mail addresses, and if you’re being consistent with
> your desire to have OpenID Connect succeed, neither can you.  OpenID
> Connect uses the ability of WebFinger to return metadata about URIs that
> are not e-mail addresses.  See
> http://openid.net/specs/openid-connect-discovery-1_0.html#URLSyntax and
> http://openid.net/specs/openid-connect-discovery-1_0.html#host.port.examplefor example uses with URLs.
> >
> > My take-away from this is that those of us who care about finishing
> WebFinger should double down in our participation to constructively help
> finish the IESG review process.  I would only despair if we went back to
> the drawing board, because that would set us back by years and destroy the
> chance of finishing something that’s nearly done and has been demonstrated
> to meet open discovery needs in practice.
> >
> >                                                                 -- Mike
> >
> > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On
> Behalf Of Tim Bray
> > Sent: Friday, June 14, 2013 10:17 AM
> > To: webfinger@ietf.org
> > Subject: [webfinger] Simplifying and unjamming WebFinger
> >
> > I’ve been following the endless back and forth on this with a feeling of
> despair... people seem to be talking back and forth past each other.  Lots
> of people think there are problems, Paul thinks there are no problems.
> >
> > Back in the day, when I first heard of WebFinger, it was the simplest
> thing imaginable: Put in an email address and get back some pointers to
> IDPs or whatever.  Somewhere along the way, it morphed into getting
> metadata about any Resource.  Which meant that you couldn’t just use an
> email address, you had to turn it into a URI.
> >
> > And thus the problem in the spec.  You have to figure out which URI
> scheme to use (acct:, mailto:, device:) and this will affect the output
> in ways that have to be specified in Other Places.
> >
> > But I don’t have a general-purpose problem about wanting metadata for
> arbitrary URIs.  I have several immediate pressing problems for retrieving
> metadata about  email addresses.   The former is now seriously getting in
> the way of the latter.
> >
> > So, how about a WebFinger light, in which the form of the query is
> >
> > /.well-known/wf-lite?email=bob@example.com
> >
> > Which yields a JRD.  You could still have the rel-selection and so on.
> It would be easy to understand. It would be self-contained. The draft would
> shrink in size dramatically. It would be instantly usable by OpenID
> Connect.  It would probably sail through the IESG.
> >
> >
> >  -T
> > _______________________________________________
> > webfinger mailing list
> > webfinger@ietf.org
> > https://www.ietf.org/mailman/listinfo/webfinger
>
> _______________________________________________
> webfinger mailing list
> webfinger@ietf.org
> https://www.ietf.org/mailman/listinfo/webfinger
>

-- 
@konklone <http://twitter.com/konklone> | konklone.com |
sunlightfoundation.com | awesomefoundation.org