From melvincarvalho@gmail.com Sat Jun 1 07:40:18 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A99621F9D4A for ; Sat, 1 Jun 2013 07:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgWlWqquQm0Q for ; Sat, 1 Jun 2013 07:40:16 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id F404D21F9D49 for ; Sat, 1 Jun 2013 07:40:12 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id ee20so2237883lab.14 for ; Sat, 01 Jun 2013 07:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rRs+rR/KWHOM0ZM/ImVfraDt1SWA6k+2nXIoE4gWlu4=; b=vmy9M++7Ae/NWY66Ls3LfRWjXADgXTwy28OtdPZhLPT08QL64liZvB46QXXuDbVRMu e/V9XL3YDSdjwjt6BOetRSzZObN6Fw3dkh/ireyjZXhQMMcgcT7XjdNhG47oHcxVGmAz xD4c2sPjkMBUQUXVaDanFPJZ3COI52IEOnck4uZdhTgrS2shNWsm6rKHx66ag6eOGI0u 58Yd0J25JcXF/4s3wtOIS5585q3P/6kLQiJgw3qhacTXZP8dpV9tI9nikBbU5pdSiaxI mkkZO3LqkzphFjB9/gw8dK5LMvD3bEHt4EmvAlXtfkIcdQ2zl+DHVAWmVhc+33mkvnLb oEFw== MIME-Version: 1.0 X-Received: by 10.112.142.97 with SMTP id rv1mr7738726lbb.134.1370097611859; Sat, 01 Jun 2013 07:40:11 -0700 (PDT) Received: by 10.112.20.231 with HTTP; Sat, 1 Jun 2013 07:40:11 -0700 (PDT) In-Reply-To: <024301ce5d92$f7d06080$e7712180$@packetizer.com> References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> Date: Sat, 1 Jun 2013 16:40:11 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=001a11c3683a766b2b04de18b589 Cc: salvatore loreto , webfinger , draft-ietf-appsawg-webfinger@tools.ietf.org Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 14:40:18 -0000 --001a11c3683a766b2b04de18b589 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 31 May 2013 02:08, Paul E. Jones wrote: > Melvin,**** > > ** ** > > Thanks for bringing that text forward.**** > > ** ** > > All,**** > > ** ** > > So, the first part of the issue seems to be one of =93what URI do I use a= nd > why?=94 The answer really is =93whatever URI you have=94.**** > > ** ** > > The second paragraph goes into one area where I understand why one might > be confused. In the example, the client queried the acct URI and just > fabricated that by taking the email address (of the form user@domain) and > turning that into an account URI. That said, I don=92t know I would call > that a semantic gap. Humans do this. If you see user@domain, you assume > it=92s an email address. Likewise, Microsoft Word will do the same. For= WF, > there is the suggestion that it=92s safe to assume it can be converted to > acct:user@domain. That might be a faulty assumption, but so might > assuming that user@domain is an email address if there is no URI scheme. > Even if there were, the intent of the acct URI is to represent user > accounts and the expectation is that the form would =93look like=94 email > addresses. So, what can we add to the document to make this clearer? > There are heuristics, but heuristics tend to associate user@host with mailto. I think it valid to ask the question "how would a machine make this determination?" Ideally you may need a preflight lookup service that will tell a machine which identifier to use. And this relation would also be confirmed when you got back the JRD record. Or you need an out of band (ie in the spec) translation service that can be coded into a client. From the perspective of a machine, another possibility is to have it cached. I'm not a huge fan of the acct: URI scheme. It seems to me that /.well-known/acct/bob Would work just as well. Now consider a hypothetical scenario that we had these two "synonyms" for a "user account". How can a machine know what to translate a mailto: address into. I would prefer to use mailto URIs instead as an 'indirect identifier', and not need acct: at all. I know some say this is problematic because semantically an email address does not have a name or avatar etc. However, you can also make the argument, that an account is not a user, either. My bank account has a name, but it is not *my* name, yet I own my bank account. In truth the distinction between user vs agent vs account vs email vs representation tends to be something of a grey area. It amount to striking the balance between semantic rectitude, interoperability and ease of use. Just my 2 cents... > ** > > ** ** > > The third paragraph goes into use of different URI schemes and the > expected results returned. WebFinger should not prescribing exactly what > gets returned for any particular URI. The intent of the WF spec is to > define the tool used to perform a query and the syntax of the query and > response. However, how one actually get configuration information or wha= t > information should be returned for a given URI should be defined elsewher= e, > IMO. We expect that account-related information about a user will be > returned if one queries with an acct URI. We do not want to define what = is > returned for mailto: or xmpp: or other. We might use it for > configuration or we may never use those with WebFinger. I would say that > should be the scope of another spec.**** > > ** ** > > The example in 3.4 is intended to be mysterious. It has been a struggle > to provide examples, as some do not like abstract examples and some do no= t > like concrete examples. This is one of the more abstract examples; the > device URI scheme does not even exist. The intent of the example is just = to > show that WF can be used for a range of things, but the syntax is > consistent. Why a particular URI scheme is used and exactly what links, > properties, etc. will be returned should be defined elsewhere.**** > > ** ** > > The last paragraph asks why the resource part is a URI at all. That was > debated at length a few years ago when the acct URI scheme was discussed. > Blaine Cook was one in favor of using no scheme at all. However, there > was a desire to be able to issue a WF query for different URIs, because > different URIs might return different responses. I appreciate the > immediate question is =93what would be different=94, but I don=92t think = it=92s the > WF spec that should dictate what gets returned for any particular URI. T= he > OpenID specs Mike referenced is a good example that prescribes what to > expect using a given URI scheme. The OpenID Connect spec can utilize > either the acct URI or an http URI.**** > > ** ** > > What words can we introduce that will help to resolve this issue?**** > > ** ** > > Paul**** > > ** ** > > *From:* Melvin Carvalho [mailto:melvincarvalho@gmail.com] > *Sent:* Thursday, May 30, 2013 4:27 AM > *To:* Paul E. Jones > *Cc:* draft-ietf-appsawg-webfinger@tools.ietf.org; salvatore loreto; > webfinger > *Subject:* Re: [webfinger] [appsawg] #12: Semantic gap for the client sid= e > **** > > ** ** > > ** ** > > ** ** > > On 30 May 2013 04:12, Paul E. Jones wrote:**** > > Folks, > > Sal noted that we have several DISCUSS points to cover. He referred us t= o > this page: > http://tools.ietf.org/wg/appsawg/trac/report/1 > > Let's take this first item. I'll start with #12 here. > > The idea with Host-Meta and, hence, WebFinger, is that a client that want= s > to know anything about a given URI, it takes the URI and issues a query a= s > per RFC 6415 or per the WebFinger spec. The intent was to allow any URI, > though if one is looking for information about a user's account, the > recommendation is to use the 'acct' URI, since it is intended to represen= t > an account owned by a user, versus other URIs like mailto or http. > > There may be multiple versions of the story that led us here, but the > problem some were trying to address was the use of http URIs for OpenID. > It was hard for users to use. Users are accustomed to user@domain form > of addresses, but then there was the question of what URI to use for thos= e. > The mailto URI could work, but it was not appropriate if one were queryi= ng > for a user on Twitter, for example. That and other reasons led to the > creation of the 'acct' URI scheme. And, so we recommend the use of that > URI scheme in Section 4.5 of the draft. However, a client most certainly > could query for information about a user using any type of URI. For > example, this is valid: > $ curl > https://packetizer.com/.well-known/webfinger?resource=3Dhttps%3A%2F%2Fwww= .packetizer.com > > The expected result is JRD that describes the queried resource. The most > useful resource probably is the 'acct' URI today. The acct URI would > return a JRD that describes the account. > > So, what is the semantic gap, exactly? What text can we add to make this > clearer without confining WF to being useful only for 'acct' URIs?**** > > ** ** > > The full text may help here: > > [[ > There appears to be a big giant semantic gap for the client side of this > protocol. I can find nothing in the document that indicates to the client > how it shall determine what sort of URI to use is the resource part of > the query or what the semantics of any given URI are supposed to be. I > suspect that the semantics are so underspecified that there could not > possibly be interoperable implementations without lots of out-of-band > information. > > The first example provides a mapping from an email address (or perhaps a > mailto URI; that's not clear) to an acct URI, but neither the example nor > anything in the rest of the document gives any clue why you would choose > to query an "acct" URI based on the contents of an email message. I think > the assumption is that if there is an email address, there must be some > sort of "account" associated with it, and therefore querying the host on > the RHS of the "@" for that account will get some interesting > information. But I don't see any reason to choose an "acct" scheme over > "mailto" or "smtp" or "email" or "foobar"; as far as I can tell, the > choice is semantics-free. > > Reading the above alongside 3.3 makes me all the more suspicious: In 3.3 > (also mentioned in 4.5), a "mailto" URI gets you configuration > information for all email configuration parameters. Does an "acct" URI > get you configuration information for email *and* xmpp *and* sip *and* > calendaring *and* all other configuration information (since you are no > longer asking for a particular protocol, but rather the general account > information), or do you only get "information" about the person and not > their account? (I might also insert privacy and security worries here, > but see Stephen's DISCUSS regarding that.) How can the client know what > sort of information it can ask for and how to get it? And for that > matter, how does the server tell what information to pass back? You'd > think there would be a hint about this in 4.3, but "rel" only seems to > provide for the client to request those things that the client already > knows about it. In particular, there appears to be no way to say, "Give > me user provided information, but not config information" or "Give me > config information, but not blog entries". > > I find the semantics for "device" in 3.4 all-the-more mysterious. As far > as I can tell, this URI scheme simply means, "Give me all of the > information for the entire host." > > Again, the semantics of all of these interactions seem so underspecified > that I don't understand how interoperation is supposed to happen. > > This also leaves me with the question about why the resource query part > is a URI at all. It seems to me that the resource you are asking about is > not a URI (or URN) at all; it's simply an identifier for an entity that > the particular host knows about. Given that, why not pass a simple > identifier? (See http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ > for example.) If the scheme is not providing any particular semantics > about the response, I see no reason to provide the scheme. If more > semantics (beyond rel) are needed, another parameter indicating the type > of identifier being used seems much more appropriate than using a URI > scheme. > ]]**** > > **** > > > Paul > > > -----Original Message----- > > From: appsawg issue tracker [mailto:trac+appsawg@grenache.tools.ietf.or= g > ] > > Sent: Wednesday, May 29, 2013 3:21 AM > > To: draft-ietf-appsawg-webfinger@tools.ietf.org; > > salvatore.loreto@ericsson.com > > Cc: appsawg@ietf.org > > Subject: [appsawg] #12: Semantic gap for the client side > > > > #12: Semantic gap for the client side > > > > the document should clarify how the client will be able to determine > > what > > sort of URI to use is the resource part of the query or > > what the semantics of any given URI are supposed to be. > > > > (This a Discuss, present in the IESG Evaluation Record) > > > > -- > > > -------------------------------------+-----------------------------------= - > > - > > Reporter: | Owner: draft-ietf-appsawg- > > salvatore.loreto@ericsson.com | webfinger@tools.ietf.org > > Type: defect | Status: new > > Priority: blocker | Milestone: > > Component: webfinger | Version: > > Severity: - | Keywords: > > > -------------------------------------+-----------------------------------= - > > - > > > > Ticket URL: > > appsawg > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger**** > > ** ** > --001a11c3683a766b2b04de18b589 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On 31 May 2013 02:08, Paul E. Jones <paulej@packetizer.com> wrote:

Melvin,

=A0<= /p>

Thanks for bringing th= at text forward.

=A0<= /p>

All,

=A0<= /p>

So, the first part of = the issue seems to be one of =93what URI do I use and why?=94=A0 The answer= really is =93whatever URI you have=94.

=A0<= /p>

The second paragraph g= oes into one area where I understand why one might be confused.=A0 In the e= xample, the client queried the acct URI and just fabricated that by taking = the email address (of the form user@domain) and turning that into an accoun= t URI.=A0 That said, I don=92t know I would call that a semantic gap.=A0 Hu= mans do this.=A0 If you see user@domain, you assume it=92s an email address= .=A0 Likewise, Microsoft Word will do the same.=A0 For WF, there is the sug= gestion that it=92s safe to assume it can be converted to acct:user@domain.= =A0 That might be a faulty assumption, but so might assuming that user@doma= in is an email address if there is no URI scheme. =A0Even if there were, th= e intent of the acct URI is to represent user accounts and the expectation = is that the form would =93look like=94 email addresses.=A0 So, what can we = add to the document to make this clearer?


There are heuristics, but heur= istics tend to associate user@host with mailto.=A0 I think it valid to ask = the question "how would a machine make this determination?"

Ideally you may need a preflight lookup service that will tell a machin= e which identifier to use.=A0 And this relation would also be confirmed whe= n you got back the JRD record.=A0 Or you need an out of band (ie in the spe= c) translation service that can be coded into a client.=A0 From the perspec= tive of a machine, another possibility is to have it cached.

I'm not a huge fan of the acct: URI scheme.=A0 It seems = to me that

/.well-known/acct/bob

Would= work just as well. Now consider a hypothetical scenario that we had these = two "synonyms" for a "user account".=A0 How can a machi= ne know what to translate a mailto: address into.

I would prefer to use mailto URIs instead as an 'indirec= t identifier', and not need acct: at all.=A0 I know some say this is pr= oblematic because semantically an email address does not have a name or ava= tar etc.=A0 However, you can also make the argument, that an account is not= a user, either.=A0 My bank account has a name, but it is not *my* name, ye= t I own my bank account.=A0 In truth the distinction between user vs agent = vs account vs email vs representation tends to be something of a grey area.= =A0 It amount to striking the balance between semantic rectitude, interoper= ability and ease of use.

Just my 2 cents...
=A0

=A0

The third paragraph goes = into use of different URI schemes and the expected results returned.=A0 Web= Finger should not prescribing exactly what gets returned for any particular= URI.=A0 The intent of the WF spec is to define the tool used to perform a = query and the syntax of the query and response.=A0 However, how one actuall= y get configuration information or what information should be returned for = a given URI should be defined elsewhere, IMO.=A0 We expect that account-rel= ated information about a user will be returned if one queries with an acct = URI.=A0 We do not want to define what is returned for mailto: or xmpp: or o= ther.=A0 We might use it for configuration or we may never use those with W= ebFinger.=A0 I would say that should be the scope of another spec.

=A0<= /p>

The example in 3.4 is = intended to be mysterious.=A0 It has been a struggle to provide examples, a= s some do not like abstract examples and some do not like concrete examples= .=A0 This is one of the more abstract examples; the device URI scheme does = not even exist. The intent of the example is just to show that WF can be us= ed for a range of things, but the syntax is consistent.=A0 Why a particular= URI scheme is used and exactly what links, properties, etc. will be return= ed should be defined elsewhere.

=A0<= /p>

The last paragraph ask= s why the resource part is a URI at all.=A0 That was debated at length a fe= w years ago when the acct URI scheme was discussed. =A0Blaine Cook was one = in favor of using no scheme at all.=A0 However, there was a desire to be ab= le to issue a WF query for different URIs, because different URIs might ret= urn different responses.=A0 I appreciate the immediate question is =93what = would be different=94, but I don=92t think it=92s the WF spec that should d= ictate what gets returned for any particular URI.=A0 The OpenID specs Mike = referenced is a good example that prescribes what to expect using a given U= RI scheme.=A0 The OpenID Connect spec can utilize either the acct URI or an= http URI.

=A0<= /p>

What words can we intr= oduce that will help to resolve this issue?

=A0<= /p>

Paul

=A0<= /p>

From: Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: Thursday, May 30, 2013 4:27 AM
To: Paul E. Jones
= Cc: draft-ietf-appsawg-webfinger@tools.ietf.org; salvatore= loreto; webfinger
Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client = side

=A0

=A0<= /u>

=A0

On 30 May 2013 04:12, Paul E. Jones <paulej@packetizer.= com> wrote:

Folks,

Sal noted that we have several DISCUSS= points to cover. =A0He referred us to this page:
http://tools.ietf.or= g/wg/appsawg/trac/report/1

Let's take this first item. =A0I'll start with #12 here.
The idea with Host-Meta and, hence, WebFinger, is that a client that wants= to know anything about a given URI, it takes the URI and issues a query as= per RFC 6415 or per the WebFinger spec. =A0The intent was to allow any URI= , though if one is looking for information about a user's account, the = recommendation is to use the 'acct' URI, since it is intended to re= present an account owned by a user, versus other URIs like mailto or http.<= br>
There may be multiple versions of the story that led us here, but the p= roblem some were trying to address was the use of http URIs for OpenID. =A0= It was hard for users to use. =A0Users are accustomed to user@domain form o= f addresses, but then there was the question of what URI to use for those. = =A0The mailto URI could work, but it was not appropriate if one were queryi= ng for a user on Twitter, for example. =A0That and other reasons led to the= creation of the 'acct' URI scheme. =A0And, so we recommend the use= of that URI scheme in Section 4.5 of the draft. =A0However, a client most = certainly could query for information about a user using any type of URI. = =A0For example, this is valid:
$ curl https://packetizer.com/.= well-known/webfinger?resource=3Dhttps%3A%2F%2Fwww.packetizer.com
The expected result is JRD that describes the queried resource. =A0The mos= t useful resource probably is the 'acct' URI today. =A0The acct URI= would return a JRD that describes the account.

So, what is the semantic gap, exactly? =A0What text can we add to make = this clearer without confining WF to being useful only for 'acct' U= RIs?

=A0

The full text may help here:

