Re: [webfinger] [appsawg] #12: Semantic gap for the client side

[Gonzalo Salgueiro <[e-mail]>]

Mike - 

Thanks for steadying the ship and looking for a sensible way forward.  My comments inline...

On Jun 14, 2013, at 9:43 PM, Mike Jones <[e-mail]> wrote:

> I've just read about two weeks of WebFinger mail (catching up after vacation) have the following observations on how we might make progress towards closing the issues being discussed.

Must have been a jarring realization that vacation was over ;-)
> 
> 1.  Explicitly state that WebFinger is a framework and that the information to be returned for specific "rel" link relation types for specific kinds of URIs is outside the scope of the specification, but is intended to be defined by other specifications.

I'm okay with this, so long as we keep clear that in addition to a framework there is a real protocol definition here that clearly prescribes on-the-wire behavior.
> 
> 2.  We could establish a registry indexed by "rel" link relation values pointing to documents that define this information.  For instance, we could then register the "rel" value "http://openid.net/specs/connect/1.0/issuer" and point it to http://openid.net/specs/openid-connect-discovery-1_0.html, which defines the meaning of that link relation.  Other link relation definitions could then also use that registry.

Sure. This is a simple step to take to provide clarity on existing uses of WF.
> 
> 3.  Explicitly state that the link relation types that will be returned from server when no "rel" parameter is used is entirely dependent upon the services supported by that host, and that, in the general case, clients must be prepared for the response to be the empty set for any particular resource.

Is this necessary? What does this buy us?
> 
> 4.  Since people are finding the examples problematic, we could remove them, or possibly only keep the OpenID Connect one, which is concrete and being used in practice.  Or in fact, we could add a second OpenID Connect example - so that there's one with the resource being a URL and another with the resource using e-mail address syntax.  We could also bring over the apparently-innocuous "copyright" and "author" examples from RFC 6415, if those would cause people less consternation.  But the device and e-mail examples seem to be generating more heat than light.

I've very reluctantly suggested this to Paul as well.  Not because I don't like the examples.  In fact, I consider them some of the most useful text for implementers and for their value in quickly relaying the power of current usage and future potential of the protocol.  In the interest of an expeditious resolution to this stalemate I'd be willing to remove the two examples giving problems, though I'd warn that we do have tangible useful information loss (e.g., no demonstrated use of properties, etc.).  My position on this is only because I expect to write future documents that will allow us to resurrect these deleted examples.  

BTW - The addition of a supplementary OpenID Connect example seems reasonable and helpful.
> 
> 5.  We could remove all references to and discussion of the acct: URI, since WebFinger actually has no dependency upon it.  Other specifications can still specify that it be used in particular contexts with WebFinger, as OpenID Connect does.

This is tragic considering they were so closely intertwined that they were one and the same document at one point. That said, if it helps get us to publication quickly...
> 
> I realize that the examples provide more context for developers but if they're standing between us and finishing the spec it would be better for them to go.  Likewise, if acct: is standing between us and finishing, it should go too.
> 
> I'll close by saying that I believe that WebFinger does one simple thing very well - enabling querying about a resource at a host, optionally narrowing the query to a particular kind of information of interest.  Like OAuth, this protocol is both incredibly simple and incredibly powerful.  Like OAuth, particular applications of WebFinger will define particular syntax to be used in requests and responses that meets the needs of those applications.
> 
> Let's focus our energies on deciding what the best next steps are to finish in a timely manner.

Amen.

Thanks,

Gonzalo


> 
> 				Cheers,
> 				-- Mike
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Pete Resnick
> Sent: Friday, June 14, 2013 11:02 AM
> To: Barry Leiba
> Cc: salvatore loreto; Paul E. Jones; Melvin Carvalho; [e-mail]; webfinger
> Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side
> 
> On 6/14/13 11:59 AM, Barry Leiba wrote:
> 
>> There are two ways we can get interoperability from this.  One is to 
>> explicitly specify everything that might be returned from a particular 
>> query.  Another is to make sure that what gets returned is 
>> self-defining.  The latter is the point of link relations -- the link 
>> relation tells you what the link means, so the recipient knows whether 
>> it understands this type or not, and, if it understands it, knows what 
>> its semantics are and what to do with it.
> 
> That will make the response interoperable. It does not help me make the query.
> 
> There is no problem in this protocol on the server side. The problem is on the client side. There is no specification of what the client is supposed to do.
> 
> pr
> 
> --
> Pete Resnick<http://www.qualcomm.com/~presnick/>
> Qualcomm Technologies, Inc. - [phone]
> 
> _______________________________________________
> webfinger mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webfinger
> _______________________________________________
> webfinger mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webfinger
>