Subject: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 16 Nov 2012 23:18:28 -0500

Folks,

I published a new -03 version of the WebFinger draft.  I made substantial
changes throughout the document, with changes in nearly every section.  The
changes should be in line with the views of the group and, most notably,
gets rid of everything related to XRD, introduces a new
/.well-known/webfinger resource, and species the default format to be JRD.

Dependencies on RFC 6415 are removed, except for the reference to the JRD
document itself.

I know there was a request for more "real-world" examples.  Mike was going
to provide one, but I certainly welcome others if you think it might be
useful.  I tried to make use of most JRD features so that developers would
see at least one example.

I did find one error right after publishing the draft.  In the example near
the bottom of page 4, the word "properties" should be "titles" in the JRD.
I used two different languages to illustrate how to add a title to a link.

Your comments are certainly welcome!

Paul

---

From: Brad Fitzpatrick <[email-masked]>
Date: Sat, 17 Nov 2012 17:51:04 -0800

This is wonderful.  Thank you!

Some comments, all minor:

are the rels in the non-normative section 4.1 and 4.2 real? (i.e. avatar,
profile-page, blog, smtp-server)  like it or not, people will use them if
they're not.

the HTTPS-to-HTTP safeguards in section 5.1 look useless.  what are you
trying to protect?  I would just say MUST use https first, MAY fall back to
http, servers SHOULD serve on https, MAY serve on http, clients SHOULD NOT
trust anything for anything important not over https.  (certainly some
things I can imagine being valid over http… but not tons)  But all the
stuff about clients dealing with 4xx vs 5xx vs 2xx vs TCP connection
failures seems useless.  A MITM could just force https connection errors
and hide any 4xx / 5xx anyway.

section 5.3, "rel" parameter: the example with a URL rel as well as a token
rel might lead to confusion on whether the client's rel query is an exact
match or a substring match.  Maybe worth clarifying.

section 5.4: love it.

section 6: I've tripped over reading this section a few times now in
different drafts.  I don't like the MUST sentence (starting with
"Specifically, all …") when that sentence alone is not a MUST.  The intent
of the sentence is that it's only a MUST if the previous sentence is true
("intended for public consumption").  And "MUST support CORS" doesn't
clarify what "support" means--- having the header vs having the header with
an open "*" policy.  I would rephrase the whole thing like:

   "WebFinger is most useful when it is accessible without restrictions on
the Internet, including web browsers. Therefore, when serving content
intended for public consumption, WebFinger servers MUST advertise a public
Cross-Origin Resource Sharing (CORS) header.  Specifically, public
responses MUST include the following HTTP header:"

section 7: I might also note that despite the "avatar" and "blog" examples
above, it's not assumed that people would put their personal information
(social networking-related or otherwise) into their WebFinger document.
 Rather, for social networking applications, it's assumed that WebFinger
will merely contain pointers to other servers which then require auth.
 WebFinger exists just to bootstrap that discovery, and not to disseminate
personal information itself.

section 9: oh wait, this is much like section 7.  can we merge these two
sections a bit?

On Fri, Nov 16, 2012 at 8:18 PM, Paul E. Jones <[email-masked]>wrote:

> Folks,****
> ** **
> ****
> ** **
> document itself.****
> ** **
> I know there was a request for more “real-world” examples.  Mike was going
> see at least one example.****
>
> ** **
>
> I did find one error right after publishing the draft.  In the example
> near the bottom of page 4, the word “properties” should be “titles” in the
> JRD.  I used two different languages to illustrate how to add a title to a
> link.****
>
> ** **
>
> Your comments are certainly welcome!****
>
> ** **
>
> Paul****
>
> ** **
>

---

From: Dick Hardt <[email-masked]>
Date: Sat, 17 Nov 2012 18:14:26 -0800

I agree with Brad, this is a great improvement! Thanks Paul!

A few comments on Brad's comments and a couple extras.

There are a number of other standards based nits, but I would suggest let's get the issues below dealt with and then can dig into nits.

On Nov 17, 2012, at 5:51 PM, Brad Fitzpatrick <[email-masked]> wrote:

> are the rels in the non-normative section 4.1 and 4.2 real? (i.e. avatar, profile-page, blog, smtp-server)  like it or not, people will use them if they're not.

Let's get clear on what these are. Is "rel" : "http://packetizer.com/rel/blog" really going to be the standard way to query for a blog?

> 
> the HTTPS-to-HTTP safeguards in section 5.1 look useless.  what are you trying to protect?  I would just say MUST use https first, MAY fall back to http, servers SHOULD serve on https, MAY serve on http, clients SHOULD NOT trust anything for anything important not over https.  (certainly some things I can imagine being valid over http… but not tons)  But all the stuff about clients dealing with 4xx vs 5xx vs 2xx vs TCP connection failures seems useless.  A MITM could just force https connection errors and hide any 4xx / 5xx anyway.

+1

5.2

Why is there a preferred order for the JSON? That seems weird, and difficult to do if you are serving dynamically and using an object->JSON library to output the JSON.

> section 7: I might also note that despite the "avatar" and "blog" examples above, it's not assumed that people would put their personal information (social networking-related or otherwise) into their WebFinger document.  Rather, for social networking applications, it's assumed that WebFinger will merely contain pointers to other servers which then require auth.  WebFinger exists just to bootstrap that discovery, and not to disseminate personal information itself.

+1

