Subject: Re: [apps-discuss] Webfinger

From: "Mykyta Yevstifeyev (М. Євстіфеєв)" <[email-masked]>
Date: Fri, 11 Nov 2011 19:59:02 +0200

Hi Paul and all,

I think you contributed a very interesting proposal indeed.  Really, RFC 
1288 finger protocol is now outdated, and you're right claiming that it 
provides no means of automatic processing.  BTW, RFC 1288 is currently 
at Draft Standard maturity level, which has been abandoned by RFC 6410, 
and we should therefore undertake something with this respect, as should 
we with respect of other Apps-related DSs, but that is what is to be 
discussed separately.

With respect to proposed 'acct' URI scheme:  how are you going to handle 
internationalization (i18n)?  We have RFC 5335 defining <utf8-addr-spec> 
(Experimental RFC) and IESG has already approved EAI 5335bis, that will 
be Standards Track.  So will <utf8-addr-spec> be allowed in 'acct' URIs 
in some way?

Webfinger implies use of some link relations.  Is it anticipated that 
URIs will be used as link relations types, or we'll need to define link 
relation types for all possible use-cases of Webfinger?

Your Section 4 seems to be somewhat narrative.  I propose to divide it 
into normative specification and examples.

With regard to CORS - I'm not actually acquainted with this technology, 
but I see it is currently documented as W3C working draft, so I don't 
suspect it is now widely-used (I may of course be wrong, so please feel 
free to correct me), and I think there is no use putting MUST 
requirement on its use in Webfinger.  You could better remove your 
section on CORS from the document at all.

I think we should also provide some means of mentioning Webfinger 
accounts in vCards.  You could please see VCARDDAV document 
http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00 which 
Webfinger elements may also be incorporated.

In Abstract, you should be more specific about what your document 
defines.  I propose mentioning directly that the document is the 
specification of Webfinger protocol, not "procedures for dicovering 
information about people".

In Section 7 you should clearly state that Webfinger (so as finger 
itself) is intentionally left w/o any means of controlling access to 
information (unless we want to produce *such* protocol).

I see the document is on APPSAWG agenda on the meeting, so I anticipate 
it will soon become APPSAWG item doc.  I won't be on meeting, but if you 
discuss the adaptation of Webfinger draft please also take into account 
I'm in favor of such adaptation (consider this as my 2p).

Mykyta Yevstifeyev

24.10.2011 23:09, Paul E. Jones wrote:
>
> Folks,
>
> We just submitted this:
>
> http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt
>
> 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.
>
> Paul
>
>
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Barry Leiba <[email-masked]>
Date: Fri, 11 Nov 2011 17:20:08 -0500

> I see the document is on APPSAWG agenda on the meeting, so I anticipate it
> will soon become APPSAWG item doc.  I won't be on meeting, but if you
> discuss the adaptation of Webfinger draft please also take into account I'm
> in favor of such adaptation (consider this as my 2p).

As the agenda says, some things are not verified... and, in
particular, this item is likely to be removed.  The chairs might
mention it in the meeting, but discussion of the document will be on
the mailing list.

More importantly, your assumption that a document's getting meeting
time implies that it "will soon become [a working group] doc" is very
much wrong.  Having it on the meeting agenda simply means that the
chairs think there will be some benefit to the working group process
to have a chance to talk about it face to face.  We still would need
to see enough interest in it, before the working group would accept
it.

Until now, there's been no interest expressed.  Thanks, Mykyta, for
weighing in.  Others should also, please, comment here and let the
working group and the document authors know whether you think this is
something we (and they -- possibly separate points) should pursue.

Barry, appsawg chair

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 11 Nov 2011 18:37:15 -0500

Mykyta,

Thanks for your positive response.

To your specific questions…

We would definitely want to ensure that Unicode is properly supported.  In wasn’t aware of RFC 5335, so I’m glad you brought that to my attention.  Do you have a pointer to the bis draft so I can see exactly what is there?  I’d be fully in favor of using utf8-addr-spec.

Link relation types might be names like “copyright” or they might be URIs.  The definition of the link relation types is outside the scope of the Webfinger document itself.  RFC 6415 defines the structure of the documents and provides examples of some link relations and the order of processing.  RFC 5988 defines the link relations more generically and establishes the registry for them.  Do you think we need to say more about link relations beyond what those documents cover?

On section 4: noted.  We’ll try to clearly separate the normative and non-normative pieces better.

On  CORS, there are some who have strongly advocated for it.  It would be very useful to allow JavaScript code to perform these queries.  Otherwise, the queries would have to be pushed to server-side code.  Let’s wait on deciding what to do until we get a definitive answer on CORS from the W3C.  I think Peter was going to do some investigating there.

Putting Webfinger into vcard: isn’t that circular?  The idea with Webfinger is that you have the identity of the user (e.g., [email-masked]), but you want to find more information.  If you have a vcard, then you have the user’s identity (via the email tag).  Or are you suggesting that we formally introduce the acct URI in vcard?  That might make sense to do.  Can you clarify your proposal?

For comments on particular sections, I’ve added notes to each one to revise them as you suggest: they’re all good suggestions.

I would very much like to make this a WG item, of course, but none of the authors will be present at this IETF meeting.  Perhaps hallway dialog might take place, but not sure.  In any case, we can do this via the mailing list, too.