[[
There= appears to be a big giant semantic gap for the client side of this
prot= ocol. I can find nothing in the document that indicates to the client
how it shall determine what sort of URI to use is the resource part of
t= he query or what the semantics of any given URI are supposed to be. I
su= spect that the semantics are so underspecified that there could not
possibly be interoperable implementations without lots of out-of-band
in= formation.

The first example provides a mapping from an email addres= s (or perhaps a
mailto URI; that's not clear) to an acct URI, but ne= ither the example nor
anything in the rest of the document gives any clue why you would chooseto query an "acct" URI based on the contents of an email message= . I think
the assumption is that if there is an email address, there mus= t be some
sort of "account" associated with it, and therefore querying the = host on
the RHS of the "@" for that account will get some inte= resting
information. But I don't see any reason to choose an "a= cct" scheme over
"mailto" or "smtp" or "email" or "foobar= "; as far as I can tell, the
choice is semantics-free.

Readi= ng the above alongside 3.3 makes me all the more suspicious: In 3.3
(also mentioned in 4.5), a "mailto" URI gets you configurationinformation for all email configuration parameters. Does an "acct&quo= t; URI
get you configuration information for email *and* xmpp *and* sip = *and*
calendaring *and* all other configuration information (since you are no
= longer asking for a particular protocol, but rather the general account
= information), or do you only get "information" about the person a= nd not
their account? (I might also insert privacy and security worries here,
b= ut see Stephen's DISCUSS regarding that.) How can the client know what<= br>sort of information it can ask for and how to get it? And for that
matter, how does the server tell what information to pass back? You'dthink there would be a hint about this in 4.3, but "rel" only s= eems to
provide for the client to request those things that the client a= lready
knows about it. In particular, there appears to be no way to say, "Giv= e
me user provided information, but not config information" or &quo= t;Give me
config information, but not blog entries".

I find = the semantics for "device" in 3.4 all-the-more mysterious. As far=
as I can tell, this URI scheme simply means, "Give me all of the
in= formation for the entire host."

Again, the semantics of all of = these interactions seem so underspecified
that I don't understand ho= w interoperation is supposed to happen.

This also leaves me with the question about why the resource query part=
is a URI at all. It seems to me that the resource you are asking about = is
not a URI (or URN) at all; it's simply an identifier for an entit= y that
the particular host knows about. Given that, why not pass a simple
ident= ifier? (See http://datatracker.ietf.org/doc/draft-ietf-radext-nai= /
for example.) If the scheme is not providing any particular semantics
ab= out the response, I see no reason to provide the scheme. If more
semanti= cs (beyond rel) are needed, another parameter indicating the type
of ide= ntifier being used seems much more appropriate than using a URI
scheme.
]]

=A0=


Paul

> -----Original Message-----
> From: appsawg issue= tracker [mailto:trac+appsawg@grenache.tools.ietf.org]
> Sent: W= ednesday, May 29, 2013 3:21 AM
> To: draft-ietf-appsawg-webfinger@tools.ietf.org;
> salvatore.l= oreto@ericsson.com
> Cc: appsawg@ietf= .org
> Subject: [appsawg] #12: Semantic gap for the client side>
> #12: Semantic gap for the client side
>
> =A0the= document should clarify how =A0the client will be able to determine
> what
> =A0sort of URI to use is the resource part of the query o= r
> =A0what the semantics of any given URI are supposed to be.
>= ;
> =A0(This a Discuss, present in the IESG Evaluation Record)
>= ;
> --
> -------------------------------------+---------------------= ---------------
> -
> =A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Owner: =A0draft-ietf-appsawg-
> = =A0 salv= atore.loreto@ericsson.com =A0 =A0 =A0| =A0webfinger@tools.ietf.org
> =A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 = =A0 Status: =A0new
> =A0Priority: =A0blocker =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0Milestone:
> Component: =A0webfinger =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0| =A0 =A0Version:
> =A0Severity: =A0- =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Keywords:
> -------------------------------------+--------------------------------= ----
> -
>
> Ticket URL: <http://tools.ietf.org/wg/= appsawg/trac/ticket/12>
> appsawg <http://tools.ietf.org/appsawg/>


______________________= _________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

=A0


--001a11c3683a766b2b04de18b589-- From paulej@packetizer.com Mon Jun 3 18:18:26 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A000821F91BF for ; Mon, 3 Jun 2013 18:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3ahRO3-vvS9 for ; Mon, 3 Jun 2013 18:18:12 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D374D21F947C for ; Mon, 3 Jun 2013 17:34:28 -0700 (PDT) Received: from email.packetizer.com (dublin.packetizer.com [75.101.130.125]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r540YONC004620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Jun 2013 20:34:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1370306065; bh=OY7OYopgAgqqHKIdRR44rKM2HgIACiT/6ep0+zEIh8c=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Date:From:To: Cc:Subject:In-Reply-To:References:Message-ID; b=GT5xVQEsvMs+Mdzx1ArhpUCQTiyXiPdd3omiBXB+o+XacPgT23jANfcL9rlN1OSA0 wqi2jgkCwFErND9NGdtIC14qg9LS5mOS2hgu8Z/BrPdddRYZxlO5ZDq6jr/4SanmEZ jjksORFNK/WEsfcU2rI+Z72Yo1L08O8st8BGvcXU= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 03 Jun 2013 20:34:24 -0400 From: "Paul E. Jones" To: Melvin Carvalho In-Reply-To: References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> Message-ID: <36096ecb650426e9c92b17ab773fa138@packetizer.com> X-Sender: paulej@packetizer.com User-Agent: Roundcube Webmail/0.5.3 Cc: salvatore loreto , webfinger , draft-ietf-appsawg-webfinger@tools.ietf.org Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 01:18:26 -0000 On Sat, 1 Jun 2013 16:40:11 +0200, Melvin Carvalho wrote: > On 31 May 2013 02:08, Paul E. Jones wrote: [snip] >> scheme. Even if there were, the intent of the acct URI is to >> represent user accounts and the expectation is that the form would >> "look like" email addresses. So, what can we add to the >> document to make this clearer? > > There are heuristics, but heuristics tend to associate user@host with > mailto. I think it valid to ask the question "how would a machine > make this determination?" Would not not be valid to simply take the email address on the From line and attach acct: to the front of it? In practice, I would expect that is what people will do. That's what I've seen already in practice, so I feel fairly confident in saying that. Granted, it will not always work. There may not be an "account" associated with the email address. And some email addresses might be unusual. (Any uucp still in use today?) But, a quick inspection to see if it looks like the usual user@domain is fairly common. > Ideally you may need a preflight lookup service that will tell a > machine which identifier to use. And this relation would also be > confirmed when you got back the JRD record. Or you need an out of > band (ie in the spec) translation service that can be coded into a > client. From the perspective of a machine, another possibility is to > have it cached. I would think that is only true if one wants to map the email address to some other identifier that is very different (e.g., mapping paulej@packetizer.com to user22@example.com). > Im not a huge fan of the acct: URI scheme. It seems to me that > > /.well-known/acct/bob > > Would work just as well. Now consider a hypothetical scenario that we > had these two "synonyms" for a "user account". How can a machine > know what to translate a mailto: address into. Do note that the example we're discussing is an email message. It does not contain a "mailto:" URI. Rather, it contains an email address, usually of the form user@domain. (Also, it is just an example, not something intended to be normative.) Using the above well-known URI would certainly work vs. the WebFinger URI. But then any well-known URI could work. The reason for using WebFinger is because this is the WebFinger service and we want to have the ability to give it any URI and the server return a JRD for that URI. > I would prefer to use mailto URIs instead as an indirect identifier, > and not need acct: at all. I know some say this is problematic > because semantically an email address does not have a name or avatar > etc. However, you can also make the argument, that an account is not > a user, either. My bank account has a name, but it is not *my* name, > yet I own my bank account. In truth the distinction between user vs > agent vs account vs email vs representation tends to be something of > a > grey area. It amount to striking the balance between semantic > rectitude, interoperability and ease of use. In truth, one could use any kind of identifier. One reason (and perhaps not the only reason) for not using a mailto URI is that it is not appropriate for some services. I mentioned this before, but it's worth saying again: Twitter user accounts do not have email addresses associated with them. The same used to be true of Facebook, but no longer. There was a desire to have some kind of account identifier that identifies an account at a service. Other kinds of services include photo sharing web sites or even identity management sites. I have an account at Amazon and many other places where I do not have email service. The "acct" URI can be used to identify the account. In the case of your bank account, perhaps your account might be acct:@. (I doubt a bank would ever implement WF for customer accounts, and surely would not advise it. Nonetheless, that's the form of the identifier I would expect to be used against a WF service at the bank. So, where does this leave us? We should either decide to make some small changes to the example to get rid of the discussion point about the email address and the leap to the acct URI, or remove the example entirely. I rather like having the example, as it helps illustrate the utility of WF. But, we can remove it or change it. I don't want to go back and rehash the necessity of the acct URI scheme. Paul From melvincarvalho@gmail.com Wed Jun 5 10:13:58 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5445421F9C53 for ; Wed, 5 Jun 2013 10:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5xsKF2FUrmK for ; Wed, 5 Jun 2013 10:13:56 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 59B9921F9C2D for ; Wed, 5 Jun 2013 10:13:56 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id eb20so1690114lab.29 for ; Wed, 05 Jun 2013 10:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T9H7mL7MyA15oCfINdyBkkRJPihITTFdkZsVuz8ye3Y=; b=Q6eyTqhhii+5DhsC1iw7bB/e7XTGmbpbKdzlswHgod2d3ZFvSXwd1pfknCmLX1nGv6 ZoSKzBY/r8Mp6IbJKyMfKAx8R6qhGzcDcKQsYz1bgEI4BPg4tN722gYZNZ6oIwg86ymy Zdf+GR5skTWuYBPLGWwfDugNnyXpQW8cnr/rfqArT5JdHEb70paCEB04B3Qmj8IMI61b FRyUBbCJLtCpWIqvdZFO8G02v1uaDrQI+qeF0cd0xSvGhjC/oRqXuoFtExEPpd4DmiiC oezQ7NkKaARIt+G1gOngcqtSrqqK2c1xw+KK2vcowV8a7IHKUj819iqRd4x5VMc8c7tU 9EBA== MIME-Version: 1.0 X-Received: by 10.112.131.129 with SMTP id om1mr15006604lbb.45.1370452435195; Wed, 05 Jun 2013 10:13:55 -0700 (PDT) Received: by 10.112.2.8 with HTTP; Wed, 5 Jun 2013 10:13:55 -0700 (PDT) In-Reply-To: <36096ecb650426e9c92b17ab773fa138@packetizer.com> References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <36096ecb650426e9c92b17ab773fa138@packetizer.com> Date: Wed, 5 Jun 2013 19:13:55 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=047d7b33da6e94dc8104de6b5203 Cc: salvatore loreto , webfinger , draft-ietf-appsawg-webfinger@tools.ietf.org Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 17:13:58 -0000 --047d7b33da6e94dc8104de6b5203 Content-Type: text/plain; charset=ISO-8859-1 On 4 June 2013 02:34, Paul E. Jones wrote: > On Sat, 1 Jun 2013 16:40:11 +0200, Melvin Carvalho wrote: > >> On 31 May 2013 02:08, Paul E. Jones wrote: >> > [snip] > > scheme. Even if there were, the intent of the acct URI is to >>> represent user accounts and the expectation is that the form would >>> "look like" email addresses. So, what can we add to the >>> document to make this clearer? >>> >> >> There are heuristics, but heuristics tend to associate user@host with >> mailto. I think it valid to ask the question "how would a machine >> make this determination?" >> > > Would not not be valid to simply take the email address on the From line > and attach acct: to the front of it? In practice, I would expect that is > what people will do. That's what I've seen already in practice, so I feel > fairly confident in saying that. > > Granted, it will not always work. There may not be an "account" > associated with the email address. And some email addresses might be > unusual. (Any uucp still in use today?) But, a quick inspection to see if > it looks like the usual user@domain is fairly common. > > > Ideally you may need a preflight lookup service that will tell a >> machine which identifier to use. And this relation would also be >> confirmed when you got back the JRD record. Or you need an out of >> band (ie in the spec) translation service that can be coded into a >> client. From the perspective of a machine, another possibility is to >> have it cached. >> > > I would think that is only true if one wants to map the email address to > some other identifier that is very different (e.g., mapping > paulej@packetizer.com to user22@example.com). > > > Im not a huge fan of the acct: URI scheme. It seems to me that >> >> /.well-known/acct/bob >> >> Would work just as well. Now consider a hypothetical scenario that we >> had these two "synonyms" for a "user account". How can a machine >> know what to translate a mailto: address into. >> > > Do note that the example we're discussing is an email message. It does > not contain a "mailto:" URI. Rather, it contains an email address, > usually of the form user@domain. (Also, it is just an example, not > something intended to be normative.) > > Using the above well-known URI would certainly work vs. the WebFinger URI. > But then any well-known URI could work. > > The reason for using WebFinger is because this is the WebFinger service > and we want to have the ability to give it any URI and the server return a > JRD for that URI. > > I would prefer to use mailto URIs instead as an indirect identifier, >> >> and not need acct: at all. I know some say this is problematic >> because semantically an email address does not have a name or avatar >> etc. However, you can also make the argument, that an account is not >> a user, either. My bank account has a name, but it is not *my* name, >> yet I own my bank account. In truth the distinction between user vs >> agent vs account vs email vs representation tends to be something of a >> grey area. It amount to striking the balance between semantic >> rectitude, interoperability and ease of use. >> > > In truth, one could use any kind of identifier. One reason (and perhaps > not the only reason) for not using a mailto URI is that it is not > appropriate for some services. I mentioned this before, but it's worth > saying again: Twitter user accounts do not have email addresses associated > with them. The same used to be true of Facebook, but no longer. There was > a desire to have some kind of account identifier that identifies an account > at a service. Other kinds of services include photo sharing web sites or > even identity management sites. I have an account at Amazon and many other > places where I do not have email service. The "acct" URI can be used to > identify the account. In the case of your bank account, perhaps your > account might be acct:@. (I doubt a bank would ever > implement WF for customer accounts, and surely would not advise it. > Nonetheless, that's the form of the identifier I would expect to be used > against a WF service at the bank. > > So, where does this leave us? We should either decide to make some small > changes to the example to get rid of the discussion point about the email > address and the leap to the acct URI, or remove the example entirely. I > rather like having the example, as it helps illustrate the utility of WF. > But, we can remove it or change it. I don't want to go back and rehash > the necessity of the acct URI scheme. > Given that the original motivation for Web Finger was the email use case (in fact in it's first drafts it was the ONLY use case), IMHO, keeping that example would be important. I'm unsure how to word it, but it seems to me that user@host is most naturally translated to mailto:user@host as a URI. Now this will either be the primary key of the data structure (subject) or the foreign key to the data structure (object). The webfinger query is asking something like either 1) give me all key / values pairs where mailto:user@host is the subject OR 2) give me all "sibling" key value pairs where mailto:user@hostis the email value, in which case the subject could be anything including an acct: URI. > > Paul > > > > --047d7b33da6e94dc8104de6b5203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 4 June 2013 02:34, Paul E. Jones <paulej@packetizer.com> wrote:
On Sat, 1 Jun 2013 16:40:11 +0200, Melvin Ca= rvalho wrote:
On 31 May 2013 02:08, Paul E. Jones wrote:
[snip]

scheme. Even if there were, the intent of the acct URI is to
represent user accounts and the expectation is that the form would
"look like" email addresses. So, what can we add to the
document to make this clearer?

There are heuristics, but heuristics tend to associate user@host with
mailto. I think it valid to ask the question "how would a machine
make this determination?"

Would not not be valid to simply take the email address on the From line an= d attach acct: to the front of it? =A0In practice, I would expect that is w= hat people will do. =A0That's what I've seen already in practice, s= o I feel fairly confident in saying that.

Granted, it will not always work. =A0There may not be an "account"= ; associated with the email address. =A0And some email addresses might be u= nusual. =A0(Any uucp still in use today?) =A0But, a quick inspection to see= if it looks like the usual user@domain is fairly common.


Ideally you may need a preflight lookup service that will tell a
machine which identifier to use. And this relation would also be
confirmed when you got back the JRD record. Or you need an out of
band (ie in the spec) translation service that can be coded into a
client. From the perspective of a machine, another possibility is to
have it cached.

I would think that is only true if one wants to map the email address to so= me other identifier that is very different (e.g., mapping paulej@packetizer.com to user22@example.com)= .


Im not a huge fan of the acct: URI scheme. It seems to me that

/.well-known/acct/bob

Would work just as well. Now consider a hypothetical scenario that we
had these two "synonyms" for a "user account". How can = a machine
know what to translate a mailto: address into.

Do note that the example we're discussing is an email message. =A0It do= es not contain a "mailto:" URI. =A0Rather, it contains an email a= ddress, usually of the form user@domain. =A0(Also, it is just an example, n= ot something intended to be normative.)

Using the above well-known URI would certainly work vs. the WebFinger URI. = =A0But then any well-known URI could work.

The reason for using WebFinger is because this is the WebFinger service and= we want to have the ability to give it any URI and the server return a JRD= for that URI.

I would prefer to use mailto URIs instead as an indirect identifier,

and not need acct: at all. I know some say this is problematic
because semantically an email address does not have a name or avatar
etc. However, you can also make the argument, that an account is not
a user, either. My bank account has a name, but it is not *my* name,
yet I own my bank account. In truth the distinction between user vs
agent vs account vs email vs representation tends to be something of a
grey area. It amount to striking the balance between semantic
rectitude, interoperability and ease of use.

In truth, one could use any kind of identifier. =A0One reason (and perhaps = not the only reason) for not using a mailto URI is that it is not appropria= te for some services. =A0I mentioned this before, but it's worth saying= again: Twitter user accounts do not have email addresses associated with t= hem. =A0The same used to be true of Facebook, but no longer. =A0There was a= desire to have some kind of account identifier that identifies an account = at a service. =A0Other kinds of services include photo sharing web sites or= even identity management sites. =A0I have an account at Amazon and many ot= her places where I do not have email service. =A0The "acct" URI c= an be used to identify the account. =A0In the case of your bank account, pe= rhaps your account might be acct:<acct#>@<bankname.com>. =A0(I doubt a bank would ev= er implement WF for customer accounts, and surely would not advise it. =A0N= onetheless, that's the form of the identifier I would expect to be used= against a WF service at the bank.

So, where does this leave us? =A0We should either decide to make some small= changes to the example to get rid of the discussion point about the email = address and the leap to the acct URI, or remove the example entirely. =A0I = rather like having the example, as it helps illustrate the utility of WF. = =A0But, we can remove it or change it. =A0I don't want to go back and r= ehash the necessity of the acct URI scheme.

Given that the original moti= vation for Web Finger was the email use case (in fact in it's first dra= fts it was the ONLY use case), IMHO, keeping that example would be importan= t.

I'm unsure how to word it, but it seems to me that user@= host is most naturally translated to mailto:us= er@host as a URI.=A0 Now this will either be the primary key of the dat= a structure (subject) or the foreign key to the data structure (object).=A0= The webfinger query is asking something like either 1) give me all key / v= alues pairs where mailto:user@host is the = subject OR 2) give me all "sibling" key value pairs where mailto:= user@host is the email value, in which cas= e the subject could be anything including an acct: URI.
=A0
<= font color=3D"#888888">
Paul




--047d7b33da6e94dc8104de6b5203-- From stpeter@stpeter.im Wed Jun 5 15:20:34 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE17E21F8AD5 for ; Wed, 5 Jun 2013 15:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yrw4Ve2yOJLr for ; Wed, 5 Jun 2013 15:20:02 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9C93121F85C9 for ; Wed, 5 Jun 2013 15:20:01 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.59]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E25FC4126A; Wed, 5 Jun 2013 16:33:12 -0600 (MDT) Message-ID: <51AFB98E.8080701@stpeter.im> Date: Wed, 05 Jun 2013 16:19:58 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Paul E. Jones" References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> <017c01ce5a67$4ceb6670$e6c23350$@packetizer.com> <51A2BFF3.2000208@stpeter.im> <804F2B2A-D2C5-4ADB-BFD3-4F10C0BA6587@ve7jtb.com> <4400A888-77BD-415D-96FB-7B59E1ED9598@ve7jtb.com> <02a701ce5aef$7e6c8d90$7b45a8b0$@packetizer.com> <70E4B79D-F5D5-4CB2-9AE8-58B223178A2E@ve7jtb.com> <047101ce5bc2$566621c0$03326540$@packetizer.com> <51A6375A.9000305@stpeter.im> <01c301ce5ca2$b4f27910$1ed76b30$@packetizer.com> <51A67E6C.3040404@stpeter.im> <023c01ce5cc5$d8e0d8d0$8aa28a70$@packetizer.com> In-Reply-To: <023c01ce5cc5$d8e0d8d0$8aa28a70$@packetizer.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Richard Barnes' , 'John Bradley' , 'Mike Jones' , 'Melvin Carvalho' , 'John Bradley' , 'webfinger' Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 22:20:34 -0000 On 5/29/13 5:40 PM, Paul E. Jones wrote: > Peter, > >> I *think* there's still an open issue of how to handle localparts that >> are of the form user@host (e.g., services that use an email address for >> registration). So if I register with foo.com with my peter@example.com >> address and foo.com thinks peter@example.com is the localpart of my acct >> URI, do we perform the hex-encoding of the '@' character to come up with >> "acct:peter%40example.com@foo.com"? At the leads, do we make any sort of >> recommendation about this in the WF spec or do we leave it totally up to >> implementations? And does it warrant a sentence in the acct-uri spec? > > If you register with foo.com using your email address, that does not > automatically mean foo.com is going to use that identifier in any way for > WebFinger. If I have a blog where you register with peter@example.com, my > server might issue a WF query to example.com to get your picture, name, or > other information for display on the blog when you post comments, for > example. > > So, I suppose the question arises when a user on the Internet wants to query > information about you at your foo.com account. The way it ought to work is > that foo.com assign an account identifier for you. So, you might be > acct:peter@foo.com. Then querying becomes quite natural. Foo.com is not > obliged to even run a WF server, too. > > Now, should foo.com decide it does not want to assign account identifiers > that people can use, yet they still want people to be able to query > information about users at the service, then it gets complicated. I would > not dare suggest to the average user to type in > acct:peter%40example.com@foo.com. Rather, if foo.com wants to provide a WF > service and it uses acct:peter@example.com as the account ID, then some > system that knows and understands that would issue a query to foo.com using > the resource identifier acct:peter@example.com. > > Just to carry this a bit further, just imagine if someone signs up at > bar.com with their foo.com account. Then we could have %-encoded %-encoded > stuff. This gets really messy. If a service wants to allow for use of WF > against the service, they should assign the user an account ID that is > different from whatever account ID that might have used to create the > account. Or, just resign to the fact that the interface will require that > the peer know and understand that the identifiers presented will not > necessarily be foo.com identifiers. There are cases where this might be > valid and useful, but we do not have to describe such uses in the standard. > > At least that's my view. I'd rather not make this complicated and this can > really get messy. You're right. I'm on board with what you say here. So the question is, do we need any text here or just leave this up to service providers and application developers? I tend toward the latter. Peter -- Peter Saint-Andre https://stpeter.im/ From paulej@packetizer.com Wed Jun 5 15:26:17 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5846C21F8EAD for ; Wed, 5 Jun 2013 15:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEx5Xf07n3IL for ; Wed, 5 Jun 2013 15:26:12 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 625FB21E804C for ; Wed, 5 Jun 2013 15:26:08 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r55MPpwt014912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Jun 2013 18:25:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1370471152; bh=zgA3Oy4hDslYcPbO13CAA0Fp0hs9Ixq9D8DRjO+fOUc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Wki0gCDSqRncTKH2K6G83FDikaaOgdCKG/v10lnGj+QoULXxOTelXJEmOom9W+oN5 Q/pQJh+wBNs0kh1tyVc9/4vHXtvWLhPqEb7FXEyL2A6DhHFkiGH18Mve3xw65Bn2Ef FmtWCLPHRHgLf6yf7SYwv3CwzvEEKylxwFxPwd1U= From: "Paul E. Jones" To: "'Peter Saint-Andre'" References: <034a01ce58b8$a094b4d0$e1be1e70$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367793529@TK5EX14MBXC285.redmond.corp.microsoft.com> <017c01ce5a67$4ceb6670$e6c23350$@packetizer.com> <51A2BFF3.2000208@stpeter.im> <804F2B2A-D2C5-4ADB-BFD3-4F10C0BA6587@ve7jtb.com> <4400A888-77BD-415D-96FB-7B59E1ED9598@ve7jtb.com> <02a701ce5aef$7e6c8d90$7b45a8b0$@packetizer.com> <70E4B79D-F5D5-4CB2-9AE8-58B223178A2E@ve7jtb.com> <047101ce5bc2$566621c0$03326540$@packetizer.com> <51A6375A.9000305@stpeter.im> <01c301ce5ca2$b4f27910$1ed76b30$@packetizer.com> <51A67E6C.3040404@stpeter.im> <023c01ce5cc5$d8e0d8d0$8aa28a70$@packetizer.com> <51AFB98E.8080701@stpeter.im> In-Reply-To: <51AFB98E.8080701@stpeter.im> Date: Wed, 5 Jun 2013 18:26:05 -0400 Message-ID: <088701ce623b$ab615bc0$02241340$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIGFCMJveTXWbzKSo6DGHvDY3YlOgJh9aLuAegQv70CYfVhSAIOSle3AsggLckA/gss1wEdCMq5AgcQ+QQBO6irjgI32FX5Ah2F1xcBoNYmlgInRJKbAfT0bQwB4E6lWgI8uwTRAkD/rgkCK+Gw+Zecaifg Content-Language: en-us Cc: 'Richard Barnes' , 'John Bradley' , 'Mike Jones' , 'Melvin Carvalho' , 'John Bradley' , 'webfinger' Subject: Re: [webfinger] FW: Preparing for next revision of the WebFinger spec X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 22:26:17 -0000 Paul, > You're right. I'm on board with what you say here. So the question is, > do we need any text here or just leave this up to service providers and > application developers? I tend toward the latter. That's my preference, too. Otherwise, I feel like we're trying to solve a problem that really wasn't in scope for WF in the first place and, while it might be useful, we need time to see how this might be used in practice. We need to keep the spec simple and let implementers be creative if they want. Paul From presnick@qti.qualcomm.com Thu Jun 13 08:09:40 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2728421F898B for ; Thu, 13 Jun 2013 08:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5swAFirTAJa5 for ; Thu, 13 Jun 2013 08:09:35 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id C469921F8624 for ; Thu, 13 Jun 2013 08:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1371136175; x=1402672175; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=0Y2aOa6w0DtDSPGdD2A2LHRFQiPwoVgvE+jNCSGmtOU=; b=RdGqnJvXknc4d4qD1X6L3fgqTM5aDl+2vsBOm669hQ/79gw9OeUr4SEs ytnoQrO4IrlGguiaW3ijGEngRSo8bRYnUkwuhvm0dAhN48XO4AGd8iRfo PfjHO+GsF5O9yLWOYKn5qmWdJkcuuy3MZqOKsTz0eogye0HODLCt8bdq8 0=; X-IronPort-AV: E=Sophos;i="4.87,859,1363158000"; d="scan'208,217";a="44929063" Received: from unknown (HELO ironmsg01-lv.qualcomm.com) ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 13 Jun 2013 08:09:35 -0700 Received: from nasanexhc06.na.qualcomm.com ([172.30.48.21]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Jun 2013 08:09:34 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc06.na.qualcomm.com (172.30.48.21) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 13 Jun 2013 08:09:34 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 13 Jun 2013 08:09:34 -0700 Message-ID: <51B9E0AC.5070508@qti.qualcomm.com> Date: Thu, 13 Jun 2013 10:09:32 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Paul E. Jones" References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> In-Reply-To: <024301ce5d92$f7d06080$e7712180$@packetizer.com> Content-Type: multipart/alternative; boundary="------------070505090504030609070808" X-Originating-IP: [172.30.48.1] Cc: 'salvatore loreto' , 'webfinger' , draft-ietf-appsawg-webfinger@tools.ietf.org, 'Melvin Carvalho' Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 15:09:40 -0000 --------------070505090504030609070808 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sorry for not hopping into this conversation much earlier. I'll try to be very responsive so we can make some progress on this. On 5/30/13 7:08 PM, Paul E. Jones wrote: > > So, the first part of the issue seems to be one of "what URI do I use > and why?" The answer really is "whatever URI you have". > > The second paragraph goes into one area where I understand why one > might be confused. In the example, the client queried the acct URI > and just fabricated that by taking the email address (of the form > user@domain) and turning that into an account URI. That said, I don't > know I would call that a semantic gap. Humans do this. If you see > user@domain, you assume it's an email address. > OK, so I'm the client. I've got an email address. What URI do I use if I want email configuration parameters? Do I use mailto:? Or smtp:? Or pop:? Does acct: get me email configuration parameters along with personal information about the user? I also think that email address is also a jabber ID (or maybe I'm wondering if it is)? Do I do a second query with jabber:user@domain? Or will acct: get me back jabber account info? My real concern here is that this document gives me no help as to what kind of information I get back from any given URI, and gives me no help in how to choose the right URI scheme to get me back the info I want. The assumption appears to be, "You client get to choose whatever URI scheme you think is interesting, and if I server have information about that URI, I'll tell you what it is. Otherwise, try again." That's not interoperable. I can come up with grand re-designs to address my concerns, but if you've got answers to the above questions, maybe that will help us figure out some easy stuff to add (an IANA registry, a "how to figure out URI semantics" section, etc.) that will make this protocol make sense. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------070505090504030609070808 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sorry for not hopping into this conversation much earlier. I'll try to be very responsive so we can make some progress on this.

On 5/30/13 7:08 PM, Paul E. Jones wrote:

So, the first part of the issue seems to be one of “what URI do I use and why?”  The answer really is “whatever URI you have”.

 

The second paragraph goes into one area where I understand why one might be confused.  In the example, the client queried the acct URI and just fabricated that by taking the email address (of the form user@domain) and turning that into an account URI.  That said, I don’t know I would call that a semantic gap.  Humans do this.  If you see user@domain, you assume it’s an email address.


OK, so I'm the client. I've got an email address. What URI do I use if I want email configuration parameters? Do I use mailto:? Or smtp:? Or pop:? Does acct: get me email configuration parameters along with personal information about the user?

I also think that email address is also a jabber ID (or maybe I'm wondering if it is)? Do I do a second query with jabber:user@domain? Or will acct: get me back jabber account info?

My real concern here is that this document gives me no help as to what kind of information I get back from any given URI, and gives me no help in how to choose the right URI scheme to get me back the info I want. The assumption appears to be, "You client get to choose whatever URI scheme you think is interesting, and if I server have information about that URI, I'll tell you what it is. Otherwise, try again." That's not interoperable.

I can come up with grand re-designs to address my concerns, but if you've got answers to the above questions, maybe that will help us figure out some easy stuff to add (an IANA registry, a "how to figure out URI semantics" section, etc.) that will make this protocol make sense.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------070505090504030609070808-- From paulej@packetizer.com Thu Jun 13 19:04:41 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40DE21F9473 for ; Thu, 13 Jun 2013 19:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zc5TthAXTi71 for ; Thu, 13 Jun 2013 19:04:35 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7908621F9B0C for ; Thu, 13 Jun 2013 19:04:35 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r5E24VT0009060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Jun 2013 22:04:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1371175472; bh=o9/6hDkFUIfSag62V69G/R8bpNbW2ycHwmrWXu3eOt0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=BsJAa3MHy1riKedPnLPLah67DDZ77c6o2qygTiHKZPj6ySUmTcCMSQKFJl35btori 8pIAo45WvUwK8GIwlTDNQXLQEvqPxFoaJIrsGHznFUXGyyhJwybg6lIzlflZCUtYOY nuoe6tdcBMA0ktZREKKBuZ/IR9qW/oKc4u25Jyls= From: "Paul E. Jones" To: "'Pete Resnick'" References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> In-Reply-To: <51B9E0AC.5070508@qti.qualcomm.com> Date: Thu, 13 Jun 2013 22:04:34 -0400 Message-ID: <002a01ce68a3$8501aac0$8f050040$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFNWMcWAQ1n5b22xM4UdUF6Zyw7DQLrgow+AwtEfrIBDFDY6AJtOwD0mesM+mA= Content-Language: en-us Cc: 'salvatore loreto' , 'webfinger' , draft-ietf-appsawg-webfinger@tools.ietf.org, 'Melvin Carvalho' Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 02:04:41 -0000 Pete, On Thu, 13 Jun 2013 10:09:32 -0500, Pete Resnick wrote: > Sorry for not hopping into this conversation much earlier. I'll > try to be very responsive so we can make some progress on this. > > On 5/30/13 7:08 PM, Paul E. Jones wrote: > >> So, the first part of the issue seems to be one of "what URI do I >> use and why?" The answer really is "whatever URI you have". >> >> The second paragraph goes into one area where I understand why one >> might be confused. In the example, the client queried the acct URI >> and just fabricated that by taking the email address (of the form >> user@domain) and turning that into an account URI. That said, I >> don't know I would call that a semantic gap. Humans do this. If you >> see user@domain, you assume it's an email address. > > OK, so I'm the client. I've got an email address. What URI do I use > if I want email configuration parameters? Do I use mailto:? Or smtp:? > Or pop:? Does acct: get me email configuration parameters along with > personal information about the user? You're assuming WF defines how to provision an email client. It doesn't. There is an example in the text, but it is merely an example to illustrate the kinds of things WF can be used. In order for WF to be used in provisioning an email client, the specific procedures would need to be spelled out in a document somewhere. > I also think that email address is also a jabber ID (or maybe I'm > wondering if it is)? Do I do a second query with jabber:user@domain? > Or will acct: get me back jabber account info? Each URI queried might return the same or different information. The specifications that rely on WebFinger would state explicitly what URI to use. As an example, the OpenID Connect specs state that acct:paulej@packetizer.com would be used to issue a WebFinger query. In general, it is expected that if one is looking for account information related to an identifier in user@domain form, then acct: would be used. For example, if you are looking for a picture of me that I publish, a list of mew ATOM feeds, or whatever else I might publish, that would be used. Obviously, this does not necessarily get all information about me, nor might the querying entity even be querying the correct account. But we all have lots of accounts in lots of places. We have picked on Twitter a number of times, because it's an good example of why "acct:" is needed. There are no email addresses there. So, let's say you know my Twitter ID paul_e_jones. You could issue a query to acct:paul_e_jones@twitter.com. At least that's the intent. What might be returned is whatever I publish via my account on the Twitter service. The acct URI is not tied to any particular protocol, but is intended to relate to a user account at the specified domain. But, we do want to allow any URI to be queried. It's even possible to query the URI "http://www.packetizer.com/" via WebFinger. That's a web page, not a person or account. Querying for that will return whatever information the server wants to return. This is what one could do with RFC 6415, so the same functionality is carried forward. > My real concern here is that this document gives me no help as to > what kind of information I get back from any given URI, and gives me > no help in how to choose the right URI scheme to get me back the info > I want. The assumption appears to be, "You client get to choose > whatever URI scheme you think is interesting, and if I server have > information about that URI, I'll tell you what it is. Otherwise, try > again." That's not interoperable. You are entirely right that it does not give guidance, except for "acct". If you are querying for information related to a user's account at some domain, then use "acct". If I want to know information about a particular URI, query for that URI. The problem is not knowing what URI to query, but knowing what set of links will be returned as a result of using a particular URI. That's not defined, because we cannot specify in this spec how to provision an email client or what kind of information one might want returned if querying for a Jabber ID. The expectation is that other documents would define link relations. In fact, we already have a laundry list of those that folks want to define. As those are defined and registered in the existing registry, then the URI to use with WF would also be defined. They might all end up under "acct" as OpenID Connect specifies. However, if the aggsrv group elects to use WebFinger to bootstrap the discovery process, they might specify the use of mailto: to get links to aggsrv documents. > I can come up with grand re-designs to address my concerns, but if > you've got answers to the above questions, maybe that will help us > figure out some easy stuff to add (an IANA registry, a "how to figure > out URI semantics" section, etc.) that will make this protocol make > sense. I'm certainly willing to add more text to help make the point, but I'm not sure what to add where. Basically, use various URIs and the expected set of links relation types (and, thus, links) is intended to be defined in other specifications, not the base WebFinger spec. Paul From bortzmeyer@nic.fr Fri Jun 14 00:00:13 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3CB21F90EF for ; Fri, 14 Jun 2013 00:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYi0Lb2teBUv for ; Fri, 14 Jun 2013 00:00:07 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9C321F99B4 for ; Fri, 14 Jun 2013 00:00:06 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 2312D2801B9; Fri, 14 Jun 2013 08:59:35 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 1D1BD28015D; Fri, 14 Jun 2013 08:59:35 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:113]) by relay2.nic.fr (Postfix) with ESMTP id 1B641B38075; Fri, 14 Jun 2013 08:59:05 +0200 (CEST) Date: Fri, 14 Jun 2013 08:59:04 +0200 From: Stephane Bortzmeyer To: "Paul E. Jones" Message-ID: <20130614065904.GA30932@nic.fr> References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002a01ce68a3$8501aac0$8f050040$@packetizer.com> X-Operating-System: Debian GNU/Linux 7.0 X-Kernel: Linux 3.2.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 'salvatore loreto' , 'webfinger' , 'Pete Resnick' , 'Melvin Carvalho' , draft-ietf-appsawg-webfinger@tools.ietf.org Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 07:00:13 -0000 On Thu, Jun 13, 2013 at 10:04:34PM -0400, Paul E. Jones wrote a message of 110 lines which said: > You're assuming WF defines how to provision an email client. It > doesn't. There is an example in the text, but it is merely an > example And a bad one since we already have RFC 6186. IMHO, this example, which is quite confusing and was already mentioned several times with misunderstanding, should be deleted. From paulej@packetizer.com Fri Jun 14 00:09:52 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F5A21F98AD for ; Fri, 14 Jun 2013 00:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZFcxvxUYu5o for ; Fri, 14 Jun 2013 00:09:47 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id ED0E221F995F for ; Fri, 14 Jun 2013 00:09:45 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r5E79f4G027680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Jun 2013 03:09:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1371193781; bh=NT8dC9oHvAuokCPFWBImcfyC6OczvDgoBKdeBlGtV9w=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=FsDSwjksDtyhe8JZWWOOQGDZhQs6sdLWKNMmDOupNPCc5eLy2LADmwT0GpxNYKud/ Fun+895YZ9Vf8R+3AXZ1STjbPuRP8Tjtx9JhtKeJM+FOLNAH+0T3t0X1GHmFOlEAJM r0FVuUOjT9LvgGZGJdGNQxEZcFy9FK6WxNqjhWbE= From: "Paul E. Jones" To: "'Stephane Bortzmeyer'" References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <20130614065904.GA30932@nic.fr> In-Reply-To: <20130614065904.GA30932@nic.fr> Date: Fri, 14 Jun 2013 03:09:44 -0400 Message-ID: <005f01ce68ce$2665a3b0$7330eb10$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFNWMcWAQ1n5b22xM4UdUF6Zyw7DQLrgow+AwtEfrIBDFDY6AJtOwD0Amz+c8MBpoKlLJnKyhaQ Content-Language: en-us Cc: 'salvatore loreto' , 'webfinger' , 'Pete Resnick' , 'Melvin Carvalho' , draft-ietf-appsawg-webfinger@tools.ietf.org Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 07:09:52 -0000 Stephane, > On Thu, Jun 13, 2013 at 10:04:34PM -0400, > Paul E. Jones wrote > a message of 110 lines which said: > > > You're assuming WF defines how to provision an email client. It > > doesn't. There is an example in the text, but it is merely an > > example > > And a bad one since we already have RFC 6186. IMHO, this example, > which is quite confusing and was already mentioned several times with > misunderstanding, should be deleted. We do have that, but that is one solution. The new Working Group aggsrv will be defining something that is HTTP-based. WF may or may not be used for that effort. Just because another mechanism exists and new mechanisms are in the works does not mean this is a bad example. If there is confusion, then we should clarify the confusion. I don't mind adding a statement that makes it explicitly clear that the example is not an IETF-approved means of provisioning an email client. With the examples in the spec, there have been comments ranging from "the example is too abstract" to "the example looks like it could be real" (the case with this email provisioning example). We could remove all examples, but I don't think that's helpful to the reader in understanding how the protocol works. Paul From presnick@qti.qualcomm.com Fri Jun 14 07:19:02 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12A821F9CCA for ; Fri, 14 Jun 2013 07:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcL+rCpK96xv for ; Fri, 14 Jun 2013 07:18:58 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 90F9F21F9CC6 for ; Fri, 14 Jun 2013 07:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1371219538; x=1402755538; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=WSLUXW6ywaragdMNuu/J/usgNYz5FL+nJOoYgPCHe+c=; b=wf2yJj37uViycRvtaBLGq9MKLwrj60IvfUVA0IZaeaRAd+Yotardr5kr 2Z7zBBEzmBcjqtYJVMPPtrSBrrljvi5YjHxFs0gwCD4XKx2G+xXbWpAOG viMrjTuxEz3sxceShQpUSOuxPUSpaqa5xcWDxGstjhnttrXbVMEmFpg1e Q=; X-IronPort-AV: E=Sophos;i="4.87,866,1363158000"; d="scan'208";a="44986721" Received: from unknown (HELO ironmsg01-lv.qualcomm.com) ([10.47.202.180]) by sabertooth01.qualcomm.com with ESMTP; 14 Jun 2013 07:18:57 -0700 Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Jun 2013 07:18:57 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 14 Jun 2013 07:18:56 -0700 Message-ID: <51BB264C.3090602@qti.qualcomm.com> Date: Fri, 14 Jun 2013 09:18:52 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Paul E. Jones" References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> In-Reply-To: <002a01ce68a3$8501aac0$8f050040$@packetizer.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: 'salvatore loreto' , 'webfinger' , 'Melvin Carvalho' , draft-ietf-appsawg-webfinger@tools.ietf.org Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 14:19:02 -0000 On 6/13/13 9:04 PM, Paul E. Jones wrote: > On Thu, 13 Jun 2013 10:09:32 -0500, Pete Resnick wrote: > > >> OK, so I'm the client. I've got an email address. What URI do I use >> if I want email configuration parameters? Do I use mailto:? Or smtp:? >> Or pop:? Does acct: get me email configuration parameters along with >> personal information about the user? >> > You're assuming WF defines how to provision an email client. It doesn't. > There is an example in the text, but it is merely an example to illustrate > the kinds of things WF can be used. > I am starting to think that the examples are part of the problem. And I think that's true because: > In order for WF to be used in provisioning an email client, the specific > procedures would need to be spelled out in a document somewhere. > So WF is not a protocol itself. It's a framework. You can't actually use WF without having a separate document specifying: 1. The semantics of what a particular URI scheme means for a query. (E.g., acct: means give me personal information associated with this string, mailto: means give me email configuration information associated with this email identifier, jabber: means give me jabber configuration information associated with this identifier, http: means give me the personal author information for this particular web page, etc.) 2. The JRD name/value pairs that can be returned for any given URI scheme. Now, I am worried that you will disagree with my description of the particular protocol document above because you will say, "For any URI scheme, the WF server could return *any* information. So, for a jabber: URI, it could return either jabber configuration information or personal information about the jabber ID or anything else. For an acct: URI, it could return personal information, or it could return account configuration information." If that's the intent, then *that's* the semantic gap and a failing of WF: If the client can't find any documentation about how it can get back particular information, the protocol is a mere guessing game and not useful *except in closed environments with out-of-band agreements*. If you have a closed environment with an out of band agreement, you don't need a standard. >> I also think that email address is also a jabber ID (or maybe I'm >> wondering if it is)? Do I do a second query with jabber:user@domain? >> Or will acct: get me back jabber account info? >> > Each URI queried might return the same or different information. The > specifications that rely on WebFinger would state explicitly what URI to > use. As an example, the OpenID Connect specs state that > acct:paulej@packetizer.com would be used to issue a WebFinger query. > That's the part that scares me. Let's say I'm not using OpenID Connect. Let's saying I'm using the "PeteID Info" protocol. Do I get to redefine what an acct: URI returns? If so, that's completely non-interoperable. > We have picked on > Twitter a number of times, because it's an good example of why "acct:" is > needed. There are no email addresses there. So, let's say you know my > Twitter ID paul_e_jones. You could issue a query to > acct:paul_e_jones@twitter.com. > Just a note for the particular example: I'd query "acct:paul_e_jones", not "acct:paul_e_jones@twitter.com", wouldn't I? Twitter doesn't use a domain portion in its account IDs, does it? > But, we do want to allow any URI to be queried. It's even possible to query > the URI "http://www.packetizer.com/" via WebFinger. That's a web page, not > a person or account. Querying for that will return whatever information the > server wants to return. This is what one could do with RFC 6415, so the > same functionality is carried forward. > So are you saying that the semantics of querying for an http: URI are identical to querying for host meta data for the URI? Then you don't mean that it "will return whatever information the server wants to return"; it's going to return a particular set of data as defined by 6415. But I suspect that's not what you're saying. > You are entirely right that it does not give guidance, except for "acct". > [...] > The problem is not knowing what URI to query, but knowing what set of links > will be returned as a result of using a particular URI. > Neither this document nor the acct: URI document gives any guidance about what set of links will be returned for the acct: URI. The semantics of querying for the acct: URI are never defined. It gives examples using the acct: URI, but it never actually defines what links or other properties an acct: URI can return. I'm perfectly OK for this document to be clear that other documents will define the specific semantics of what particular URI schemes will return and for what purpose they ought to be queried, but everything in the document and everything that I've heard said indicates that those documents will do no such thing. They are not going to lock down the semantics for the client; the semantics of what gets returned is going to be entirely up to the server and only known to the client through out-of-band means. > The expectation is that other documents would define link relations. In > fact, we already have a laundry list of those that folks want to define. As > those are defined and registered in the existing registry, then the URI to > use with WF would also be defined. They might all end up under "acct" as > OpenID Connect specifies. So how do I as a client know whether I am doing an OpenID Connect query or a PeteID Info query? I can't tell via the URI scheme? Something is missing in this protocol. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From bortzmeyer@nic.fr Fri Jun 14 07:28:48 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884B921F9CC8 for ; Fri, 14 Jun 2013 07:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dljnxs2DRJ7C for ; Fri, 14 Jun 2013 07:28:42 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id A957421F9CC6 for ; Fri, 14 Jun 2013 07:28:42 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id D5EAD2803DE; Fri, 14 Jun 2013 16:28:05 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id CF42D28023F; Fri, 14 Jun 2013 16:28:05 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:113]) by relay1.nic.fr (Postfix) with ESMTP id CC7DB4C0053; Fri, 14 Jun 2013 16:27:35 +0200 (CEST) Date: Fri, 14 Jun 2013 16:27:35 +0200 From: 'Stephane Bortzmeyer' To: "Paul E. Jones" Message-ID: <20130614142735.GA10799@nic.fr> References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <20130614065904.GA30932@nic.fr> <005f01ce68ce$2665a3b0$7330eb10$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005f01ce68ce$2665a3b0$7330eb10$@packetizer.com> X-Operating-System: Debian GNU/Linux 7.0 X-Kernel: Linux 3.2.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 'Pete Resnick' , 'Stephane Bortzmeyer' , draft-ietf-appsawg-webfinger@tools.ietf.org, 'Melvin Carvalho' , 'salvatore loreto' , 'webfinger' Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 14:28:48 -0000 On Fri, Jun 14, 2013 at 03:09:44AM -0400, Paul E. Jones wrote a message of 31 lines which said: > I don't mind adding a statement that makes it explicitly clear that > the example is not an IETF-approved means of provisioning an email > client. Then saying clearly that the example is not an example of present and actual use: it's brainstorming about what WebFinger could do in the future. > With the examples in the spec, there have been comments ranging from > "the example is too abstract" to "the example looks like it could be > real" (the case with this email provisioning example). We could > remove all examples, Indeed, some of the examples are wrong. In -14: > Locating a User's Blog OK for me (except the erroneous "en-us" that I already mentioned here) > Identity Provider Discovery for OpenID Connect OK for me (I assume not OK for Pete Resnick because there are no details about the possible "rel" in the query and the possible links in the response) > Auto-Configuration of Email Clients Useless and dangerous. > Retrieving Device Information Dangerous, for security reasons, as mentioned in the IESG ballot From cyrus@daboo.name Fri Jun 14 07:34:09 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C49C21F9CB1 for ; Fri, 14 Jun 2013 07:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35pwhN3QNSKM for ; Fri, 14 Jun 2013 07:34:03 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1CA21F9CB3 for ; Fri, 14 Jun 2013 07:34:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 41C974556B51; Fri, 14 Jun 2013 10:34:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6K5cyeB9JOJH; Fri, 14 Jun 2013 10:34:01 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 8EA7D4556B46; Fri, 14 Jun 2013 10:33:59 -0400 (EDT) Date: Fri, 14 Jun 2013 10:33:55 -0400 From: Cyrus Daboo To: Pete Resnick , "Paul E. Jones" Message-ID: In-Reply-To: <51BB264C.3090602@qti.qualcomm.com> References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <51BB264C.3090602@qti.qualcomm.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1081 Cc: 'salvatore loreto' , 'webfinger' , draft-ietf-appsawg-webfinger@tools.ietf.org, 'Melvin Carvalho' Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 14:34:09 -0000 Hi Pete, --On June 14, 2013 at 9:18:52 AM -0500 Pete Resnick wrote: >> Each URI queried might return the same or different information. The >> specifications that rely on WebFinger would state explicitly what URI to >> use. As an example, the OpenID Connect specs state that >> acct:paulej@packetizer.com would be used to issue a WebFinger query. >> > > That's the part that scares me. Let's say I'm not using OpenID Connect. > Let's saying I'm using the "PeteID Info" protocol. Do I get to redefine > what an acct: URI returns? If so, that's completely non-interoperable. That touches one of the concerns I had about using webfinger for aggregated service discovery. In most cases aggsrv clients are only going to care about a aggsrv details/links so they ought to have a way to request that only those links be returned in the webfinger response. So adding some query parameters that would let the client list the specific pieces of information it wants would solve that, and may well address Pete's specific point above. -- Cyrus Daboo From bortzmeyer@nic.fr Fri Jun 14 07:34:42 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BEB21F9691 for ; Fri, 14 Jun 2013 07:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yi74Z9ZuQRjH for ; Fri, 14 Jun 2013 07:34:35 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id A996D21F9CE6 for ; Fri, 14 Jun 2013 07:34:35 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 0EDEF28023F; Fri, 14 Jun 2013 16:34:05 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 08E752801A0; Fri, 14 Jun 2013 16:34:05 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:113]) by relay1.nic.fr (Postfix) with ESMTP id 065574C007F; Fri, 14 Jun 2013 16:33:35 +0200 (CEST) Date: Fri, 14 Jun 2013 16:33:35 +0200 From: Stephane Bortzmeyer To: Pete Resnick Message-ID: <20130614143334.GB10799@nic.fr> References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <51BB264C.3090602@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51BB264C.3090602@qti.qualcomm.com> X-Operating-System: Debian GNU/Linux 7.0 X-Kernel: Linux 3.2.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 'salvatore loreto' , "Paul E. Jones" , draft-ietf-appsawg-webfinger@tools.ietf.org, 'Melvin Carvalho' , 'webfinger' Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 14:34:42 -0000 On Fri, Jun 14, 2013 at 09:18:52AM -0500, Pete Resnick wrote a message of 126 lines which said: > I am starting to think that the examples are part of the problem. I agree that some of the examples describe, not what WebFinger does today, but what it may do in a bright future where many other things will have been specified. The last two in -14 are specially problematic. From paulej@packetizer.com Fri Jun 14 09:19:38 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C6C21F91BC for ; Fri, 14 Jun 2013 09:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFel-l8MXsIE for ; Fri, 14 Jun 2013 09:19:34 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 46CC421F9A87 for ; Fri, 14 Jun 2013 09:19:34 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r5EGJMjX029526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Jun 2013 12:19:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1371226763; bh=dcfnEv6kuj6VHBJu9tCFpGBTvXJgoWf7MZlZWiSzgDU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ATyBiMEmB/M8WovtiLqXpee87dGtWP1AyPV588egDk7MVBYWamnJA9sRNXt4PHifA knKx8Ym34zEeTIPj+mmcskNzFKWHf26+J+dDBW8k5Rf+Ei9mWm2kb1FKSkbjRYghlI iqTxclpBiNMEgcj4V5sVKWO/IYy3mzMNKYtnG3ko= From: "Paul E. Jones" To: "'Pete Resnick'" References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <51BB264C.3090602@qti.qualcomm.com> In-Reply-To: <51BB264C.3090602@qti.qualcomm.com> Date: Fri, 14 Jun 2013 12:19:27 -0400 Message-ID: <00b501ce691a$f1a59570$d4f0c050$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFNWMcWAQ1n5b22xM4UdUF6Zyw7DQLrgow+AwtEfrIBDFDY6AJtOwD0Amz+c8MCw8Ka+5nCaXMw Content-Language: en-us Cc: 'salvatore loreto' , 'webfinger' , 'Melvin Carvalho' , draft-ietf-appsawg-webfinger@tools.ietf.org Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 16:19:38 -0000 Pete, > >> OK, so I'm the client. I've got an email address. What URI do I use > >> if I want email configuration parameters? Do I use mailto:? Or smtp:? > >> Or pop:? Does acct: get me email configuration parameters along with > >> personal information about the user? > >> > > You're assuming WF defines how to provision an email client. It doesn't. > > There is an example in the text, but it is merely an example to > illustrate > > the kinds of things WF can be used. > > > > I am starting to think that the examples are part of the problem. And I > think that's true because: > > > In order for WF to be used in provisioning an email client, the specific > > procedures would need to be spelled out in a document somewhere. > > > > So WF is not a protocol itself. It's a framework. You can't actually use > WF without having a separate document specifying: > > 1. The semantics of what a particular URI scheme means for a query. > (E.g., acct: means give me personal information associated with this > string, mailto: means give me email configuration information associated > with this email identifier, jabber: means give me jabber configuration > information associated with this identifier, http: means give me the > personal author information for this particular web page, etc.) I would agree with most of this, except that I do view this as more than just a framework document. If I want to get a set of links related to a given URI, the document tells you exactly how to do that. It also documents in detail the exact format of the query and the response. What is not detailed (and to your point) is what link types would one expect to receive in the returned JRD document when querying the server with any particular URI. That will have to be defined somewhere else. Many have been defined already inside and outside the IETF. The OpenID Connect document is one example. I have assembled a list of ones in use that I know about and there are some that folks do intend to standardize in the IETF. > 2. The JRD name/value pairs that can be returned for any given URI scheme. > > Now, I am worried that you will disagree with my description of the Moi? Disagree? :-) > particular protocol document above because you will say, "For any URI > scheme, the WF server could return *any* information. So, for a jabber: > URI, it could return either jabber configuration information or personal > information about the jabber ID or anything else. For an acct: URI, it > could return personal information, or it could return account > configuration information." If that's the intent, then *that's* the > semantic gap and a failing of WF: If the client can't find any > documentation about how it can get back particular information, the > protocol is a mere guessing game and not useful *except in closed > environments with out-of-band agreements*. If you have a closed > environment with an out of band agreement, you don't need a standard. It is true that a WF server could return any information for a given URI scheme, but that's because we have not specified anything that is to be expected for any given URI, except "acct:". We do not want to have the ambiguity you describe. Devices and applications should not play guessing games. If one wishes to retrieve information about a user's account, then "acct:" is to be used and that is recommended in the WF spec. This is one reason that OpenID Connect uses the acct URI scheme. Those folks then defined the particular link type that the client should look for. Folks are planning to specify use of acct for other link types, including pointers to a user's picture, blog, etc. Until there is a specification that says exactly what information to expect if one were to use mailto: or jabber:, then one should not use those URIs. That said, we do want WebFinger to accommodate those or any URI type. This is to align with RFC 6415, but also because there might be something useful defined for other URIs in the future, just as we're seeing 'acct' take shape. > >> I also think that email address is also a jabber ID (or maybe I'm > >> wondering if it is)? Do I do a second query with jabber:user@domain? > >> Or will acct: get me back jabber account info? > >> > > Each URI queried might return the same or different information. The > > specifications that rely on WebFinger would state explicitly what URI to > > use. As an example, the OpenID Connect specs state that > > acct:paulej@packetizer.com would be used to issue a WebFinger query. > > > > That's the part that scares me. Let's say I'm not using OpenID Connect. > Let's saying I'm using the "PeteID Info" protocol. Do I get to redefine > what an acct: URI returns? If so, that's completely non-interoperable. No, but you might define a new link type. Consider the example in the OpenID Connect spec: http://openid.net/specs/openid-connect-discovery-1_0.html#EmailSyntax The "rel" value is defined by the OpenID Foundation. You may also define your own "rel" value. When a client queries a WF server for acct:paulej@packetizer.com, any number of link types might be returned. Some might be defined within the IETF and some might be defined outside the IETF. However, a client will know exactly what it is looking for and would ignore link type is does not understand. Any client that implements PeteID would be looking for a specific link type defined in your protocol spec. You can query my account to see some example link types: $ curl https://packetizer.com/.well-known/webfinger?resource=acct:paulej@packetizer .com You'll see some "rel" values that are in the webfinger.net domain and some in the packetizer.com domain. What folks want to do is specify some of those in the IETF. For example, say you want my vcard. Presently, nothing tells you how to find it. My server will return a "rel" of "http://packetizer.com/rel/businesscard" and a type of "text/vcard". To be useful, this would need to be standardized. There is an intent to standardize this one and others (blog, avatar, profile-page, etc.). > > We have picked on > > Twitter a number of times, because it's an good example of why "acct:" > is > > needed. There are no email addresses there. So, let's say you know my > > Twitter ID paul_e_jones. You could issue a query to > > acct:paul_e_jones@twitter.com. > > > > Just a note for the particular example: I'd query "acct:paul_e_jones", > not "acct:paul_e_jones@twitter.com", wouldn't I? Twitter doesn't use a > domain portion in its account IDs, does it? The 'acct' URI scheme is of this form: acctURI = "acct" ":" userpart "@" host (See draft-ietf-appsawg-acct-uri-04.) The intent was that the host portion would always be present. Twitter does not use email addresses, so you never see "@twitter.com". But, if querying for account information at twitter.com for user paul_e_jones, the URI would be constructed as I showed it. > > But, we do want to allow any URI to be queried. It's even possible to > query > > the URI "http://www.packetizer.com/" via WebFinger. That's a web page, > not > > a person or account. Querying for that will return whatever information > the > > server wants to return. This is what one could do with RFC 6415, so the > > same functionality is carried forward. > > > > So are you saying that the semantics of querying for an http: URI are > identical to querying for host meta data for the URI? Correct. > Then you don't > mean that it "will return whatever information the server wants to > return"; it's going to return a particular set of data as defined by > 6415. But I suspect that's not what you're saying. I would say yes to this, except that RFC 6415 does not really define the set of link types that will be returned, either. It specifies the protocol to use, but the specification of the link types was intended to be detailed elsewhere. RFC 6415 gives examples of "copyright" and "author" link types. Those are defined outside the context of RFC 6415, but used as examples in that spec. Those are valid link types to be returned if one were to query using the URI of a web page. Still, nothing concretely says those are to be expected or may appear in the response. (I'm not sure if anyone uses those in practice, either, with WebFinger or RFC 6415.) > > You are entirely right that it does not give guidance, except for "acct". > > [...] > > The problem is not knowing what URI to query, but knowing what set of > links > > will be returned as a result of using a particular URI. > > > > Neither this document nor the acct: URI document gives any guidance > about what set of links will be returned for the acct: URI. The > semantics of querying for the acct: URI are never defined. It gives > examples using the acct: URI, but it never actually defines what links > or other properties an acct: URI can return. That's true. The OpenID Connect spec is one that does define one link type. There are some other groups that have defined some link types outside the IETF. But as I mentioned above, the intent is to standardize some link types. That plan has been on the table waiting for WF to get done. Even if that document never sees the light of day, other groups are specifying link types for use with WF. (I would personally like to see a set of agreed standard link types, though.) > I'm perfectly OK for this document to be clear that other documents will > define the specific semantics of what particular URI schemes will return > and for what purpose they ought to be queried, but everything in the > document and everything that I've heard said indicates that those > documents will do no such thing. They are not going to lock down the > semantics for the client; the semantics of what gets returned is going > to be entirely up to the server and only known to the client through > out-of-band means. It was definitely not the intent that clients would be guessing as to how to perform a query. If a client is looking for my avatar, for example, the client needs to know exactly what URI to use and what link type to look for. That should be spelled out in the document that describes the link type. Any words you want to suggest for the WF spec to make that abundantly clear, I'm happy to introduce. > > The expectation is that other documents would define link relations. In > > fact, we already have a laundry list of those that folks want to define. > As > > those are defined and registered in the existing registry, then the URI > to > > use with WF would also be defined. They might all end up under "acct" > as > > OpenID Connect specifies. > > So how do I as a client know whether I am doing an OpenID Connect query > or a PeteID Info query? I can't tell via the URI scheme? As the client, you know whether you're trying to do OpenID or PeteID. I don't see that as an issue. If you are an OpenID Connect client, then you follow the procedures as specified in the above referenced spec, looking for acct:user@domain and for a specific link type. > Something is missing in this protocol. I believe it's the specification of link types, properties, etc. Those would be spelled out by other specifications. Paul From paulej@packetizer.com Fri Jun 14 09:28:14 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFC121F9D0F for ; Fri, 14 Jun 2013 09:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmEN2irUyfPZ for ; Fri, 14 Jun 2013 09:28:09 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8332F21F9CFD for ; Fri, 14 Jun 2013 09:28:09 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r5EGS5If030078 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Jun 2013 12:28:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1371227286; bh=FS0yXOHQUrBRfCMY70wvWZeO+bK2tvq9QNIvv9XfSEA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=aMA6GjAhRZ1ZAUWsQ1x3nE0BnUzlm3rDp5XBwMl7wnNvFFbibumSoWpTGnuOpRTIf DPjiG2RfjQZjGe2C9szQaGPhPA7SnVR+Oq/XqLaBFoap0Ld7cXigcp5WoyOBSUuand mu7VOPkhKW4mFNOM0/fSCSvaUSMSNxCM45BE4PKg= From: "Paul E. Jones" To: "'Stephane Bortzmeyer'" References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <20130614065904.GA30932@nic.fr> <005f01ce68ce$2665a3b0$7330eb10$@packetizer.com> <20130614142735.GA10799@nic.fr> In-Reply-To: <20130614142735.GA10799@nic.fr> Date: Fri, 14 Jun 2013 12:28:10 -0400 Message-ID: <00b701ce691c$29354200$7b9fc600$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFNWMcWAQ1n5b22xM4UdUF6Zyw7DQLrgow+AwtEfrIBDFDY6AJtOwD0Amz+c8MBpoKlLAHOxQXMAoqTx4eZqJsIoA== Content-Language: en-us Cc: 'salvatore loreto' , 'webfinger' , 'Pete Resnick' , 'Melvin Carvalho' , draft-ietf-appsawg-webfinger@tools.ietf.org Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 16:28:14 -0000 Stephane, > On Fri, Jun 14, 2013 at 03:09:44AM -0400, > Paul E. Jones wrote > a message of 31 lines which said: > > > I don't mind adding a statement that makes it explicitly clear that > > the example is not an IETF-approved means of provisioning an email > > client. > > Then saying clearly that the example is not an example of present and > actual use: it's brainstorming about what WebFinger could do in the > future. Yes and no. The intent is to give the reader a crisp idea of how the protocol works. The email configuration example, IMO, was a good one, because it illustrated how to use those elements of the syntax so well that somebody on the list remarked that "this could really work" or something like that. > > With the examples in the spec, there have been comments ranging from > > "the example is too abstract" to "the example looks like it could be > > real" (the case with this email provisioning example). We could > > remove all examples, > > Indeed, some of the examples are wrong. In -14: > > > Locating a User's Blog > > OK for me (except the erroneous "en-us" that I already mentioned here) What's the issue with "en-us"? > > Identity Provider Discovery for OpenID Connect > > OK for me (I assume not OK for Pete Resnick because there are no > details about the possible "rel" in the query and the possible links > in the response) That's defined in the OpenID Connect discovery specification. > > Auto-Configuration of Email Clients > > Useless and dangerous. I'm pretty sure nobody will get murdered over this, so I question the claim it's dangerous. The fact that is looks so real it could work suggests is properly demonstrates in a practical example how WF could be used. The fact that this is not the way we will provision an email client is a separate issue and I don't mind adding text -- whatever you suggest -- to make it even more clear that this is only an example for illustrative purposes. > > Retrieving Device Information > > Dangerous, for security reasons, as mentioned in the IESG ballot I really don't understand how this could have any security implications since the example is entirely bogus. Again, this is only an example, and it's an example that will not even work since "device:" is not defined. If we defined "device:" tomorrow, it's still an example that would require a different spec to spell out the link types and properties. Paul From paulej@packetizer.com Fri Jun 14 09:35:04 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5627C21F99A1 for ; Fri, 14 Jun 2013 09:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3e9AKvrMw2p for ; Fri, 14 Jun 2013 09:34:59 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 961B721F997E for ; Fri, 14 Jun 2013 09:34:59 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r5EGYnUj030491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Jun 2013 12:34:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1371227690; bh=OQeIWoTGHsDvIZnDuptCajIDbiu/Af7ta8RdEnv+wSQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=IcHYwZHVnIWjMgnACfvJcNf6FyVC1fH9358jIOQxeTjk5zsrh0Rw1pDuUHrncS7uA YuE96Z0HBn0TaKygvNM0lW3iEWPBjQf+kH51rnyWFCTIOkMWZsjbbroWCgfdMm3Hy6 Tjumxz5NqjIfjOHNnsVqDqs0c0xUYG/Xc+Edo7qI= From: "Paul E. Jones" To: "'Cyrus Daboo'" , "'Pete Resnick'" References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <51BB264C.3090602@qti.qualcomm.com> In-Reply-To: Date: Fri, 14 Jun 2013 12:34:54 -0400 Message-ID: <00b901ce691d$19e8ac50$4dba04f0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFNWMcWAQ1n5b22xM4UdUF6Zyw7DQLrgow+AwtEfrIBDFDY6AJtOwD0Amz+c8MCw8Ka+wIRnN/ombHxYVA= Content-Language: en-us Cc: 'salvatore loreto' , 'webfinger' , 'Melvin Carvalho' , draft-ietf-appsawg-webfinger@tools.ietf.org Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 16:35:04 -0000 Cyrus, > Hi Pete, > > --On June 14, 2013 at 9:18:52 AM -0500 Pete Resnick > wrote: > > >> Each URI queried might return the same or different information. The > >> specifications that rely on WebFinger would state explicitly what URI > to > >> use. As an example, the OpenID Connect specs state that > >> acct:paulej@packetizer.com would be used to issue a WebFinger query. > >> > > > > That's the part that scares me. Let's say I'm not using OpenID Connect. > > Let's saying I'm using the "PeteID Info" protocol. Do I get to redefine > > what an acct: URI returns? If so, that's completely non-interoperable. > > That touches one of the concerns I had about using webfinger for > aggregated > service discovery. In most cases aggsrv clients are only going to care > about a aggsrv details/links so they ought to have a way to request that > only those links be returned in the webfinger response. So adding some > query parameters that would let the client list the specific pieces of > information it wants would solve that, and may well address Pete's > specific > point above. There is a way for the client to request only the links of interest. That's done via the "rel" parameter in WebFinger, which may appear multiple times, each with a different value. Compare these two: $ curl https://packetizer.com/.well-known/webfinger?resource=acct:paulej@packetizer .com $ curl 'https://packetizer.com/.well-known/webfinger?resource=acct:paulej@packetize r.com&rel=http://packetizer.com/rel/blog&rel=http://webfinger.net/rel/avatar ' The first returns the entire JRD. The second returns only the link types of interest. Even if additional link types are returned, those can safely be ignored by the client. For aggsrv, we may not even want to use 'acct', but perhaps protocol-specific URIs (e.g., 'smtp' or 'jabber'). Whatever is used, the aggsrv specs would specify the URI scheme(s) to use, along with the link types, properties, etc. Paul From barryleiba.mailing.lists@gmail.com Fri Jun 14 09:59:16 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB09921F9D01 for ; Fri, 14 Jun 2013 09:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.097 X-Spam-Level: X-Spam-Status: No, score=-102.097 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kE+PbP7rBK3n for ; Fri, 14 Jun 2013 09:59:16 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A6AD621F9D00 for ; Fri, 14 Jun 2013 09:59:15 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id jz10so675494veb.17 for ; Fri, 14 Jun 2013 09:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=MTy/rLScoey/n0gXeXf4u/r4hN70fYqEbCoVqMWK7n8=; b=tKK8+d+JvPQQdbPVKhW/AbIjMNFcYxvn4hzB1g2cGIrjPtF6qRsrUSoBNT0Sljhuuz 9K5mK5Kt6Fv01HFKE60xNP5VRsasAzaDF31LPlHHHCCM2PHx56OyRgOLvMmqUKA80AjX t/59LJzljcJU4NXws1zf2Zojv74Le/HCLUdavOsYOLj/fyoGaAaBqJ9GSRH9u1HYK8n8 B+ihNVvD0x9yeeRGKVhlJi5tXMhDpUPmkL2LBaq4HYfprZSUswA1xLqauMG9DDctkyuf lC8pQKae0Mlnmbc3J/ycxn2Y6wc8zILboD2ZIou8F7+oqxFBwnnB8oTJazMryGek+rTI d0kQ== MIME-Version: 1.0 X-Received: by 10.220.101.69 with SMTP id b5mr1255891vco.55.1371229154831; Fri, 14 Jun 2013 09:59:14 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.234.105 with HTTP; Fri, 14 Jun 2013 09:59:14 -0700 (PDT) In-Reply-To: <51BB264C.3090602@qti.qualcomm.com> References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <51BB264C.3090602@qti.qualcomm.com> Date: Fri, 14 Jun 2013 18:59:14 +0200 X-Google-Sender-Auth: bz93FzVnrCuj9zSPPn01k1RMXEA Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: multipart/alternative; boundary=047d7b3a7e92adf47604df202a01 Cc: salvatore loreto , "Paul E. Jones" , "draft-ietf-appsawg-webfinger@tools.ietf.org" , Melvin Carvalho , webfinger Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 16:59:16 -0000 --047d7b3a7e92adf47604df202a01 Content-Type: text/plain; charset=ISO-8859-1 > > 2. The JRD name/value pairs that can be returned for any given URI scheme. ... > Neither this document nor the acct: URI document gives any guidance about > what set of links will be returned for the acct: URI. The semantics of > querying for the acct: URI are never defined. It gives examples using the > acct: URI, but it never actually defines what links or other properties an > acct: URI can return. > Let me stick something in here: 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. Barry --047d7b3a7e92adf47604df202a01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2. The JRD name/value pairs that can be retu= rned for any given URI scheme.
...
Neither this document nor the acct: URI document gives any guidance about w= hat set of links will be returned for the acct: URI. The semantics of query= ing for the acct: URI are never defined. It gives examples using the acct: = URI, but it never actually defines what links or other properties an acct: = URI can return.