> 
> section 9: oh wait, this is much like section 7.  can we merge these two sections a bit?

These should stay separate. Security Considerations is a standard RFC section. (7) is about Access Control.

> 
> 
> On Fri, Nov 16, 2012 at 8:18 PM, Paul E. Jones <[email-masked]> wrote:
> Folks,
> 
>  
> 
> I published a new -03 version of the WebFinger draft.  I made substantial changes throughout the document, with changes in nearly every section.  The changes should be in line with the views of the group and, most notably, gets rid of everything related to XRD, introduces a new /.well-known/webfinger resource, and species the default format to be JRD.
> 
>  
> 
> Dependencies on RFC 6415 are removed, except for the reference to the JRD document itself.
> 
>  
> 
> I know there was a request for more “real-world” examples.  Mike was going to provide one, but I certainly welcome others if you think it might be useful.  I tried to make use of most JRD features so that developers would see at least one example.
> 
>  
> 
> I did find one error right after publishing the draft.  In the example near the bottom of page 4, the word “properties” should be “titles” in the JRD.  I used two different languages to illustrate how to add a title to a link.
> 
>  
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 18 Nov 2012 16:35:03 -0500

Brad,

Comments below:

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brad Fitzpatrick
Sent: Saturday, November 17, 2012 8:51 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt

PEJ: The first paragraph in section 4 says that the entire section is non-normative (and I’ll make sentence more direct).  Some of the rels are “real” in the sense that people do use them.   Some that look like they might defined,  like “vcard”, are not defined.  I think it’s important to show rel values that are simple tokens and some that are URIs, but I’m not worried if people use any of these.  I doubt the printer example ever would be defined, but the others likely would.  Suggestions?

PEJ: I tried to keep this simple. If a connection can be established using HTTPS, use that.  Only if a connection cannot be established (e.g., there is nothing listening on 443), then use HTTP.  The other language is there only to prevent a client from trying HTTPS and then HTTP, moving back and forth like a kid going to the mother and father trying to get permission to do something ;-)

section 5.3, "rel" parameter: the example with a URL rel as well as a token rel might lead to confusion on whether the client's rel query is an exact match or a substring match.  Maybe worth clarifying.

PEJ: OK.. I’ll try.

section 5.4: love it.

section 6: I've tripped over reading this section a few times now in different drafts.  I don't like the MUST sentence (starting with "Specifically, all …") when that sentence alone is not a MUST.  The intent of the sentence is that it's only a MUST if the previous sentence is true ("intended for public consumption").  And "MUST support CORS" doesn't clarify what "support" means--- having the header vs having the header with an open "*" policy.  I would rephrase the whole thing like:

   "WebFinger is most useful when it is accessible without restrictions on the Internet, including web browsers. Therefore, when serving content intended for public consumption, WebFinger servers MUST advertise a public Cross-Origin Resource Sharing (CORS) header.  Specifically, public responses MUST include the following HTTP header:"

PEJ: I think we can simplify this even further.  Here’s what I propose:

WebFinger is most useful when it is accessible without restrictions on the Internet, including web browsers.  Therefore, WebFinger servers MUST support Cross-Origin Resource Sharing (CORS) [10] by including the following HTTP header in responses:

                Access-Control-Allow-Origin: *

Enterprise WebFinger servers that wish to restrict access to information from external entities SHOULD use a more restrictive Access-Control-Allow-Origin header.

PEJ: That’s it… the whole section.  One might argue that the MUST and SHOULD contradict. However, there is a desire to allow enterprise servers to be more restrictive.

PEJ: I’m one example of a person who did put info out there directly. Few people will do that.  Rather, it will be populated via social networking sites (as you note), corporate directories, or somewhere else.  That said, what else do you want to add here, exactly?

PEJ: Yeah, we can certainly do that.  I’ll just move it.  I’m not sure how to merge it, though.  I invite suggestions. :-)

Paul

Folks,

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 18 Nov 2012 16:40:22 -0500

Dick,

Comments below:

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Dick Hardt
Sent: Saturday, November 17, 2012 9:14 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt

There are a number of other standards based nits, but I would suggest let's
get the issues below dealt with and then can dig into nits.

Let's get clear on what these are. Is "rel" :
"http://packetizer.com/rel/blog" really going to be the standard way to
query for a blog?

PEJ: They could.  The challenge is that we have no other URI type defined
for this purpose.  For the examples, we have a chicken and egg problem.

the HTTPS-to-HTTP safeguards in section 5.1 look useless.  what are you
trying to protect?  I would just say MUST use https first, MAY fall back to
http, servers SHOULD serve on https, MAY serve on http, clients SHOULD NOT
trust anything for anything important not over https.  (certainly some
things I can imagine being valid over http. but not tons)  But all the stuff
about clients dealing with 4xx vs 5xx vs 2xx vs TCP connection failures
seems useless.  A MITM could just force https connection errors and hide any
4xx / 5xx anyway.

+1

5.2

Why is there a preferred order for the JSON? That seems weird, and difficult
to do if you are serving dynamically and using an object->JSON library to
output the JSON.

section 7: I might also note that despite the "avatar" and "blog" examples
above, it's not assumed that people would put their personal information
(social networking-related or otherwise) into their WebFinger document.
Rather, for social networking applications, it's assumed that WebFinger will
merely contain pointers to other servers which then require auth.  WebFinger
exists just to bootstrap that discovery, and not to disseminate personal
information itself.

+1