Thanks!

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of "Mykyta Yevstifeyev (?. ?????????)"
Sent: Friday, November 11, 2011 12:59 PM
To: [email-masked]
Subject: Re: [apps-discuss] Webfinger

Hi Paul and all,

I think you contributed a very interesting proposal indeed.  Really, RFC 1288 finger protocol is now outdated, and you're right claiming that it provides no means of automatic processing.  BTW, RFC 1288 is currently at Draft Standard maturity level, which has been abandoned by RFC 6410, and we should therefore undertake something with this respect, as should we with respect of other Apps-related DSs, but that is what is to be discussed separately.

With respect to proposed 'acct' URI scheme:  how are you going to handle internationalization (i18n)?  We have RFC 5335 defining <utf8-addr-spec> (Experimental RFC) and IESG has already approved EAI 5335bis, that will be Standards Track.  So will <utf8-addr-spec> be allowed in 'acct' URIs in some way?

Webfinger implies use of some link relations.  Is it anticipated that URIs will be used as link relations types, or we'll need to define link relation types for all possible use-cases of Webfinger?

Your Section 4 seems to be somewhat narrative.  I propose to divide it into normative specification and examples.

With regard to CORS - I'm not actually acquainted with this technology, but I see it is currently documented as W3C working draft, so I don't suspect it is now widely-used (I may of course be wrong, so please feel free to correct me), and I think there is no use putting MUST requirement on its use in Webfinger.  You could better remove your section on CORS from the document at all.

I think we should also provide some means of mentioning Webfinger accounts in vCards.  You could please see VCARDDAV document http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00 which Webfinger elements may also be incorporated.

In Abstract, you should be more specific about what your document defines.  I propose mentioning directly that the document is the specification of Webfinger protocol, not "procedures for dicovering information about people".

In Section 7 you should clearly state that Webfinger (so as finger itself) is intentionally left w/o any means of controlling access to information (unless we want to produce *such* protocol).

I see the document is on APPSAWG agenda on the meeting, so I anticipate it will soon become APPSAWG item doc.  I won't be on meeting, but if you discuss the adaptation of Webfinger draft please also take into account I'm in favor of such adaptation (consider this as my 2p).

Mykyta Yevstifeyev

Folks,

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.

Paul

---

From: "Mykyta Yevstifeyev (М. Євстіфеєв)" <[email-masked]>
Date: Sat, 12 Nov 2011 07:31:51 +0200

Hello Paul,

12.11.2011 1:37, Paul E. Jones wrote:
> We would definitely want to ensure that Unicode is properly 
> supported.  In wasn’t aware of RFC 5335, so I’m glad you brought that 
> to my attention.  Do you have a pointer to the bis draft so I can see 
> exactly what is there?  I’d be fully in favor of using utf8-addr-spec.
>

This is http://tools.ietf.org/html/draft-ietf-eai-rfc5335bis-13.  But 
please note that this document, unlike RFC 5335, introduced UTF-8 
additions to *base* RFC 5322 productions.  This means that <addr-spec> 
will be defined as follows now:

>     addr-spec       =   local-part "@" domain
>     local-part      =   dot-atom / quoted-string / obs-local-part
>     domain          =   dot-atom / domain-literal / obs-domain
>     domain-literal  =   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
>     dtext           =   %d33-90 /          ; Printable US-ASCII
>                         %d94-126 /         ;  characters not including
>                         obs-dtext          ;  "[", "]", or "\"
>     dtext           =/  UTF8-non-ascii     ; from 5335bis
>     dot-atom        =   [CFWS] dot-atom-text [CFWS]
>     dot-atom-text   =   1*atext *("." 1*atext)
>     atext           =/  UTF8-non-ascii     ; from 5335bis

So everything you will have to do is to have a note on 'acct' RI being 
possible to carry UTF8 characters and therefore being possibly IRIs.

> Link relation types might be names like “copyright” or they might be 
> URIs.  The definition of the link relation types is outside the scope 
> of the Webfinger document itself.  RFC 6415 defines the structure of 
> the documents and provides examples of some link relations and the 
> order of processing.  RFC 5988 defines the link relations more 
> generically and establishes the registry for them.  Do you think we 
> need to say more about link relations beyond what those documents cover?
>

I mean that Webfinger will have to operate on a variety of link 
relations in LRDD documents, and nobody will benefit from link relation 
types defined by URIs used there, as this eliminates the possibility for 
automatic processing.  So I ask whether we'll have to define non-URI 
link relation types for all the possible Webfinger use-cases?

> non-normative pieces better.

Thanks.

> On  CORS, there are some who have strongly advocated for it.  It would 
> be very useful to allow JavaScript code to perform these queries.  
> Otherwise, the queries would have to be pushed to server-side code.  
> Let’s wait on deciding what to do until we get a definitive answer on 
> CORS from the W3C.  I think Peter was going to do some investigating 
> there.
>
> Putting Webfinger into vcard: isn’t that circular?  The idea with 
> Webfinger is that you have the identity of the user (e.g., 
> [email-masked] <mailto:[email-masked]>), but you want to 
> find more information.  If you have a vcard, then you have the user’s 
> identity (via the email tag).  Or are you suggesting that we formally 
> introduce the acct URI in vcard?  That might make sense to do.  Can 
> you clarify your proposal?
>

 From RFC 6350, Section 6.4.2:

> 6.4.2. EMAIL
>
>    Purpose:  To specify the electronic mail address for communication
>       with the object the vCard represents.