Let me stick something in here:
=
There are two ways we can get interoperability from this. = =A0One is to explicitly specify everything that might be returned from a pa= rticular query. =A0Another is to make sure that what gets returned is self-= defining. =A0The latter is the point of link relations -- the link relation= tells you what the link means, so the recipient knows whether it understan= ds this type or not, and, if it understands it, knows what its semantics ar= e and what to do with it.

Barry
=A0
--047d7b3a7e92adf47604df202a01-- From tbray@textuality.com Fri Jun 14 10:16:40 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1028C21F9AF7 for ; Fri, 14 Jun 2013 10:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.432 X-Spam-Level: X-Spam-Status: No, score=0.432 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bq+D5-xdahz2 for ; Fri, 14 Jun 2013 10:16:34 -0700 (PDT) Received: from mail-vb0-x22b.google.com (mail-vb0-x22b.google.com [IPv6:2607:f8b0:400c:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1073B21F9B42 for ; Fri, 14 Jun 2013 10:16:33 -0700 (PDT) Received: by mail-vb0-f43.google.com with SMTP id e12so619829vbg.16 for ; Fri, 14 Jun 2013 10:16:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=F74CT4KYwu7jdXSdKzNTWIvQ5pV6O2GO0bK2SYd8S5g=; b=TjPnWuQLPwh8G+g0ltAe1ySKN94F1FwyPGdC91bN4WKD8hgfsI0srqpsedLq4JkRyf qIP9p/vT9QTB9rO2tVICCdNUdGk4+XuizuWCmCHcb+t6CwRwil7rtWVpEur8dv+scSuy zWgsplGehyLNY7bnwqftbc+YjLKmLTYKpy/TJCBcRnAcl9V8RTHcAM2D8Q/mBzxsAYyD CIReleP9FN3BEf4keVJa3FvM4lFiZXQbzRSGzf5U/gvJZ+sZc00Bhyi3eFl0kjpolVhp Kg4h7LaFl+UzUkDq04d0ajh7wrqCIk0D1EQaI07ASpNWRS4ymCnIR7w+Pk3gs2/ZVrmf xb0Q== MIME-Version: 1.0 X-Received: by 10.52.89.234 with SMTP id br10mr1058080vdb.103.1371230192815; Fri, 14 Jun 2013 10:16:32 -0700 (PDT) Received: by 10.220.25.199 with HTTP; Fri, 14 Jun 2013 10:16:32 -0700 (PDT) X-Originating-IP: [24.84.235.32] Date: Fri, 14 Jun 2013 10:16:32 -0700 Message-ID: From: Tim Bray To: "webfinger@ietf.org" Content-Type: multipart/alternative; boundary=20cf307f37d68c656004df206863 X-Gm-Message-State: ALoCoQlRE+nHp/dgDqxWEw1pRKbzK+nsCqPgRNUCX2r6+SgNjnYs249cau7noCkPAOVsO8jDo1Hr Subject: [webfinger] Simplifying and unjamming WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 17:16:40 -0000 --20cf307f37d68c656004df206863 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99ve been following the endless back and forth on this with a feeli= ng 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=E2=80=99t just use an email addr= ess, 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=E2=80=99t have a general-purpose problem about wanting metadata f= or 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=3Dbob@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 --20cf307f37d68c656004df206863 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I=E2=80=99ve been = following the endless back and forth on this with a feeling of despair... p= eople seem to be talking back and forth past each other.=C2=A0 Lots of peop= le think there are problems, Paul thinks there are no problems.

Back in the day, when I first heard of WebFinger, it was the simp= lest thing imaginable: Put in an email address and get back some pointers t= o IDPs or whatever.=C2=A0 Somewhere along the way, it morphed into getting = metadata about any Resource.=C2=A0 Which meant that you couldn=E2=80=99t ju= st use an email address, you had to turn it into a URI.

And thus the problem in the spec.=C2=A0 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.=C2=A0
But I don=E2=80=99t have a general-purpose problem about wanting metadata f= or arbitrary URIs.=C2=A0 I have several immediate pressing problems for ret= rieving metadata about=C2=A0 email addresses.=C2=A0=C2=A0 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 i= s

/.well-known/wf-lite?email=3Dbob@example.com

Which yields a JRD.=C2=A0 You could s= till have the rel-selection and so on. It would be easy to understand. It w= ould be self-contained. The draft would shrink in size dramatically. It wou= ld be instantly usable by OpenID Connect.=C2=A0 It would probably sail thro= ugh the IESG.


=C2=A0-T
--20cf307f37d68c656004df206863-- From konklone@gmail.com Fri Jun 14 10:34:43 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8DF21F9808 for ; Fri, 14 Jun 2013 10:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apR+5J1MSmT6 for ; Fri, 14 Jun 2013 10:34:42 -0700 (PDT) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3177C21F9607 for ; Fri, 14 Jun 2013 10:34:42 -0700 (PDT) Received: by mail-ea0-f174.google.com with SMTP id o10so506873eaj.5 for ; Fri, 14 Jun 2013 10:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sbnVb/UkNwmDK4TAdltRbQx3rblV20hUybk2UDBk9SQ=; b=qkQj3jQRmg/a26XBEH11DDXI1EA7oZe6XRK4WofUxpb+IYgmKKBC6gTnIxDCAmjrNB OQkW3q+UXT24nUCf8Vgk8ULCNI91icYJnyu7lFpKZeG/Mcrid+hdbJGuaxmiJtMk4RaV rgCLS7D3wkCwz2k+XcYX2MaMEBcW7HmjR5f612b8s3TNZlSvjN+uYZdJL8QZoFMcaehV 3sc7bsZVFCuLaGMHjw4Ghra6wqYViqu74jPwmLkwOOBO/XISn/KFahzi2RViMPpGpSeC jvvy1EKIJUOVl/g2cC9CidQo5r7fmOo/9icZr7KCVSWX5glV13XAUBDZ8wnnpi/IhqGD UPdQ== X-Received: by 10.15.107.6 with SMTP id ca6mr4229122eeb.120.1371231281227; Fri, 14 Jun 2013 10:34:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.72.144 with HTTP; Fri, 14 Jun 2013 10:34:01 -0700 (PDT) In-Reply-To: References: From: Eric Mill Date: Fri, 14 Jun 2013 13:34:01 -0400 Message-ID: To: Tim Bray Content-Type: multipart/alternative; boundary=089e016813306c4e7a04df20a934 Cc: "webfinger@ietf.org" Subject: Re: [webfinger] Simplifying and unjamming WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 17:34:43 -0000 --089e016813306c4e7a04df20a934 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable A thousand times yes. Webfinger is the small beautiful idea that could, and this endless back-and-forth is sucking the life out of it. I haven't been involved in the spec work, but I did do some actual evangelism to the Rails community soon after Webfinger began - *3 years ago*. But that's all I did - once the spec slowed down to a crawl and got lost in the weeds, I couldn't sustain that energy. I'm sure I'm not the only one to be affected that way. email -> metadata. Make it possible to own your identity with your email. That's what we need. -- Eric On Fri, Jun 14, 2013 at 1:16 PM, Tim Bray wrote: > I=92ve been following the endless back and forth on this with a feeling o= f > despair... people seem to be talking back and forth past each other. Lot= s > 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=92t 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 schem= e > to use (acct:, mailto:, device:) and this will affect the output in ways > that have to be specified in Other Places. > > But I don=92t have a general-purpose problem about wanting metadata for > arbitrary URIs. I have several immediate pressing problems for retrievin= g > 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=3Dbob@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 > > --=20 @konklone | konklone.com | sunlightfoundation.com | awesomefoundation.org --089e016813306c4e7a04df20a934 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
A thousand times yes. Webfinger is the small beautiful ide= a that could, and this endless back-and-forth is sucking the life out of it= .

I haven't been involved in the spec work, bu= t I did do some ac= tual evangelism to the Rails community soon after Webfinger began - = 3 years ago. But that's all I did - once the spec slowed down to a = crawl and got lost in the weeds, I couldn't sustain that energy. I'= m sure I'm not the only one to be affected that way.

email -> metadata. Make it possible to o= wn your identity with your email. That's what we need.
=
-- Eric


On Fri, Jun 14, 2013 at 1:16 PM, Tim Bray <t= bray@textuality.com> wrote:
I=92ve been follow= ing the endless back and forth on this with a feeling of despair... people = seem to be talking back and forth past each other.=A0 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 simp= lest thing imaginable: Put in an email address and get back some pointers t= o IDPs or whatever.=A0 Somewhere along the way, it morphed into getting met= adata about any Resource.=A0 Which meant that you couldn=92t just use an em= ail address, you had to turn it into a URI.

And thus the problem in the spec.=A0 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.=A0

But I don=92t have a general-purpose problem about wanting metadata for arb= itrary URIs.=A0 I have several immediate pressing problems for retrieving m= etadata about=A0 email addresses.=A0=A0 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 i= s

/.well-known/wf-lite?email=3Dbob@example.com

Which yields a JRD.= =A0 You could still have the rel-selection and so on. It would be easy to u= nderstand. It would be self-contained. The draft would shrink in size drama= tically. It would be instantly usable by OpenID Connect.=A0 It would probab= ly sail through the IESG.

=A0-T

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger




--
--089e016813306c4e7a04df20a934-- From bradfitz@google.com Fri Jun 14 10:51:55 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9922D21F9C81 for ; Fri, 14 Jun 2013 10:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqKCBG9eoPAk for ; Fri, 14 Jun 2013 10:51:54 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBA221F9B7E for ; Fri, 14 Jun 2013 10:51:53 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so2320304wiw.2 for ; Fri, 14 Jun 2013 10:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nY7/TlnmMeDUrE5XA0glcE4sVuSxchDGd13zqa312Cc=; b=BZ133sVbZuGLkOQeW8KYN4skNyEJuB02Cv9mzLBCyCnNz3Pw8LBZ/FkglbQHddC6A1 PtGNg/VbzJVBw9slivahuIFts32FXQIo/q/lYkXowe4vRBo4o7rj+qDyqbu6fs4bc82K wJ2r0Hy87/9xl3kajEokbfFLlYXvRDYmdOq1dDZZEHo6CdfDwPNW0WRQyGcW/g3XZwJN cW/3mKzFMavqGH8D9SCXsGSwdGSOeFkTMl0Dk1mE+n25jvkqjxo9EOz539svTxhSaRs8 1FT+DgWpk1AZg005EGhtsWF6p6nXakSviYQTK5L3lF1yjFq9treC/0WjytqWL4rjcSeQ H3Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=nY7/TlnmMeDUrE5XA0glcE4sVuSxchDGd13zqa312Cc=; b=JIi7SHZ3CjfI6D7oOviqDnbeypHUqT4vv0jtF6O7p2Q3cI2jD0f6H1ws8UGH87FT/N lrH65RetavrTzPXcC+2uRwL88+hc0p5wizdulD0joVTCJfTVJCWGToOVIcaQMHaPQ0EU pfWGiNBg8Ynkb3M74htrERmi7OEAnGD4/Wa/P6IruWFhlJq/kAHPuOmQLyVFNKTkb7pQ N95ZnBBT58qosZeFiTE1JyxV5gsqXSamCjY7r+6ecCHGy/jwoTTAx6PmmP6M2ID3KCOG DYv1Wh8gH/1kgBUf2hp2ciPM4eHy/UfmCCouJ3g2zwjBBCjFRgwPsCeR1tS1u1NaFRYp e6Og== MIME-Version: 1.0 X-Received: by 10.194.219.6 with SMTP id pk6mr2131969wjc.82.1371232313065; Fri, 14 Jun 2013 10:51:53 -0700 (PDT) Received: by 10.194.3.98 with HTTP; Fri, 14 Jun 2013 10:51:53 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Jun 2013 10:51:53 -0700 Message-ID: From: Brad Fitzpatrick To: Eric Mill Content-Type: multipart/alternative; boundary=001a11c1ba4eecf6d504df20e65c X-Gm-Message-State: ALoCoQntVxsS1GDKXOvY9lW6IpjfpxYd4meZlY2vuxWpTlA21lp08k4QwGkwMHdFWTjzkN9CaISaFS7TuAbl9rEBWNHDiFill65DfTq9+JAAFEIRTXCndOLaNxG7okYsEA3N5YcSKOllc5x5slUUxV1Yl30sW0Obc93YG1aKXVX7y+AgNOhbAdS9+ERUysq317hBWHWlIUym Cc: "webfinger@ietf.org" , Tim Bray Subject: Re: [webfinger] Simplifying and unjamming WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 17:51:55 -0000 --001a11c1ba4eecf6d504df20e65c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 3 years ago? That's recent! I've been watching this over-specification-wankery for much longer than that. Which is to say: I agree with Tim. Stop inventing unnecessary problems and ship something small and useful and composable. On Fri, Jun 14, 2013 at 10:34 AM, Eric Mill wrote: > A thousand times yes. Webfinger is the small beautiful idea that could, > and this endless back-and-forth is sucking the life out of it. > > I haven't been involved in the spec work, but I did do some actual > evangelism to the Rails > community soon after Webfinger began - *3 years ago*. But that's all I > did - once the spec slowed down to a crawl and got lost in the weeds, I > couldn't sustain that energy. I'm sure I'm not the only one to be affecte= d > that way. > > email -> metadata. Make it possible to own your identity with your email. > That's what we need. > > -- Eric > > > On Fri, Jun 14, 2013 at 1:16 PM, Tim Bray wrote: > >> I=E2=80=99ve been following the endless back and forth on this with a fe= eling of >> despair... people seem to be talking back and forth past each other. Lo= ts >> 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=E2=80=99t 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=E2=80=99t have a general-purpose problem about wanting metadat= a for >> arbitrary URIs. I have several immediate pressing problems for retrievi= ng >> metadata about email addresses. The former is now seriously getting i= n >> the way of the latter. >> >> So, how about a WebFinger light, in which the form of the query is >> >> /.well-known/wf-lite?email=3Dbob@example.com >> >> Which yields a JRD. You could still have the rel-selection and so on. I= t >> 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 >> >> > > > -- > @konklone | konklone.com | > sunlightfoundation.com | awesomefoundation.org > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --001a11c1ba4eecf6d504df20e65c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
3 years ago? That's recent! I've been watching thi= s over-specification-wankery for much longer than that.

= Which is to say: I agree with Tim.

Stop inventing = unnecessary problems and ship something small and useful and composable.



On Fri, Jun 14, 2013 at 10:34 AM, Eric Mill <<= a href=3D"mailto:konklone@gmail.com" target=3D"_blank">konklone@gmail.com> wrote:
A thousand times yes. Webfi= nger is the small beautiful idea that could, and this endless back-and-fort= h is sucking the life out of it.

I haven't been involved in the spec work, but I did do s= ome actual evangelism to the Rails community soon after Webfinger began= - 3 years ago. But that's all I did - once the spec slowed down= to a crawl and got lost in the weeds, I couldn't sustain that energy. = I'm sure I'm not the only one to be affected that way.

email -> metadata. Make it possible to own your iden= tity with your email. That's what we need.

-- = Eric


On Fri, Jun 14, 2013 at 1= :16 PM, Tim Bray <tbray@textuality.com> wrote:
<= /div>
I=E2=80=99ve been = following the endless back and forth on this with a feeling of despair... p= eople seem to be talking back and forth past each other.=C2=A0 Lots of peop= le think there are problems, Paul thinks there are no problems.

Back in the day, when I first heard of WebFinger, it was the simp= lest thing imaginable: Put in an email address and get back some pointers t= o IDPs or whatever.=C2=A0 Somewhere along the way, it morphed into getting = metadata about any Resource.=C2=A0 Which meant that you couldn=E2=80=99t ju= st use an email address, you had to turn it into a URI.

And thus the problem in the spec.=C2=A0 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.=C2=A0
But I don=E2=80=99t have a general-purpose problem about wanting metadata f= or arbitrary URIs.=C2=A0 I have several immediate pressing problems for ret= rieving metadata about=C2=A0 email addresses.=C2=A0=C2=A0 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 i= s

/.well-known/wf-lite?email=3Dbob@example.com

Which yields a JRD.= =C2=A0 You could still have the rel-selection and so on. It would be easy t= o understand. It would be self-contained. The draft would shrink in size dr= amatically. It would be instantly usable by OpenID Connect.=C2=A0 It would = probably sail through the IESG.


=C2=A0= -T

_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger


<= br clear=3D"all">

--

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--001a11c1ba4eecf6d504df20e65c-- From presnick@qti.qualcomm.com Fri Jun 14 11:01:16 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A1D21F9CD3 for ; Fri, 14 Jun 2013 11:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91joCvA1s+Ck for ; Fri, 14 Jun 2013 11:01:12 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id CC8B921F9CBD for ; Fri, 14 Jun 2013 11:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1371232871; x=1402768871; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ajOrHm9R3mVqnQwWbn9tSMKvUuOB6m3wLb1g8Yc43wM=; b=lpKGNSjxlMns48QlL3MuXA0FkF+tQkRdPV6MeWfwQCkSnSVBasw6GAFg IoHwi5VETZttZJSKMhcf8xks9mDiGvFzwTsFR4QDB8/i9oOIrTsCCR4ZS L5KFy5tGCsZkn99pvj5BiK/YmGlJhtR1IulEDrU8l/Bu8zO2ZOb7Pk6UH I=; X-IronPort-AV: E=Sophos;i="4.87,867,1363158000"; d="scan'208";a="56592259" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 14 Jun 2013 11:01:11 -0700 X-IronPort-AV: E=Sophos;i="4.87,867,1363158000"; d="scan'208";a="553684790" Received: from nasanexhc17.na.qualcomm.com ([10.45.158.129]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Jun 2013 11:01:07 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by NASANEXHC17.na.qualcomm.com (10.45.158.129) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 14 Jun 2013 11:00:47 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 14 Jun 2013 11:00:46 -0700 Message-ID: <51BB5A4A.20803@qti.qualcomm.com> Date: Fri, 14 Jun 2013 13:00:42 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Paul E. Jones" References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <51BB264C.3090602@qti.qualcomm.com> <00b501ce691a$f1a59570$d4f0c050$@packetizer.com> In-Reply-To: <00b501ce691a$f1a59570$d4f0c050$@packetizer.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: 'salvatore loreto' , 'webfinger' , draft-ietf-appsawg-webfinger@tools.ietf.org, 'Melvin Carvalho' Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 18:01:16 -0000 On 6/14/13 11:19 AM, Paul E. Jones wrote: >> Now, I am worried that you will disagree with my description of the >> particular protocol document above because you will say, "For any URI >> scheme, the WF server could return *any* information. So, for a jabber: >> URI, it could return either jabber configuration information or personal >> information about the jabber ID or anything else. For an acct: URI, it >> could return personal information, or it could return account >> configuration information." If that's the intent, then *that's* the >> semantic gap and a failing of WF: If the client can't find any >> documentation about how it can get back particular information, the >> protocol is a mere guessing game and not useful *except in closed >> environments with out-of-band agreements*. If you have a closed >> environment with an out of band agreement, you don't need a standard. >> > It is true that a WF server could return any information for a given URI > scheme, but that's because we have not specified anything that is to be > expected for any given URI, except "acct:". > Where in the document (or in the -acct-uri document) does it specify what is to be expected for the acct: URI? I can find nothing in the -webfinger document that is outside of an example, and certainly nothing with a MUST or a SHOULD or even a MAY, describing what is to be expected for a query on an acct: URI. Your statement appears to be incorrect. > We do not want to have the ambiguity you describe. Devices and applications > should not play guessing games. If one wishes to retrieve information about > a user's account, then "acct:" is to be used and that is recommended in the > WF spec. Where???? If the document said anything like this, I would not be pushing back. Do you think that section 4.5 is saying that? That's not nearly what I would call a specification. > Until there is a specification that says exactly what information to expect > if one were to use mailto: or jabber:, then one should not use those URIs. > That said, we do want WebFinger to accommodate those or any URI type. This > is to align with RFC 6415, but also because there might be something useful > defined for other URIs in the future, just as we're seeing 'acct' take > shape. > The document should say that the semantics of URI queries will be defined in other documents. The document should probably also set up an IANA registry of URI queries that can be used along with their specific meanings and pointers to the documents defining these things. Again, right now the client is flying completely blind. >>> Each URI queried might return the same or different information. The >>> specifications that rely on WebFinger would state explicitly what URI to >>> use. As an example, the OpenID Connect specs state that >>> acct:paulej@packetizer.com would be used to issue a WebFinger query. >>> >> That's the part that scares me. Let's say I'm not using OpenID Connect. >> Let's saying I'm using the "PeteID Info" protocol. Do I get to redefine >> what an acct: URI returns? If so, that's completely non-interoperable. >> > No, but you might define a new link type. > Let's skip link types. Let's talk about properties. What properties can I expect to get back for the acct: URI webfinger query? Where is this documented? For instance, how do I ask for the full name of the person associated with the account? Other than the example in 4.4.3, I find nothing in this document or the -acct-uri document that tells me what I can expect, or how I can even ask the question. > However, a client will know exactly what it is looking for and would ignore > link type is does not understand. Any client that implements PeteID would > be looking for a specific link type defined in your protocol spec. > [...] > For example, say you want my vcard. Presently, nothing > tells you how to find it. My server will return a "rel" of > "http://packetizer.com/rel/businesscard" and a type of "text/vcard". To be > useful, this would need to be standardized. There is an intent to > standardize this one and others (blog, avatar, profile-page, etc.). > That's my point. You haven't specified the use of the acct: URI at all in this document. You're leaving it for a future standard. You haven't even set up a registry of URIs that can be used for webfinger that would contain pointers to the standard that would define the semantics. There is not enough in this document to do anything interoperable with. > The 'acct' URI scheme is of this form: > > acctURI = "acct" ":" userpart "@" host > > (See draft-ietf-appsawg-acct-uri-04.) > > The intent was that the host portion would always be present. Twitter does > not use email addresses, so you never see "@twitter.com". But, if querying > for account information at twitter.com for user paul_e_jones, the URI would > be constructed as I showed it. > How am I (as a client) supposed to know that? I got a Twitter identifier. It doesn't have a domain portion. How am I supposed to figure out that I'm supposed to put "@twitter.com" after it? Why not "@twitter.net" or "@twitter.id"? Why not leave it out and use a URI that doesn't require a domain name? Where is this defined? (I *hope* not every service that wants to provide account information has to separately publish it's own rules for forming the query!) Skipping down... > It was definitely not the intent that clients would be guessing as to how to > perform a query. If a client is looking for my avatar, for example, the > client needs to know exactly what URI to use and what link type to look for. > That should be spelled out in the document that describes the link type. > > Any words you want to suggest for the WF spec to make that abundantly clear, > I'm happy to introduce. > I can work on that if desired. Tim Bray's idea would also make it abundantly clear. But what would also address the issue is some text which explicitly says, "This is a framework. How to query for particular purposes is in other documents. This document defines a registry where you can find the different use cases." And if you want, register "acct:". And give it some expected semantics. I think Tim is correct: This document is trying to boil the ocean. The problem is it's only providing instructions on what to do after the entire ocean is in the pot and the fire is going. It's short a few pieces of info. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From presnick@qti.qualcomm.com Fri Jun 14 11:02:10 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE0F21F9CD3 for ; Fri, 14 Jun 2013 11:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpL43vmRq+1z for ; Fri, 14 Jun 2013 11:02:06 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id CD68F21F9D19 for ; Fri, 14 Jun 2013 11:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1371232925; x=1402768925; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=WudCfjRVQpSPKtmQ+PENcR/OEHi9eGRkyN5F4MUW1og=; b=L2kEG4UKh6hgHLm6C2vWv6Vl03rjAYMLWohAOfuKU/GotrUs0TkkV2li 4fY82DLvjsLB3XRlATsOsEeVjz/Q6CmW/h5qpo5RTsTtUz8j7gkhm8reG W1sxMAvYEiftL/bn+jZbBYjTOwdTkPY3FQ/sH2OwIGgwBKQpjZRNZqkZJ w=; X-IronPort-AV: E=Sophos;i="4.87,867,1363158000"; d="scan'208";a="45032591" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP; 14 Jun 2013 11:02:02 -0700 X-IronPort-AV: E=Sophos;i="4.87,867,1363158000"; d="scan'208";a="553684933" Received: from nasanexhc12.na.qualcomm.com ([172.30.39.187]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Jun 2013 11:02:02 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc12.na.qualcomm.com (172.30.39.187) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 14 Jun 2013 11:02:02 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 14 Jun 2013 11:02:01 -0700 Message-ID: <51BB5A96.4000308@qti.qualcomm.com> Date: Fri, 14 Jun 2013 13:01:58 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <51BB264C.3090602@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: salvatore loreto , "Paul E. Jones" , Melvin Carvalho , "draft-ietf-appsawg-webfinger@tools.ietf.org" , webfinger Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 18:02:10 -0000 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 Qualcomm Technologies, Inc. - +1 (858)651-4478 From Michael.Jones@microsoft.com Fri Jun 14 11:20:16 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796C521F9922 for ; Fri, 14 Jun 2013 11:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEN-Wo+Ld2nl for ; Fri, 14 Jun 2013 11:20:11 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 2140A21F9C02 for ; Fri, 14 Jun 2013 11:20:06 -0700 (PDT) Received: from BY2FFO11FD015.protection.gbl (10.1.15.203) by BY2FFO11HUB036.protection.gbl (10.1.14.179) with Microsoft SMTP Server (TLS) id 15.0.707.0; Fri, 14 Jun 2013 18:20:05 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD015.mail.protection.outlook.com (10.1.14.131) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Fri, 14 Jun 2013 18:20:04 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.25]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0136.001; Fri, 14 Jun 2013 18:19:48 +0000 From: Mike Jones To: Tim Bray , "webfinger@ietf.org" Thread-Topic: [webfinger] Simplifying and unjamming WebFinger Thread-Index: AQHOaSL2oEEfbPpYmEis0pC9Nurt/Zk1g45w Date: Fri, 14 Jun 2013 18:19:47 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367855E7C@TK5EX14MBXC283.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367855E7CTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454002)(189002)(199002)(66066001)(20776003)(31966008)(49866001)(44976003)(63696002)(47446002)(50986001)(53806001)(80022001)(59766001)(6806003)(54356001)(76482001)(47736001)(69226001)(76796001)(65816001)(33656001)(79102001)(54316002)(51856001)(4396001)(55846006)(512874002)(47976001)(74706001)(16406001)(76786001)(56816003)(46102001)(74876001)(77096001)(56776001)(77982001)(81342001)(81542001)(74366001)(71186001)(16236675002)(74502001)(16297215003)(15202345002)(15395725003)(74662001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB036; H:TK5EX14HUBC102.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 08770259B4 Subject: Re: [webfinger] Simplifying and unjamming WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 18:20:16 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367855E7CTK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGltLCBJ4oCZbSBub3Qgc3VyZSB3aGVyZSB0aGUgZmVlbGluZyBvZiBkZXNwYWlyIGNvbWVzIGZy b20sIG90aGVyIHRoYW4gZmluaXNoaW5nIHRoaW5ncyBhbHdheXMgc2VlbXMgdG8gdGFrZSBsb25n ZXIgdGhhbiBpdCBzaG91bGQuICAoSSBhZ3JlZSB3aXRoIHlvdSB0aGVyZS4pDQoNClRoYXQgc2Fp ZCwgSSBjYW7igJl0IHN1cHBvcnQgY2hhbmdlcyB0byBXZWJGaW5nZXIgdGhhdCByZXN0cmljdCBp dOKAmXMgYXBwbGljYWJpbGl0eSB0byBvbmx5IGUtbWFpbCBhZGRyZXNzZXMsIGFuZCBpZiB5b3Xi gJlyZSBiZWluZyBjb25zaXN0ZW50IHdpdGggeW91ciBkZXNpcmUgdG8gaGF2ZSBPcGVuSUQgQ29u bmVjdCBzdWNjZWVkLCBuZWl0aGVyIGNhbiB5b3UuICBPcGVuSUQgQ29ubmVjdCB1c2VzIHRoZSBh YmlsaXR5IG9mIFdlYkZpbmdlciB0byByZXR1cm4gbWV0YWRhdGEgYWJvdXQgVVJJcyB0aGF0IGFy ZSBub3QgZS1tYWlsIGFkZHJlc3Nlcy4gIFNlZSBodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVu aWQtY29ubmVjdC1kaXNjb3ZlcnktMV8wLmh0bWwjVVJMU3ludGF4IGFuZCBodHRwOi8vb3Blbmlk Lm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1kaXNjb3ZlcnktMV8wLmh0bWwjaG9zdC5wb3J0LmV4 YW1wbGUgZm9yIGV4YW1wbGUgdXNlcyB3aXRoIFVSTHMuDQoNCk15IHRha2UtYXdheSBmcm9tIHRo aXMgaXMgdGhhdCB0aG9zZSBvZiB1cyB3aG8gY2FyZSBhYm91dCBmaW5pc2hpbmcgV2ViRmluZ2Vy IHNob3VsZCBkb3VibGUgZG93biBpbiBvdXIgcGFydGljaXBhdGlvbiB0byBjb25zdHJ1Y3RpdmVs eSBoZWxwIGZpbmlzaCB0aGUgSUVTRyByZXZpZXcgcHJvY2Vzcy4gIEkgd291bGQgb25seSBkZXNw YWlyIGlmIHdlIHdlbnQgYmFjayB0byB0aGUgZHJhd2luZyBib2FyZCwgYmVjYXVzZSB0aGF0IHdv dWxkIHNldCB1cyBiYWNrIGJ5IHllYXJzIGFuZCBkZXN0cm95IHRoZSBjaGFuY2Ugb2YgZmluaXNo aW5nIHNvbWV0aGluZyB0aGF04oCZcyBuZWFybHkgZG9uZSBhbmQgaGFzIGJlZW4gZGVtb25zdHJh dGVkIHRvIG1lZXQgb3BlbiBkaXNjb3ZlcnkgbmVlZHMgaW4gcHJhY3RpY2UuDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAt LSBNaWtlDQoNCkZyb206IHdlYmZpbmdlci1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86d2ViZmlu Z2VyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaW0gQnJheQ0KU2VudDogRnJpZGF5 LCBKdW5lIDE0LCAyMDEzIDEwOjE3IEFNDQpUbzogd2ViZmluZ2VyQGlldGYub3JnDQpTdWJqZWN0 OiBbd2ViZmluZ2VyXSBTaW1wbGlmeWluZyBhbmQgdW5qYW1taW5nIFdlYkZpbmdlcg0KDQpJ4oCZ dmUgYmVlbiBmb2xsb3dpbmcgdGhlIGVuZGxlc3MgYmFjayBhbmQgZm9ydGggb24gdGhpcyB3aXRo IGEgZmVlbGluZyBvZiBkZXNwYWlyLi4uIHBlb3BsZSBzZWVtIHRvIGJlIHRhbGtpbmcgYmFjayBh bmQgZm9ydGggcGFzdCBlYWNoIG90aGVyLiAgTG90cyBvZiBwZW9wbGUgdGhpbmsgdGhlcmUgYXJl IHByb2JsZW1zLCBQYXVsIHRoaW5rcyB0aGVyZSBhcmUgbm8gcHJvYmxlbXMuDQpCYWNrIGluIHRo ZSBkYXksIHdoZW4gSSBmaXJzdCBoZWFyZCBvZiBXZWJGaW5nZXIsIGl0IHdhcyB0aGUgc2ltcGxl c3QgdGhpbmcgaW1hZ2luYWJsZTogUHV0IGluIGFuIGVtYWlsIGFkZHJlc3MgYW5kIGdldCBiYWNr IHNvbWUgcG9pbnRlcnMgdG8gSURQcyBvciB3aGF0ZXZlci4gIFNvbWV3aGVyZSBhbG9uZyB0aGUg d2F5LCBpdCBtb3JwaGVkIGludG8gZ2V0dGluZyBtZXRhZGF0YSBhYm91dCBhbnkgUmVzb3VyY2Uu ICBXaGljaCBtZWFudCB0aGF0IHlvdSBjb3VsZG7igJl0IGp1c3QgdXNlIGFuIGVtYWlsIGFkZHJl c3MsIHlvdSBoYWQgdG8gdHVybiBpdCBpbnRvIGEgVVJJLg0KDQpBbmQgdGh1cyB0aGUgcHJvYmxl bSBpbiB0aGUgc3BlYy4gIFlvdSBoYXZlIHRvIGZpZ3VyZSBvdXQgd2hpY2ggVVJJIHNjaGVtZSB0 byB1c2UgKGFjY3Q6LCBtYWlsdG86LCBkZXZpY2U6KSBhbmQgdGhpcyB3aWxsIGFmZmVjdCB0aGUg b3V0cHV0IGluIHdheXMgdGhhdCBoYXZlIHRvIGJlIHNwZWNpZmllZCBpbiBPdGhlciBQbGFjZXMu DQpCdXQgSSBkb27igJl0IGhhdmUgYSBnZW5lcmFsLXB1cnBvc2UgcHJvYmxlbSBhYm91dCB3YW50 aW5nIG1ldGFkYXRhIGZvciBhcmJpdHJhcnkgVVJJcy4gIEkgaGF2ZSBzZXZlcmFsIGltbWVkaWF0 ZSBwcmVzc2luZyBwcm9ibGVtcyBmb3IgcmV0cmlldmluZyBtZXRhZGF0YSBhYm91dCAgZW1haWwg YWRkcmVzc2VzLiAgIFRoZSBmb3JtZXIgaXMgbm93IHNlcmlvdXNseSBnZXR0aW5nIGluIHRoZSB3 YXkgb2YgdGhlIGxhdHRlci4NClNvLCBob3cgYWJvdXQgYSBXZWJGaW5nZXIgbGlnaHQsIGluIHdo aWNoIHRoZSBmb3JtIG9mIHRoZSBxdWVyeSBpcw0KLy53ZWxsLWtub3duL3dmLWxpdGU/ZW1haWw9 Ym9iQGV4YW1wbGUuY29tPG1haWx0bzpib2JAZXhhbXBsZS5jb20+DQpXaGljaCB5aWVsZHMgYSBK UkQuICBZb3UgY291bGQgc3RpbGwgaGF2ZSB0aGUgcmVsLXNlbGVjdGlvbiBhbmQgc28gb24uIEl0 IHdvdWxkIGJlIGVhc3kgdG8gdW5kZXJzdGFuZC4gSXQgd291bGQgYmUgc2VsZi1jb250YWluZWQu IFRoZSBkcmFmdCB3b3VsZCBzaHJpbmsgaW4gc2l6ZSBkcmFtYXRpY2FsbHkuIEl0IHdvdWxkIGJl IGluc3RhbnRseSB1c2FibGUgYnkgT3BlbklEIENvbm5lY3QuICBJdCB3b3VsZCBwcm9iYWJseSBz YWlsIHRocm91Z2ggdGhlIElFU0cuDQoNCiAtVA0K --_000_4E1F6AAD24975D4BA5B168042967394367855E7CTK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGltLCBJ4oCZbSBub3Qg c3VyZSB3aGVyZSB0aGUgZmVlbGluZyBvZiBkZXNwYWlyIGNvbWVzIGZyb20sIG90aGVyIHRoYW4g ZmluaXNoaW5nIHRoaW5ncyBhbHdheXMgc2VlbXMgdG8gdGFrZSBsb25nZXIgdGhhbiBpdCBzaG91 bGQuJm5ic3A7IChJIGFncmVlIHdpdGggeW91IHRoZXJlLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYXQgc2FpZCwg SSBjYW7igJl0IHN1cHBvcnQgY2hhbmdlcyB0byBXZWJGaW5nZXIgdGhhdCByZXN0cmljdCBpdOKA mXMgYXBwbGljYWJpbGl0eSB0byBvbmx5IGUtbWFpbCBhZGRyZXNzZXMsIGFuZCBpZiB5b3XigJly ZSBiZWluZyBjb25zaXN0ZW50IHdpdGggeW91ciBkZXNpcmUgdG8NCiBoYXZlIE9wZW5JRCBDb25u ZWN0IHN1Y2NlZWQsIG5laXRoZXIgY2FuIHlvdS4mbmJzcDsgT3BlbklEIENvbm5lY3QgdXNlcyB0 aGUgYWJpbGl0eSBvZiBXZWJGaW5nZXIgdG8gcmV0dXJuIG1ldGFkYXRhIGFib3V0IFVSSXMgdGhh dCBhcmUgbm90IGUtbWFpbCBhZGRyZXNzZXMuJm5ic3A7IFNlZQ0KPGEgaHJlZj0iaHR0cDovL29w ZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtZGlzY292ZXJ5LTFfMC5odG1sI1VSTFN5bnRh eCI+aHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtZGlzY292ZXJ5LTFfMC5o dG1sI1VSTFN5bnRheDwvYT4gYW5kDQo8YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9v cGVuaWQtY29ubmVjdC1kaXNjb3ZlcnktMV8wLmh0bWwjaG9zdC5wb3J0LmV4YW1wbGUiPg0KaHR0 cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtZGlzY292ZXJ5LTFfMC5odG1sI2hv c3QucG9ydC5leGFtcGxlPC9hPiBmb3IgZXhhbXBsZSB1c2VzIHdpdGggVVJMcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pk15IHRha2UtYXdheSBmcm9tIHRoaXMgaXMgdGhhdCB0aG9zZSBvZiB1cyB3aG8gY2FyZSBhYm91 dCBmaW5pc2hpbmcgV2ViRmluZ2VyIHNob3VsZCBkb3VibGUgZG93biBpbiBvdXIgcGFydGljaXBh dGlvbiB0byBjb25zdHJ1Y3RpdmVseSBoZWxwIGZpbmlzaCB0aGUgSUVTRw0KIHJldmlldyBwcm9j ZXNzLiZuYnNwOyBJIHdvdWxkIG9ubHkgZGVzcGFpciBpZiB3ZSB3ZW50IGJhY2sgdG8gdGhlIGRy YXdpbmcgYm9hcmQsIGJlY2F1c2UgdGhhdCB3b3VsZCBzZXQgdXMgYmFjayBieSB5ZWFycyBhbmQg ZGVzdHJveSB0aGUgY2hhbmNlIG9mIGZpbmlzaGluZyBzb21ldGhpbmcgdGhhdOKAmXMgbmVhcmx5 IGRvbmUgYW5kIGhhcyBiZWVuIGRlbW9uc3RyYXRlZCB0byBtZWV0IG9wZW4gZGlzY292ZXJ5IG5l ZWRzIGluIHByYWN0aWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IHdlYmZpbmdlci1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86d2ViZmluZ2VyLWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRpbSBCcmF5PGJyPg0KPGI+U2VudDo8L2I+IEZy aWRheSwgSnVuZSAxNCwgMjAxMyAxMDoxNyBBTTxicj4NCjxiPlRvOjwvYj4gd2ViZmluZ2VyQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFt3ZWJmaW5nZXJdIFNpbXBsaWZ5aW5nIGFuZCB1 bmphbW1pbmcgV2ViRmluZ2VyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPknigJl2ZSBiZWVuIGZvbGxvd2luZyB0aGUgZW5k bGVzcyBiYWNrIGFuZCBmb3J0aCBvbiB0aGlzIHdpdGggYSBmZWVsaW5nIG9mIGRlc3BhaXIuLi4g cGVvcGxlIHNlZW0gdG8gYmUgdGFsa2luZyBiYWNrIGFuZCBmb3J0aCBwYXN0IGVhY2ggb3RoZXIu Jm5ic3A7IExvdHMgb2YgcGVvcGxlIHRoaW5rIHRoZXJlIGFyZSBwcm9ibGVtcywgUGF1bCB0aGlu a3MgdGhlcmUgYXJlIG5vDQogcHJvYmxlbXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkJhY2sgaW4gdGhlIGRheSwgd2hlbiBJIGZpcnN0IGhlYXJkIG9mIFdl YkZpbmdlciwgaXQgd2FzIHRoZSBzaW1wbGVzdCB0aGluZyBpbWFnaW5hYmxlOiBQdXQgaW4gYW4g ZW1haWwgYWRkcmVzcyBhbmQgZ2V0IGJhY2sgc29tZSBwb2ludGVycyB0byBJRFBzIG9yIHdoYXRl dmVyLiZuYnNwOyBTb21ld2hlcmUgYWxvbmcgdGhlIHdheSwgaXQgbW9ycGhlZCBpbnRvIGdldHRp bmcgbWV0YWRhdGEgYWJvdXQgYW55IFJlc291cmNlLiZuYnNwOw0KIFdoaWNoIG1lYW50IHRoYXQg eW91IGNvdWxkbuKAmXQganVzdCB1c2UgYW4gZW1haWwgYWRkcmVzcywgeW91IGhhZCB0byB0dXJu IGl0IGludG8gYSBVUkkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkFuZCB0aHVzIHRoZSBwcm9ibGVtIGluIHRoZSBz cGVjLiZuYnNwOyBZb3UgaGF2ZSB0byBmaWd1cmUgb3V0IHdoaWNoIFVSSSBzY2hlbWUgdG8gdXNl IChhY2N0OiwgbWFpbHRvOiwgZGV2aWNlOikgYW5kIHRoaXMgd2lsbCBhZmZlY3QgdGhlIG91dHB1 dCBpbiB3YXlzIHRoYXQgaGF2ZSB0byBiZSBzcGVjaWZpZWQgaW4gT3RoZXIgUGxhY2VzLiZuYnNw Ow0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+QnV0IEkgZG9u4oCZdCBoYXZlIGEgZ2VuZXJhbC1wdXJwb3Nl IHByb2JsZW0gYWJvdXQgd2FudGluZyBtZXRhZGF0YSBmb3IgYXJiaXRyYXJ5IFVSSXMuJm5ic3A7 IEkgaGF2ZSBzZXZlcmFsIGltbWVkaWF0ZSBwcmVzc2luZyBwcm9ibGVtcyBmb3IgcmV0cmlldmlu ZyBtZXRhZGF0YSBhYm91dCZuYnNwOyBlbWFpbCBhZGRyZXNzZXMuJm5ic3A7Jm5ic3A7IFRoZSBm b3JtZXIgaXMgbm93IHNlcmlvdXNseQ0KIGdldHRpbmcgaW4gdGhlIHdheSBvZiB0aGUgbGF0dGVy LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPlNvLCBob3cgYWJvdXQgYSBXZWJGaW5nZXIgbGlnaHQsIGluIHdo aWNoIHRoZSBmb3JtIG9mIHRoZSBxdWVyeSBpcw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Ly53ZWxsLWtu b3duL3dmLWxpdGU/ZW1haWw9PGEgaHJlZj0ibWFpbHRvOmJvYkBleGFtcGxlLmNvbSI+Ym9iQGV4 YW1wbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPldoaWNoIHlpZWxkcyBhIEpSRC4mbmJzcDsg WW91IGNvdWxkIHN0aWxsIGhhdmUgdGhlIHJlbC1zZWxlY3Rpb24gYW5kIHNvIG9uLiBJdCB3b3Vs ZCBiZSBlYXN5IHRvIHVuZGVyc3RhbmQuIEl0IHdvdWxkIGJlIHNlbGYtY29udGFpbmVkLiBUaGUg ZHJhZnQgd291bGQgc2hyaW5rIGluIHNpemUgZHJhbWF0aWNhbGx5LiBJdCB3b3VsZCBiZSBpbnN0 YW50bHkgdXNhYmxlIGJ5DQogT3BlbklEIENvbm5lY3QuJm5ic3A7IEl0IHdvdWxkIHByb2JhYmx5 IHNhaWwgdGhyb3VnaCB0aGUgSUVTRy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDstVDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B168042967394367855E7CTK5EX14MBXC283r_-- From melvincarvalho@gmail.com Fri Jun 14 11:31:50 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5EF21F9AE2 for ; Fri, 14 Jun 2013 11:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81EMhKogXgje for ; Fri, 14 Jun 2013 11:31:49 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4582921F9ABD for ; Fri, 14 Jun 2013 11:31:49 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id er20so822871lab.3 for ; Fri, 14 Jun 2013 11:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H59zmgwUeGZJU/CiF9bH0YKMa51GaJHVlMTLUQoJ0PI=; b=mOG+G1VNF3khAozmo/wMEN4mjJTC431760oDtMNIljpKtyHx/pJOzYsZjuHyXo1HBw QMB8y4JAErAjh8iv2rpXcZ9i0YwousxSk3qIIMO6My258oIMNVscsoNbScBbV+/vj5W3 pWKaotNPU58nq5nLQWvqSe7h8UkZoMFKrvHKrI04LD/q7sUSNEG/F3sgUIxL/tKfAJjP XSnO09Ynz8wDiJFi1IvaI7evyCd6FcobDo0mzwak8ko11OCtWZp1P+t1Mh+IS8Pc4T0o fdfjjzlnaCl60eWgi849o9lWLpyHPubUuyVvkvJ0hMfF0eSqdMmTJllSrOkWKK1INbBe bAKw== MIME-Version: 1.0 X-Received: by 10.152.87.81 with SMTP id v17mr1753772laz.1.1371234708207; Fri, 14 Jun 2013 11:31:48 -0700 (PDT) Received: by 10.112.2.8 with HTTP; Fri, 14 Jun 2013 11:31:48 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Jun 2013 20:31:48 +0200 Message-ID: From: Melvin Carvalho To: Tim Bray Content-Type: multipart/alternative; boundary=001a11c356e2afbe4404df21755e Cc: "webfinger@ietf.org" Subject: Re: [webfinger] Simplifying and unjamming WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 18:31:50 -0000 --001a11c356e2afbe4404df21755e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 14 June 2013 19:16, Tim Bray wrote: > I=92ve been following the endless back and forth on this with a feeling o= f > despair... people seem to be talking back and forth past each other. Lot= s > 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=92t 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 schem= e > to use (acct:, mailto:, device:) and this will affect the output in ways > that have to be specified in Other Places. > > But I don=92t have a general-purpose problem about wanting metadata for > arbitrary URIs. I have several immediate pressing problems for retrievin= g > 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=3Dbob@example.com > IMHO webfinger light would be: /.well-known/acct/bob The server MUST return JRD, but MAY return other representations. > > 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 > > --001a11c356e2afbe4404df21755e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On 14 June 2013 19:16, Tim Bray <tbray@textuality.com> wrote:
I=92ve 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.=A0 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 simp= lest thing imaginable: Put in an email address and get back some pointers t= o IDPs or whatever.=A0 Somewhere along the way, it morphed into getting met= adata about any Resource.=A0 Which meant that you couldn=92t just use an em= ail address, you had to turn it into a URI.

And thus the problem in the spec.=A0 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.=A0

But I don=92t have a general-purpose problem about wanting metadata for arb= itrary URIs.=A0 I have several immediate pressing problems for retrieving m= etadata about=A0 email addresses.=A0=A0 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 i= s

/.well-known/wf-lite?email=3Dbob@example.com

IMHO webfinger light would be:

/.well= -known/acct/bob

The server MUST return JRD, but MAY retur= n other representations.
=A0

Which yields a JRD.=A0 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 b= e instantly usable by OpenID Connect.=A0 It would probably sail through the= IESG.


=A0-T

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--001a11c356e2afbe4404df21755e-- From stpeter@stpeter.im Fri Jun 14 11:40:23 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D1321F9CCA for ; Fri, 14 Jun 2013 11:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IF9bT3O5jIKZ for ; Fri, 14 Jun 2013 11:40:18 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 16C6121F9C92 for ; Fri, 14 Jun 2013 11:40:18 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.59]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E900E412C6; Fri, 14 Jun 2013 12:53:57 -0600 (MDT) Message-ID: <51BB638E.9020703@stpeter.im> Date: Fri, 14 Jun 2013 12:40:14 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Pete Resnick References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <51BB264C.3090602@qti.qualcomm.com> <00b501ce691a$f1a59570$d4f0c050$@packetizer.com> <51BB5A4A.20803@qti.qualcomm.com> In-Reply-To: <51BB5A4A.20803@qti.qualcomm.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'salvatore loreto' , "Paul E. Jones" , 'Melvin Carvalho' , draft-ietf-appsawg-webfinger@tools.ietf.org, 'webfinger' Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 18:40:23 -0000 On 6/14/13 12:00 PM, Pete Resnick wrote: >>>> Each URI queried might return the same or different information. The >>>> specifications that rely on WebFinger would state explicitly what >>>> URI to >>>> use. As an example, the OpenID Connect specs state that >>>> acct:paulej@packetizer.com would be used to issue a WebFinger query. >>>> >>> That's the part that scares me. Let's say I'm not using OpenID Connect. >>> Let's saying I'm using the "PeteID Info" protocol. Do I get to redefine >>> what an acct: URI returns? If so, that's completely non-interoperable. >>> >> No, but you might define a new link type. >> > > Let's skip link types. Let's talk about properties. What properties can > I expect to get back for the acct: URI webfinger query? Where is this > documented? For instance, how do I ask for the full name of the person > associated with the account? Other than the example in 4.4.3, I find > nothing in this document or the -acct-uri document that tells me what I > can expect, or how I can even ask the question. WebFinger enables the client to say "please tell me more about this account", not "please tell me the full name of the person associated with this account". The response might include a pointer to a URI for the vCard, and if you retrieve that vCard it will probably contain the full name. But the WebFinger server just gives you pointers to data, not the data itself. Or so it seems to me. Peter -- Peter Saint-Andre https://stpeter.im/ From evan@e14n.com Fri Jun 14 18:08:19 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7379921E8082 for ; Fri, 14 Jun 2013 18:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-Psz8ZBRUzE for ; Fri, 14 Jun 2013 18:08:14 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id C308021E804E for ; Fri, 14 Jun 2013 18:08:14 -0700 (PDT) Received: from [192.168.1.24] (pool-64-223-125-116.burl.east.myfairpoint.net [64.223.125.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 9AF0E8D4534 for ; Sat, 15 Jun 2013 01:25:44 +0000 (UTC) Message-ID: <51BBBE7C.7080702@e14n.com> Date: Fri, 14 Jun 2013 21:08:12 -0400 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: webfinger References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <51BB264C.3090602@qti.qualcomm.com> <51BB5A96.4000308@qti.qualcomm.com> In-Reply-To: <51BB5A96.4000308@qti.qualcomm.com> Content-Type: multipart/alternative; boundary="------------090705090903000301020600" Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 01:08:19 -0000 This is a multi-part message in MIME format. --------------090705090903000301020600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 13-06-14 02:01 PM, Pete Resnick wrote: > 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 > * If you want to know the URL of the profile page of the user with account "evan" on server "e14n.com", * request the JRD at https://e14n.com/.well-known/webfinger?resource=acct:evan@e14n.com, * and find the link with rel "http://webfinger.net/rel/profile-page". What you do with that information (show it to someone, store the HTML in a database, whatever) is out of scope. Just as a point: Webfinger is already in use; the older LRDD version has been in use for years. It's great for finding endpoints for various APIs on different servers for different users. -Evan --------------090705090903000301020600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 13-06-14 02:01 PM, Pete Resnick wrote:
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

What you do with that information (show it to someone, store the HTML in a database, whatever) is out of scope.

Just as a point: Webfinger is already in use; the older LRDD version has been in use for years. It's great for finding endpoints for various APIs on different servers for different users.

-Evan

--------------090705090903000301020600-- From evan@e14n.com Fri Jun 14 18:09:28 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1393F21E8082 for ; Fri, 14 Jun 2013 18:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8-GUDLVesWK for ; Fri, 14 Jun 2013 18:09:22 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 4264C21E804E for ; Fri, 14 Jun 2013 18:09:22 -0700 (PDT) Received: from [192.168.1.24] (pool-64-223-125-116.burl.east.myfairpoint.net [64.223.125.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id CF1BF8D4534 for ; Sat, 15 Jun 2013 01:26:52 +0000 (UTC) Message-ID: <51BBBEC0.9050007@e14n.com> Date: Fri, 14 Jun 2013 21:09:20 -0400 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "webfinger@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [webfinger] Simplifying and unjamming WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 01:09:28 -0000 Trying to change the spec at this late date is not the way to get it to ship. I realize the intentions are good but there are probably better ways to get us to release this spec. -Evan From evan@e14n.com Fri Jun 14 18:20:57 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD69B21F8EB3 for ; Fri, 14 Jun 2013 18:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33ktbi5xItPv for ; Fri, 14 Jun 2013 18:20:52 -0700 (PDT) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 04AA721F8EAE for ; Fri, 14 Jun 2013 18:20:52 -0700 (PDT) Received: from [192.168.1.24] (pool-64-223-125-116.burl.east.myfairpoint.net [64.223.125.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 905338D48AB for ; Sat, 15 Jun 2013 01:38:22 +0000 (UTC) Message-ID: <51BBC172.8000903@e14n.com> Date: Fri, 14 Jun 2013 21:20:50 -0400 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: 'webfinger' References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <51BB264C.3090602@qti.qualcomm.com> In-Reply-To: <51BB264C.3090602@qti.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 01:20:57 -0000 I feel like this discussion is stalemated and I'd like to ask for it to be closed. What's the next step for coming to a decision here? -Evan From Michael.Jones@microsoft.com Fri Jun 14 18:43:48 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164AE21E8050 for ; Fri, 14 Jun 2013 18:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JBq7-jSlwvR for ; Fri, 14 Jun 2013 18:43:43 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id 7398421F9B44 for ; Fri, 14 Jun 2013 18:43:43 -0700 (PDT) Received: from BN1AFFO11FD019.protection.gbl (10.58.52.201) by BN1BFFO11HUB031.protection.gbl (10.58.53.141) with Microsoft SMTP Server (TLS) id 15.0.707.0; Sat, 15 Jun 2013 01:43:34 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD019.mail.protection.outlook.com (10.58.52.79) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Sat, 15 Jun 2013 01:43:34 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.25]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0136.001; Sat, 15 Jun 2013 01:43:16 +0000 From: Mike Jones To: Pete Resnick , Barry Leiba Thread-Topic: [webfinger] [appsawg] #12: Semantic gap for the client side Thread-Index: AQFNWMcWAQ1n5b22xM4UdUF6Zyw7DZoe/5QggABt4wCAAQbogIAVahYAgAC3BACAAM0pAIAALM4AgAARhwCAAHpTMA== Date: Sat, 15 Jun 2013 01:43:15 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436785E621@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <51BB264C.3090602@qti.qualcomm.com> <51BB5A96.4000308@qti.qualcomm.com> In-Reply-To: <51BB5A96.4000308@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(24454002)(377454002)(479174002)(13464003)(33656001)(74876001)(74366001)(6806003)(76786001)(47446002)(74706001)(31966008)(74662001)(76482001)(56816003)(69226001)(50986001)(65816001)(50466002)(54316002)(74502001)(66066001)(81542001)(56776001)(23726002)(77096001)(55846006)(81342001)(47736001)(47776003)(20776003)(76796001)(15202345002)(80022001)(15395725003)(63696002)(51856001)(4396001)(53806001)(47976001)(79102001)(77982001)(54356001)(16406001)(46102001)(49866001)(59766001)(46406003)(562404012); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB031; H:TK5EX14HUBC102.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 087894CD3C Cc: salvatore loreto , "Paul E. Jones" , "draft-ietf-appsawg-webfinger@tools.ietf.org" , Melvin Carvalho , webfinger Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 01:43:48 -0000 I've just read about two weeks of WebFinger mail (catching up after vacatio= n) have the following observations on how we might make progress towards cl= osing the issues being discussed. 1. Explicitly state that WebFinger is a framework and that the information= to be returned for specific "rel" link relation types for specific kinds o= f URIs is outside the scope of the specification, but is intended to be def= ined by other specifications. 2. We could establish a registry indexed by "rel" link relation values poi= nting to documents that define this information. For instance, we could th= en register the "rel" value "http://openid.net/specs/connect/1.0/issuer" an= d point it to http://openid.net/specs/openid-connect-discovery-1_0.html, wh= ich defines the meaning of that link relation. Other link relation definit= ions could then also use that registry. 3. Explicitly state that the link relation types that will be returned fro= m server when no "rel" parameter is used is entirely dependent upon the ser= vices supported by that host, and that, in the general case, clients must b= e prepared for the response to be the empty set for any particular resource= . 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 exampl= e - 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 apparen= tly-innocuous "copyright" and "author" examples from RFC 6415, if those wou= ld cause people less consternation. But the device and e-mail examples see= m to be generating more heat than light. 5. We could remove all references to and discussion of the acct: URI, sinc= e WebFinger actually has no dependency upon it. Other specifications can s= till specify that it be used in particular contexts with WebFinger, as Open= ID Connect does. 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 ve= ry well - enabling querying about a resource at a host, optionally narrowin= g the query to a particular kind of information of interest. Like OAuth, t= his 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. Cheers, -- Mike -----Original Message----- From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Beh= alf Of Pete Resnick Sent: Friday, June 14, 2013 11:02 AM To: Barry Leiba Cc: salvatore loreto; Paul E. Jones; Melvin Carvalho; draft-ietf-appsawg-we= bfinger@tools.ietf.org; 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=20 > explicitly specify everything that might be returned from a particular=20 > query. Another is to make sure that what gets returned is=20 > self-defining. The latter is the point of link relations -- the link=20 > relation tells you what the link means, so the recipient knows whether=20 > it understands this type or not, and, if it understands it, knows what=20 > its semantics are and what to do with it. That will make the response interoperable. It does not help me make the que= ry. 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 t= o do. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger From paulej@packetizer.com Fri Jun 14 18:47:19 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D88D21F9B44 for ; Fri, 14 Jun 2013 18:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0-w4PoGhIJH for ; Fri, 14 Jun 2013 18:47:14 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id BEE8421F9B07 for ; Fri, 14 Jun 2013 18:47:13 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r5F1l4Nq032127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Jun 2013 21:47:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1371260830; bh=gM00XqoBsxK85sfcN8/1trpnHBAfN/1RuM2CUOWogzw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=d/6DKgY39n4S2peqjSpL4NXNld/BMsWIdtMaVlABELtcnIuAvbeSBx8c8AD1j0XOC tIXd5/qu/YqZWcr2auUg+1PYaROHaQ7T99d3jjEoxlqm13Hi5PzLIt69w+sf9O6xbH OV8t3qw3s5lPgwBzJD7kdEX+EYq8PHI3qu+1vbF4= From: "Paul E. Jones" To: "'Pete Resnick'" References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <51BB264C.3090602@qti.qualcomm.com> <00b501ce691a$f1a59570$d4f0c050$@packetizer.com> <51BB5A4A.20803@qti.qualcomm.com> In-Reply-To: <51BB5A4A.20803@qti.qualcomm.com> Date: Fri, 14 Jun 2013 21:47:10 -0400 Message-ID: <01a701ce696a$42d07290$c87157b0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFNWMcWAQ1n5b22xM4UdUF6Zyw7DQLrgow+AwtEfrIBDFDY6AJtOwD0Amz+c8MCw8Ka+wHw8B8iAqfjo9GZnjkT8A== Content-Language: en-us Cc: 'salvatore loreto' , 'webfinger' , draft-ietf-appsawg-webfinger@tools.ietf.org, 'Melvin Carvalho' Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 01:47:19 -0000 Pete, > > It is true that a WF server could return any information for a given URI > > scheme, but that's because we have not specified anything that is to be > > expected for any given URI, except "acct:". > > > > Where in the document (or in the -acct-uri document) does it specify > what is to be expected for the acct: URI? I can find nothing in the > -webfinger document that is outside of an example, and certainly nothing > with a MUST or a SHOULD or even a MAY, describing what is to be expected > for a query on an acct: URI. Your statement appears to be incorrect. The WF spec only says if you want information about an account, the acct URI should be used. Now, what gets returned when querying an acct URI is not specified. The plan is that one might be able to get OpenID Connect info, an avatar, a vcard, etc. The OpenID Connect draft already spells that out. The others are to be specified in other drafts. Over time, there may be any number of new link relation types defined and intended for use with WebFinger. There are already requirements in place for that registry to have an RFC spelling things out. > > We do not want to have the ambiguity you describe. Devices and > applications > > should not play guessing games. If one wishes to retrieve information > about > > a user's account, then "acct:" is to be used and that is recommended in > the > > WF spec. > > Where???? Uhm... > If the document said anything like this, I would not be pushing back. Do > you think that section 4.5 is saying that? That's not nearly what I > would call a specification. Yeah... section 4.5. WF does not dictate the use of any URI. The group just wanted to encourage use of "acct" when querying a user's account at whatever service. Much of this relates to social network accounts, but certainly not limited to those. What URI is queried to get whatever information via WebFinger would be specified elsewhere. > > Until there is a specification that says exactly what information to > expect > > if one were to use mailto: or jabber:, then one should not use those > URIs. > > That said, we do want WebFinger to accommodate those or any URI type. > This > > is to align with RFC 6415, but also because there might be something > useful > > defined for other URIs in the future, just as we're seeing 'acct' take > > shape. > > > > The document should say that the semantics of URI queries will be > defined in other documents. The document should probably also set up an > IANA registry of URI queries that can be used along with their specific > meanings and pointers to the documents defining these things. I'll insert whatever words you want. Exactly what would you like me to put where? I'm not quite sure how we'd construct this registry. There is already the link relation registry. Now, which of those are for use in HTTP? Which ones for use in ATOM? Are there separate registries for those two protocols? > Again, right now the client is flying completely blind. Presently, that's largely true. However, there are community-defined link relation types out there that people just started using. Those would be returned if one queries a user's account URI. OpenID Connect has a formal spec that explains how an OpenID Connect client would perform a query. There is intent by a few folks to define a few other link relation types for use with WebFinger once the base spec is done. Those would also spell out that queries would be via the acct URI. The aggsrv group, if it elected to use WebFinger, would specify use of acct or perhaps smtp, jabber, etc. That's really their call and would be documented in their specs. > >>> Each URI queried might return the same or different information. The > >>> specifications that rely on WebFinger would state explicitly what URI > to > >>> use. As an example, the OpenID Connect specs state that > >>> acct:paulej@packetizer.com would be used to issue a WebFinger query. > >>> > >> That's the part that scares me. Let's say I'm not using OpenID Connect. > >> Let's saying I'm using the "PeteID Info" protocol. Do I get to redefine > >> what an acct: URI returns? If so, that's completely non-interoperable. > >> > > No, but you might define a new link type. > > > > Let's skip link types. Let's talk about properties. What properties can > I expect to get back for the acct: URI webfinger query? Where is this > documented? For instance, how do I ask for the full name of the person > associated with the account? Other than the example in 4.4.3, I find > nothing in this document or the -acct-uri document that tells me what I > can expect, or how I can even ask the question. The WF spec allows for URI-level properties and link-level properties. Property types are fully-qualified URIs and the property name (URI) and value would be defined in whatever specification wanted to define them. As Peter responded, the user's name is likely to be found via a link that points to a vcard or xcard. I would personally like to define properties at the account level that are the user's names, but it would be redundant with the vcard. Still, it might be useful so that a client would not have to grab a vcard and parse it. This would be a subject for discussion at some later point. For now, properties are not defined anywhere. The mail server configuration example shows the intent of properties. If there was a spec that defined how to provision an email client, it would detail the link relation type, specify the URI scheme to use to query for the JRD, and define any properties associated with that link type. > > However, a client will know exactly what it is looking for and would > ignore > > link type is does not understand. Any client that implements PeteID > would > > be looking for a specific link type defined in your protocol spec. > > [...] > > For example, say you want my vcard. Presently, nothing > > tells you how to find it. My server will return a "rel" of > > "http://packetizer.com/rel/businesscard" and a type of "text/vcard". To > be > > useful, this would need to be standardized. There is an intent to > > standardize this one and others (blog, avatar, profile-page, etc.). > > > > That's my point. You haven't specified the use of the acct: URI at all > in this document. You're leaving it for a future standard. You haven't > even set up a registry of URIs that can be used for webfinger that would > contain pointers to the standard that would define the semantics. There > is not enough in this document to do anything interoperable with. The acct URI scheme is recommended. It used to be a part of this draft, even, but it was pulled out separately since there was belief it has broader value. Any URI may be used with WebFinger, so what would the registry tell us? Let's say I am writing a blogging application and I want names and faces of users visiting the blog to appear on the site. As part of the registration, I might ask you to enter the account identifier from which to get your name and face. This might be your email address, your facebook ID, Twitter ID, or whatever. The client I write on the blog site create a URI in the form acct:user@domain, because the two pieces of information are link relation types defined for use with the acct URI. I know this, because there will be an RFC written that says so. The link relation types in that to-be-written document are registered with IANA, just as link relation types for HTTP and ATOM are registered there. > > The 'acct' URI scheme is of this form: > > > > acctURI = "acct" ":" userpart "@" host > > > > (See draft-ietf-appsawg-acct-uri-04.) > > > > The intent was that the host portion would always be present. Twitter > does > > not use email addresses, so you never see "@twitter.com". But, if > querying > > for account information at twitter.com for user paul_e_jones, the URI > would > > be constructed as I showed it. > > > > How am I (as a client) supposed to know that? I got a Twitter > identifier. It doesn't have a domain portion. How am I supposed to > figure out that I'm supposed to put "@twitter.com" after it? Why not > "@twitter.net" or "@twitter.id"? Why not leave it out and use a URI that > doesn't require a domain name? Where is this defined? (I *hope* not > every service that wants to provide account information has to > separately publish it's own rules for forming the query!) >From the "acct" URI spec: Thus a particular 'acct' URI is formed by setting the "user" portion to the user's account name at the service provider and by setting the "host" portion to the DNS domain name of the service provider. That's the guidance. I assume Twitter's account IDs do not start with an '@'. It's not present in the URI when visiting a person's Twitter page. Thus, I assume the '@' is just a means of indicating to the Twitter platform that the following is an account ID vs. regular text when tweeting. Given the above and then yet-to-be-written RFCs (that defines the link relation types) to perform WF queries, it should be possible to visit the blog I described above, tell it your Twitter account (and I'd even write it to be smart enough to auto-convert @paul_e_jones to acct:paul_e_jones@twitter.com), and it would query Twitter to see if it can get your name and picture. > Skipping down... > > > It was definitely not the intent that clients would be guessing as to > how to > > perform a query. If a client is looking for my avatar, for example, the > > client needs to know exactly what URI to use and what link type to look > for. > > That should be spelled out in the document that describes the link type. > > > > Any words you want to suggest for the WF spec to make that abundantly > clear, > > I'm happy to introduce. > > > > I can work on that if desired. Tim Bray's idea would also make it > abundantly clear. But what would also address the issue is some text > which explicitly says, "This is a framework. How to query for particular > purposes is in other documents. This document defines a registry where > you can find the different use cases." And if you want, register > "acct:". And give it some expected semantics. Is HTTP (RFC 2616) a framework document? It defines the syntax of the request and response, but does not define the payload. WebFinger is more-or-less the same thing: it defines that the protocol on the wire looks like going to the server and from the server. But, it does not define what a client will query for, nor does it define the payload to be returned. The link relation registry already exists, so I'm not sure we need another registry. We may need a registry for properties, though, if any properties are to be defined with an IETF-specified URI. Presently, we've not discussed defining any properties (aside from my mention above). In any case, I'll add whatever text you think is appropriate. > I think Tim is correct: This document is trying to boil the ocean. The > problem is it's only providing instructions on what to do after the > entire ocean is in the pot and the fire is going. It's short a few > pieces of info. Allowing use of any URI is not boiling the ocean, IMO. The only issue, I think, is that there are missing pieces. The WF spec does not describe what set of links is returned if one issues a query for any particular URI. That was deliberately left for other specifications. I would venture to guess that the 'acct' URI will be what is used most with WF, because of the interest from social networking circles. However, we didn't want to limit it to that one URI scheme. Some have stated, for example, that they'd like to use the 'tel' URI with WF. I can appreciate how one might use that as a means of determining which of several ENUM registries to query, for example. Some are already using http URIs with WebFinger, too (e.g. http://openid.net/specs/openid-connect-discovery-1_0.html#URLSyntax). And if we want to know the author of a web page, querying a server and passing the URI of the web page could result in returning a link with the "author" link relation type, perhaps also a "copyright", etc. (Those are examples in RFC 6415.) I think boiling the ocean would have been defining all these use cases in the WF spec. We did not want to do that. Instead, we define the base protocol and then other specs define how to use WF to get certain information. Paul From gsalguei@cisco.com Fri Jun 14 18:50:22 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA7021F99A2 for ; Fri, 14 Jun 2013 18:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jagsukFGES4f for ; Fri, 14 Jun 2013 18:50:18 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD2621F999E for ; Fri, 14 Jun 2013 18:50:18 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5F1oHGn001589 for ; Fri, 14 Jun 2013 21:50:17 -0400 (EDT) Received: from rtp-gsalguei-8915.cisco.com (rtp-gsalguei-8915.cisco.com [10.116.132.54]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5F1oHA7006181; Fri, 14 Jun 2013 21:50:17 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Gonzalo Salgueiro In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367855E7C@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 14 Jun 2013 21:50:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B168042967394367855E7C@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1508) Cc: webfinger@ietf.org, Tim Bray Subject: Re: [webfinger] Simplifying and unjamming WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 01:50:22 -0000 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.=20 Gonzalo On Jun 14, 2013, at 2:19 PM, Mike Jones = wrote: > Tim, I=92m 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.) > =20 > That said, I can=92t support changes to WebFinger that restrict it=92s = applicability to only e-mail addresses, and if you=92re 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.exampl= e for example uses with URLs. > =20 > 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=92s nearly done and has been = demonstrated to meet open discovery needs in practice. > =20 > -- = Mike > =20 > 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 > =20 > I=92ve 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. >=20 > 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=92t just use = an email address, you had to turn it into a URI. > =20 > 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.=20 >=20 > But I don=92t 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. >=20 > So, how about a WebFinger light, in which the form of the query is >=20 > /.well-known/wf-lite?email=3Dbob@example.com >=20 > 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. >=20 > =20 > -T > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger From konklone@gmail.com Fri Jun 14 20:03:58 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7699E21F9B52 for ; Fri, 14 Jun 2013 20:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kh8qRkN2hhii for ; Fri, 14 Jun 2013 20:03:57 -0700 (PDT) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 89EB221F9B3C for ; Fri, 14 Jun 2013 20:03:56 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id z15so690832ead.21 for ; Fri, 14 Jun 2013 20:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=opPS65t9Jecc5Wq6bBMsLTZmJH2xA9lFoL/A2V4HQTg=; b=aM5Yy2HC818cRfo/EN0dzkijafhzbzLojAK8I8P+TPHex6xWs9qFi5TOVithlEJQp9 nqhA8YRnr+Ra81MxCW6Iz91dhc2obU+IY9A875U6Vq/thGuPrf+LEIQsXOT+E3FfEwur iC0r2kjZ37mJFXChlCSE/KVdkkSTBLNi+WBIC+jE0XAyiGxwVMGEsvhZiCQFSOVS6lEL 7mzDaZisVzlM6ca+DfamUQyuDacIAas0kXIUHhSH49oMRu0jfyUYQ4q6YHWnydEQ0RDu skwgvASB7WLZi9pNlO2FR+ALv2TD0JYasSbT2fHRys1hFi3VpfIYRy89qnNXK6QeeJYo 8/Kw== X-Received: by 10.15.43.203 with SMTP id x51mr6083329eev.144.1371265435617; Fri, 14 Jun 2013 20:03:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.72.144 with HTTP; Fri, 14 Jun 2013 20:03:15 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394367855E7C@TK5EX14MBXC283.redmond.corp.microsoft.com> From: Eric Mill Date: Fri, 14 Jun 2013 23:03:15 -0400 Message-ID: To: Gonzalo Salgueiro Content-Type: multipart/alternative; boundary=089e0160c4602eef6204df289d5c Cc: "webfinger@ietf.org" , Mike Jones , Tim Bray Subject: Re: [webfinger] Simplifying and unjamming WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 03:03:58 -0000 --089e0160c4602eef6204df289d5c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In that case, how about a deadline? On Fri, Jun 14, 2013 at 9:50 PM, Gonzalo Salgueiro wrot= e: > 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 ver= y > 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 > wrote: > > > Tim, I=92m not sure where the feeling of despair comes from, other than > finishing things always seems to take longer than it should. (I agree wi= th > you there.) > > > > That said, I can=92t support changes to WebFinger that restrict it=92s > applicability to only e-mail addresses, and if you=92re 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.examp= lefor 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 th= e > chance of finishing something that=92s nearly done and has been demonstra= ted > 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=92ve 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. Lot= s > 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=92t 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=92t have a general-purpose problem about wanting metadata for > arbitrary URIs. I have several immediate pressing problems for retrievin= g > 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=3Dbob@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 wou= ld > 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 > --=20 @konklone | konklone.com | sunlightfoundation.com | awesomefoundation.org --089e0160c4602eef6204df289d5c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
In that case, how about a deadline?


On Fri, Jun 14, 2013 at 9:50 P= M, Gonzalo Salgueiro <gsalguei@cisco.com> wrote:
Finally, a voice of reason has spoken. =A0Th= anks, Mike!

When we are in the process of clearing the final two DISCUSSes in IESG revi= ew is not the time to start over from scratch. =A0We spent years of very lo= ng discussion coming to consensus on the document we have now....one, I mig= ht add, that we were all supportive of. =A0Pete Resnick is asking some reas= onable questions regarding the document providing enough client instruction= on URI selection for the purposes of information retrieval. =A0Let's j= ust decide if we need additional text and,when possible, offer it concretel= y to speed things along.

Gonzalo


On Jun 14, 2013, at 2:19 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

> Tim, I=92m not sure where the feeling of despair comes from, other tha= n finishing things always seems to take longer than it should. =A0(I agree = with you there.)
>
> That said, I can=92t support changes to WebFinger that restrict it=92s= applicability to only e-mail addresses, and if you=92re being consistent w= ith your desire to have OpenID Connect succeed, neither can you. =A0OpenID = Connect uses the ability of WebFinger to return metadata about URIs that ar= e not e-mail addresses. =A0See http://openid.net/spe= cs/openid-connect-discovery-1_0.html#URLSyntax and http://openid.net/specs/openid-connect-discovery-1_0.html#host.= port.example for example uses with URLs.
>
> My take-away from this is that those of us who care about finishing We= bFinger should double down in our participation to constructively help fini= sh the IESG review process. =A0I would only despair if we went back to the = drawing board, because that would set us back by years and destroy the chan= ce of finishing something that=92s nearly done and has been demonstrated to= meet open discovery needs in practice.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike
>
> From: webfinger-bounces@= ietf.org [mailto:webfinge= r-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=92ve been following the endless back and forth on this with a feelin= g of despair... people seem to be talking back and forth past each other. = =A0Lots of people think there are problems, Paul thinks there are no proble= ms.
>
> 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 IDP= s or whatever. =A0Somewhere along the way, it morphed into getting metadata= about any Resource. =A0Which meant that you couldn=92t just use an email a= ddress, you had to turn it into a URI.
>
> And thus the problem in the spec. =A0You 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=92t have a general-purpose problem about wanting metadata fo= r arbitrary URIs. =A0I have several immediate pressing problems for retriev= ing metadata about =A0email addresses. =A0 The former is now seriously gett= ing 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=3Dbob@ex= ample.com
>
> Which yields a JRD. =A0You could still have the rel-selection and so o= n. It would be easy to understand. It would be self-contained. The draft wo= uld shrink in size dramatically. It would be instantly usable by OpenID Con= nect. =A0It would probably sail through the IESG.
>
>
> =A0-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 | konklone.com |=A0<= a href=3D"http://sunlightfoundation.com" target=3D"_blank">sunlightfoundati= on.com=A0| a= wesomefoundation.org
--089e0160c4602eef6204df289d5c-- From stpeter@stpeter.im Fri Jun 14 20:07:04 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD7821E8083 for ; Fri, 14 Jun 2013 20:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLwgLQYpNSoP for ; Fri, 14 Jun 2013 20:06:59 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DFB0021E804C for ; Fri, 14 Jun 2013 20:06:56 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E4A1F412C7; Fri, 14 Jun 2013 21:20:33 -0600 (MDT) Message-ID: <51BBDA49.3050303@stpeter.im> Date: Fri, 14 Jun 2013 21:06:49 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Mike Jones References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <51BB264C.3090602@qti.qualcomm.com> <51BB5A96.4000308@qti.qualcomm.com> <4E1F6AAD24975D4BA5B16804296739436785E621@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436785E621@TK5EX14MBXC283.redmond.corp.microsoft.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pete Resnick , "draft-ietf-appsawg-webfinger@tools.ietf.org" , "Paul E. Jones" , Melvin Carvalho , salvatore loreto , webfinger , Barry Leiba Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 03:07:04 -0000 On 6/14/13 7:43 PM, Mike Jones wrote: > I've just read about two weeks of WebFinger mail (catching up after > vacation) You're a good man. :-) > have the following observations on how we might make > progress towards closing the issues being discussed. > > 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. Agreed. > 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. That seems quite sensible. > 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. I'll need to think about that more. > 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. Yes. > 5. We could remove all references to and discussion of the acct: > URI, since WebFinger actually has no dependency upon it. I think that would be helpful, because in the off-list email threads with the IESG there is a lot of confusion about the meaning of an acct URI, and much of that confusion stems from (I think) a misunderstanding of WebFinger's relationship to acct URIs and a conflation of the semantic meaning that comes from WebFinger and the semantic meaning that comes from acct URIs. > Other > specifications can still specify that it be used in particular > contexts with WebFinger, as OpenID Connect does. Right. > 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. I'd hate to remove examples that are helpful, but if some of the examples are confusing (and I think they are, because they are speculative rather than examples that reflect existing usage or WebFinger-based applications) then let's remove them. > Likewise, if acct: is standing between us and > finishing, it should go too. Works for me. I didn't conceive of acct URIs, I'm just trying to get them documented properly. > 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. Thanks for the productive message. Let's get this done. Peter -- Peter Saint-Andre https://stpeter.im/ From gsalguei@cisco.com Fri Jun 14 20:15:43 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E65E21E804C for ; Fri, 14 Jun 2013 20:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mwq1ovEO4ep0 for ; Fri, 14 Jun 2013 20:15:39 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 844DA11E80A5 for ; Fri, 14 Jun 2013 20:15:39 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5F3FbDG009305 for ; Fri, 14 Jun 2013 23:15:38 -0400 (EDT) Received: from rtp-gsalguei-8915.cisco.com (rtp-gsalguei-8915.cisco.com [10.116.132.54]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5F3FUvM009897; Fri, 14 Jun 2013 23:15:30 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Gonzalo Salgueiro In-Reply-To: Date: Fri, 14 Jun 2013 23:15:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B168042967394367855E7C@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Eric Mill X-Mailer: Apple Mail (2.1508) Cc: webfinger@ietf.org, Mike Jones , Tim Bray Subject: Re: [webfinger] Simplifying and unjamming WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 03:15:43 -0000 Eric -=20 I'm a huge advocate of increased agility in the IETF standardization = process and I certainly wish we had the luxury of a deadline, but I'm = afraid that IESG review doesn't work that way. We're going to have roll = up our sleeves and do it the old-fashioned way...come to an agreement = that satisfies the ADs, yet retains our agreed upon consensus of what = the Webfinger protocol/framework should be. Mike's most recent email = providing different options to break this gridlock is a great start. Gonzalo On Jun 14, 2013, at 11:03 PM, Eric Mill wrote: > In that case, how about a deadline? >=20 >=20 > On Fri, Jun 14, 2013 at 9:50 PM, Gonzalo Salgueiro = wrote: > Finally, a voice of reason has spoken. Thanks, Mike! >=20 > 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. >=20 > Gonzalo >=20 >=20 > On Jun 14, 2013, at 2:19 PM, Mike Jones = wrote: >=20 > > Tim, I=92m 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=92t support changes to WebFinger that restrict it=92s= applicability to only e-mail addresses, and if you=92re 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.exampl= e for 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=92s 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=92ve 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=92t = 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=92t 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=3Dbob@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 >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger >=20 >=20 >=20 > --=20 > @konklone | konklone.com | sunlightfoundation.com | = awesomefoundation.org > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger From gsalguei@cisco.com Fri Jun 14 21:21:53 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD49221F9675 for ; Fri, 14 Jun 2013 21:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YL9-1DFocagC for ; Fri, 14 Jun 2013 21:21:50 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id C08D321F9B28 for ; Fri, 14 Jun 2013 21:21:48 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5F4Lm1w015726 for ; Sat, 15 Jun 2013 00:21:48 -0400 (EDT) Received: from rtp-gsalguei-8915.cisco.com (rtp-gsalguei-8915.cisco.com [10.116.132.54]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5F4Li6B027611; Sat, 15 Jun 2013 00:21:44 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Gonzalo Salgueiro In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436785E621@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Sat, 15 Jun 2013 00:21:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3ACB44C8-7A06-4D7D-90F4-679197769A67@cisco.com> References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <51BB264C.3090602@qti.qualcomm.com> <51BB5A96.4000308@qti.qualcomm.com> <4E1F6AAD24975D4BA5B16804296739436785E621@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1508) Cc: Pete Resnick , draft-ietf-appsawg-webfinger@tools.ietf.org, Paul Jones , Melvin Carvalho , Salvatore Loreto , webfinger , Barry Leiba Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 04:21:53 -0000 Mike -=20 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 = 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 ;-) >=20 > 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. >=20 > 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. >=20 > 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? >=20 > 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. =20 BTW - The addition of a supplementary OpenID Connect example seems = reasonable and helpful. >=20 > 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... >=20 > 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. >=20 > 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. >=20 > Let's focus our energies on deciding what the best next steps are to = finish in a timely manner. Amen. Thanks, Gonzalo >=20 > Cheers, > -- Mike >=20 > -----Original Message----- > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] = On Behalf Of Pete Resnick > Sent: Friday, June 14, 2013 11:02 AM > To: Barry Leiba > Cc: salvatore loreto; Paul E. Jones; Melvin Carvalho; = draft-ietf-appsawg-webfinger@tools.ietf.org; webfinger > Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client = side >=20 > On 6/14/13 11:59 AM, Barry Leiba wrote: >=20 >> There are two ways we can get interoperability from this. One is to=20= >> explicitly specify everything that might be returned from a = particular=20 >> query. Another is to make sure that what gets returned is=20 >> self-defining. The latter is the point of link relations -- the link=20= >> relation tells you what the link means, so the recipient knows = whether=20 >> it understands this type or not, and, if it understands it, knows = what=20 >> its semantics are and what to do with it. >=20 > That will make the response interoperable. It does not help me make = the query. >=20 > 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. >=20 > pr >=20 > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 >=20 > _______________________________________________ > 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 >=20 From laurentwalter.goix@telecomitalia.it Wed Jun 19 06:01:45 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E40521F9BEB for ; Wed, 19 Jun 2013 06:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIZ9E2LlTTtH for ; Wed, 19 Jun 2013 06:01:41 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id AE9BA21F9BAF for ; Wed, 19 Jun 2013 06:01:40 -0700 (PDT) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 19 Jun 2013 15:01:31 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Wed, 19 Jun 2013 15:01:31 +0200 From: Goix Laurent Walter To: Gonzalo Salgueiro , Mike Jones Date: Wed, 19 Jun 2013 15:00:26 +0200 Thread-Topic: [webfinger] [appsawg] #12: Semantic gap for the client side Thread-Index: Ac5pf+FdiP2zRfEJTDiTGugc20TN0gDauSMQ Message-ID: References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <51BB264C.3090602@qti.qualcomm.com> <51BB5A96.4000308@qti.qualcomm.com> <4E1F6AAD24975D4BA5B16804296739436785E621@TK5EX14MBXC283.redmond.corp.microsoft.com> <3ACB44C8-7A06-4D7D-90F4-679197769A67@cisco.com> In-Reply-To: <3ACB44C8-7A06-4D7D-90F4-679197769A67@cisco.com> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-cr-hashedpuzzle: DHpl Uizq d9fq goHb jgvN mLcc uR8M 5sy3 AAaXxQ== ABj+0Q== ACj/9w== AI6xvg== AJW6Gg== AJ5lsQ== ALFHKA== ALMKYQ==; 9; YgBhAHIAcgB5AGwAZQBpAGIAYQBAAGMAbwBtAHAAdQB0AGUAcgAuAG8AcgBnADsAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGEAcABwAHMAYQB3AGcALQB3AGUAYgBmAGkAbgBnAGUAcgBAAHQAbwBvAGwAcwAuAGkAZQB0AGYALgBvAHIAZwA7AGcAcwBhAGwAZwB1AGUAaQBAAGMAaQBzAGMAbwAuAGMAbwBtADsAbQBlAGwAdgBpAG4AYwBhAHIAdgBhAGwAaABvAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBtAGkAYwBoAGEAZQBsAC4AagBvAG4AZQBzAEAAbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQA7AHAAYQB1AGwAZQBqAEAAcABhAGMAawBlAHQAaQB6AGUAcgAuAGMAbwBtADsAcAByAGUAcwBuAGkAYwBrAEAAcQB0AGkALgBxAHUAYQBsAGMAbwBtAG0ALgBjAG8AbQA7AHMAYQBsAHYAYQB0AG8AcgBlAC4AbABvAHIAZQB0AG8AQABlAHIAaQBjAHMAcwBvAG4ALgBjAG8AbQA7AHcAZQBiAGYAaQBuAGcAZQByAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {506D3CE5-9FD9-4B51-ACCA-87B9F08834BF}; bABhAHUAcgBlAG4AdAB3AGEAbAB0AGUAcgAuAGcAbwBpAHgAQAB0AGUAbABlAGMAbwBtAGkAdABhAGwAaQBhAC4AaQB0AA==; Wed, 19 Jun 2013 13:00:26 GMT; UgA6ACAAWwB3AGUAYgBmAGkAbgBnAGUAcgBdACAAWwBhAHAAcABzAGEAdwBnAF0AIAAjADEAMgA6ACAAUwBlAG0AYQBuAHQAaQBjACAAZwBhAHAAIABmAG8AcgAgAHQAaABlACAAYwBsAGkAZQBuAHQAIABzAGkAZABlAA== x-cr-puzzleid: {506D3CE5-9FD9-4B51-ACCA-87B9F08834BF} acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: multipart/mixed; boundary="_002_A09A9E0A4B9C654E8672D1DC003633AE53D43B077AGRFMBX704BA02_" MIME-Version: 1.0 Cc: Pete Resnick , "draft-ietf-appsawg-webfinger@tools.ietf.org" , Paul Jones , Melvin Carvalho , Salvatore Loreto , webfinger , Barry Leiba Subject: [webfinger] R: [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 13:01:45 -0000 --_002_A09A9E0A4B9C654E8672D1DC003633AE53D43B077AGRFMBX704BA02_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I am catching up as well a bit late and would like to move things forward f= or those realistic use cases. Some comments inline... [snip] > > > > 1. Explicitly state that WebFinger is a framework and that the informa= tion > 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 def= ined > by other specifications. > > I'm okay with this, so long as we keep clear that in addition to a framew= ork > there is a real protocol definition here that clearly prescribes on-the-w= ire > behavior. [walter] +1. Actually OMA SNEW is another spec (besides OpenID Connect) tha= t leverages webfinger for (mobile) federated social networks. I re-attach a= mail I sent a couple of months ago with a related example after some discu= ssion already on the examples section. (feedback/revision is welcome) > > > > 2. We could establish a registry indexed by "rel" link relation values > pointing to documents that define this information. For instance, we cou= ld > 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, wh= ich > defines the meaning of that link relation. Other link relation definitio= ns > could then also use that registry. > > Sure. This is a simple step to take to provide clarity on existing uses o= f WF. [walter] link rel registry already exist at IANA and we should probably lev= erage on that, which is also useful for other contexts such as embedding su= ch link rels in atom feeds or html pages for example. But surely 1) we can = define new official link rel tokens that fit concrete use cases, 2) we may = have an informal registry for the link rel URIs (and could use the one from= Paul on packetizer as basis) [snip] > > > > 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 resou= rce > 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 expedi= tious > resolution to this stalemate I'd be willing to remove the two examples gi= ving > problems, though I'd warn that we do have tangible useful information los= s > (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 resurrec= t > these deleted examples. > > BTW - The addition of a supplementary OpenID Connect example seems reason= able > and helpful. [walter] i would really avoid removing the whole example section. This is v= ery much helpful for developers to understand the protocol, and the documen= t format (we re-defined JRD in this doc so it makes a lot of sense to show = examples of this *new* data model). Besides openid connect I am proposing t= he oma snew case, but one or more fictitious examples that possibly don't h= arm any community (no email config, no aggrsrv, etc) and that moreover coul= d better showcase the expressiveness of JRD would be useful IMHO. > > > > 5. We could remove all references to and discussion of the acct: URI, = since > WebFinger actually has no dependency upon it. Other specifications can s= till > 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 wer= e 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 shoul= d go > too. [walter] webfinger was originally very much motivated by "account identifie= rs" (then became acct: URI) and as such would deserve a mention as it curre= ntly states. I don't believe that its mention limits the proposal (it clear= ly states that any other URI scheme is valid) but clarifies the original in= tent. I do not see why it would help removing it, but if it makes it ship f= aster... walter Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. --_002_A09A9E0A4B9C654E8672D1DC003633AE53D43B077AGRFMBX704BA02_ Content-Type: message/rfc822 Received: from TELHUB003BA020.telecomitalia.local (10.188.101.121) by GRFHUB703BA020.griffon.local (10.188.101.113) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 11 Apr 2013 10:30:49 +0200 Received: from GRFHUB706RM001.griffon.local (10.19.3.71) by TELHUB003BA020.telecomitalia.local (10.188.101.121) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 11 Apr 2013 10:30:48 +0200 Received: from TELEMX001RM001.telecomitalia.local (10.19.3.94) by GRFHUB706RM001.griffon.local (10.19.3.71) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 11 Apr 2013 10:30:48 +0200 Received: from mail.ietf.org (12.22.58.30) by mx4.telecomitalia.it (217.169.121.15) with Microsoft SMTP Server id 14.2.328.9; Thu, 11 Apr 2013 10:30:47 +0200 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9212C21F8EC1; Thu, 11 Apr 2013 01:30:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E7B21F8EBE; Thu, 11 Apr 2013 01:30:43 -0700 (PDT) Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7+0exNiyDUN; Thu, 11 Apr 2013 01:30:42 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3F321F8E94; Thu, 11 Apr 2013 01:30:41 -0700 (PDT) Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 11 Apr 2013 10:30:39 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Thu, 11 Apr 2013 10:30:38 +0200 From: Goix Laurent Walter To: "Paul E. Jones" , 'Pete Resnick' , 'The IESG' CC: "webfinger@ietf.org" , "appsawg-chairs@tools.ietf.org" , "draft-ietf-appsawg-webfinger@tools.ietf.org" Sender: "webfinger-bounces@ietf.org" Date: Thu, 11 Apr 2013 10:30:35 +0200 Subject: [webfinger] R: Pete Resnick's Discuss on draft-ietf-appsawg-webfinger-12: (with DISCUSS and COMMENT) Thread-Topic: [webfinger] R: Pete Resnick's Discuss on draft-ietf-appsawg-webfinger-12: (with DISCUSS and COMMENT) Thread-Index: AQIFZ47RBvRxNougrt0H0X5S9MAW/Zhh8agQgABaiVA= Message-ID: References: <20130410151341.19923.80191.idtracker@ietfa.amsl.com> <0d3a01ce3666$3b7524a0$b25f6de0$@packetizer.com> List-Help: List-Subscribe: , List-Unsubscribe: , In-Reply-To: <0d3a01ce3666$3b7524a0$b25f6de0$@packetizer.com> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: TELEMX001RM001.telecomitalia.local X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-virus-scanned: amavisd-new at amsl.com x-spam-status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1365669046; bh=ZLIgaEc0Ad05TLyH7+flGVH0nxnNf3jEam6dH4R+z7o=; h=From:To:Date:Message-ID:References:In-Reply-To:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=ydjhrZorDJv5dxiLUN2Y7Y+7ywXfsBUtyiLeaa7ovhLVfOAOaobfw69+yAK5BHREU BsYcC71gRMv2fdHFCyOJrdhjzBiTFowMTXKMJaK/6yOUtb3lSev/eP3xZsY9R+11w7 0qoHdIcuURdWCACzkFhcVP6IrMngJh1OAcLxla1c= delivered-to: webfinger@ietfa.amsl.com x-spam-level: errors-to: webfinger-bounces@ietf.org list-post: x-spam-score: -1.719 list-id: Discussion of the Webfinger protocol proposal in the Applications Area x-beenthere: webfinger@ietf.org x-mailman-version: 2.1.12 list-archive: x-spam-flag: NO x-original-to: webfinger@ietfa.amsl.com x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Dear all, After reading this thread and the various ballots, I'd like to help the DIS= CUSSion and hopefully clarify (part of) the doubts by proposing an example = of usage of webfinger within federated social networks. This example is der= ived from the OMA Social Network Web specification, which references Webfin= ger for this specific purpose. I'd also like to recall (as Paul anticipated talking about rfc6415) that so= cial network federation was actually the first use case of the original web= finger community spec, and as such imo well deserves an example using this = new spec as it may become extremely relevant in the next years. Of course improvements are welcome if the generic idea is sound. Walter --- 3.x Federated Social Networks In the context of interoperable, federated, social networks, the Webfinger = discovery process is used by a SN Server when receiving a request from an S= N Client on behalf of a user asking to interact with a user identified by h= is SN account eg acct:joe@example.com. In particular the SN Server identifi= es whether it is authoritative for the recipient (i.e. the domain of his/he= r account is "locally" managed by this SN Server) or whether it pertains to= another remote SN domain/provider. If the recipient's address corresponds = to a "acct:" address, which domain-part corresponds to a remote domain, the= SN Server can locate the recipient's SN Server based on this domain-part a= nd trigger the Webfinger discovery process for that recipient (the "resourc= e"). This process can hence be triggered when receiving requests to follow remot= e users or when receiving reactions (e.g. comments, replies, mentions) that= relate to social activities of remote users, etc. Depending on the incomin= g request from the client, the SN Server may be interested in some specific= link rels that will be used to contact the remote SN Server on the related= endpoint(s). SN Servers can cache the information provided in the retrieve= d descriptor and/or issue conditional requests at a later stage to check fo= r updates of this information, subject to the mechanisms defined in [RFC 26= 16] section 13. The following JRD is an example of a user descriptor returned by an SN Serv= er for a Webfinger query to user account acct:joe@example.com. In this requ= est no specific rel is mentioned as it may be useful for the requesting SN = Server to cache to entire descriptor for future needs. { "subject" : "acct:joe@example.com", "properties" : { "http://salmon-protocol.org/ns/magic-key" : "RSA.mVgY8RN6URBTstn= dvmUUPb4UZTdwvwmddSKE5z_jvKUEK6yk1u3rrC9yN8k6FilGj9K0eeUPe2hf4Pj-5CmHww.AQA= B" }, "links" : [ { "rel" : "http://portablecontacts.net/spec/1.0", "href" : "http://example.com/api/people" }, { "rel" : "http://portablecontacts.net/spec/1.0#me", "href" : "http://example.com/api/people/joe" }, { "rel" : "http://ns.opensocial.org/2008/opensocial/people", "href" : "http://example.com/api/people" }, { "rel" : "http://webfinger.net/rel/profile-page", "type" : "text/html", "href" : "http://example.com/profiles/joe" }, { "rel" : "describedby", "type" : "text/html", "href" : "http://example.com/profiles/joe" }, { "rel" : "http://webfinger.net/rel/avatar", "href" : "http://example.com/profiles/joe/photo" }, { "rel" : "http://schemas.google.com/g/2010#updates-from", "type" : "application/atom+xml", "href" : "http://example.com/activities/joe" }, { "rel" : "salmon", "href" : "http://example.com/salmon/joe" } ] } Depending on the original request from the client the SN Server will typica= lly read a specific link rel and invoke the related endpoint. For example i= t can read the http://schemas.google.com/g/2010#updates-from relation link = of type "application/atom+xml" to access the user's activity stream feed or= the http://portablecontacts.net/spec/1.0 relation link to access personal = user information such as his profile or relationships. The actual access to= such endpoints and the retrieved data ,if any, will be subject to the remo= te SN policies and user settings. > -----Messaggio originale----- > Da: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] Per co= nto > di Paul E. Jones > Inviato: gioved=EC 11 aprile 2013 5.40 > A: 'Pete Resnick'; 'The IESG' > Cc: webfinger@ietf.org; appsawg-chairs@tools.ietf.org; draft-ietf-appsawg= - > webfinger@tools.ietf.org > Oggetto: Re: [webfinger] Pete Resnick's Discuss on draft-ietf-appsawg- > webfinger-12: (with DISCUSS and COMMENT) > > Pete, > > > [All: As I noted earlier to the Webfinger mailing list, I have Cc'ed > > this > > to the Webfinger list along with the document authors, the document > > shepherd, and the rest of the IESG. > > > > Also note that I intend to DISCUSS this until Thursday. If I get no > > further support from the IESG and/or the WG that this is a serious and > > showstopper problem, I will simply ABSTAIN on both this and on the > > -acct-uri document (on which I also currently have an open DISCUSS > > position). But it looks like Richard and I are in some agreement on > > this.] > > > > There appears to be a big giant semantic gap for the client side of thi= s > > protocol. I can find nothing in the document that indicates to the > > client > > how it shall determine what sort of URI to use is the resource part of > > the query or what the semantics of any given URI are supposed to be. I > > suspect that the semantics are so underspecified that there could not > > possibly be interoperable implementations without lots of out-of-band > > information. > > If you are seeking information related to a user account, then the > specification recommends the use of the "acct" URI. Use of other URI typ= es is > not fully specified and no recommendations are given. Syntactically, the > server behavior will be the same for any type of URI. The only gap is kn= owing > what set of link relations type to expect for a given URI scheme. Do you= use > "mailto" or "acct"? We had a lot of debate over that for years and settl= ed on > "acct". > > So what should one expect if one issued a query like this? > > $ curl https://packetizer.com/.well- > known/webfinger?resource=3Dhttp://www.packetizer.com > > I would expect it to return information about that URL. The link relatio= n > types returned might be "copyright" or "author" or other. It would be ty= pes > that are valid for a web page. > > > The first example provides a mapping from an email address (or perhaps = a > > mailto URI; that's not clear) to an acct URI, but neither the example > > nor > > anything in the rest of the document gives any clue why you would choos= e > > to query an "acct" URI based on the contents of an email message. I > > think > > the assumption is that if there is an email address, there must be some > > sort of "account" associated with it, and therefore querying the host o= n > > the RHS of the "@" for that account will get some interesting > > information. But I don't see any reason to choose an "acct" scheme over > > "mailto" or "smtp" or "email" or "foobar"; as far as I can tell, the > > choice is semantics-free. > > Again, this was a 3 year long discussion. You're right that it could be > anything. We even argued to use no URI at all and just use "user@domain"= . > However, it finally decided to use "acct". It identifies an account at a > domain. It does not identify an email address. Using mailto URI didn't = fit > Twitter, for example, as there is no email. The same can be said for oth= er > services, including photo sharing services, blogs, and so forth. If you = want > to query information about my account on a social networking site, it wou= ld > not be an email address that would be used. > > > Reading the above alongside 3.3 makes me all the more suspicious: In 3.= 3 > > (also mentioned in 4.5), a "mailto" URI gets you configuration > > information for all email configuration parameters. Does an "acct" URI > > get you configuration information for email *and* xmpp *and* sip *and* > > calendaring *and* all other configuration information (since you are no > > longer asking for a particular protocol, but rather the general account > > information), or do you only get "information" about the person and not > > their account? (I might also insert privacy and security worries here, > > but see Stephen's DISCUSS regarding that.) How can the client know what > > sort of information it can ask for and how to get it? And for that > > matter, how does the server tell what information to pass back? You'd > > think there would be a hint about this in 4.3, but "rel" only seems to > > provide for the client to request those things that the client already > > knows about it. In particular, there appears to be no way to say, "Give > > me user provided information, but not config information" or "Give me > > config information, but not blog entries". > > The "rel" parameter is just a filter to reduce the size of the JRD down t= o > only the particular link relation types of interest (e.g., "vcard", "jcar= d", > "blog", "profile"). > > If you wish to query for information about a person, you query the person= 's > acct URI. The other examples, such as use of "mailto" or "device" are ju= st > examples of what is possible. As an example of how I would expect to us= e > "mailto", you can see this presentation: > http://www.ietf.org/proceedings/86/slides/slides-86-aggsrv-3.pdf > > However, the aggsrv group could say (if they even elected to use WF) that= the > "mailto" URI shall be used to query for configuration information related= to > email. I don't know what they will recommend. The WF draft shows an exa= mple > of how one could use an email URI, but it is a non-working example since = none > of the link relation types are defined. > > The WF spec does not go into detail on what a client should expect to rec= eive > for any URI scheme, but only recommends use of "acct" to get user account > information. The link relations returned from such a query are in use to= day > and some will be standardized (as that's next on the "to-do" list). > > > I find the semantics for "device" in 3.4 all-the-more mysterious. As fa= r > > as I can tell, this URI scheme simply means, "Give me all of the > > information for the entire host." > > Well, "device" does not exist and that will likely never exist. The only > point with that was to demonstrate how any URI scheme could be used, incl= uding > one intended for device identification. And if we had one for device > identification, it might return that kind of information. Again, this is= just > a non-normative example showing broadly what we can do with WF. > > > Again, the semantics of all of these interactions seem so underspecifie= d > > that I don't understand how interoperation is supposed to happen. > > Yeah, this definitely was not intended to be defined. When or if we deci= ded > to use WF for this purpose, it would be defined in another spec. However= , I > would expect the syntax and procedures for making the request to the serv= er to > be the same as querying for an account URI. > > > This also leaves me with the question about why the resource query part > > is a URI at all. It seems to me that the resource you are asking about > > is > > not a URI (or URN) at all; it's simply an identifier for an entity that > > the particular host knows about. Given that, why not pass a simple > > identifier? (See http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ > > for example.) If the scheme is not providing any particular semantics > > about the response, I see no reason to provide the scheme. If more > > semantics (beyond rel) are needed, another parameter indicating the typ= e > > of identifier being used seems much more appropriate than using a URI > > scheme. > > URI schemes allow for a natural separation. And, a WF server for a domai= n > could know all kinds of information about itself. It would know who auth= ored > web pages on the domain. It would know information about account holders= on > the domain. There was back and forth, as I noted above, as to whether we > needed "acct" or not. In the end, it was agreed to identify information = about > users -- stuff users share or that are shared within a company (e.g., emp= loyee > pictures or contact info). > > Years of work on this topic resulted in RFC 6415. RFC 6415, in fact, is = what > people had envisaged for "webfinger". It defined a well-known location c= alled > "host-meta" and a different link relation called "LRDD" for querying > information about a particular URI. > > The challenge with RFC 6415 is that it too so long to move forward that b= y the > time it was done, JSON had become the favored syntax language, people wan= ted > to mandate use of TLS for a variety of security reasons, people did not w= ant > two round trips to the server to return the JRD. So, we set about fixing= all > of the gripes people had with RFC 6415. We removed XML entirely, we full= y > documented JRD, the server does the merging of host-meta and LRDD documen= ts > (though not described that way for simplicity's sake), TLS was mandated, = and > we introduced the "rel" parameter to allow for selecting one or a few typ= es of > links to reduce the size of the document. > > RFC 6415 uses any type of URI. This is useful, since the URI scheme does > provide separation in namespace and since we do want to allow retrieval o= f a > set of link relations for those URIs -- web pages (http), user accounts > (acct), tel URIs (tel), etc. The only point of confusion, I think, is "w= hat > do we do with mailto, sip, h323, telnet, etc.?" Well, we're not prescrib= ing > that. That would be documented in a document that wants to use those oth= er > URIs. They might be used to configure a device or help route a call or > whatever. We only have examples of possible use, but we do not specify t= heir > use. > > Paul > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger --_002_A09A9E0A4B9C654E8672D1DC003633AE53D43B077AGRFMBX704BA02_-- From melvincarvalho@gmail.com Wed Jun 19 06:17:30 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5733F21F9B85 for ; Wed, 19 Jun 2013 06:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gn+kIE+emLrR for ; Wed, 19 Jun 2013 06:17:27 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 242E521F9B5D for ; Wed, 19 Jun 2013 06:17:25 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id gw10so4561025lab.2 for ; Wed, 19 Jun 2013 06:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xxwglSrrnDMPrpVGR79QBB3YIliJPBgudUjjxK228QM=; b=AuMWyP/+C18ANM2LJm95teNd2DPKJ3GJCj/f7DbyX7q8x8jOTzAN0WmxxyR9GUlCS7 vlCquSUO7Z+Jw2uXifm9WhBGFmz9/cpyx2xbcr8UWpKZRcSoQLuRsfq0fxf+0YY2+2c2 JtL5TeTU0EvN9S2frL9GgrBCfyIdlm/2dUVyI7Q4UYXA/OXHCTuOmlsWW8703JoSLZUE qJbQOVJrQEd3RdZDqQGU/bdyKrOCMrKE8mF0uWw0aaKryOpc8fN5G4KvKMcofouc6rTq tpafhSmTiG+ZYgTYBagjiZbG6NFkS5R3KxHnmKqp10AStjYV+tyE1I9Pl6Vajbxm8WFW YAFQ== MIME-Version: 1.0 X-Received: by 10.152.87.81 with SMTP id v17mr1378123laz.1.1371647844611; Wed, 19 Jun 2013 06:17:24 -0700 (PDT) Received: by 10.112.2.8 with HTTP; Wed, 19 Jun 2013 06:17:24 -0700 (PDT) In-Reply-To: References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <51BB264C.3090602@qti.qualcomm.com> <51BB5A96.4000308@qti.qualcomm.com> <4E1F6AAD24975D4BA5B16804296739436785E621@TK5EX14MBXC283.redmond.corp.microsoft.com> <3ACB44C8-7A06-4D7D-90F4-679197769A67@cisco.com> Date: Wed, 19 Jun 2013 15:17:24 +0200 Message-ID: From: Melvin Carvalho To: Goix Laurent Walter Content-Type: multipart/alternative; boundary=001a11c356e289008404df81a60f Cc: Pete Resnick , Gonzalo Salgueiro , "draft-ietf-appsawg-webfinger@tools.ietf.org" , Paul Jones , Mike Jones , Salvatore Loreto , webfinger , Barry Leiba Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 13:17:30 -0000 --001a11c356e289008404df81a60f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 19 June 2013 15:00, Goix Laurent Walter < laurentwalter.goix@telecomitalia.it> wrote: > Hi all, > > I am catching up as well a bit late and would like to move things forward > for those realistic use cases. Some comments inline... > > [snip] > > > > > > 1. Explicitly state that WebFinger is a framework and that the > information > > to be returned for specific "rel" link relation types for specific kind= s > 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. > > [walter] +1. Actually OMA SNEW is another spec (besides OpenID Connect) > that leverages webfinger for (mobile) federated social networks. I > re-attach a mail I sent a couple of months ago with a related example aft= er > some discussion already on the examples section. (feedback/revision is > welcome) > > > > > > > 2. We could establish a registry indexed by "rel" link relation valu= es > > 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. > > [walter] link rel registry already exist at IANA and we should probably > leverage on that, which is also useful for other contexts such as embeddi= ng > such link rels in atom feeds or html pages for example. But surely 1) we > can define new official link rel tokens that fit concrete use cases, 2) w= e > may have an informal registry for the link rel URIs (and could use the on= e > from Paul on packetizer as basis) > > [snip] > > > > > > > 4. Since people are finding the examples problematic, we could remov= e > 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 wou= ld > > 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 curre= nt > > 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 i= s > 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. > > [walter] i would really avoid removing the whole example section. This is > very much helpful for developers to understand the protocol, and the > document format (we re-defined JRD in this doc so it makes a lot of sense > to show examples of this *new* data model). Besides openid connect I am > proposing the oma snew case, but one or more fictitious examples that > possibly don't harm any community (no email config, no aggrsrv, etc) and > that moreover could better showcase the expressiveness of JRD would be > useful IMHO. > > > > > > > 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 OpenI= D > > 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 i= f > > 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. > > [walter] webfinger was originally very much motivated by "account > identifiers" (then became acct: URI) and as such would deserve a mention = as > it currently states. I don't believe that its mention limits the proposal > (it clearly states that any other URI scheme is valid) but clarifies the > original intent. I do not see why it would help removing it, but if it > makes it ship faster... > I think the original webfinger was motivated by email identiiers and acct: came in later http://code.google.com/p/webfinger/ "WebFinger is about making email addresses more valuable, by letting people attach public metadata to them" > > walter > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the > intended recipient, please delete this message and any attachments and > advise the sender by return e-mail, Thanks. > > > > ---------- Forwarded message ---------- > From: Goix Laurent Walter > To: "Paul E. Jones" , 'Pete Resnick' < > presnick@qti.qualcomm.com>, 'The IESG' > Cc: "webfinger@ietf.org" , " > appsawg-chairs@tools.ietf.org" , " > draft-ietf-appsawg-webfinger@tools.ietf.org" < > draft-ietf-appsawg-webfinger@tools.ietf.org> > Date: Thu, 11 Apr 2013 10:30:35 +0200 > Subject: [webfinger] R: Pete Resnick's Discuss on > draft-ietf-appsawg-webfinger-12: (with DISCUSS and COMMENT) > Dear all, > > After reading this thread and the various ballots, I'd like to help the > DISCUSSion and hopefully clarify (part of) the doubts by proposing an > example of usage of webfinger within federated social networks. This > example is derived from the OMA Social Network Web specification, which > references Webfinger for this specific purpose. > I'd also like to recall (as Paul anticipated talking about rfc6415) that > social network federation was actually the first use case of the original > webfinger community spec, and as such imo well deserves an example using > this new spec as it may become extremely relevant in the next years. > > Of course improvements are welcome if the generic idea is sound. > > Walter > > --- > 3.x Federated Social Networks > In the context of interoperable, federated, social networks, the Webfinge= r > discovery process is used by a SN Server when receiving a request from an > SN Client on behalf of a user asking to interact with a user identified b= y > his SN account eg acct:joe@example.com. In particular the SN Server > identifies whether it is authoritative for the recipient (i.e. the domain > of his/her account is "locally" managed by this SN Server) or whether it > pertains to another remote SN domain/provider. If the recipient's address > corresponds to a "acct:" address, which domain-part corresponds to a remo= te > domain, the SN Server can locate the recipient's SN Server based on this > domain-part and trigger the Webfinger discovery process for that recipien= t > (the "resource"). > This process can hence be triggered when receiving requests to follow > remote users or when receiving reactions (e.g. comments, replies, mention= s) > that relate to social activities of remote users, etc. Depending on the > incoming request from the client, the SN Server may be interested in some > specific link rels that will be used to contact the remote SN Server on t= he > related endpoint(s). SN Servers can cache the information provided in the > retrieved descriptor and/or issue conditional requests at a later stage t= o > check for updates of this information, subject to the mechanisms defined = in > [RFC 2616] section 13. > > The following JRD is an example of a user descriptor returned by an SN > Server for a Webfinger query to user account acct:joe@example.com. In > this request no specific rel is mentioned as it may be useful for the > requesting SN Server to cache to entire descriptor for future needs. > > { > "subject" : "acct:joe@example.com", > "properties" : > { > "http://salmon-protocol.org/ns/magic-key" : > "RSA.mVgY8RN6URBTstndvmUUPb4UZTdwvwmddSKE5z_jvKUEK6yk1u3rrC9yN8k6FilGj9K0= eeUPe2hf4Pj-5CmHww.AQAB" > }, > "links" : > [ > { > "rel" : "http://portablecontacts.net/spec/1.0", > "href" : "http://example.com/api/people" > }, > { > "rel" : "http://portablecontacts.net/spec/1.0#me", > "href" : "http://example.com/api/people/joe" > }, > { > "rel" : "http://ns.opensocial.org/2008/opensocial/people", > "href" : "http://example.com/api/people" > }, > { > "rel" : "http://webfinger.net/rel/profile-page", > "type" : "text/html", > "href" : "http://example.com/profiles/joe" > }, > { > "rel" : "describedby", > "type" : "text/html", > "href" : "http://example.com/profiles/joe" > }, > { > "rel" : "http://webfinger.net/rel/avatar", > "href" : "http://example.com/profiles/joe/photo" > }, > { > "rel" : "http://schemas.google.com/g/2010#updates-from", > "type" : "application/atom+xml", > "href" : "http://example.com/activities/joe" > }, > { > "rel" : "salmon", > "href" : "http://example.com/salmon/joe" > } > ] > } > > Depending on the original request from the client the SN Server will > typically read a specific link rel and invoke the related endpoint. For > example it can read the http://schemas.google.com/g/2010#updates-fromrela= tion link of type "application/atom+xml" to access the user's activity > stream feed or the http://portablecontacts.net/spec/1.0 relation link to > access personal user information such as his profile or relationships. Th= e > actual access to such endpoints and the retrieved data ,if any, will be > subject to the remote SN policies and user settings. > > > -----Messaggio originale----- > > Da: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] Per > conto > > di Paul E. Jones > > Inviato: gioved=EC 11 aprile 2013 5.40 > > A: 'Pete Resnick'; 'The IESG' > > Cc: webfinger@ietf.org; appsawg-chairs@tools.ietf.org; > draft-ietf-appsawg- > > webfinger@tools.ietf.org > > Oggetto: Re: [webfinger] Pete Resnick's Discuss on draft-ietf-appsawg- > > webfinger-12: (with DISCUSS and COMMENT) > > > > Pete, > > > > > [All: As I noted earlier to the Webfinger mailing list, I have Cc'ed > > > this > > > to the Webfinger list along with the document authors, the document > > > shepherd, and the rest of the IESG. > > > > > > Also note that I intend to DISCUSS this until Thursday. If I get no > > > further support from the IESG and/or the WG that this is a serious an= d > > > showstopper problem, I will simply ABSTAIN on both this and on the > > > -acct-uri document (on which I also currently have an open DISCUSS > > > position). But it looks like Richard and I are in some agreement on > > > this.] > > > > > > There appears to be a big giant semantic gap for the client side of > this > > > protocol. I can find nothing in the document that indicates to the > > > client > > > how it shall determine what sort of URI to use is the resource part o= f > > > the query or what the semantics of any given URI are supposed to be. = I > > > suspect that the semantics are so underspecified that there could not > > > possibly be interoperable implementations without lots of out-of-band > > > information. > > > > If you are seeking information related to a user account, then the > > specification recommends the use of the "acct" URI. Use of other URI > types is > > not fully specified and no recommendations are given. Syntactically, t= he > > server behavior will be the same for any type of URI. The only gap is > knowing > > what set of link relations type to expect for a given URI scheme. Do > you use > > "mailto" or "acct"? We had a lot of debate over that for years and > settled on > > "acct". > > > > So what should one expect if one issued a query like this? > > > > $ curl https://packetizer.com/.well- > > known/webfinger?resource=3Dhttp://www.packetizer.com > > > > I would expect it to return information about that URL. The link > relation > > types returned might be "copyright" or "author" or other. It would be > types > > that are valid for a web page. > > > > > The first example provides a mapping from an email address (or perhap= s > a > > > mailto URI; that's not clear) to an acct URI, but neither the example > > > nor > > > anything in the rest of the document gives any clue why you would > choose > > > to query an "acct" URI based on the contents of an email message. I > > > think > > > the assumption is that if there is an email address, there must be so= me > > > sort of "account" associated with it, and therefore querying the host > on > > > the RHS of the "@" for that account will get some interesting > > > information. But I don't see any reason to choose an "acct" scheme ov= er > > > "mailto" or "smtp" or "email" or "foobar"; as far as I can tell, the > > > choice is semantics-free. > > > > Again, this was a 3 year long discussion. You're right that it could b= e > > anything. We even argued to use no URI at all and just use "user@domai= n > ". > > However, it finally decided to use "acct". It identifies an account at= a > > domain. It does not identify an email address. Using mailto URI didn'= t > fit > > Twitter, for example, as there is no email. The same can be said for > other > > services, including photo sharing services, blogs, and so forth. If yo= u > want > > to query information about my account on a social networking site, it > would > > not be an email address that would be used. > > > > > Reading the above alongside 3.3 makes me all the more suspicious: In > 3.3 > > > (also mentioned in 4.5), a "mailto" URI gets you configuration > > > information for all email configuration parameters. Does an "acct" UR= I > > > get you configuration information for email *and* xmpp *and* sip *and= * > > > calendaring *and* all other configuration information (since you are = no > > > longer asking for a particular protocol, but rather the general accou= nt > > > information), or do you only get "information" about the person and n= ot > > > their account? (I might also insert privacy and security worries here= , > > > but see Stephen's DISCUSS regarding that.) How can the client know wh= at > > > sort of information it can ask for and how to get it? And for that > > > matter, how does the server tell what information to pass back? You'd > > > think there would be a hint about this in 4.3, but "rel" only seems t= o > > > provide for the client to request those things that the client alread= y > > > knows about it. In particular, there appears to be no way to say, "Gi= ve > > > me user provided information, but not config information" or "Give me > > > config information, but not blog entries". > > > > The "rel" parameter is just a filter to reduce the size of the JRD down > to > > only the particular link relation types of interest (e.g., "vcard", > "jcard", > > "blog", "profile"). > > > > If you wish to query for information about a person, you query the > person's > > acct URI. The other examples, such as use of "mailto" or "device" are > just > > examples of what is possible. As an example of how I would expect to > use > > "mailto", you can see this presentation: > > http://www.ietf.org/proceedings/86/slides/slides-86-aggsrv-3.pdf > > > > However, the aggsrv group could say (if they even elected to use WF) > that the > > "mailto" URI shall be used to query for configuration information > related to > > email. I don't know what they will recommend. The WF draft shows an > example > > of how one could use an email URI, but it is a non-working example sinc= e > none > > of the link relation types are defined. > > > > The WF spec does not go into detail on what a client should expect to > receive > > for any URI scheme, but only recommends use of "acct" to get user accou= nt > > information. The link relations returned from such a query are in use > today > > and some will be standardized (as that's next on the "to-do" list). > > > > > I find the semantics for "device" in 3.4 all-the-more mysterious. As > far > > > as I can tell, this URI scheme simply means, "Give me all of the > > > information for the entire host." > > > > Well, "device" does not exist and that will likely never exist. The on= ly > > point with that was to demonstrate how any URI scheme could be used, > including > > one intended for device identification. And if we had one for device > > identification, it might return that kind of information. Again, this > is just > > a non-normative example showing broadly what we can do with WF. > > > > > Again, the semantics of all of these interactions seem so > underspecified > > > that I don't understand how interoperation is supposed to happen. > > > > Yeah, this definitely was not intended to be defined. When or if we > decided > > to use WF for this purpose, it would be defined in another spec. > However, I > > would expect the syntax and procedures for making the request to the > server to > > be the same as querying for an account URI. > > > > > This also leaves me with the question about why the resource query pa= rt > > > is a URI at all. It seems to me that the resource you are asking abou= t > > > is > > > not a URI (or URN) at all; it's simply an identifier for an entity th= at > > > the particular host knows about. Given that, why not pass a simple > > > identifier? (See > http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ > > > for example.) If the scheme is not providing any particular semantics > > > about the response, I see no reason to provide the scheme. If more > > > semantics (beyond rel) are needed, another parameter indicating the > type > > > of identifier being used seems much more appropriate than using a URI > > > scheme. > > > > URI schemes allow for a natural separation. And, a WF server for a > domain > > could know all kinds of information about itself. It would know who > authored > > web pages on the domain. It would know information about account > holders on > > the domain. There was back and forth, as I noted above, as to whether = we > > needed "acct" or not. In the end, it was agreed to identify informatio= n > about > > users -- stuff users share or that are shared within a company (e.g., > employee > > pictures or contact info). > > > > Years of work on this topic resulted in RFC 6415. RFC 6415, in fact, i= s > what > > people had envisaged for "webfinger". It defined a well-known location > called > > "host-meta" and a different link relation called "LRDD" for querying > > information about a particular URI. > > > > The challenge with RFC 6415 is that it too so long to move forward that > by the > > time it was done, JSON had become the favored syntax language, people > wanted > > to mandate use of TLS for a variety of security reasons, people did not > want > > two round trips to the server to return the JRD. So, we set about > fixing all > > of the gripes people had with RFC 6415. We removed XML entirely, we > fully > > documented JRD, the server does the merging of host-meta and LRDD > documents > > (though not described that way for simplicity's sake), TLS was mandated= , > and > > we introduced the "rel" parameter to allow for selecting one or a few > types of > > links to reduce the size of the document. > > > > RFC 6415 uses any type of URI. This is useful, since the URI scheme do= es > > provide separation in namespace and since we do want to allow retrieval > of a > > set of link relations for those URIs -- web pages (http), user accounts > > (acct), tel URIs (tel), etc. The only point of confusion, I think, is > "what > > do we do with mailto, sip, h323, telnet, etc.?" Well, we're not > prescribing > > that. That would be documented in a document that wants to use those > other > > URIs. They might be used to configure a device or help route a call or > > whatever. We only have examples of possible use, but we do not specify > their > > use. > > > > Paul > > > > > > _______________________________________________ > > webfinger mailing list > > webfinger@ietf.org > > https://www.ietf.org/mailman/listinfo/webfinger > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the > intended recipient, please delete this message and any attachments and > advise the sender by return e-mail, Thanks. > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --001a11c356e289008404df81a60f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 19 June 2013 15:00, Goix Laurent Walter <laur= entwalter.goix@telecomitalia.it> wrote:
Hi all,

I am catching up as well a bit late and would like to move things forward f= or those realistic use cases. Some comments inline...

[snip]
> >
> > 1. =A0Explicitly state that WebFinger is a framework and that the= information
> to be returned for specific "rel" link relation types for sp= ecific 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-th= e-wire
> behavior.

[walter] +1. Actually OMA SNEW is another spec (besides OpenID Connec= t) that leverages webfinger for (mobile) federated social networks. I re-at= tach a mail I sent a couple of months ago with a related example after some= discussion already on the examples section. (feedback/revision is welcome)=

> >
> > 2. =A0We could establish a registry indexed by "rel" li= nk relation values
> pointing to documents that define this information. =A0For instance, w= e could
> then register the "rel" value "http://openid.net/specs/co= nnect/1.0/issuer" and
> point it to http://openid.net/specs/openid-connect-discov= ery-1_0.html, which
> defines the meaning of that link relation. =A0Other link relation defi= nitions
> could then also use that registry.
>
> Sure. This is a simple step to take to provide clarity on existing use= s of WF.

[walter] link rel registry already exist at IANA and we should probab= ly leverage on that, which is also useful for other contexts such as embedd= ing such link rels in atom feeds or html pages for example. But surely 1) w= e can define new official link rel tokens that fit concrete use cases, 2) w= e may have an informal registry for the link rel URIs (and could use the on= e from Paul on packetizer as basis)

