[apps-discuss] R: the need for acct (was: Re: Looking at Webfinger)

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

I do think there are many potential usages of the acct: URI, besides WF.
In particular there are many placeholders of IRIs already appropriate for acct: URIs. Atom feeds (and the related ActivityStreams), the ActivityStreams JSON format, and even the OpenSocial API URI syntax make use of IRIs for identifying users (or in general entities, should this be a group, a place, etc).

Originally many blogging platforms exporting rss/atom feeds have been using the mailto: uri for identifying authors as this has been the most popular at that time. However, most of such platforms did not offer email service and sometimes email accounts provided in such feeds where actually referring to a different domain, which is of course still acceptable.
The rise of social networking services have made even more popular such user-related feeds where account identifiers are disjoints from the mailto namespace/service (or xmpp etc) and where acct: URIs are the most appropriate identifier.

walter

Da: [e-mail] [mailto:[e-mail]] Per conto di William Mills
Inviato: martedì 3 luglio 2012 19.29
A: Peter Saint-Andre; Phillip Hallam-Baker
Cc: Mark Nottingham; IETF Apps Discuss
Oggetto: Re: [apps-discuss] the need for acct (was: Re: Looking at Webfinger)

For describing why we need acct: I come back to the previous discussion where the point was made almost exactly that xmpp:, mailto: and others have specific contexts and in the context of Webfinger are appropriate for discovering information about that specific context.  The acct: scheme satisfies the need for "I need information about this user" when it's not in the context of a specific applicaiton protocol.

________________________________
From: Peter Saint-Andre <[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
Cc: Mark Nottingham <[e-mail]>; IETF Apps Discuss <[e-mail]>
Sent: Tuesday, July 3, 2012 9:05 AM
Subject: [apps-discuss] the need for acct (was: Re: Looking at Webfinger)

On 7/3/12 8:52 AM, Phillip Hallam-Baker wrote:

> The place where I would see acct: being used in WebFinger is actually
> more the data structures being returned. So for example if I am
> looking up my friends profile, I would probably want to see their
> battle.net accounts listed there along with their other stuff.
>
> WebFinger would still be a way to resolve acct: URIs, but only one way
> and the http: transport might only be one option.
>
> If I click on an acct: link in a browser I would have a range of
> possible options:
>    * Grab the public WebFinger data
>    * Grab the profile data exposed to me by virtue of me being a friend.
>    * Attempt to connect on chat

Don't we have xmpp: for that?

>    * Attempt to send an email

Don't we have mailto: for that?

You're saying that acct: would be a general identifier and that
applications could attempt many different kinds of interactions with
that account, using specific protocols like SMTP or XMPP. But deciding
whether to attempt such interactions would depend on knowing if the
service provider actually offers email service, IM service, public
profiles, microblogging, etc. Presumably that information could be
discovered via WebFinger (for a particular account), but I wouldn't
assume that one can send email to an account simply because an acct: URI
exists.

> I would expect there to be a default action but that choice is
> something the user would probably make.

It seems that the default action would be discovery.

> The place I would be using acct: identifiers is in the authentication
> and authorization layer.

Describing those use cases more completely would help us decide whether
we really need the 'acct' URI scheme.

Peter

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




_______________________________________________
apps-discuss mailing list
[e-mail]<mailto:[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.

[cid:[e-mail]]Rispetta l'ambiente. Non stampare questa mail se non è necessario.