...and the use might have email address different from Webfinger ID.  
I've already pointed to 
http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00, which 
VCARDDAV WG works on, and so you may try to introduce some similar 
property for Webfinger IDs.  (You see, vCards may not carry all the 
variety of information, though some people actually think in other way, 
and thus it would be a good idea to provide a means of accessing some 
additional info.)

> For comments on particular sections, I’ve added notes to each one to 
> revise them as you suggest: they’re all good suggestions.
>

Yes, thanks as well.

> I would very much like to make this a WG item, of course, but none of 
> the authors will be present at this IETF meeting.  Perhaps hallway 
> dialog might take place, but not sure.  In any case, we can do this 
> via the mailing list, too.
>

See Barry's note on this.

> Paul

All the best,
Mykyta Yevstifeyev

> *From:[email-masked] 
> [mailto:[email-masked]] *On Behalf Of *"Mykyta 
> Yevstifeyev (?. ?????????)"
> *Sent:* Friday, November 11, 2011 12:59 PM
> *To:* [email-masked]
> *Subject:* Re: [apps-discuss] Webfinger
>
> Hi Paul and all,
>
> I think you contributed a very interesting proposal indeed.  Really, 
> RFC 1288 finger protocol is now outdated, and you're right claiming 
> that it provides no means of automatic processing.  BTW, RFC 1288 is 
> currently at Draft Standard maturity level, which has been abandoned 
> by RFC 6410, and we should therefore undertake something with this 
> respect, as should we with respect of other Apps-related DSs, but that 
> is what is to be discussed separately.
>
> With respect to proposed 'acct' URI scheme:  how are you going to 
> handle internationalization (i18n)?  We have RFC 5335 defining 
> <utf8-addr-spec> (Experimental RFC) and IESG has already approved EAI 
> 5335bis, that will be Standards Track.  So will <utf8-addr-spec> be 
> allowed in 'acct' URIs in some way?
>
> URIs will be used as link relations types, or we'll need to define 
> link relation types for all possible use-cases of Webfinger?
>
> With regard to CORS - I'm not actually acquainted with this 
> technology, but I see it is currently documented as W3C working draft, 
> so I don't suspect it is now widely-used (I may of course be wrong, so 
> please feel free to correct me), and I think there is no use putting 
> MUST requirement on its use in Webfinger.  You could better remove 
> your section on CORS from the document at all.
>
> http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00 
> which Webfinger elements may also be incorporated.
>
> I see the document is on APPSAWG agenda on the meeting, so I 
> anticipate it will soon become APPSAWG item doc.  I won't be on 
> meeting, but if you discuss the adaptation of Webfinger draft please 
> also take into account I'm in favor of such adaptation (consider this 
> as my 2p).
>
> Mykyta Yevstifeyev
>
> [email-masked]  <mailto:[email-masked]>

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 13 Nov 2011 08:46:39 +0800

> something we (and they -- possibly separate points) should pursue.

<hat type='individual'/>

I think that documentation of the webfinger protocol would be a good 
thing, given that it's somewhat widely used on the web. I do not have a 
strong opinion about whether it is needful for the APPSAWG to take on 
this work.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 13 Nov 2011 12:21:51 -0500

Peter,

> strong opinion about whether it is needful for the APPSAWG to take on

The main reason I see a need for the WG item is that we're proposing a new
URI scheme ("acct").  Presently, the text also recommends the use of CORS
and makes other normative statements.

I could be persuaded that "acct" should be pulled out into its own document,
since I can imagine the utility for it might be broader than Webfinger.  If
we did that, then perhaps there is less of an argument for it being a WG
item, but I'm not sure out the text would be progressed in that case.

In any case, I'll take input on the best way to go forward.  I don't care
how we get there, but I fully agree with you that it ought to be documented.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 13 Nov 2011 13:31:28 -0500

Mykyta,

I fear this might get complicated with references to the email documents.  Those documents are trying to solve a real problem, but Webfinger does not have some of those historical constraints.

Here’s my proposal: let’s not reference 5335 or 5322.  Rather, let’s only reference the generic URI syntax spec (RFC 3986).  Let’s define the URI scheme using the syntax found there:

   acctURI   = "acct:" userinfo "@" host

The productions “userinfo” and “host” are already defined.  Perhaps the one thing I don’t like is that “host” might be an IP address, but perhaps some people prefer that.

RFC 3986 already says that these components are UTF-8 encoded and then percent-escaped when a character is outside the ASCII character set range.

Would this be a suitable replacement for the current text?

With respect to your comments on link relations and URIs, I still do not understand.  You say that “nobody will benefit from link relation types defined by URIs”, but why not?  There are several already define and used today.  In any case, I would prefer that all link relation values (URI or simple strings) be defined outside of the Webfinger draft.  As I mentioned, there is already a registry, so one can be proposed any time.

Paul

From: "Mykyta Yevstifeyev (М. Євстіфеєв)" [mailto:[email-masked]] 
Sent: Saturday, November 12, 2011 12:32 AM
To: Paul E. Jones
Cc: [email-masked]
Subject: Re: [apps-discuss] Webfinger

Hello Paul,

Mykyta,

This is http://tools.ietf.org/html/draft-ietf-eai-rfc5335bis-13.  But please note that this document, unlike RFC 5335, introduced UTF-8 additions to *base* RFC 5322 productions.  This means that <addr-spec> will be defined as follows now:

So everything you will have to do is to have a note on 'acct' RI being possible to carry UTF8 characters and therefore being possibly IRIs.

I mean that Webfinger will have to operate on a variety of link relations in LRDD documents, and nobody will benefit from link relation types defined by URIs used there, as this eliminates the possibility for automatic processing.  So I ask whether we'll have to define non-URI link relation types for all the possible Webfinger use-cases?

Thanks.

6.4.2. EMAIL

...and the use might have email address different from Webfinger ID.  I've already pointed to http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00, which VCARDDAV WG works on, and so you may try to introduce some similar property for Webfinger IDs.  (You see, vCards may not carry all the variety of information, though some people actually think in other way, and thus it would be a good idea to provide a means of accessing some additional info.)

Yes, thanks as well.

 

Thanks!

Paul

All the best,
Mykyta Yevstifeyev

Hi Paul and all,

Mykyta Yevstifeyev

Folks,

We just submitted this:

Paul

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 14 Nov 2011 16:13:49 +0900

Hello Paul,

You can also have a look at RFC http://tools.ietf.org/html/rfc6068 and 
http://tools.ietf.org/html/draft-duerst-eai-mailto-01.

If I understand the acct: scheme correctly, it should be possible to 
make the syntax a subset of mailto:.

Regards,    Martin.

On 2011/11/14 3:31, Paul E. Jones wrote:
> This is http://tools.ietf.org/html/draft-ietf-eai-rfc5335bis-13.  But please note that this document, unlike RFC 5335, introduced UTF-8 additions to *base* RFC 5322 productions.  This means that<addr-spec>  will be defined as follows now:
>
>
>
>
> With respect to proposed 'acct' URI scheme:  how are you going to handle internationalization (i18n)?  We have RFC 5335 defining<utf8-addr-spec>  (Experimental RFC) and IESG has already approved EAI 5335bis, that will be Standards Track.  So will<utf8-addr-spec>  be allowed in 'acct' URIs in some way?
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 14 Nov 2011 09:07:35 -0500

Martin,

That's actually where I started, but decided to narrow the definition to addr-spec only, since we do not want a lot of the other syntax associated with "mailto".  However, feedback I got was that addr-spec might even be too broad.  Do we need anything more than acct:user@domain?  If not, I think RFC 3986 might define enough.  Would we lose anything?

Paul

> -----Original Message-----
> From: "Martin J. Dürst" [mailto:[email-masked]]
> Sent: Monday, November 14, 2011 2:14 AM
> To: Paul E. Jones
> Cc: "'\"Mykyta Yevstifeyev (М. Євстіфеєв)\"'"; [email-masked]
> > I fear this might get complicated with references to the email
> documents.  Those documents are trying to solve a real problem, but
> Webfinger does not have some of those historical constraints.
> >
> >
> >
> > Here’s my proposal: let’s not reference 5335 or 5322.  Rather, let’s
> only reference the generic URI syntax spec (RFC 3986).  Let’s define the
> URI scheme using the syntax found there:
> >
> > The productions “userinfo” and “host” are already defined.  Perhaps
> the one thing I don’t like is that “host” might be an IP address, but
> perhaps some people prefer that.
> >
> >
> >
> > RFC 3986 already says that these components are UTF-8 encoded and then
> percent-escaped when a character is outside the ASCII character set
> range.
> >
> >
> >
> > With respect to your comments on link relations and URIs, I still do
> not understand.  You say that “nobody will benefit from link relation
> types defined by URIs”, but why not?  There are several already define
> and used today.  In any case, I would prefer that all link relation
> values (URI or simple strings) be defined outside of the Webfinger
> draft.  As I mentioned, there is already a registry, so one can be
> proposed any time.
> >
> >
> >
> > Paul
> >
> >
> >
> > We would definitely want to ensure that Unicode is properly supported.
> In wasn’t aware of RFC 5335, so I’m glad you brought that to my
> attention.  Do you have a pointer to the bis draft so I can see exactly
> what is there?  I’d be fully in favor of using utf8-addr-spec.
> >
> >
> additions to *base* RFC 5322 productions.  This means that<addr-spec>
> URIs.  The definition of the link relation types is outside the scope of
> the Webfinger document itself.  RFC 6415 defines the structure of the
> documents and provides examples of some link relations and the order of
> processing.  RFC 5988 defines the link relations more generically and
> establishes the registry for them.  Do you think we need to say more
> about link relations beyond what those documents cover?
> >
> >
> [email-masked]), but you want to find more information.  If you
> have a vcard, then you have the user’s identity (via the email tag).  Or
> are you suggesting that we formally introduce the acct URI in vcard?
> That might make sense to do.  Can you clarify your proposal?
> >
> >
> > http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00,
> > which VCARDDAV WG works on, and so you may try to introduce some
> > similar property for Webfinger IDs.  (You see, vCards may not carry
> > all the variety of information, though some people actually think in
> > other way, and thus it would be a good idea to provide a means of
> > accessing some additional info.)
> >
> >
> >
> >
> >
> >
> dialog might take place, but not sure.  In any case, we can do this via
> the mailing list, too.
> >
> >
> > From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of "Mykyta Yevstifeyev (?. ?????????)"
> RFC 1288 finger protocol is now outdated, and you're right claiming that
> it provides no means of automatic processing.  BTW, RFC 1288 is
> currently at Draft Standard maturity level, which has been abandoned by
> RFC 6410, and we should therefore undertake something with this respect,
> as should we with respect of other Apps-related DSs, but that is what is
> to be discussed separately.
> >
> handle internationalization (i18n)?  We have RFC 5335 defining<utf8-
> addr-spec>  (Experimental RFC) and IESG has already approved EAI
> 5335bis, that will be Standards Track.  So will<utf8-addr-spec>  be
> MUST requirement on its use in Webfinger.  You could better remove your
> anticipate it will soon become APPSAWG item doc.  I won't be on meeting,
> but if you discuss the adaptation of Webfinger draft please also take
> into account I'm in favor of such adaptation (consider this as my 2p).
> >
> > Mykyta Yevstifeyev
> >
> 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.
> >
> >
> >