These should stay separate. Security Considerations is a standard RFC
section. (7) is about Access Control.

PEJ: What if we took section 7 and put all of the contents in as the second
paragraph in 9?  Would you like it there or prefer it separate?  I have no
strong preference.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 18 Nov 2012 17:02:44 -0500

Dick,

These should be separate drafts.  I agree "blog" is good, but there are
surely more.  A lot of good ones are defined under webfinger.net, too.

But I would really prefer to not slow down this draft with addition of link
relation values.  If somebody (you?) wants to start a WebFinger Link
Relations document, I think it would be timely.

Paul

Let's define some then! This is the one area that is vague and IMHO is a
barrier to adoption. What should the "rel" values be for items that I want
to publish? If we don't spec the common ones, we will end up with several
different identifiers for the same thing. Challenge of course is that
getting agreement on schema is always fun, but better to have some that will
be used that are not already defined.

Need to add an IANA section for that of course.

"blog" is a good one :)

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 18 Nov 2012 17:43:29 -0500

Dick,

The first example is fairly meaningful in that most of the rels are in use. The vcard one is not, but I'd like to see that defined. I'd be OK with using the token 'blog' if we're going to agree on that.

The second example does not use real values, but it is important in that it shows use of properties.

The third example is important in that it related to non-humans.

We are supposed to get one more example related to OpenID Connect, but that is not in there yet.

Paul

-------- Original Message --------
From: Dick Hardt <[email-masked]>
Sent: Sun Nov 18 17:22:37 EST 2012
To: "Paul E. Jones" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt

Hi Paul

I agree it should be separate drafts. I'd be willing to edit if there is interest. My interest in WebFinger is as a consumer much more than a publisher - so I don't feel I am a domain expert.

Is it possible to have meaningful examples with existing "rel" values, or do we need to have some others defined to have meaningful examples?

-- Dick

On Nov 18, 2012, at 2:02 PM, "Paul E. Jones" <[email-masked]> wrote:

> Dick,
>  
> These should be separate drafts.  I agree “blog” is good, but there are surely more.  A lot of good ones are defined under webfinger.net, too.
>  
> But I would really prefer to not slow down this draft with addition of link relation values.  If somebody (you?) wants to start a WebFinger Link Relations document, I think it would be timely.
>  
> Paul
>  
>  
> PEJ: They could.  The challenge is that we have no other URI type defined for this purpose.  For the examples, we have a chicken and egg problem.
>  
> Let's define some then! This is the one area that is vague and IMHO is a barrier to adoption. What should the "rel" values be for items that I want to publish? If we don't spec the common ones, we will end up with several different identifiers for the same thing. Challenge of course is that getting agreement on schema is always fun, but better to have some that will be used that are not already defined.
>

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Sun, 18 Nov 2012 21:34:07 -0500

Dick - 

I made a commitment to the APPSAWG chairs that I'd take the acct link relation (that we just removed from the latest Webfinger draft) and put it into a separate draft. I think it makes a lot of sense to add that to the effort proposed below of standardizing the set of useful link relations for Webfinger. With that in mind, I'll offer to help merge those parallel efforts and co-author such a document with you.

Cheers,

Gonzalo

---

From: Goix Laurent Walter <[email-masked]>
Date: Mon, 19 Nov 2012 12:07:30 +0100

+1 for the suggestions on the link relations.
I definitely think it would be valuable to start consider:
- existing iana-registered link relations that can be useful with webfinger. This could act as appendix to the draft
- work on one or more separate drafts to register additional meaningful link rels. I am thinking especially at the context of social networks (federation) where most of the current most popular link rels are not yet registered (updates-from, avatar, etc)

I'd be happy to help as well.

walter

> -----Messaggio originale-----
> Da: [email-masked] [mailto:[email-masked]] Per
> conto di Gonzalo Salgueiro
> Inviato: lunedì 19 novembre 2012 3.34
> A: Dick Hardt
> Cc: [email-masked]; General discussion of application-layer
> protocols
> Oggetto: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt
>
> Dick -
>
> I made a commitment to the APPSAWG chairs that I'd take the acct link relation
> (that we just removed from the latest Webfinger draft) and put it into a
> separate draft. I think it makes a lot of sense to add that to the effort
> proposed below of standardizing the set of useful link relations for
> Webfinger. With that in mind, I'll offer to help merge those parallel efforts
> and co-author such a document with you.
>
> Cheers,
>
> Gonzalo
>
> > I agree it should be separate drafts. I'd be willing to edit if there is
> interest. My interest in WebFinger is as a consumer much more than a publisher
> - so I don't feel I am a domain expert.
> >
> > Is it possible to have meaningful examples with existing "rel" values, or do
> we need to have some others defined to have meaningful examples?
> >
> > -- Dick
> >
> relation values.  If somebody (you?) wants to start a WebFinger Link Relations
> document, I think it would be timely.
> >>
> >> Paul
> >>
> >>
> barrier to adoption. What should the "rel" values be for items that I want to
> publish? If we don't spec the common ones, we will end up with several
> different identifiers for the same thing. Challenge of course is that getting
> agreement on schema is always fun, but better to have some that will be used
> that are not already defined.
> >>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

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: Goix Laurent Walter <[email-masked]>
Date: Mon, 19 Nov 2012 12:14:01 +0100

Very clean spec now, thanks paul for this huge cleanup!