[snip]

> >
> > 4. =A0Since people are finding the examples problematic, we could= remove them,
> or possibly only keep the OpenID Connect one, which is concrete and be= ing used
> in practice. =A0Or in fact, we could add a second OpenID Connect examp= le - so
> that there's one with the resource being a URL and another with th= e resource
> using e-mail address syntax. =A0We could also bring over the apparentl= y-
> innocuous "copyright" and "author" examples from R= FC 6415, if those would
> cause people less consternation. =A0But the device and e-mail examples= seem to
> be generating more heat than light.
>
> I've very reluctantly suggested this to Paul as well. =A0Not becau= se I don't
> like the examples. =A0In fact, I consider them some of the most useful= text for
> implementers and for their value in quickly relaying the power of curr= ent
> usage and future potential of the protocol. =A0In the interest of an e= xpeditious
> resolution to this stalemate I'd be willing to remove the two exam= ples giving
> problems, though I'd warn that we do have tangible useful informat= ion loss
> (e.g., no demonstrated use of properties, etc.). =A0My position on thi= s is only
> because I expect to write future documents that will allow us to resur= rect
> these deleted examples.
>
> BTW - The addition of a supplementary OpenID Connect example seems rea= sonable
> and helpful.

[walter] i would really avoid removing the whole example section. Thi= s is very much helpful for developers to understand the protocol, and the d= ocument format (we re-defined JRD in this doc so it makes a lot of sense to= show examples of this *new* data model). Besides openid connect I am propo= sing the oma snew case, but one or more fictitious examples that possibly d= on't harm any community (no email config, no aggrsrv, etc) and that mor= eover could better showcase the expressiveness of JRD would be useful IMHO.=

