[apps-discuss] R: Webfinger

Goix Laurent Walter <laurentwalter.goix@telecomitalia.it> Tue, 22 November 2011 18:42 UTC

Return-Path: <laurentwalter.goix@telecomitalia.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B25B511E8082 for <apps-discuss@ietfa.amsl.com>; Tue, 22 Nov 2011 10:42:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.039
X-Spam-Status: No, score=-0.039 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id unz80gXZawaD for <apps-discuss@ietfa.amsl.com>; Tue, 22 Nov 2011 10:42:05 -0800 (PST)
Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it []) by ietfa.amsl.com (Postfix) with ESMTP id 11EE521F8B4A for <apps-discuss@ietf.org>; Tue, 22 Nov 2011 10:42:03 -0800 (PST)
Content-Type: multipart/mixed; boundary="_7294c471-aea8-46ae-b3fb-650a059446cb_"
Received: from GRFHUB702BA020.griffon.local ( by GRFEDG701BA020.telecomitalia.it ( with Microsoft SMTP Server (TLS) id; Tue, 22 Nov 2011 19:41:59 +0100
Received: from GRFMBX704BA020.griffon.local ([]) by GRFHUB702BA020.griffon.local ([]) with mapi; Tue, 22 Nov 2011 19:41:59 +0100
From: Goix Laurent Walter <laurentwalter.goix@telecomitalia.it>
To: Eran Hammer-Lahav <eran@hueniverse.com>, "Paul E. Jones" <paulej@packetizer.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Date: Tue, 22 Nov 2011 19:41:55 +0100
Thread-Topic: [apps-discuss] Webfinger
Thread-Index: AQI/v0XgjFwdy9sXrXmTVWBMa/eIuQJBqnysAgBEW78CHWIk+ZSf7BkwgAAksVCAAAGYgA==
Message-ID: <A09A9E0A4B9C654E8672D1DC003633AE4057006772@GRFMBX704BA020.griffon.local>
References: <032101cc9288$e3a06910$aae13b30$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735EDED@P3PW5EX1MB01.EX1.SECURESERVER.NET> <06b001cca865$1d9ccb80$58d66280$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735F00B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <086001cca93b$f455cc90$dd0165b0$@packetizer.com> <90C41DD21FB7C64BB94121FBBC2E7234526735F0DD@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234526735F0DD@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US, it-IT
Content-Language: it-IT
acceptlanguage: en-US, it-IT
MIME-Version: 1.0
Cc: 'Joseph Smarr' <jsmarr@google.com>
Subject: [apps-discuss] R: Webfinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Nov 2011 18:42:09 -0000

I guess the discussion is moving from a pure descriptor (which may be static in most cases) to a sort of API, which could have endless parameters.

>From the current/original webfinger description, the host-meta would mostly be static, which implies no API-like, and no parameter, but the lrdd link can typically be dynamic/API-like (to support the template mechanism). As such it could easily accommodate some more parameters as well (in a similar flavor than opensearch), e.g. to request specific link rels if we want.

What would be the scope of supporting uri parameters when accessing host-meta? Does this intend to save an interaction step?


Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Per conto di Eran Hammer-Lahav
Inviato: martedì 22 novembre 2011 19.33
A: Paul E. Jones; apps-discuss@ietf.org
Cc: 'Joseph Smarr'
Oggetto: Re: [apps-discuss] Webfinger

Yes, it is no longer a template and must be converted to href.

As for testing support, just check for Subject. Pretty simple to do.


From: Paul E. Jones [mailto:paulej@packetizer.com]
Sent: Tuesday, November 22, 2011 9:27 AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

A couple more questions on (3):

Why expand templates like this:

The requesting entity could expand the templates.  I can appreciate the reasoning for having "?resource" query the LRDD URL and return back the ordered list of links, but why have the server modify the discovered templates like the one above?  It's no longer a template, really.  Should we change "template" to be "href"?

If a server does not understand "?resource", it's likely to simply ignore it.  But, if a client expects it to be processed, it will cause confusion.  Would it be better to introduce /.well-known/host-meta-resource?  If a 404 is returned, then that is a clear indicator to the client.  Other suggestions?


From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]<mailto:[mailto:eran@hueniverse.com]>
Sent: Monday, November 21, 2011 9:52 PM
To: Paul E. Jones; apps-discuss@ietf.org<mailto:apps-discuss@ietf.org>
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

1.       Require the server to offer JRD, leave it to the client to pick one flavor.

2.       Host-meta dumps the decision on the applications. You need to decide if WebFinger is an application or just syntactic sugar on top of host-meta.

3.       Expand every template in host-meta + level one LRDD links (excluding templates in LRDD).


From: Paul E. Jones [mailto:paulej@packetizer.com]<mailto:[mailto:paulej@packetizer.com]>
Sent: Monday, November 21, 2011 7:49 AM
To: Eran Hammer-Lahav; apps-discuss@ietf.org<mailto:apps-discuss@ietf.org>
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger


Thanks for your feedback.  The editorial, structural, and behavioral items we'll addressed (including adhering to host-meta section 4.2).

Let me ask about specific comments:

1)      You want to mandate use of JSON, which we also indicated in the draft.  However, I would personally prefer to give both XML and JSON equal weight and require both.