i also believe that we should be careful with the link rels in the examples. Whenever the link rels mentioned are tokens and truly exist, I would suggest to reference the specific spec. in other cases we could either use uris under some example.net namespace, or simply state that the token used is fictitious at the time of writing.

Some other minor comments:

-          In section 3 I have not clear the purpose of the educational paragraph on link rels and the effective relation with webfinger based on the current text. Could we remove it?

-          In section 4.1 you mention “any valid alias for the user”. It may be cleaner to state “any valid URI as alias for the user” to emphasize the usage of uris

-          In section 5.2 I would suggest to invert the “expires” and “subject” bullets to mention required elements first.

Da: [email-masked] [mailto:[email-masked]] Per conto di Paul E. Jones
Inviato: domenica 18 novembre 2012 23.43
A: Dick Hardt
Cc: [email-masked]; [email-masked]
Oggetto: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt

Dick,

Paul
________________________________

Hi Paul

-- Dick

On Nov 18, 2012, at 2:02 PM, "Paul E. Jones" <[email-masked]<mailto:[email-masked]>> wrote:

Dick,

These should be separate drafts.  I agree “blog” is good, but there are surely more.  A lot of good ones are defined under webfinger.net<http://webfinger.net>, too.

Paul

PEJ: They could.  The challenge is that we have no other URI type defined for this purpose.  For! the examples, we have a chicken and egg problem.

Need to add an IANA section ! for that of course.

"blog" is a good one :)

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

---

From: Dick Hardt <[email-masked]>
Date: Sun, 18 Nov 2012 13:47:04 -0800

On Nov 18, 2012, at 1:40 PM, "Paul E. Jones" <[email-masked]> wrote:

> Dick,
>  
> Comments below:
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dick Hardt

"blog" is a good one :)

> PEJ: What if we took section 7 and put all of the contents in as the second paragraph in 9?  Would you like it there or prefer it separate?  I have no strong preference.

Sorry I was not clear. I think your current structure is good. I would rename (7) to be Access Control, which is not the same as Security Considerations.

---

From: Dick Hardt <[email-masked]>
Date: Sun, 18 Nov 2012 14:22:37 -0800

Hi Paul

-- Dick

---

From: Goix Laurent Walter <[email-masked]>
Date: Mon, 19 Nov 2012 18:09:51 +0100

Although it is an XRD, here is a good example of link rels widely used in the context of federated social networks [1].

Amongst them, it could be worth registering in the new draft:

-          http://webfinger.net/rel/profile-page -> "profile-page" ?

-          http://webfinger.net/rel/avatar -> "avatar" ?

-          http://schemas.google.com/g/2010#updates-from -> "activitystream" ?

to cite a few generic. I do expect others to remain URLs referred to a specific company/project but the ones above would definitely help in having a common framework for interoperability made of *registered* link rels.

walter

[1] http://identi.ca/main/xrd?uri=http://identi.ca/w3c

Da: [email-masked] [mailto:[email-masked]] Per conto di Dick Hardt
Inviato: domenica 18 novembre 2012 23.23
A: Paul E. Jones
Cc: [email-masked]; [email-masked]
Oggetto: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt

Hi Paul

-- Dick

Dick,

These should be separate drafts.  I agree "blog" is good, but there are surely more.  A lot of good ones are defined under webfinger.net<http://webfinger.net>, too.

Paul

"blog" is a good one :)

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

---

From: James M Snell <[email-masked]>
Date: Mon, 19 Nov 2012 09:19:26 -0800

On Mon, Nov 19, 2012 at 9:09 AM, Goix Laurent Walter <
[email-masked]> wrote:

>  Although it is an XRD, here is a good example of link rels widely used
> in the context of federated social networks [1].****
>
> ** **
>
> Amongst them, it could be worth registering in the new draft:****
>
> **-          **http://webfinger.net/rel/profile-page -> “profile-page” ?
>
Hmm.. does this one need a separate rel? We already have "about" (being
registered by my "additional link rels" draft). Given the usual purpose and
use of a profile page, rel="about" could serve the use case well.

> ****
>
> **-          **http://webfinger.net/rel/avatar -> “avatar” ?
>
+1

> ****
>
> **-          **http://schemas.google.com/g/2010#updates-from ->
> “activitystream” ?****
>
> **
>
"activitystream" is too specific, I think... Perhaps just "updates".

- James

>  **
>
> to cite a few generic. I do expect others to remain URLs referred to a
> specific company/project but the ones above would definitely help in having
> a common framework for interoperability made of **registered** link rels.*
> ***
>
> ** **
>
> walter****
>
> ** **
>
> [1] http://identi.ca/main/xrd?uri=http://identi.ca/w3c ****
>
> ** **
>
> *Da:* [email-masked] [mailto:[email-masked]]
> *Per conto di *Dick Hardt
> *Inviato:* domenica 18 novembre 2012 23.23
> *A:* Paul E. Jones
>
> *Cc:* [email-masked]; [email-masked]
> *Oggetto:* Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt****
>
>  ** **
>
> Hi Paul****
>
> ** **
>
> interest. My interest in WebFinger is as a consumer much more than a
> publisher - so I don't feel I am a domain expert.****
>
> ** **
>
> Is it possible to have meaningful examples with existing "rel" values, or
> do we need to have some others defined to have meaningful examples?****
>
> ** **
>
> -- Dick****
>
> ** **
>
> On Nov 18, 2012, at 2:02 PM, "Paul E. Jones" <[email-masked]>
> wrote:****
>
>
>
> ****
>
> Dick,****
>
>  ****
>
> These should be separate drafts.  I agree “blog” is good, but there are
> surely more.  A lot of good ones are defined under webfinger.net, too.****
>
>  ****
>
> But I would really prefer to not slow down this draft with addition of
> link relation values.  If somebody (you?) wants to start a WebFinger Link
> Relations document, I think it would be timely.****
>
>  ****
>
> Paul****
>
>  ****
>
>  ****
>
> for this purpose.  For the examples, we have a chicken and egg problem.***
> *
>
>  ****
>
> getting agreement on schema is always fun, but better to have some that
> will be used that are not already defined.****
>
>  ****
>
> Need to add an IANA section for that of course.****
>
>  ****
>
> "blog" is a good one :)****
>
> ** **
>     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: James M Snell <[email-masked]>
Date: Mon, 19 Nov 2012 09:36:20 -0800