---

From: "Mykyta Yevstifeyev (М. Євстіфеєв)" <[email-masked]>
Date: Mon, 14 Nov 2011 21:19:02 +0200

13.11.2011 20:31, Paul E. Jones wrote:
> only reference the generic URI syntax spec (RFC 3986).  Let’s define 
> the URI scheme using the syntax found there:
>

Again, if you re-use RFC 3986 productions, please have a look at RFC 
3987, a companion doc., defining IRIs and i18ned variants of <userinfo> 
and <host>.  I really doubt you'll manage to avoid i18n issues anyway :-)

> perhaps some people prefer that.

Yes, and that is also an issue.  RFC 5322/i18n addition defined a very 
suitable production for this case, I think, so please re-consider 
returning to them.

> percent-escaped when a character is outside the ASCII character set range.
>

Shouldn't we allow direct UTF-8?

> draft.  As I mentioned, there is already a registry, so one can be 

How will there be an automatic processing if URI relation types are only 
suitable for humans as they need to follow that URI to know out the 
meaning of the rel.?  Moreover, is that possible to define that variety 
of ever possible link relations for Webfinger?

Mykyta Yevstifeyev

> Paul
>
> *From:*"Mykyta Yevstifeyev (М. Євстіфеєв)" [mailto:[email-masked]]
> *Sent:* Saturday, November 12, 2011 12:32 AM
> *To:* Paul E. Jones
> *Cc:* [email-masked]
> relations in LRDD documents, and nobody will benefit from link 
> relation types defined by URIs used there, as this eliminates the 
> possibility for automatic processing.  So I ask whether we'll have to 
> define non-URI link relation types for all the possible Webfinger 
> use-cases?
>
>
> <mailto:[email-masked]> 
> *To:* [email-masked] <mailto:[email-masked]>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 16 Nov 2011 18:06:18 +0800

> how we get there, but I fully agree with you that it ought to be documented.

Your point about the 'acct' URI scheme makes sense. I don't see a strong
need to pull it into a separate spec, but perhaps that's because I don't
know of other uses for the scheme outside of webfinger.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Wed, 16 Nov 2011 09:29:56 -0500

> know of other uses for the scheme outside of webfinger.

I don't think this needs to break that off into a separate doc. I'll also weigh in on the fact that this can certainly be progressed as an AD-sponsored independent submission, but given the choice, I tend to agree that there would be a benefit to have it be a WG item based on the normative addition introduced by 'acct' URI and the added WG focus in reviewing.

Regards,

Gonzalo

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 19 Nov 2011 08:03:05 -0700

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

   {
      "subject":"http://example.com/xy",

      "properties":{
        "http://spec.example.net/color":"red"
      },

      "links":[
        {
          "rel":"hub",
          "href":"http://example.com/hub",
        },
        {
          "rel":"hub",
          "href":"http://example.com/another/hub",
        },
        {
          "rel":"author",
          "href":"http://example.com/john",
        },
        {
          "rel":"author",
          "template":"http://example.com/author?q=http%3A%2F%2Fexample.com%2Fxy"
        }
      ]
    }

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.

EHL

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

Folks,

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.

Paul

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 19 Nov 2011 08:04:41 -0700