> >
> > 5. =A0We could remove all references to and discussion of the acc= t: URI, since
> WebFinger actually has no dependency upon it. =A0Other specifications = can still
> specify that it be used in particular contexts with WebFinger, as Open= ID
> 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 b= ut if
> they're standing between us and finishing the spec it would be bet= ter for them
> to go. =A0Likewise, if acct: is standing between us and finishing, it = should go
> too.

[walter] webfinger was originally very much motivated by "accoun= t identifiers" (then became acct: URI) and as such would deserve a men= tion as it currently states. I don't believe that its mention limits th= e proposal (it clearly states that any other URI scheme is valid) but clari= fies the original intent. I do not see why it would help removing it, but i= f it makes it ship faster...

I think the original webfinger was motivat= ed by email identiiers and acct: came in later

http://code.google.com/p/webfinger/

"WebFinger is about making email addresses more valuable, by letting p= eople attach public metadata to them"
=A0

walter

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks.



---------- Forwarded message ----------
From:=A0Goix Laurent Wal= ter <laurentwalte= r.goix@telecomitalia.it>
To:=A0"Paul E. Jones" <paulej@packetizer.com>, 'Pe= te Resnick' <presnick@q= ti.qualcomm.com>, 'The IESG' <iesg@ietf.org>
Cc:=A0"webfinger@ietf.org&qu= ot; <webfinger@ietf.org>, &= quot;appsawg-chairs@tools.= ietf.org" <app= sawg-chairs@tools.ietf.org>, "draft-ietf-appsawg-webfinger@tools.ietf.org" <draft-ietf-appsawg-webfinger@tools.ietf.org>
Date:=A0Thu, 11 Apr 2013 10:30:35 +0200
Subject:=A0[webfinger] R: Pete R= esnick's Discuss on draft-ietf-appsawg-webfinger-12: (with DISCUSS and = COMMENT)
Dear all,