Just a quick note on this... I already have the existing "Additional Link
Relations" draft [1] in progress (currently submitted as an independent
submission) that registers link relations such as "about", "type",
"terms-of-service", "privacy-policy" and "preview". It would be possible to
pull this draft back and add a few more link relation types to it if
necessary. We would just need to identify the set of new link rels and I
could very easily drop them in or write up a quick second document based on
the same simple template.

[1] http://tools.ietf.org/html/draft-snell-additional-link-relations-06

That said, the "about" link relation can be used to link to both
profile-page and vcard type resources... differentiated, of course, by the
media type of the linked resource.

Also... We need to be careful not to get too specific with link relation
labels. The rel values themselves are intended to state the nature of the
relationship and not the type of resource it is. Having something like
{"rel":"updates","href":"http://example.org/my/blog","type":"text/html"}
should be generally preferable over something like {"rel":"blog","href":"
http://example.org/my/blog"}.

- James

On Sun, Nov 18, 2012 at 2:22 PM, Dick Hardt <[email-masked]> wrote:

> publisher - so I don't feel I am a domain expert.
>
> do we need to have some others defined to have meaningful examples?
>
> -- Dick
>
> wrote:

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 19 Nov 2012 23:55:13 -0500

Walter,

For the link relations… this gets tough.  I could certainly replace:

http://webfinger.net/rel/profile-page

with

http://example.com/rel/profile-page

However, the former is really used today.  I think we can be fairly safe in assuming “vcard” is going to exist one day.  We can probably agree that “blog” will exist.  I could make that one change.  But, what about the webfinger.net URIs?  Those are real, but there is nothing I can reference.  Since they are URIs rels, it should be expected.

For the text in section 3, I think you are referring to the bit about IRIs?  I forgot who provided that text, but it has been there for a while and I didn’t write it.  I, too, think it’s unnecessary at this point, but… what is the preference of the group?  (Especially whomever provided the text in the first place.)

For 4.1, I really meant “any valid alias”.  Not all URIs for a user are aliases that will return the same content.  In the follow-on sentence, I refer explicitly to the alias shown in the example.

In 5.2, the “expires” element is supposed to come first.  This is an error in RFC 6415.

Paul

From: Goix Laurent Walter [mailto:[email-masked]] 
Sent: Monday, November 19, 2012 6:14 AM
To: Paul E. Jones; Dick Hardt
Cc: [email-masked]; [email-masked]
Subject: R: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt

 

Dick,

Paul

  _____  

Hi Paul

-- Dick

Dick,

These should be separate drafts.  I agree “blog” is good, but there are surely more.  A lot of good ones are defined under  <http://webfinger.net> webfinger.net, too.

Paul

"blog" is a good one :)

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 20 Nov 2012 00:00:36 -0500

James,

I think the “updates-from” was intended to be an ATOM feed, though I might be wrong.  In your example, you show a blog.  But, at the same time we want to define “blog” as its own rel.

I think it’s important that we have a very narrow scope for any rel.  I don’t care what the values are, but we need to ensure there is no ambiguity in what a given token means.

Paul

From: James M Snell [mailto:[email-masked]] 
Sent: Monday, November 19, 2012 12:36 PM
To: Dick Hardt
Cc: Paul E. Jones; [email-masked]; IETF Apps Discuss
Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt

Just a quick note on this... I already have the existing "Additional Link Relations" draft [1] in progress (currently submitted as an independent submission) that registers link relations such as "about", "type", "terms-of-service", "privacy-policy" and "preview". It would be possible to pull this draft back and add a few more link relation types to it if necessary. We would just need to identify the set of new link rels and I could very easily drop them in or write up a quick second document based on the same simple template.

That said, the "about" link relation can be used to link to both profile-page and vcard type resources... differentiated, of course, by the media type of the linked resource. 

Also... We need to be careful not to get too specific with link relation labels. The rel values themselves are intended to state the nature of the relationship and not the type of resource it is. Having something like {"rel":"updates","href":"http://example.org/my/blog","type":"text/html"} should be generally preferable over something like {"rel":"blog","href":"http://example.org/my/blog"}. 

- James

Hi Paul

-- Dick

Dick,

Paul

"blog" is a good one :)

---

From: Goix Laurent Walter <[email-masked]>
Date: Tue, 20 Nov 2012 14:39:03 +0100

+1 for narrow & unambiguous rels with clear semantics that guarantee interop (btw I think we are deriving from the core webfinger discussion here so I changed the subject)

