Subject: [apps-discuss] R: R: Comment on draft-ietf-appsawg-acct-uri-00.txt

From: Goix Laurent Walter <[email-masked]>
Date: Mon, 3 Sep 2012 15:59:54 +0200

Hello Paul,
>
> Walter,
>
> > I agree it is "more or less" the same at the end. However I expect that
> > from current implementations of webfinger, very little link rels are
> > provided in the host-meta vs resource-specific descriptor so putting many
> > templates in the host-meta already is not best practice yet afaik.
> > Of course nothing prevents from changing this behaviour in the future but
> > as this scenario may become mainstream (I do hope that in a few years very
> > big social islands will webfinger each other).
> >
> > Thus I am wondering whether it could make sense:
> > - adding it as an example in the draft clarifying the practice and
> > emphasizing the insertion of additional link rel templates already in the
> > host-meta
>
> I could certainly show an example similar to what is in RFC 6415 Section 1.1,
> perhaps adding additional host-wide properties and link relations.  However,
> I'm not sure what you mean by "emphasizing the insertion of additional link
> rel templates".  Host-wide information uses link relations, not templates.
> Templates are used for resource-specific information.

[walter] well the example could illustrate how to follow someone on a "remote domain", showing the webfinger query from server1 to server2. In that case the xrd/jrd for the host-meta could show a list of link rels "typical" of this example (federated social networks), such as "http://webfinger.net/rel/avatar", "http://schemas.google.com/g/2010#updates-from", "salmon", "http://portablecontacts.net/spec/1.0" and the related templates (for the purpose of the example) that contain a {uri} template parameter in the example itself,
e.g.
<?xml version='1.0' encoding='UTF-8'?>
   <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>

     <!-- Resource-specific Information -->

     <Link rel='http://webfinger.net/rel/avatar'
      template='http://example.com/avatar/{uri}' />

     <Link rel='salmon'
      template='http://example.com/salmon/{uri}' />

     <Link rel='http://portablecontacts.net/spec/1.0'
      href='http://example.com/people' />

     <Link rel="http://schemas.google.com/g/2010#updates-from"  template="http://example.com/activitystreams/{uri}/@self?format=atom"
        type="application/atom+xml" />

   </XRD>
And commenting that these templates (for resource-specific info) allow to avoid querying each single resource on server example.com for these link rels, thus useful for interconnection of large providers.

>
> > - specifying new templates variable names to be used in templates, as this
> > scenario makes strong use of templates and may need to reference
> > additional information. The first that comes into my mind (as per the
> > example in my previous email) is the local username, that could be
> > identified as {uri.userpart}, {username} or anything else. Maybe other
> > could also make sense.
>
> I really think it's a bad idea for us to introduce more template variables.
> This gets complicated.  WebFinger was designed to operate on a single URI.
> Since a URI can contain any kind of information, I think that should be
> sufficient.
[walter] My proposal is based on the observation of the webfinger endpoints already exposed, where the URL of most resource-specific information (link rels) is actually based on a pattern, which is common to all resources under that domain, but which pattern do not typically includes the whole account URI but only a username (or some sort of id, eg in case of G+).

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 10 Sep 2012 23:56:31 -0400

Walter,

This flexibility does exist thanks to RFC 6415.  I'm thinking about how we might present this example.  I'm taking note of your comments, but I don't have time to make text changes right now.

Paul

> -----Original Message-----
> From: Goix Laurent Walter [mailto:[email-masked]]
> Sent: Monday, September 03, 2012 10:00 AM
> To: Paul E. Jones; '☮ elf Pavlik ☮'; 'Peter Saint-Andre'
> Cc: 'apps-discuss'
> Subject: R: [apps-discuss] R: Comment on draft-ietf-appsawg-acct-uri-
> 00.txt
> 
> Hello Paul,
> >
> > Walter,
> >
> > > I agree it is "more or less" the same at the end. However I expect
> > > that from current implementations of webfinger, very little link
> > > rels are provided in the host-meta vs resource-specific descriptor
> > > so putting many templates in the host-meta already is not best
> practice yet afaik.
> > > Of course nothing prevents from changing this behaviour in the
> > > future but as this scenario may become mainstream (I do hope that in
> > > a few years very big social islands will webfinger each other).
> > >
> > > emphasizing the insertion of additional link rel templates already
> > > in the host-meta
> >
> > I could certainly show an example similar to what is in RFC 6415
> > Section 1.1, perhaps adding additional host-wide properties and link
> > relations.  However, I'm not sure what you mean by "emphasizing the
> > insertion of additional link rel templates".  Host-wide information uses
> link relations, not templates.
> [walter] well the example could illustrate how to follow someone on a
> "remote domain", showing the webfinger query from server1 to server2. In
> that case the xrd/jrd for the host-meta could show a list of link rels
> "typical" of this example (federated social networks), such as
> "http://webfinger.net/rel/avatar",
> "http://schemas.google.com/g/2010#updates-from", "salmon",
> "http://portablecontacts.net/spec/1.0" and the related templates (for the
> purpose of the example) that contain a {uri} template parameter in the
> example itself, e.g.
>      <Link rel="http://schemas.google.com/g/2010#updates-from"
> template="http://example.com/activitystreams/{uri}/@self?format=atom"
> And commenting that these templates (for resource-specific info) allow to
> avoid querying each single resource on server example.com for these link
> rels, thus useful for interconnection of large providers.
> 
> >
> > > - specifying new templates variable names to be used in templates,
> > > as this scenario makes strong use of templates and may need to
> > > reference additional information. The first that comes into my mind
> > > (as per the example in my previous email) is the local username,
> > > that could be identified as {uri.userpart}, {username} or anything
> > > else. Maybe other could also make sense.
> >
> > Since a URI can contain any kind of information, I think that should
> > be sufficient.
> [walter] My proposal is based on the observation of the webfinger
> endpoints already exposed, where the URL of most resource-specific
> information (link rels) is actually based on a pattern, which is common to
> all resources under that domain, but which pattern do not typically
> includes the whole account URI but only a username (or some sort of id, eg
> in case of G+).
> 
> walter
> >
> > 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.