Subject: [webfinger] Webfinger and RFC 6415

From: Evan Prodromou <[email-masked]>
Date: Mon, 11 Feb 2013 21:58:16 -0500

If a server supports Web Host Metadata per RFC 6415, it can easily use 
the Webfinger endpoint as a JRD-serving LRDD link. You can make your 
/.well-known/host-meta.json (JRD-serving host-wide metadata) look 
something like this:

     {
         "links": [
                 {
                     "rel": "lrdd",
                     "type": "application/json",
                     "template": 
"http://example.com/.well-known/webfinger?resource={uri}"
                 }
         ]
     }

Supporting this usage was an important part of how we got to the current 
structure, but we don't mention it in the current draft.

It can be documented elsewhere, but it might be useful in the document 
itself. Definitely not a blocker, but I wanted to bring it up.

-Evan

---

From: Kingsley Idehen <[email-masked]>
Date: Thu, 14 Feb 2013 07:35:25 -0500

On 2/11/13 9:58 PM, Evan Prodromou wrote:
> Supporting this usage was an important part of how we got to the 
> current structure, but we don't mention it in the current draft.
>

+1

We support this pattern in our servers.

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

---

From: Goix Laurent Walter <[email-masked]>
Date: Thu, 14 Feb 2013 14:25:10 +0100

I would definitely sponsor mentioning this. Either as use case / example, or by creating a new section "Relationship with RFC6415 (Informational)" that could illustrate this, and maybe add some statement about JRDs as well.

In fact we will end up having JRD specified in 2 RFCs, and even if wire-compatible (despite maybe the "expires" property...), some additional words could be spent on this eg to state whether the wf jrd definition "obsoletes" the rfc6145 one or otherwise how they relate.

Another statement in that section could be on querying via wf for host-wide information, that is instead of querying
http://example.com/.well-known/host-meta.json
query
https://example.com/.well-known/webfinger?resource=http://example.com
as Paul already suggested quite a few times.

finally, note that in your example the lrdd template url / wf endpoint is http whilst it should be https :)

walter

> -----Messaggio originale-----
> Da: [email-masked] [mailto:[email-masked]] Per conto
> di Kingsley Idehen
> Inviato: giovedì 14 febbraio 2013 13.35
> A: [email-masked]
> Oggetto: Re: [webfinger] Webfinger and RFC 6415
>

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.

---

From: Evan Prodromou <[email-masked]>
Date: Fri, 15 Feb 2013 09:00:08 -0500

I think describing the relationship with RFC 6415 would be great.

There's a subtle distinction between the host "example.com" and the 
specific resource "http://example.com/".

I would expect to find information about SMTP and IMAP setup for the 
host, but it would be less reasonable for the URL.

And, yes, the Webfinger endpoint should be https. Good eye!

-Evan

On 13-02-14 08:25 AM, Goix Laurent Walter wrote:
> _______________________________________________
> webfinger mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webfinger

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 18 Feb 2013 17:56:18 -0500

Evan, et al,

So, there is a proposal for a one-line comment and one for a more expansive
section.  I have no strong preference.  Would you or someone else like to
suggest exactly what they would like to see in the document?

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Evan Prodromou
> Sent: Friday, February 15, 2013 9:00 AM
> To: [email-masked]
> Subject: Re: [webfinger] R: Webfinger and RFC 6415
> 
> > I would definitely sponsor mentioning this. Either as use case /
> example, or by creating a new section "Relationship with RFC6415
> (Informational)" that could illustrate this, and maybe add some
> statement about JRDs as well.
> >
> > In fact we will end up having JRD specified in 2 RFCs, and even if
> wire-compatible (despite maybe the "expires" property...), some
> additional words could be spent on this eg to state whether the wf jrd
> definition "obsoletes" the rfc6145 one or otherwise how they relate.
> >
> > Another statement in that section could be on querying via wf for
> > host-wide information, that is instead of querying
> >> Da: [email-masked] [mailto:[email-masked]]
> >> Per conto di Kingsley Idehen
> >>> If a server supports Web Host Metadata per RFC 6415, it can easily
> >>> use the Webfinger endpoint as a JRD-serving LRDD link. You can make
> >>> your /.well-known/host-meta.json (JRD-serving host-wide metadata)
> >>> look something like this:
> >>>
> >>>      {
> >>>          "links": [
> >>>                  {
> >>>                      "rel": "lrdd",
> >>> It can be documented elsewhere, but it might be useful in the
> >>> document itself. Definitely not a blocker, but I wanted to bring it
> up.
> >>>
> >>> -Evan
> >> +1
> >>
> >> Company Web: http://www.openlinksw.com Personal Weblog:
> >> http://www.openlinksw.com/blog/~kidehen
> > 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.
> >