This can be further improved by specifying another 'rel' query filter to return only matching links, but that's less important to me.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Saturday, November 19, 2011 7:03 AM
To: Paul E. Jones; [email-masked]
Cc: Joseph Smarr
Subject: Re: [apps-discuss] Webfinger

   {

      "properties":{

      "links":[
        {
          "rel":"hub",

EHL

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

Folks,

We just submitted this:

Paul

---

From: Blaine Cook <[email-masked]>
Date: Sat, 19 Nov 2011 15:40:07 +0000

On 19 November 2011 15:03, Eran Hammer-Lahav <[email-masked]> wrote:

One minor objection:

> 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.

The '?resource' form of host-meta responses shouldn't be *required*,
since many providers will be unable to provide dynamic responses from
their host-meta location.

b.

---

From: "Mykyta Yevstifeyev (М. Євстіфеєв)" <[email-masked]>
Date: Sun, 20 Nov 2011 07:05:51 +0200

19.11.2011 17:03, Eran Hammer-Lahav wrote:
>
> 3.Are there reasons not to mandate HTTPS?
>

I don't think the document should put MUST on using HTTPS.  RFC 6415 
specified that host-meta document can be located using both HTTP and 
HTTPS, and I don't see a reason to constrain this in Webfinger.  Maybe 
the spec. should repeat that both HTTP and secured variants may be used.

Mykyta Yevstifeyev

---

From: Goix Laurent Walter <[email-masked]>
Date: Mon, 21 Nov 2011 11:26:31 +0100

+1 for this. There may not be the need for HTTPS all the time. Some security could be provided using XRD signature, which may be considered enough by some implementations.

Also I do not see why JRD need be mandated instead of XRD, which existed long before and is already used and referenced by several specs, which may not be aware/akeen to also support json.
I guess it also relates to which entity will use webfinger. My understand is that nowadays a webfinger client is implemented by a network resource for federation purposes more than within some javascript code. I can understand future usages for a direct javascript invocation but wouldn’t limit to it, to keep consistency with XRD.

walter

Da: [email-masked] [mailto:[email-masked]] Per conto di "Mykyta Yevstifeyev (?. ?????????)"
Inviato: domenica 20 novembre 2011 6.06
A: [email-masked]
Oggetto: Re: [apps-discuss] Webfinger

Are there reasons not to mandate HTTPS?

I don't think the document should put MUST on using HTTPS.  RFC 6415 specified that host-meta document can be located using both HTTP and HTTPS, and I don't see a reason to constrain this in Webfinger.  Maybe the spec. should repeat that both HTTP and secured variants may be used.

Mykyta Yevstifeyev
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.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 21 Nov 2011 10:49:10 -0500

Eran,

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?)

Paul

From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Saturday, November 19, 2011 10:03 AM
To: Paul E. Jones; [email-masked]
Cc: Joseph Smarr; Gonzalo Salgueiro; Blaine Cook
Subject: RE: [apps-discuss] Webfinger

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).

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

   {

      "properties":{

      },

      "links":[

        {

          "rel":"hub",

        },

        {

          "rel":"hub",

        },

        {

          "rel":"author",

        },

        {

          "rel":"author",

        }

      ]

    }

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

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).

EHL

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

Folks,

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.

Paul

---

From: Blaine Cook <[email-masked]>
Date: Mon, 21 Nov 2011 17:53:42 +0000

> draft.  However, I would personally prefer to give both XML and JSON equal

Implementations of XML-based host-meta clients are significantly more
complex than JSON implementations. To completely abandon XML-based
host-meta would have been impossible, but JSON is vastly preferred. To
lower the barrier for Webfinger adoption, +1 for JSON as a strong
recommendation over XML. It's still early days, so existing
implementations shouldn't be given undue weight.

> 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?

host-meta does not necessarily have security implications. Webfinger
almost certainly does, and as such should mandate HTTPS.

b.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 21 Nov 2011 13:27:06 -0500

> http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

One general comment I have is that there seems to be a lot of overlap with
features already in vCard or that could be defined as extensions to vCard. Let's
take for example one example from the draft:

     <?xml version="1.0" encoding="UTF-8"?>
     <XRD xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0">
       <Subject>acct:[email-masked]</Subject>
       <Link rel="http://webfinger.net/rel/avatar"
             href="http://example.com/bob/images/avatar.jpg"/>
       <Link rel="blog"
             href="http://example.net/bob/blog/"/>
       <Link rel="vcard"
             href="http://example.com/bob/vcard.vcf"/>
       <Link rel="http://specs.openid.net/auth/2.0/provider"
             href="https://openid.example.com/bob"/>
       <Link rel="share" href="http://example.com/bob/public/"/>
       <Link rel="http://webfinger.net/rel/profile-page"
             href="http://example.com/bob/profile/"/>
     </XRD>

All of the <Link> elements, except the one pointing to the vCard itself, could
be contained inside the vCard.

Did you look at vCard and find it inappropriate for your needs?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Blaine Cook <[email-masked]>
Date: Mon, 21 Nov 2011 18:57:12 +0000

+1 - Ideally, the webfinger profile would link to a VCard; however,
there are many links within a webfinger profile that might be
inappropriate for vcards, and as such it seemed prudent to not confuse
the two.

b.

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 21 Nov 2011 14:13:25 -0500

Simon,

There is certainly some overlap with the kinds of information Webfinger
provides and vcard provides.  However, Webfinger solves a problem vcard was
not designed to solve: finding the user's information in the first place.
If I already have a vcard in hand, that's great, but I usually do not.

You can imagine a point in the future where one may not even need to have an
address book containing anything more than email (er, "acct" URIs).  The
email client, phone application, web portal, etc. could grab all of the
other information as needed via Webfinger.  I would hope vcard would be a
part of that.

As Blane mentioned separately, some data that might be provided via
Webfinger (i.e., some link relations) may not be appropriate for a vcard.
For example, my list of identity providers may not be secret, but probably
not what I'd want to publish via a vcard.

We've had some discussion on whether link relations should be defined as a
part of the Webfinger spec or separately.  It seems most people are of the
opinion that they should be defined in a separate document.  Thus, I'd
invite you to work on the vcard link relation spec. This would be added to
the registry established by RFC 5988, I believe.

Paul

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Monday, November 21, 2011 1:27 PM
> To: Paul E. Jones
> Cc: [email-masked]; Joseph Smarr; Gonzalo Salgueiro
> One general comment I have is that there seems to be a lot of overlap
> with features already in vCard or that could be defined as extensions to
> vCard. Let's take for example one example from the draft:
> 
> All of the <Link> elements, except the one pointing to the vCard itself,
> could be contained inside the vCard.
>

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Mon, 21 Nov 2011 16:24:38 -0500

> implementations shouldn't be given undue weight.

I agree that XML should be retained, but JSON given preference.  This is a nice opportunity for a good old fashioned RFC 2119 'RECOMMENDED'.

--Gonzalo

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 21 Nov 2011 19:52:13 -0700

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).