After reading this thread and the various ballots, I'd like to help the= DISCUSSion and hopefully clarify (part of) the doubts by proposing an exam= ple of usage of webfinger within federated social networks. This example is= derived from the OMA Social Network Web specification, which references We= bfinger for this specific purpose.
I'd also like to recall (as Paul anticipated talking about rfc6415) tha= t social network federation was actually the first use case of the original= webfinger community spec, and as such imo well deserves an example using t= his new spec as it may become extremely relevant in the next years.

Of course improvements are welcome if the generic idea is sound.

Walter

---
3.x Federated Social Networks
In the context of interoperable, federated, social networks, the Webfinger = discovery process is used by a SN Server when receiving a request from an S= N Client on behalf of a user asking to interact with a user identified by h= is SN account eg acct:joe@example= .com. In particular the SN Server identifies whether it is authoritativ= e for the recipient (i.e. the domain of his/her account is "locally&qu= ot; managed by this SN Server) or whether it pertains to another remote SN = domain/provider. If the recipient's address corresponds to a "acct= :" address, which domain-part corresponds to a remote domain, the SN S= erver can locate the recipient's SN Server based on this domain-part an= d trigger the Webfinger discovery process for that recipient (the "res= ource").
This process can hence be triggered when receiving requests to follow remot= e users or when receiving reactions (e.g. comments, replies, mentions) that= relate to social activities of remote users, etc. Depending on the incomin= g request from the client, the SN Server may be interested in some specific= link rels that will be used to contact the remote SN Server on the related= endpoint(s). SN Servers can cache the information provided in the retrieve= d descriptor and/or issue conditional requests at a later stage to check fo= r updates of this information, subject to the mechanisms defined in [RFC 26= 16] section 13.

The following JRD is an example of a user descriptor returned by an SN Serv= er for a Webfinger query to user account acct:joe@example.com. In this request no specific rel is mentio= ned as it may be useful for the requesting SN Server to cache to entire des= criptor for future needs.

{
=A0 =A0 =A0 =A0"subject" : "acct:joe@example.com",
=A0 =A0 =A0 =A0"properties" :
=A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0"http://salmon-protocol.org/ns/magic-key" := "RSA.mVgY8RN6URBTstndvmUUPb4UZTdwvwmddSKE5z_jvKUEK6yk1u3rrC9yN8k6FilG= j9K0eeUPe2hf4Pj-5CmHww.AQAB"
=A0 =A0 =A0 =A0},
=A0 =A0 =A0 =A0"links" :
=A0 =A0 =A0 =A0[
=A0 =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0"rel" : "http://portablecontacts.net/spec/1.0= ",
=A0 =A0 =A0 =A0 =A0 =A0"href" : "http://example.com/api/people" =A0 =A0 =A0 =A0 =A0},
=A0 =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0"rel" : "http://portablecontacts.net/spec/= 1.0#me",
=A0 =A0 =A0 =A0 =A0 =A0"href" : "http://example.com/api/people/joe&= quot;
=A0 =A0 =A0 =A0 =A0},
=A0 =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0"rel" : "http://ns.opensocial.org/= 2008/opensocial/people",
=A0 =A0 =A0 =A0 =A0 =A0"href" : "http://example.com/api/people" =A0 =A0 =A0 =A0 =A0},
=A0 =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0"rel" : "http://webfinger.net/rel/profile-pa= ge",
=A0 =A0 =A0 =A0 =A0 =A0"type" : "text/html",
=A0 =A0 =A0 =A0 =A0 =A0"href" : "http://example.com/profiles/joe"= ;
=A0 =A0 =A0 =A0 =A0},
=A0 =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0"rel" : "describedby",
=A0 =A0 =A0 =A0 =A0 =A0"type" : "text/html",
=A0 =A0 =A0 =A0 =A0 =A0"href" : "http://example.com/profiles/joe"= ;
=A0 =A0 =A0 =A0 =A0},
=A0 =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0"rel" : "http://webfinger.net/rel/avatar"= ,
=A0 =A0 =A0 =A0 =A0 =A0"href" : "http://example.com/profiles/joe/ph= oto"
=A0 =A0 =A0 =A0 =A0},
=A0 =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0"rel" : "http://schemas.google.com/g= /2010#updates-from",
=A0 =A0 =A0 =A0 =A0 =A0"type" : "application/atom+xml",=
=A0 =A0 =A0 =A0 =A0 =A0"href" : "http://example.com/activities/joe&= quot;
=A0 =A0 =A0 =A0 =A0},
=A0 =A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0"rel" : "salmon",
=A0 =A0 =A0 =A0 =A0 =A0"href" : "http://example.com/salmon/joe" =A0 =A0 =A0 =A0 =A0}
=A0 =A0 =A0 =A0]
}

