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

[Goix Laurent Walter <[e-mail]>]

Hello Paul,

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

Walter


> -----Messaggio originale-----
> Da: Paul E. Jones [mailto:[e-mail]]
> Inviato: mercoledì 29 agosto 2012 19.58
> A: Goix Laurent Walter; '☮ elf Pavlik ☮'; 'Peter Saint-Andre'
> Cc: 'apps-discuss'
> Oggetto: RE: [apps-discuss] R: Comment on draft-ietf-appsawg-acct-uri-00.txt
>
> Walter,
>
> If you query /.well-known/host-meta[.json], one will get a set of link
> relations that are host-wide and templates that are resource-specific.  Isn't
> that more-or-less the same as what you are suggesting with acct:example.com?
> I don't see the difference.
>
> You can see an example:
> curl -v https://packetizer.com/.well-known/host-meta.json
>
> Paul
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > On Behalf Of Goix Laurent Walter
> > Sent: Wednesday, August 29, 2012 4:25 AM
> > To: ☮ elf Pavlik ☮; Peter Saint-Andre
> > Cc: apps-discuss
> > Subject: [apps-discuss] R: Comment on draft-ietf-appsawg-acct-uri-00.txt
> >
> > > -----Messaggio originale-----
> > > Da: [e-mail]
> > > [mailto:[e-mail]] Per conto di ? elf Pavlik ?
> > > Inviato: martedì 28 agosto 2012 20.19
> > > A: Peter Saint-Andre
> > > Cc: apps-discuss
> > > Oggetto: Re: [apps-discuss] Comment on
> > > draft-ietf-appsawg-acct-uri-00.txt
> > >
> > > Excerpts from Peter Saint-Andre's message of 2012-08-28 17:50:29 +0000:
> > > > Hash: SHA1
> > > >
> > > > On 8/28/12 11:05 AM, elf Pavlik wrote:
> > > > > Excerpts from Mike Jones's message of 2012-08-23 18:49:36 +0000:
> > > > >> As long as I'm writing about the acct: URI, let me add my voice
> > > > >> supporting allowing local account identifiers such as "acct:joe"
> > > > >> to be used, in addition to fully qualified names such
> > > > >> "acct:[e-mail]".  The reason that this this can work fine
> > > > >> for discovery is that if you're contacting the discovery server
> > > > >> at example.com, the identifier "acct:joe" is unambiguous in that
> > > > >> context.
> > > > >
> > > > > While ago I've suggested on webfinger mailing list to allow
> > > > > identifiers without local part, just: @domain.tld
> > > >
> > > > Hmm, if local part and domain part are both optional, can we also
> > > > have "acct:@"? ;-)
> > > >
> > > > > This way projects could have sort of catch all accounts like:
> > > > > @ietf.org and people having personal domains could also just use
> > > > > @name.me (rather than [e-mail] or [e-mail] etc.)
> > > >
> > > > Yes, I recall that discussion, and if I recall correctly most people
> > > > thought it wasn't a great idea. What does it mean to, say, perform a
> > > > WebFinger query against a bare domain?
> > > Yes, many people mentioned the original intention to mimic familiar to
> > > most people email addresses
> > >
> > > >
> > > > > It seams to me attractive if used in ostatus for federated
> > > > > microblogging.
> > > >
> > > > Could you perhaps explain that scenario in a bit more detail? I'm
> > > > curious to learn what requirements that brings in.
> > > At some point i thought that for example twitter specific: @ietf could
> > > become possibly self hosted @ietf.org as well as people with personal
> > > domains could use just identifiers like @franky.me and choose where
> > > they want to host their accounts.
> > >
> > > I also recall Markus Sabadello enthusiasm to in some ways infamous
> > > i-names which just use =name for individuals and @name for
> > > organizations https://en.wikipedia.org/wiki/I-name
> > >
> > > Honestly I just wanted to hear more opinions about it, seeing myself
> > > possible convenience in having option to just skip local part.
> > [walter] Personally I'd rather see the value of domain-only rather than
> > domain-less acct: URIs for deployments. In [1] I illustrated a use case
> > for large deployments and federated social networks where lots of
> > webfinger discoveries could happen across users on distinct social
> > networks (e.g. when start cross-following). That email suggested the use
> > of templates and new template variables, which is not exactly the subject
> > here, but the main point remains and allowing domain-only identifiers
> > could help in that.
> > Potentially a server (knowing in advance it may deal with several users on
> > the same foreign server) could issue a webfinger query to the resource
> > acct:example.com instead of a specific user. I would expect a difference
> > wrt to issuing a pure host-meta query where only a limited subset of
> > endpoints/link rels may be provided: by specifying the domain-only
> > resource explicitly it would be understood as a 2nd level query (meaning
> > extracting the link rels provided by the lrdd descriptor typically) and
> > thus could provide these additional links. Combined with templates (here
> > we can then discuss on the reserved template parameter names) it could
> > become a powerful mechanism to retrieve template-based endpoints that
> > could be valid for all users on that server/domain, thus reducing the
> > number of wf queries for distinct users on the same foreign server. In
> > case some link rels do not follow a specific pattern and are more complex
> > they could simply not be returned in that type of xrd/jrd, and the server
> > would need to issue a user-specific query to retrieve extra link rels if
> > needed.
> >
> > Here is an example:
> > GET /.well-known/host-meta.json?resource=acct:example.com HTTP/1.1
> > Host: example.com
> >
> > The reply might have this body (using a fictitious "{uri.userpart}" to
> > represent only the user-part of the acct: URI):
> >
> > {
> >   "subject" : "acct:example.com",
> >   "links" :
> >   [
> >     {
> >       "rel" : "http://webfinger.net/rel/avatar",
> >       "template" :
> > "http://www.example.com/people/{uri}/images/{uri.userpart}.jpg"
> >     },
> >     {
> >       "rel" : "http://webfinger.net/rel/profile-page",
> >       "template" : "http://www.example.com/people/{uri}"
> >     },
> >     {
> >       "rel" : "http://schemas.google.com/g/2010#updates-from",
> >       "template" : "http://www.example.com/people/{uri}/blog/blog.xml"
> >     }
> >   ]
> > }
> >
> > walter
> >
> > [1] http://www.ietf.org/mail-archive/web/apps-
> > discuss/current/msg06073.html
> >
> > >
> > > >
> > > > > On that thread someone also mentioned that in xmpp realm
> > > > > @domain.tld makes a valid jid but i haven't research it further
> > > > > yet :(
> > > >
> > > > You can have xmpp:domain.tld (the address of a server), but you
> > > > can't have xmpp:@domain.tld (some sort of catch-all for all accounts
> > > > at the server??).
> > > Thanks for clarifying, also acct:domain.tld looks also somehow more
> > > sane than acct:@domain.tld :)
> > >
> > > >
> > > > Peter
> > > >
> > > _______________________________________________
> > > apps-discuss mailing list
> > > [e-mail]
> > > 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.
> >
> > _______________________________________________
> > apps-discuss mailing list
> > [e-mail]
> > 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.