EHL

From: Paul E. Jones [mailto:[email-masked]]
Sent: Monday, November 21, 2011 7:49 AM
To: Eran Hammer-Lahav; [email-masked]
Cc: 'Joseph Smarr'; 'Gonzalo Salgueiro'; 'Blaine Cook'
Subject: RE: [apps-discuss] Webfinger

Eran,

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

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?)

Paul

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

   {

      "properties":{

      "links":[
        {
          "rel":"hub",

EHL

Folks,

We just submitted this:

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 22 Nov 2011 12:27:03 -0500

A couple more questions on (3):

Why expand templates like this:

        {

          "rel":"author",

        }

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?

Paul

Sent: Monday, November 21, 2011 9:52 PM

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).

EHL

Eran,

Paul

   {

      "properties":{

      },

      "links":[

        {

          "rel":"hub",

        },

        {

          "rel":"hub",

        },

        {

          "rel":"author",

        },

        {

          "rel":"author",

        }

      ]

    }

EHL

Folks,

We just submitted this:

Paul

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 22 Nov 2011 11:32:37 -0700

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.

EHL

Sent: Tuesday, November 22, 2011 9:27 AM

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?

Paul

EHL

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

Eran,

Paul

   {

      "properties":{

      "links":[
        {
          "rel":"hub",

EHL

Folks,

We just submitted this:

Paul

---

From: Goix Laurent Walter <[email-masked]>
Date: Tue, 22 Nov 2011 19:41:55 +0100

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?

walter

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

EHL

Paul

EHL

Eran,

Paul

   {

      "properties":{

      "links":[
        {
          "rel":"hub",

EHL

Folks,

We just submitted this:

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 22 Nov 2011 13:48:59 -0500

Ah. yes.  Missed that suggestion on Subject.  That would work.

Thanks,

Paul

Sent: Tuesday, November 22, 2011 1:33 PM

EHL

        {

          "rel":"author",

        }

Paul

EHL

Eran,

Paul

   {

      "properties":{

      },

      "links":[

        {

          "rel":"hub",

        },

        {

          "rel":"hub",

        },

        {

          "rel":"author",

        },

        {

          "rel":"author",

        }

      ]

    }

EHL

Folks,

We just submitted this:

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 22 Nov 2011 13:54:35 -0500

Walter,

Including the ‘resource’ parameter could remove the need to further process
the templates on the client side and to perform a second query for the
“lrdd” XRD/JRD document.  If the server implementation does not support the
“resource” parameter, then the client would have to go about it as it would
today.

I like the idea of reducing complexity on the client, but if resource is
optional, then we do not actually reduce the complexity at all.  It does
potentially reduce the time required to fetch the information by one
round-trip to the server.  Is that worth it?  Perhaps.  For most data, there
are three queries:

1)      host-meta

2)      LRDD

3)      Actual data sought (e.g., an avatar file)

Introducing “resource” means we do to queries:

1)      host-mesa?resource

2)      Actual data sought (e.g., an avatar file)

That sounds good for a single piece of information.  However, if the client
needs to perform 10 queries for 10 links found, then that one additional
step is little savings.  I’m on the fence over it.

Paul

From: Goix Laurent Walter [mailto:[email-masked]] 
Sent: Tuesday, November 22, 2011 1:42 PM
To: Eran Hammer-Lahav; Paul E. Jones; [email-masked]
Cc: 'Joseph Smarr'
Subject: R: [apps-discuss] Webfinger

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?

walter

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

EHL

        {

          "rel":"author",

        }

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?

Paul

EHL

Eran,

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

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?)

Paul

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

   {

      "properties":{

      },

      "links":[

        {

          "rel":"hub",

        },

        {

          "rel":"hub",

        },

        {

          "rel":"author",

        },

        {

          "rel":"author",

        }

      ]

    }

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.

EHL

Folks,

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.

Paul

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. 

rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non è
necessario.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 22 Nov 2011 12:08:49 -0700

Still very much static. The two parameters I proposed are purely filters on the static data meant to make life easier for developers consuming this, given that 99% they just want one rel for one resource, and in JSON.

EHL

From: Goix Laurent Walter [mailto:[email-masked]]
Sent: Tuesday, November 22, 2011 10:42 AM
To: Eran Hammer-Lahav; Paul E. Jones; [email-masked]
Cc: 'Joseph Smarr'
Subject: R: [apps-discuss] Webfinger

walter

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

EHL

Paul

EHL

Eran,

Paul

   {

      "properties":{

      "links":[
        {
          "rel":"hub",

EHL

Folks,

We just submitted this:

Paul

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 22 Nov 2011 12:10:06 -0700

Not exactly. Resource gives all the links for that resource. Rel further reduces the selection. If you need 10, don't use rel, just resource.

EHL

From: Paul E. Jones [mailto:[email-masked]]
Sent: Tuesday, November 22, 2011 10:55 AM
To: 'Goix Laurent Walter'; Eran Hammer-Lahav; [email-masked]
Cc: 'Joseph Smarr'
Subject: RE: [apps-discuss] Webfinger

Walter,

Including the 'resource' parameter could remove the need to further process the templates on the client side and to perform a second query for the "lrdd" XRD/JRD document.  If the server implementation does not support the "resource" parameter, then the client would have to go about it as it would today.

I like the idea of reducing complexity on the client, but if resource is optional, then we do not actually reduce the complexity at all.  It does potentially reduce the time required to fetch the information by one round-trip to the server.  Is that worth it?  Perhaps.  For most data, there are three queries:

1)      host-meta

2)      LRDD

Introducing "resource" means we do to queries:

1)      host-mesa?resource

That sounds good for a single piece of information.  However, if the client needs to perform 10 queries for 10 links found, then that one additional step is little savings.  I'm on the fence over it.

Paul

From: Goix Laurent Walter [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, November 22, 2011 1:42 PM
To: Eran Hammer-Lahav; Paul E. Jones; [email-masked]<mailto:[email-masked]>
Cc: 'Joseph Smarr'
Subject: R: [apps-discuss] Webfinger

walter

EHL

Paul

EHL

Eran,

Paul

   {

      "properties":{

      "links":[
        {
          "rel":"hub",

EHL

Folks,

We just submitted this:

Paul

---

From: Goix Laurent Walter <[email-masked]>
Date: Wed, 23 Nov 2011 09:45:24 +0100

All,

I am not sure that making the host-meta itself act as a proxy for resource-specific information is the best option.

There are probably different use cases we are thinking of:

- one is related to a server that wishes to interact with (multiple) users on another server.

- another (more unclear to me) is related to a web app directly requesting specific information about a remote user

For the first scenario the local server would probably retrieve the remote host-meta once, cache it and then perform queries for each user using the lrdd link template. Also typically this large amount of users may not be known simultaneously, so no need for specifying a list of users (resources) in the same query. However I would assume in most cases the urls/templates for the target rels in the single resource descriptor provided by the remote server may often be along the same pattern. This may call for an easier mechanism for a server to discover/cache not only the lrdd template but the other rels it needs (avatar, profile-page, etc): I can understand this may not always be feasible but at least it would save numerous queries.

In the second one the web app typically would ideally like a single request (json) to get a specific info (1 or more rels) about a specific user (resource). This calls for some sort of standard API but I'm not sure it is host-meta responsibility to define it. In principle this would be like standardizing the lrdd endpoint and its parameters ('rel' and 'resource/uri').

Summarizing, what about rethinking the following:

1- standardize (under webfinger) the lrdd endpoint (e.g as ".well-known/lrdd[.json]") so that we can save one invocation from a web app

2- enable/suggest this same lrdd endpoint to provide back rels as templates when no specific resource is requested. This may require the definition of additional variables ({}) to refer to the username only for example (in general to give more flexibility to the hosting server), whilst at the same time potentially enabling the requesting server to cache these templates and use them to retrieve user information more easily/frequently

Probably in both cases the entity performing the invocation knows already which rels is needs, so filters here may be useful although not a must.

Here are some examples:

Ø  GET /.well-known/lrdd.json?resource=acct:[email-masked]&rel=hub&rel=author HTTP/1.1

   {
      "subject":"acct:[email-masked]",

      "links":[
        {
          "rel":"hub",
          "href":"http://example.com/xy/hub",
        },
        {
          "rel":"author",
          "href":"http://example.com/xy",
        },
        {
          "rel":"author",
          "template":"http://example.com/author?q=acct:xy%40example.com"
        }
      ]
    }

Ø  GET /.well-known/lrdd?rel=hub&rel=author HTTP/1.1

<?xml version="1.0" encoding="UTF-8"?>
     <XRD xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0">
       <Subject>example.com</Subject> <!-- host name here -->
       <Link rel="hub"
             template="http://example.com/{username}/hub"/> <!-- {username} could be defined to refer to that part only of the URI. Works with acct: URI only... -->
       <Link rel="author" template="http://example.com/{username}"/>
       <Link rel="author" template="http://example.com/author?q={uri}"/>
     </XRD>

Thoughts?
walter

Da: Eran Hammer-Lahav [mailto:[email-masked]]
Inviato: martedì 22 novembre 2011 20.10
A: Paul E. Jones; Goix Laurent Walter; [email-masked]
Cc: 'Joseph Smarr'
Oggetto: RE: [apps-discuss] Webfinger

EHL

Walter,

1)      host-meta

2)      LRDD

1)      host-mesa?resource

Paul

walter

EHL

Paul

EHL

Eran,

Paul

   {

      "properties":{

      "links":[
        {
          "rel":"hub",

EHL

Folks,

We just submitted this:

Paul

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 24 Nov 2011 04:34:42 +0100

>http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-00.txt

There:

   Suppose you meet somebody at a party and they provide you with their
   email address.  After the party, you decide to visit your new
   friend's blog to learn more about them.  How do you find it?  You
   could search for your friend's name on the Internet or on various
   social networking sites, but sometimes it is very hard to locate a
   person or information about a person with merely an email address or
   a name.

I believe the technical term for that is "cyberstalking". What are you
planning to do to ensure the draft properly addresses security, privacy,
and netiquette issues? Right now the document seems to omit the reasons
for why the finger protocol did not gain traction, which revolve around
privacy and social engineering security issues, does not discuss neti-
quette at all, just has a "if you don't like it, don't use it" remark
in the Security Considerations, and has an ironic "Author's Addresses"
section.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/