The link rels proposed by james in the draft are meaningful (I do have some doubts on about vs related, which is already registered). “avatar” could be added there in case the draft can serve as basis for this activity.

For “updates-from” indeed these are specific to activity streams represented in atom, and should not vary their meaning (besides a type parameter which could allow for json as well): for this reason the reference to activitystreams could be stronger imo. maybe “activities”?

walter

Da: [email-masked] [mailto:[email-masked]] Per conto di Paul E. Jones
Inviato: martedì 20 novembre 2012 6.01
A: 'James M Snell'; 'Dick Hardt'
Cc: [email-masked]; 'IETF Apps Discuss'
Oggetto: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt

James,

Paul

- James

On Sun, Nov 18, 2012 at 2:22 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
Hi Paul

-- Dick

Dick,

Paul

"blog" is a good one :)

_______________________________________________
apps-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Goix Laurent Walter <[email-masked]>
Date: Tue, 20 Nov 2012 14:57:11 +0100

Hi paul,

Comments in red w>

Da: Paul E. Jones [mailto:[email-masked]]
Inviato: martedì 20 novembre 2012 5.55
A: Goix Laurent Walter; 'Dick Hardt'
Cc: [email-masked]; [email-masked]
Oggetto: RE: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt

Walter,

w> This is my feeling as well that URIs rels should be referenceable. Anyway the “webfinger.net” ones are indeed used so they can be kept in the current examples (my comment was more for future work in having them registered to avoid this issue). Regarding simple tokens mentioned as examples (vcard, blog) I do have some more doubts if they are not registered yet and as such if we don’t replace them with example URIs I would suggest to state explicitly that they are fictitious.

w> I was referring to that part yes.

w> I agree not all uris are aliases. My point was on clarifying that all aliases need to be URIS ☺. You may add at the end of that sentence “(as long as it is a URI)” or something similar.

w> right, I double-checked the xrd spec.
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. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

---

From: James M Snell <[email-masked]>
Date: Tue, 20 Nov 2012 07:42:04 -0800

On Tue, Nov 20, 2012 at 5:39 AM, Goix Laurent Walter <
[email-masked]> wrote:

>  +1 for narrow & unambiguous rels with clear semantics that guarantee
> interop (btw I think we are deriving from the core webfinger discussion
> here so I changed the subject)****
>
> **
>

Clear and unambiguous is good... overly specific is not. Remember that we
have the media type attribute to help make things less ambiguous... the
link rel itself should never be defined in terms of a single representation
type (e.g. "updates-from" could point to any type of resource, not just an
atom document).

- James

> **
>
> The link rels proposed by james in the draft are meaningful (I do have
> some doubts on about vs related, which is already registered). “avatar”
> could be added there in case the draft can serve as basis for this activity.
> ****
>
> ** **
>
> For “updates-from” indeed these are specific to activity streams
> represented in atom, and should not vary their meaning (besides a type
> parameter which could allow for json as well): for this reason the
> reference to activitystreams could be stronger imo. maybe “activities”?***
> *
>
> ** **
>
> walter****
>
> ** **
>
> *Per conto di *Paul E. Jones
> *Inviato:* martedì 20 novembre 2012 6.01
> *A:* 'James M Snell'; 'Dick Hardt'
> *Cc:* [email-masked]; 'IETF Apps Discuss'
> James,****
> I think the “updates-from” was intended to be an ATOM feed, though I might
> be wrong.  In your example, you show a blog.  But, at the same time we want
> to define “blog” as its own rel.****
>
> ** **
>
> I think it’s important that we have a very narrow scope for any rel.  I
> don’t care what the values are, but we need to ensure there is no ambiguity
> in what a given token means.****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* James M Snell [mailto:[email-masked]]
> *Sent:* Monday, November 19, 2012 12:36 PM
> *To:* Dick Hardt
> *Cc:* Paul E. Jones; [email-masked]; IETF Apps Discuss
> *Subject:* Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt****
>
> ** **
>
> the same simple template.****
>
> ** **
>
> [1] http://tools.ietf.org/html/draft-snell-additional-link-relations-06***
> *
>
> ** **
>
> media type of the linked resource. ****
>
> ** **
>
> http://example.org/my/blog"}. ****
>
> ** **
>
> - James****
>
> ** **
>
> On Sun, Nov 18, 2012 at 2:22 PM, Dick Hardt <[email-masked]> wrote:*
> ***
>
> Hi Paul****
>
> ** **
>
> https://www.ietf.org/mailman/listinfo/apps-discuss****
>
> ** **

---

From: Erik Wilde <[email-masked]>
Date: Tue, 20 Nov 2012 09:17:44 -0800

On 2012-11-20 7:42 , James M Snell wrote:
> On Tue, Nov 20, 2012 at 5:39 AM, Goix Laurent Walter
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>     interop (btw I think we are deriving from the core webfinger
>     discussion here so I changed the subject)____
> Clear and unambiguous is good... overly specific is not. Remember that
> we have the media type attribute to help make things less ambiguous...
> the link rel itself should never be defined in terms of a single
> representation type (e.g. "updates-from" could point to any type of
> resource, not just an atom document).

+1; specific rels when it comes to *why* a client would want to follow a 
link is good and should be a goal, specific rels when it comes to *what* 
a client expects to find at the other end of the link (in terms of a 
specific media type, for example) should be avoided.

cheers,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

---