2)      You wanted to mandate HTTPS. I'm not opposed, but host-meta does not mandate it.  Shouldn't we Webfinger requirements on what is there?

3)      Regarding "resource" extension: if I query host-meta, there may be any number of templates.  Would we want the server to automatically expand every template it finds?  Or would we only expand the 'lrdd' template?  (And how many levels of recursion might be possible?)


From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]<mailto:[mailto:eran@hueniverse.com]>
Sent: Saturday, November 19, 2011 10:03 AM
To: Paul E. Jones; apps-discuss@ietf.org<mailto:apps-discuss@ietf.org>
Cc: Joseph Smarr; Gonzalo Salgueiro; Blaine Cook
Subject: RE: [apps-discuss] Webfinger

This is a good start. Some feedback and nits:

1.       The protocol flow is incorrect and needs to be adjusted based on the final host-meta specification (RFC 6415). Namely, WebFinger must follow section 4.2 exactly as specified.

2.       WebFinger should focus exclusively on JSON and mandate WebFinger providers to support the JRD format. This does not preclude using XRD (XML) but it will ensure that every compliant WebFinger implementation provides full JSON support which is much more likely to be adopted. This is something we could not do in host-meta due to the late stage it was in, but this is the right time to make the switch (without taking away any existing functionality).

3.       Are there reasons not to mandate HTTPS?

4.       Section 3 should be a sub-section of the introduction and each example needs actual JRD code.

In addition, I would very much like to see WebFinger extend the host-meta endpoint by defining a 'resource' query parameter. Using the example in RFC 6415 section 1.1.1 (example not properly encoded to make it easier to read):

> GET /.well-known/host-meta?resource=http://example.com/xy HTTP/1.1




The rules for this extension parameter are pretty simple:

1.       JSON is implied. If the server understands '?resource' it MUST return a JRD document.

2.       The subject must be set to the value of the 'resource' parameter.

3.       If the server does not support that resource (wrong domain, etc.) it must return an empty JRD with the right subject.

4.       The client MUST verify the server supports '?resource' by making sure the response is both JRD and has the requested subject (this will ensure full compatibility with any other host-meta endpoint).

I would like to see such endpoint extension required for WebFinger so that clients can make a single call and get the full WebFinger result in JSON. This would significantly improve adoption and usability, and adds very little work to providers.


From: apps-discuss-bounces@ietf.org<mailto:apps-discuss-bounces@ietf.org> [mailto:apps-discuss-bounces@ietf.org]<mailto:[mailto:apps-discuss-bounces@ietf.org]> On Behalf Of Paul E. Jones
Sent: Monday, October 24, 2011 1:10 PM
To: apps-discuss@ietf.org<mailto:apps-discuss@ietf.org>
Cc: Joseph Smarr; Gonzalo Salgueiro
Subject: [apps-discuss] Webfinger


We just submitted this:

The tools for Webfinger are now defined, but the procedures need to be clearer with respect to what most of us understand as "webfinger".  This is just a first stab at making that happen and we hope to progress this to publish an RFC in the application area.

We welcome any comments you have on the topic, either privately or publicly.


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. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne 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, 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.

[cid:00000000000000000000000000000001@TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non è necessario.