Depending on the original request from the client the SN Server will typica= lly read a specific link rel and invoke the related endpoint. For example i= t can read the http://schemas.google.com/g/2010#updates-from relation = link of type "application/atom+xml" to access the user's acti= vity stream feed or the http://portablecontacts.net/spec/1.0 relation link to a= ccess personal user information such as his profile or relationships. The a= ctual access to such endpoints and the retrieved data ,if any, will be subj= ect to the remote SN policies and user settings.

> -----Messaggio originale-----
> Da: webfinger-bounces@ie= tf.org [mailto:webfinger-= bounces@ietf.org] Per conto
> di Paul E. Jones
> Inviato: gioved=EC 11 aprile 2013 5.40
> A: 'Pete Resnick'; 'The IESG'
> Cc: webfinger@ietf.org; appsawg-chairs@tools.ietf.org<= /a>; draft-ietf-appsawg-
> webfinger@tools.ietf.org
> Oggetto: Re: [webfinger] Pete Resnick's Discuss on draft-ietf-apps= awg-
> webfinger-12: (with DISCUSS and COMMENT)
>
> Pete,
>
> > [All: As I noted earlier to the Webfinger mailing list, I have Cc= 'ed
> > this
> > to the Webfinger list along with the document authors, the docume= nt
> > shepherd, and the rest of the IESG.
> >
> > Also note that I intend to DISCUSS this until Thursday. If I get = no
> > further support from the IESG and/or the WG that this is a seriou= s and
> > showstopper problem, I will simply ABSTAIN on both this and on th= e
> > -acct-uri document (on which I also currently have an open DISCUS= S
> > position). But it looks like Richard and I are in some agreement = on
> > this.]
> >
> > There appears to be a big giant semantic gap for the client side = of this
> > protocol. I can find nothing in the document that indicates to th= e
> > client
> > how it shall determine what sort of URI to use is the resource pa= rt of
> > the query or what the semantics of any given URI are supposed to = be. I
> > suspect that the semantics are so underspecified that there could= not
> > possibly be interoperable implementations without lots of out-of-= band
> > information.
>
> If you are seeking information related to a user account, then the
> specification recommends the use of the "acct" URI. =A0Use o= f other URI types is
> not fully specified and no recommendations are given. =A0Syntactically= , the
> server behavior will be the same for any type of URI. =A0The only gap = is knowing
> what set of link relations type to expect for a given URI scheme. =A0D= o you use
> "mailto" or "acct"? =A0We had a lot of debate over= that for years and settled on
> "acct".
>
> So what should one expect if one issued a query like this?
>
> $ curl htt= ps://packetizer.com/.well-
> known/webfinger?resource=3Dhttp://www.packetizer.com
>
> I would expect it to return information about that URL. =A0The link re= lation
> types returned might be "copyright" or "author" or= other. =A0It would be types
> that are valid for a web page.
>
> > The first example provides a mapping from an email address (or pe= rhaps a
> > mailto URI; that's not clear) to an acct URI, but neither the= example
> > nor
> > anything in the rest of the document gives any clue why you would= choose
> > to query an "acct" URI based on the contents of an emai= l message. I
> > think
> > the assumption is that if there is an email address, there must b= e some
> > sort of "account" associated with it, and therefore que= rying the host on
> > the RHS of the "@" for that account will get some inter= esting
> > information. But I don't see any reason to choose an "ac= ct" scheme over
> > "mailto" or "smtp" or "email" or &q= uot;foobar"; as far as I can tell, the
> > choice is semantics-free.
>
> Again, this was a 3 year long discussion. =A0You're right that it = could be
> anything. =A0We even argued to use no URI at all and just use "us= er@domain".
> However, it finally decided to use "acct". =A0It identifies = an account at a
> domain. =A0It does not identify an email address. =A0Using mailto URI = didn't fit
> Twitter, for example, as there is no email. =A0The same can be said fo= r other
> services, including photo sharing services, blogs, and so forth. =A0If= you want
> to query information about my account on a social networking site, it = would
> not be an email address that would be used.
>
> > Reading the above alongside 3.3 makes me all the more suspicious:= In 3.3
> > (also mentioned in 4.5), a "mailto" URI gets you config= uration
> > information for all email configuration parameters. Does an "= ;acct" URI
> > get you configuration information for email *and* xmpp *and* sip = *and*
> > calendaring *and* all other configuration information (since you = are no
> > longer asking for a particular protocol, but rather the general a= ccount
> > information), or do you only get "information" about th= e person and not
> > their account? (I might also insert privacy and security worries = here,
> > but see Stephen's DISCUSS regarding that.) How can the client= know what
> > sort of information it can ask for and how to get it? And for tha= t
> > matter, how does the server tell what information to pass back? Y= ou'd
> > think there would be a hint about this in 4.3, but "rel"= ; only seems to
> > provide for the client to request those things that the client al= ready
> > knows about it. In particular, there appears to be no way to say,= "Give
> > me user provided information, but not config information" or= "Give me
> > config information, but not blog entries".
>
> The "rel" parameter is just a filter to reduce the size of t= he JRD down to
> only the particular link relation types of interest (e.g., "vcard= ", "jcard",
> "blog", "profile").
>
> If you wish to query for information about a person, you query the per= son's
> acct URI. =A0The other examples, such as use of "mailto" or = "device" are just
> examples of what is possible. =A0 As an example of how I would expect = to use
> "mailto", you can see this presentation:
> http://www.ietf.org/proceedings/86/slides/slides-8= 6-aggsrv-3.pdf
>
> However, the aggsrv group could say (if they even elected to use WF) t= hat the
> "mailto" URI shall be used to query for configuration inform= ation related to
> email. =A0I don't know what they will recommend. =A0The WF draft s= hows an example
> of how one could use an email URI, but it is a non-working example sin= ce none
> of the link relation types are defined.
>
> The WF spec does not go into detail on what a client should expect to = receive
> for any URI scheme, but only recommends use of "acct" to get= user account
> information. =A0The link relations returned from such a query are in u= se today
> and some will be standardized (as that's next on the "to-do&q= uot; list).
>
> > I find the semantics for "device" in 3.4 all-the-more m= ysterious. As far
> > as I can tell, this URI scheme simply means, "Give me all of= the
> > information for the entire host."
>
> Well, "device" does not exist and that will likely never exi= st. =A0The only
> point with that was to demonstrate how any URI scheme could be used, i= ncluding
> one intended for device identification. =A0And if we had one for devic= e
> identification, it might return that kind of information. =A0Again, th= is is just
> a non-normative example showing broadly what we can do with WF.
>
> > Again, the semantics of all of these interactions seem so undersp= ecified
> > that I don't understand how interoperation is supposed to hap= pen.
>
> Yeah, this definitely was not intended to be defined. =A0When or if we= decided
> to use WF for this purpose, it would be defined in another spec. =A0Ho= wever, I
> would expect the syntax and procedures for making the request to the s= erver to
> be the same as querying for an account URI.
>
> > This also leaves me with the question about why the resource quer= y part
> > is a URI at all. It seems to me that the resource you are asking = about
> > is
> > not a URI (or URN) at all; it's simply an identifier for an e= ntity that
> > the particular host knows about. Given that, why not pass a simpl= e
> > identifier? (See http://datatracker.ietf.org/doc/draft-= ietf-radext-nai/
> > for example.) If the scheme is not providing any particular seman= tics
> > about the response, I see no reason to provide the scheme. If mor= e
> > semantics (beyond rel) are needed, another parameter indicating t= he type
> > of identifier being used seems much more appropriate than using a= URI
> > scheme.
>
> URI schemes allow for a natural separation. =A0And, a WF server for a = domain
> could know all kinds of information about itself. =A0It would know who= authored
> web pages on the domain. =A0It would know information about account ho= lders on
> the domain. =A0There was back and forth, as I noted above, as to wheth= er we
> needed "acct" or not. =A0In the end, it was agreed to identi= fy information about
> users -- stuff users share or that are shared within a company (e.g., = employee
> pictures or contact info).
>
> Years of work on this topic resulted in RFC 6415. =A0RFC 6415, in fact= , is what
> people had envisaged for "webfinger". =A0It defined a well-k= nown location called
> "host-meta" and a different link relation called "LRDD&= quot; for querying
> information about a particular URI.
>
> The challenge with RFC 6415 is that it too so long to move forward tha= t by the
> time it was done, JSON had become the favored syntax language, people = wanted
> to mandate use of TLS for a variety of security reasons, people did no= t want
> two round trips to the server to return the JRD. =A0So, we set about f= ixing all
> of the gripes people had with RFC 6415. =A0We removed XML entirely, we= fully
> documented JRD, the server does the merging of host-meta and LRDD docu= ments
> (though not described that way for simplicity's sake), TLS was man= dated, and
> we introduced the "rel" parameter to allow for selecting one= or a few types of
> links to reduce the size of the document.
>
> RFC 6415 uses any type of URI. =A0This is useful, since the URI scheme= does
> provide separation in namespace and since we do want to allow retrieva= l of a
> set of link relations for those URIs -- web pages (http), user account= s
> (acct), tel URIs (tel), etc. =A0The only point of confusion, I think, = is "what
> do we do with mailto, sip, h323, telnet, etc.?" =A0Well, we'r= e not prescribing
> that. =A0That would be documented in a document that wants to use thos= e other
> URIs. =A0They might be used to configure a device or help route a call= or
> whatever. =A0We only have examples of possible use, but we do not spec= ify their
> use.
>
> Paul
>
>
> _______________________________________________
> webfinger mailing list
> webfinger@ietf.org
> https://www.ietf.org/mailman/listinfo/webfinger

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks.

_______________________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--001a11c356e289008404df81a60f-- From presnick@qti.qualcomm.com Thu Jun 20 13:41:07 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E065021F9346 for ; Thu, 20 Jun 2013 13:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCd0LXoiVEJO for ; Thu, 20 Jun 2013 13:41:02 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id A95B921F880F for ; Thu, 20 Jun 2013 13:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1371760862; x=1403296862; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LawzpAwmwdJ8k7vyRuN6MKRQ3Od2UEVKUmgyQ4nASkk=; b=JtR6DrBf1LI1uyL71SQuGB3mR2RusjlfqHtiNJCnlgPbG4pWfvfuybiV WWQpNPScUKpO+IVMxKR+N2wLCksOORLouu86xMClf2PKJTg4KpRcUqGFJ jnYq2hpmsVGkYDPaoF7qhlmTu0XWBJ1chKXinNkUC+sEFMlIoUF8YDO8o M=; X-IronPort-AV: E=Sophos;i="4.87,907,1363158000"; d="scan'208";a="57995322" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 20 Jun 2013 13:41:02 -0700 X-IronPort-AV: E=Sophos;i="4.87,907,1363158000"; d="scan'208";a="468078038" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Jun 2013 13:41:02 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 20 Jun 2013 13:41:01 -0700 Message-ID: <51C368DC.3020201@qti.qualcomm.com> Date: Thu, 20 Jun 2013 15:41:00 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Mike Jones References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <51BB264C.3090602@qti.qualcomm.com> <51BB5A96.4000308@qti.qualcomm.com> <4E1F6AAD24975D4BA5B16804296739436785E621@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436785E621@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: "draft-ietf-appsawg-webfinger@tools.ietf.org" , "Paul E. Jones" , Melvin Carvalho , salvatore loreto , webfinger , Barry Leiba Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 20:41:07 -0000 Sorry for the delay. A few comments, but generally a good direction here: On 6/14/13 8:43 PM, Mike Jones 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. > > 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. > Fine, of course. > 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. > This sounds reasonable, though I would add a third column (well, actually I would make it the first column of 3) called "Service". In this case, the service would be "Open ID Connect Issuer". As time goes on, I'd expect there to be things like "Mail Client Configuration", "User Account Info", and other such entries. > 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. > I've always found this a weird case and never understood why you'd want to allow queries without "rel" parameters; I don't understand why a client would ever want to do that. But if you're going to do that, this explanation seems useful. As I've said a few times now, what this document is missing is some hint of how the client is going to figure out what it needs to do. > 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. > Agreed. One other possibility is simply to remove all examples, but have an informative reference to an existing spec, e.g. OpenID Connect. > 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. > I'd like to see how the acct: URI discussion shakes out before making that call. For a while, the two document seemed inextricably linked. Now, I'm not sure. This is a reasonable start toward addressing my concerns. I look forward to some proposed text. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From laurentwalter.goix@telecomitalia.it Fri Jun 21 00:34:50 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7162421F9B4B for ; Fri, 21 Jun 2013 00:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzzsXWnj4DAF for ; Fri, 21 Jun 2013 00:34:46 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAA711E8163 for ; Fri, 21 Jun 2013 00:34:45 -0700 (PDT) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 21 Jun 2013 09:34:43 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Fri, 21 Jun 2013 09:34:43 +0200 From: Goix Laurent Walter To: Pete Resnick , Mike Jones Date: Fri, 21 Jun 2013 09:34:18 +0200 Thread-Topic: [webfinger] [appsawg] #12: Semantic gap for the client side Thread-Index: Ac5t9oDCufq9i7PtSHCq5jNpadcY4QAWiOpg Message-ID: References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <51BB264C.3090602@qti.qualcomm.com> <51BB5A96.4000308@qti.qualcomm.com> <4E1F6AAD24975D4BA5B16804296739436785E621@TK5EX14MBXC283.redmond.corp.microsoft.com> <51C368DC.3020201@qti.qualcomm.com> In-Reply-To: <51C368DC.3020201@qti.qualcomm.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: IWFg SxSc TKuM Xj6U Yo13 npZc oLSg uNoR xYYy 42v/ /4YM ABxAJA== AByY4A== ACW5Mw== AE+0UQ== AF5Ejw==; 8; YgBhAHIAcgB5AGwAZQBpAGIAYQBAAGMAbwBtAHAAdQB0AGUAcgAuAG8AcgBnADsAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGEAcABwAHMAYQB3AGcALQB3AGUAYgBmAGkAbgBnAGUAcgBAAHQAbwBvAGwAcwAuAGkAZQB0AGYALgBvAHIAZwA7AG0AZQBsAHYAaQBuAGMAYQByAHYAYQBsAGgAbwBAAGcAbQBhAGkAbAAuAGMAbwBtADsAbQBpAGMAaABhAGUAbAAuAGoAbwBuAGUAcwBAAG0AaQBjAHIAbwBzAG8AZgB0AC4AYwBvAG0AOwBwAGEAdQBsAGUAagBAAHAAYQBjAGsAZQB0AGkAegBlAHIALgBjAG8AbQA7AHAAcgBlAHMAbgBpAGMAawBAAHEAdABpAC4AcQB1AGEAbABjAG8AbQBtAC4AYwBvAG0AOwBzAGEAbAB2AGEAdABvAHIAZQAuAGwAbwByAGUAdABvAEAAZQByAGkAYwBzAHMAbwBuAC4AYwBvAG0AOwB3AGUAYgBmAGkAbgBnAGUAcgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {C6A99A4E-5BA7-4674-81FC-2A1AA33426C3}; bABhAHUAcgBlAG4AdAB3AGEAbAB0AGUAcgAuAGcAbwBpAHgAQAB0AGUAbABlAGMAbwBtAGkAdABhAGwAaQBhAC4AaQB0AA==; Fri, 21 Jun 2013 07:34:18 GMT; UgA6ACAAWwB3AGUAYgBmAGkAbgBnAGUAcgBdACAAWwBhAHAAcABzAGEAdwBnAF0AIAAjADEAMgA6ACAAUwBlAG0AYQBuAHQAaQBjACAAZwBhAHAAIABmAG8AcgAgAHQAaABlACAAYwBsAGkAZQBuAHQAIABzAGkAZABlAA== x-cr-puzzleid: {C6A99A4E-5BA7-4674-81FC-2A1AA33426C3} acceptlanguage: en-US x-messagesize: 21014 x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-appsawg-webfinger@tools.ietf.org" , "Paul E. Jones" , Melvin Carvalho , salvatore loreto , webfinger , Barry Leiba Subject: [webfinger] R: [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 07:34:50 -0000 > > 2. We could establish a registry indexed by "rel" link relation values > pointing to documents that define this information. For instance, we cou= ld > 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, wh= ich > defines the meaning of that link relation. Other link relation definitio= ns > could then also use that registry. > > > > This sounds reasonable, though I would add a third column (well, > actually I would make it the first column of 3) called "Service". In > this case, the service would be "Open ID Connect Issuer". As time goes > on, I'd expect there to be things like "Mail Client Configuration", > "User Account Info", and other such entries. > > > 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 ser= vices > 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= . > > > > I've always found this a weird case and never understood why you'd want > to allow queries without "rel" parameters; I don't understand why a > client would ever want to do that. But if you're going to do that, this > explanation seems useful. As I've said a few times now, what this > document is missing is some hint of how the client is going to figure > out what it needs to do. [walter] is there then interest for creating a new concept of "rel sets" (s= imilarly to what you called "Service") that could have a unique name/URI (i= n case of simple token a registry may be useful) and would be documented in= an external spec as a specific list of rels? This may help in querying on = wf with a single param (avoiding to list explicitly all rels) and at the sa= me time facilitate interop so that the client could explicitly state what i= t is looking for. "openidconnect" could be one of them (no matter how many rels it covers, wh= ich would be listed in the openidconnect spec), , the "oauth" related rels = could be another, and others may be created eg for federated social web (th= inking of salmon, pubsub, etc) link rels... Would this make the spec too complex if we define such additional (optional= ) parameter and manage the naming conventions just like for rels ? walter Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From bortzmeyer@nic.fr Fri Jun 28 03:11:51 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C3E21F9DD4 for ; Fri, 28 Jun 2013 03:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bD7EbuYln3Oy for ; Fri, 28 Jun 2013 03:11:41 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 422FC21F9E93 for ; Fri, 28 Jun 2013 03:11:38 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 2AD4D280107; Fri, 28 Jun 2013 12:11:04 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 262E2280023; Fri, 28 Jun 2013 12:11:04 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:113]) by relay1.nic.fr (Postfix) with ESMTP id 249DE4C0053; Fri, 28 Jun 2013 12:10:34 +0200 (CEST) Date: Fri, 28 Jun 2013 12:10:33 +0200 From: 'Stephane Bortzmeyer' To: "Paul E. Jones" Message-ID: <20130628101033.GA22661@nic.fr> References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <20130614065904.GA30932@nic.fr> <005f01ce68ce$2665a3b0$7330eb10$@packetizer.com> <20130614142735.GA10799@nic.fr> <00b701ce691c$29354200$7b9fc600$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b701ce691c$29354200$7b9fc600$@packetizer.com> X-Operating-System: Debian GNU/Linux 7.1 X-Kernel: Linux 3.2.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: webfinger@ietf.org Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 10:11:51 -0000 On Fri, Jun 14, 2013 at 12:28:10PM -0400, Paul E. Jones wrote a message of 66 lines which said: > > OK for me (except the erroneous "en-us" that I already mentioned here) > > What's the issue with "en-us"? http://www.ietf.org/mail-archive/web/webfinger/current/msg00555.html RFC 5646 says: > Use as precise a tag as possible, but no more specific than is > justified. Avoid using subtags that are not important for > distinguishing content in an application. > > * For example, 'de' might suffice for tagging an email written > in German, while "de-CH-1996" is probably unnecessarily > precise for such a task. Which seems to apply exactly here (there is nothing US-specific in the sentence). May be, instead: "titles" : { "en-us" : "The Magical Theater of Bob", "en-gb" : "The Magical Theatre of Bob", ... From paulej@packetizer.com Fri Jun 28 03:46:48 2013 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD91921F9EFE for ; Fri, 28 Jun 2013 03:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5hnf+mct4OT for ; Fri, 28 Jun 2013 03:46:39 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 252F621F9EF7 for ; Fri, 28 Jun 2013 03:46:39 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r5SAkcCQ027784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Jun 2013 06:46:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1372416398; bh=RQwoLBH8i0AidP4BspQxbJIsHRtMt7uQHcTqBkLABaQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=hInTv6QNABwh9QAZtwDziVMpVSCVTvSTWEf10a4KOnYwpURhCJfCVx7a4m2TaSJtA xEDvcisDzDpl8PzVCc2msc26ez5NAeKWrJGnMl9UFdacKr8nOo7KtNMnZz57d/cjM/ 6in8SUxNVwtcLxaP16uxj5YB1heqejEkXQuj0rsE= From: "Paul E. Jones" To: "'Stephane Bortzmeyer'" References: <071.1f5cc037d908127f5ac6f4afd3d8842a@trac.tools.ietf.org> <026701ce5cdb$2e7d2630$8b777290$@packetizer.com> <024301ce5d92$f7d06080$e7712180$@packetizer.com> <51B9E0AC.5070508@qti.qualcomm.com> <002a01ce68a3$8501aac0$8f050040$@packetizer.com> <20130614065904.GA30932@nic.fr> <005f01ce68ce$2665a3b0$7330eb10$@packetizer.com> <20130614142735.GA10799@nic.fr> <00b701ce691c$29354200$7b9fc600$@packetizer.com> <20130628101033.GA22661@nic.fr> In-Reply-To: <20130628101033.GA22661@nic.fr> Date: Fri, 28 Jun 2013 06:47:02 -0400 Message-ID: <073401ce73ec$d2b6e240$7824a6c0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFNWMcWAQ1n5b22xM4UdUF6Zyw7DQLrgow+AwtEfrIBDFDY6AJtOwD0Amz+c8MBpoKlLAHOxQXMAoqTx4cB9PKMGwH0pdfCmZ7wJpA= Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client side X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of the Webfinger protocol proposal in the Applications Area List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 10:46:49 -0000 Stephane, If I am entering the text that goes into the WF output and I spell words using US English, then en-us is the appropriate thing to put. Just = because the spelling in that particular example aligns with British spelling = does not mean there is no significance. Following your example, I assume you would agree with this: { "en-us" : "The Magical Theater of Bob", "fr" : "Le Th=E9=E2tre magique de Bob" } But the software didn't change. And my WF server is not going to have a language analyzer to know the least restrictive value to use. The = language tag is likely going to be fairly automatic and derived from the user's locale. Paul > -----Original Message----- > From: 'Stephane Bortzmeyer' [mailto:bortzmeyer@nic.fr] > Sent: Friday, June 28, 2013 6:11 AM > To: Paul E. Jones > Cc: webfinger@ietf.org > Subject: Re: [webfinger] [appsawg] #12: Semantic gap for the client = side >=20 > On Fri, Jun 14, 2013 at 12:28:10PM -0400, > Paul E. Jones wrote > a message of 66 lines which said: >=20 > > > OK for me (except the erroneous "en-us" that I already mentioned = here) > > > > What's the issue with "en-us"? >=20 > http://www.ietf.org/mail-archive/web/webfinger/current/msg00555.html >=20 > RFC 5646 says: >=20 > > Use as precise a tag as possible, but no more specific than is > > justified. Avoid using subtags that are not important for > > distinguishing content in an application. > > > > * For example, 'de' might suffice for tagging an email written > > in German, while "de-CH-1996" is probably unnecessarily > > precise for such a task. >=20 > Which seems to apply exactly here (there is nothing US-specific in the > sentence). May be, instead: >=20 > "titles" : > { > "en-us" : "The Magical Theater of Bob", > "en-gb" : "The Magical Theatre of Bob", > ...