From: Mike Kelly <[email-masked]>
Date: Tue, 20 Nov 2012 17:21:24 +0000

On Tue, Nov 20, 2012 at 5:17 PM, Erik Wilde <[email-masked]> wrote:
> link is good and should be a goal, specific rels when it comes to *what* a
> client expects to find at the other end of the link (in terms of a specific
> media type, for example) should be avoided.
>

Are there any objective reasons for this? Or is it just your opinion?

Cheers,
M

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 20 Nov 2012 12:44:53 -0500

If we can agree to add “vcard” and “blog” to the document James and/or Dick and/or Gonzalo are working on, the that would be best.  I’ll change the IMAP and SMTP server ones to be http://example.net/rel/imap-server, for example.  

I’ll remove the second paragraph in section 3.  Since we’re removing that and there is already some dialog in section 2, I propose we add one more sentence to the end of Section 2 that says:

WebFinger also uses the "rel" attribute, where the "rel" value is either a single IANA-registered link relation type or a URI.

It is stated in section 5.4 that a host may return one or more URIs that serve as aliases.  However, I’ll add another sentence in Section 4.  It’s important that we ensure we have all of the normative language somewhere other than Section 4, though.  How about this right after “any valid alias for the user might also be used.”:

An alias is a URI that is different from the “subject” URI that identifies the same entity.  In the above example, there is one “http” alias returned, though there might have been more than one.

Paul

From: Goix Laurent Walter [mailto:[email-masked]] 
Sent: Tuesday, November 20, 2012 8:57 AM
To: Paul E. Jones; 'Dick Hardt'
Cc: [email-masked]; [email-masked]
Subject: R: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt

Hi paul,

Comments in red w>

Walter,

with

w> I agree not all uris are aliases. My point was on clarifying that all aliases need to be URIS J. You may add at the end of that sentence “(as long as it is a URI)” or something similar.

walter

---

From: Goix Laurent Walter <[email-masked]>
Date: Tue, 20 Nov 2012 18:49:25 +0100

+1 to all suggestions. Minor addition is to add a pointer to the iana link rel registry uri as informative reference.

Inviato: martedì 20 novembre 2012 18.45

Paul

Hi paul,

Comments in red w>

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Walter,

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 20 Nov 2012 12:52:25 -0500

I agree if it's just a format change (ATOM vs. RSS), but I would hope we can agree that if "updates-from" is one of those typed of feeds, that it would not apply to a blog and that blog should be a different rel.

Paul

-------- Original Message --------
From: James M Snell <[email-masked]>
Sent: Tue Nov 20 10:42:04 EST 2012
To: Goix Laurent Walter <[email-masked]>
Cc: "Paul E. Jones" <[email-masked]>, Dick Hardt <[email-masked]>, "[email-masked]" <[email-masked]>, IETF Apps Discuss <[email-masked]>
Subject: Re: [apps-discuss] Link rels

- James

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 20 Nov 2012 13:01:41 -0500

How do we do that?  The registry location might move one day.  I note we don’t provide URLs to RFCs, likely for the same reason.

Paul

Sent: Tuesday, November 20, 2012 12:49 PM

Paul

Hi paul,

Comments in red w>

Walter,

with

walter

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 20 Nov 2012 18:07:38 +0000

On Nov 20, 2012, at 12:45 PM, "Paul E. Jones" <[email-masked]<mailto:[email-masked]>> wrote:

If we can agree to add “vcard” and “blog” to the document James and/or Dick and/or Gonzalo are working on, the that would be best.

We'll add those to the list for the draft Dick and I are working on for Webfinger rels.  We'll be coming to the list soon with a base set that we can get consensus on.

Cheers,

Gonzalo

---

From: t.petch <[email-masked]>
Date: Wed, 21 Nov 2012 08:54:16 +0000

----- Original Message -----
From: "Paul E. Jones" <[email-masked]>
To: "'Goix Laurent Walter'" <[email-masked]>;
"'Dick Hardt'" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, November 20, 2012 6:01 PM
Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt

How do we do that?  The registry location might move one day.  I note we
don’t provide URLs to RFCs, likely for the same reason.

<tp>
Paul

I am sure you don't really mean how:-) but it is quite a common practice
to include URLs to the IANA website as a quick awk will show.

Tom Petch

Paul

+1 to all suggestions. Minor addition is to add a pointer to the iana
link rel registry uri as informative reference.

If we can agree to add “vcard” and “blog” to the document James and/or
Dick and/or Gonzalo are working on, the that would be best.  I’ll change
the IMAP and SMTP server ones to be http://example.net/rel/imap-server,
for example.

I’ll remove the second paragraph in section 3.  Since we’re removing
that and there is already some dialog in section 2, I propose we add one
more sentence to the end of Section 2 that says:

WebFinger also uses the "rel" attribute, where the "rel" value is either
a single IANA-registered link relation type or a URI.

It is stated in section 5.4 that a host may return one or more URIs that
serve as aliases.  However, I’ll add another sentence in Section 4.  It’
s important that we ensure we have all of the normative language
somewhere other than Section 4, though.  How about this right after “any
valid alias for the user might also be used.”:

An alias is a URI that is different from the “subject” URI that
identifies the same entity.  In the above example, there is one “http”
alias returned, though there might have been more than one.

Paul

Hi paul,

Comments in red w>

Walter,

with

However, the former is really used today.  I think we can be fairly safe
in assuming “vcard” is going to exist one day.  We can probably agree
that “blog” will exist.  I could make that one change.  But, what about
the webfinger.net URIs?  Those are real, but there is nothing I can
reference.  Since they are URIs rels, it should be expected.

w> This is my feeling as well that URIs rels should be referenceable.
Anyway the “webfinger.net” ones are indeed used so they can be kept in
the current examples (my comment was more for future work in having them
registered to avoid this issue). Regarding simple tokens mentioned as
examples (vcard, blog) I do have some more doubts if they are not
registered yet and as such if we don’t replace them with example URIs I
would suggest to state explicitly that they are fictitious.

For the text in section 3, I think you are referring to the bit about
IRIs?  I forgot who provided that text, but it has been there for a
while and I didn’t write it.  I, too, think it’s unnecessary at this
point, but… what is the preference of the group?  (Especially whomever
provided the text in the first place.)

For 4.1, I really meant “any valid alias”.  Not all URIs for a user are
aliases that will return the same content.  In the follow-on sentence, I
refer explicitly to the alias shown in the example.

w> I agree not all uris are aliases. My point was on clarifying that all
aliases need to be URIS J. You may add at the end of that sentence “(as
long as it is a URI)” or something similar.

In 5.2, the “expires” element is supposed to come first.  This is an
error in RFC 6415.

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

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: Barry Leiba <[email-masked]>
Date: Wed, 21 Nov 2012 09:09:26 -0500

> How do we do that?  The registry location might move one day.  I note
> we don’t provide URLs to RFCs, likely for the same reason.

It's always a good idea to use the registry URL in an I-D, to be sure
that everyone (including IANA) knows which registry you're talking
about, and that there's no ambiguity.  Whether the URL remains in the
published RFC is a separate issue.

When you include registry URLs, IANA prefers that you omit the final
bit -- for link relations, use this:
   http://www.iana.org/assignments/link-relations/
...and NOT this:
   http://www.iana.org/assignments/link-relations/link-relations.xml

That way, if a registry is converted from HTML to XML or whatever
(perhaps from XML to JSON in the future?), the link you use will not
change.

Barry, Apps AD

---

From: Larry Masinter <[email-masked]>
Date: Thu, 22 Nov 2012 18:16:50 -0800

Negotiating controlled vocabularies is a difficult course. “narrow”, “unambiguous”, “clear semantics”, “guarantee interop” are great aspirations, but ultimately impossible. Ambiguity is intrinsic.

“minimize ambiguity”, “well-documented semantics” and “promote interoperability” would be more realistic.

Applications will use link relations, and some applications will apply specialized meaning to a link relation that other applications will not.

“The link relation registry should be maintained, such that documentation for applications that rely on particular link relations are easy to find from the link relation registry”.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Goix Laurent Walter
Sent: Tuesday, November 20, 2012 5:39 AM
To: Paul E. Jones; 'James M Snell'; 'Dick Hardt'
Cc: [email-masked]; 'IETF Apps Discuss'
Subject: [apps-discuss] Link rels

walter

Da: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] Per conto di Paul E. Jones
Inviato: martedì 20 novembre 2012 6.01
A: 'James M Snell'; 'Dick Hardt'
Cc: [email-masked]<mailto:[email-masked]>; 'IETF Apps Discuss'
Oggetto: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt

James,

Paul

From: James M Snell [mailto:[email-masked]]
Sent: Monday, November 19, 2012 12:36 PM
To: Dick Hardt
Cc: Paul E. Jones; [email-masked]<mailto:[email-masked]>; IETF Apps Discuss
Subject: Re: [apps-discuss] New draft-ietf-appsawg-webfinger-03.txt

- James

-- Dick

Dick,

Paul

"blog" is a good one :)

---

From: James M Snell <[email-masked]>
Date: Fri, 23 Nov 2012 08:57:01 -0800

On Thu, Nov 22, 2012 at 6:16 PM, Larry Masinter <[email-masked]> wrote:

> Negotiating controlled vocabularies is a difficult course. “narrow”,
> “unambiguous”, “clear semantics”, “guarantee interop” are great
> aspirations, but ultimately impossible. Ambiguity is intrinsic.****
>
> ** **
>
> “minimize ambiguity”, “well-documented semantics” and “promote
> interoperability” would be more realistic.****
>
> ** **
>
> Applications will use link relations, and some applications will apply
> specialized meaning to a link relation that other applications will not. *
> ***
>
> **
>

Agreed... what I'm going for more here is modeling "good behavior".
Applications have the option of using registered link relations or
extension link relations. If a link rel needs to be very specific to a
particular kind of resource, then we should encourage applications to use
extension link rels in the form of absolute URIs. Obviously this isn't
something that can be strictly enforced but we can, at the very least, set
a good example.

- James

> **
>
> “The link relation registry should be maintained, such that documentation
> for applications that rely on particular link relations are easy to find
> from the link relation registry”.****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:
> [email-masked]] *On Behalf Of *Goix Laurent Walter
> *Sent:* Tuesday, November 20, 2012 5:39 AM
> *To:* Paul E. Jones; 'James M Snell'; 'Dick Hardt'
>
> *Subject:* [apps-discuss] Link rels****
>
> ** **
>
> *Da:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *From:* James M Snell [mailto:[email-masked] <[email-masked]>]
> 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. ****
>
> advise the sender by return e-mail, Thanks.* ****
>
> mail se non è necessario.* ****
>
> ** **
>