Account URI scheme 'acct'
Eran Hammer-Lahav
Thanks for the quick response. I am adding the webfinger group.
> -----Original Message-----
> From: Larry Masinter [mailto:masi...@adobe.com]
> Sent: Tuesday, August 18, 2009 3:38 PM
> To: Eran Hammer-Lahav
> Cc: Brad Fitzpatrick; Graham Klyne (G...@ACM.ORG)
> Subject: RE: Account URI scheme
>
> Feel free to forward.
>
> > The consensus is not to use http://
> > URIs for accounts or to identify users (for many reasons).
>
> I think "consensus" here requires a scope.
> Definitions of permanent URI scheme registration
> requires IETF consensus. You could make it a
> "temporary" registration, but there are likely
> other uses of "acct".
Consensus among those working on webfinger. I am well aware of BCP 35 and the threshold of minting a new URI scheme. We are thinking of experimenting with it, then requesting a provisional registration, and then see how things go. I did a quick search for account-like URIs and didn't come up with anything, so while I am sure it will inspire others to find new uses for it, we have one now that is very consistent with how most known account systems work. Basically, it is any identifier (string, encoded as required by the URI spec) at an authority.
> While I'm not as strong a fan of "use HTTP URIs for everything"
> since you are, in fact, using the HTTP protocol, it's a
> case where I think using a HTTP URI would make sense, and have
> a better incremental deployment strategy than a new scheme.
I am not a fan of using HTTP URIs for things that are not HTTP resources - that is, where HTTP is used to obtain a representation. My main issue is that it requires some form of additional discovery step to figure out what that URI is about (and that it is not a profile page or some service endpoint).
In this case, we use HTTP (and DNS) to obtain a descriptor (metadata) of the account and a list of related services (like address book, calendar, login service). I do not consider these a representation of the account. I also envision other protocols using these account identifiers in the future to do something useful with them beyond an HTTP descriptor of them.
> Could you give, say, three of the "many" reasons?
- No direct way of telling what the URI is without performing some discovery on it (or at least a GET). Unless we do something like a well-known URI prefix (like http://webfinger.info/account/authority/local-part).
- An HTTP URI as an account identifier is completely unintuitive to people as we have learned from OpenID. We want something that looks like email (and works like email in most cases), but is not tied to the SMTP infrastructure. These URIs tend to leak out of the machine world and appear in front of users (again, a lot of OpenID experience). It also creates either conflict (if an account URI is also used as a profile page) or confusion (users having both an HTTP profile and an HTTP account URIs).
- No easy way to ask people to manually enter their account information and construct an HTTP URI for it. Services can assign HTTP URIs to accounts, but knowing my account (username and domain where I login) does not allow me to construct that URI. This means I have no way of providing it to services without either a fixed template (which violates the namespace of the service) or a hardcoded conversion template for each service.
- It needs context when used in links. It is clear what <link rel="me" href="acct://j...@example.com" /> means. No so much for <link rel="me" href="http://example.com/account/joe" />. The first means "I am known as Joe at example.com". The second means today, I own the web page at that URI. Not really the same use case or usability for clients.
> > Just like the finger protocol which was about an account (not email
> > address), this is not about email addresses or xmpp addresses. It is
> simply the combination of a local-id and authority.
>
> I'm always wary of "simply".
In general, yes. But other than indicating this is an account (which is a pretty well defined network concept), it relies completely on the URI framework. It defined an authority and space to put any arbitrary local identifier. Can you suggest an account that does not fit into the profile of any identifier at a given authority (as defined by the URI spec).
> > We want to use a new URI scheme 'acct'
>
> This seems misleading and confusing, IMHO.
I think 'id', 'identity', and 'user' are all misleading. I am not sure why 'acct' or 'account' is misleading or confusing? What are your intuitive expectations? Is there another definition of an account that I am missing that this construct fails to represent?
> > that will include an authority and
> > local identifier (resolvable by the authority). There are a few
> options:
>
> > acct://example.com/joe
> > acct://j...@example.com
> > acct:j...@example.com
>
> > We like the second option because it uses 3986 as-is without defining any
> > additional structure (like local-part in the path, or everything in the path
> > with parsing rules).
>
> I think the account information in the local authority is really
> problematic when it comes to internationalization.
How so? I am asking because I don't know. Doesn't IRI allow for other languages in the userinfo component?
> > My questions:
>
> > 1. Is this compliant use of userinfo?
>
> I don't think 'compliance' is the issue here. The URI spec gives a
> generic syntax which schemes may use when it is appropriate.
Then is it in the spirit of the spec? If you were tasked with picking a syntax, what would you choose?
> > 2. Are there other alternatives to a new URI scheme?
>
> Many. You are looking for a data structure to represent "how to
> presence information about someone". Putting that into a URI is one option, but
> cramming data structures into the URI syntax makes more sense if you're
> trying to deploy this access method in a context that currently
> only allows URIs. The only reason *not* to use http: I've heard is
> in cases where the resolution and authority has no connection with
> HTTP.
URI, as I understand it, is how we identify stuff on the web. It is for that reason that many existing and new protocols/schemas define their identifier space using URIs. Instead of doing:
<Identifier type="uri">
<Identifier type="phone">
We simply put a URI in there and make sure we have a valid scheme for the object types we care about.
> > 3. Should we base it on IRI?
>
> As I hope is clearer from the new IRI draft, there isn't an
> "IRI scheme", there is a "URI scheme" that has an internationalized
> form.
Cool. Still need clarification on the userinfo component.
> > [1] http://code.google.com/p/webfinger/
>
> says " If I give you my email address today, you can't do anything
> with it except email me."
>
> which I think is confusing. You can do anything you like with
> my email address, including using it as a lookup method or
> identifier for me. The "mailto:" scheme defines some uses,
> some of which involve sending mail.
>
> I don't understand the difference between the first P in
> "XMPP" and "finger" information. I might suspect some
> round-rolling-device-invention, no?
This description doesn't accurately represent the general idea which the original finger protocol offered (local account focused, not email at all). At the same time, email is an intuitive syntax for people to identify themselves online. We want to build on that, but without breaking or creating conflicts with existing protocols.
Thanks,
EHL
Eran Hammer-Lahav
Brad Fitzpatrick
Eran Hammer-Lahav
Thanks. Added:
Is this a New Idea?
Nope.
XRI attempted something very similar but with a lot more complexity (or, richness, depending on your point of view). One of the use cases XRI was trying to solve was the creation of an abstract identifier that can be used to identify individuals. However, XRI uses a completely new syntax (like '=eran') which requires learning a new format and made it less attractive to most people than HTTP URIs.
Also, in the process of building the Google Social Graph API, Brad Fitzpatrick and the Google team came up with the Social Graph Node Mapper and the 'sgn://' URI scheme. SGN's scope is greater than what the account URI is trying to accomplish, and those extra requirement force it to be less user-friendly. But it clearly shows that there is a need to identify individuals beyond what HTTP URIs offer, as they are widely used today across the social web. It also shows the complexity and customization needed to extract account information today.
EHL
Eran Hammer-Lahav
EHL
> -----Original Message-----
> From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On
> Behalf Of Eran Hammer-Lahav
> Sent: Tuesday, August 18, 2009 7:42 PM
> To: Larry Masinter
> Cc: Brad Fitzpatrick; Graham Klyne (G...@ACM.ORG);
> webf...@googlegroups.com
> Subject: Account URI scheme 'acct'
>
>
Brad Fitzpatrick
Christian M. Jensen
My big question is - what then. Suppose you get the
acct://b...@example.com - what is the electronic process to getting the
XRD?
Is it hit a specific URI with HTTP? Is it a socket connection to port
79?
Maybe I missed it, but what is wrong with webfinger://b...@example.com or
finger://b...@example.com
Thanks again!
John Panzer
2. Shouldn't the link relation (in HTML and Atom and other places) be sufficient evidence that you need to represent this concept as URI to be compatible? (Just heard of a new use case, rel="owner", for HTML pages, last night.)
3. If the vote is user: vs. acct:, then I vote for user: It's more understandable and even less ambiguous.
4. But I'd prefer identifier: -- I know why this evokes an immune system reaction but it's the most accurate terminology.
Eran Hammer-Lahav
> -----Original Message-----
> From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On
> Behalf Of John Panzer
> Sent: Wednesday, August 19, 2009 2:24 PM
> To: webf...@googlegroups.com
> Subject: Re: Account URI scheme 'acct'
>
> 1. Has the yelling started yet?
Not yet, but I can see the dust over the horizon from the mob coming to push HTTP URIs... :-)
> 2. Shouldn't the link relation (in HTML and Atom and other places) be
> sufficient evidence that you need to represent this concept as URI to
> be compatible? (Just heard of a new use case, rel="owner", for HTML
> pages, last night.)
Yes, but it doesn't answer the 'why not use HTTP URIs' question. These days, that's the most important question you have to answer. We don't have a perfect story yet for this one. Help would be appreciated.
> 3. If the vote is user: vs. acct:, then I vote for user: It's more
> understandable and even less ambiguous.
I'll keep track of preferences. I prefer account over user because it is more technical and doesn't imply a person.
> 4. But I'd prefer identifier: -- I know why this evokes an immune
> system reaction but it's the most accurate terminology.
That's the I in URI. You get it for free :-). All URIs are identifiers... It is far too generic.
EHL
Eran Hammer-Lahav
> -----Original Message-----
> From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On
> Behalf Of Christian M. Jensen
> Sent: Wednesday, August 19, 2009 1:54 PM
> To: webf...@googlegroups.com
> Subject: RE: Account URI scheme 'acct'
>
>
> Thanks for the article!
>
> My big question is - what then. Suppose you get the
> acct://b...@example.com - what is the electronic process to getting the
> XRD?
Right now? WebFinger (see protocol outline thread and posts from Brad).
> Is it hit a specific URI with HTTP? Is it a socket connection to port
> 79?
I hope not. We need to decide if there is value is binding the new scheme to a single protocol. I think we are better off offering a protocol that is useful and allowing others to define new ways to interact with the identifier.
> Maybe I missed it, but what is wrong with webfinger://b...@example.com
> or
> finger://b...@example.com
Primary concern is the association with the old finger protocol. It would be awkward to say user webfinger with finger URIs. It also creates a strong binding to a protocol which I don't think helps here since we are likely to find new/better protocols for fetching such identifiers in the future.
EHL
John Panzer
> Subject: Re: Account URI scheme 'acct'
>
> 1. Has the yelling started yet?
Not yet, but I can see the dust over the horizon from the mob coming to push HTTP URIs... :-)Yes, but it doesn't answer the 'why not use HTTP URIs' question. These days, that's the most important question you have to answer. We don't have a perfect story yet for this one. Help would be appreciated.
> 2. Shouldn't the link relation (in HTML and Atom and other places) be
> sufficient evidence that you need to represent this concept as URI to
> be compatible? (Just heard of a new use case, rel="owner", for HTML
> pages, last night.)
I'll keep track of preferences. I prefer account over user because it is more technical and doesn't imply a person.
> 3. If the vote is user: vs. acct:, then I vote for user: It's more
> understandable and even less ambiguous.
I don't care too much -- mostly my vote would be for whatever will pass muster with the pitchfork-waving mob.
That's the I in URI. You get it for free :-). All URIs are identifiers... It is far too generic.
> 4. But I'd prefer identifier: -- I know why this evokes an immune
> system reaction but it's the most accurate terminology.
Then I propose the uri: URI scheme ;)
EHL
Dirk Balfanz
Brad Fitzpatrick
> Can some kind soul explain the difference between acct://b...@example.com and
> acct:b...@example.com to the uninitiated amongst us? To me it seems that the
> extra two slashes are just dead weight, but I'm sure there is some deep
> reason why they're there...
RFC 3986 ....
"The authority component is preceded by a double slash ("//") and is
terminated by the next slash ("/"), question mark ("?"), or number
sign ("#") character, or by the end of the URI."
Because "example.com" here is the authority.
And:
authority = [ userinfo "@" ] host [ ":" port ]
Dirk Balfanz
Dirk.
Eran Hammer-Lahav
The email part of mailto: is considered a URI path. There is no requirement to use the authority section defined by the URI spec. However if you don't you need to define your own rules on how to parse the path and extract the local and host parts. This is not a big deal (just a few more words in the spec), but it does have a few implications:
1. Clients need to write their own parsing code because a standard 3986 parser breaking a URI into its components:
scheme://userinfo@host:port/path?query#fragment
will not be able to go beyond path.
2. Generic rules about authority and trust will need to be defined separately for acct and http. We had this problem in the first version of LRDD which tried to place mailto: URIs in the same boat as HTTP URIs. However, those mailto: URIs only gave you a {path} variable and did not work for the generic {userinfo} or {host}. This means the generic URI vocabulary defined by LRDD will not work for 'acct' URIs (pros/cons), but more importantly, any trust profile will need to explicitly address how to extract the authority from an 'acct' URI because the generic rules that apply to HTTP will not work.
Going with acct: instead of acct:// means more spec work in multiple places, and a bit more code. Since I don't expect people to ever type 'acct://j...@example.com' directly, I don't think the extra // do any hard. And even if they do type it manually, I think it fits the http:// template better. After all, who types mailto: URIs?
EHL
> -----Original Message-----
> From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On
> Behalf Of Dirk Balfanz
> Sent: Wednesday, August 19, 2009 5:14 PM
> To: webf...@googlegroups.com
> Subject: Re: Account URI scheme 'acct'
>
>
Santosh Rajan
Yes, but it doesn't answer the 'why not use HTTP URIs' question. These days, that's the most important question you have to answer. We don't have a perfect story yet for this one. Help would be appreciated.
Eran Hammer-Lahav
The story why we need an email like identifier isn’t perfect.
EHL
From:
webf...@googlegroups.com [mailto:webf...@googlegroups.com] On Behalf Of Santosh
Rajan
Sent: Wednesday, August 19, 2009 8:52 PM
To: webf...@googlegroups.com
Subject: Re: Account URI scheme 'acct'
On Thu, Aug 20, 2009 at 3:04 AM, Eran Hammer-Lahav <er...@hueniverse.com> wrote:
Santosh Rajan
Blaine Cook
> The story why we need an email like identifier isn’t perfect.
It's not perfect, but the more I settle into it, the more it just
seems common sense. There's no reason to believe that HTTP URIs are
any more usable than email addresses (for people), and any posturing
in that direction is purely a preference. As far as I'm concerned,
people advocating HTTP URIs need to prove that they're more usable
than email-like identifiers, not the other way around.
Postal addresses, email, telephone numbers all follow a simple,
consistent, and hierarchical format. There are so many more of these
identifiers than there are HTTP URIs that are passed around on a daily
basis that it seems outrageous to suggest that somehow the flexibility
(and inconsistency) of HTTP is a win on the human level.
b.
David Fuelling
Steven Livingstone-Perez
short URL is easy (albeit - at the moment - incompatible with their desire
to phone me but sure xrds lookups could solve that one).
At this point perhaps doing some kind of survey amongst less technical folks
may be useful rather than guessing.
For one, the term "email like identifier" needs to go. At least people are
now comfortable with typing a URL to get to a persons profile (whereas they
are used to email for private one-to-one messages).
steven
http://livz.org
--------------------------------------------------
From: "Blaine Cook" <rom...@gmail.com>
Sent: Thursday, August 20, 2009 12:12 PM
David Fuelling
That said, I think Grandma might understand the term "user" better than "account", because "account" is pretty generic (account could mean a variety of things, not to mention my bank account, etc, whereas "user" is pretty obvious).
I could go either way, but for mass adoption I would pick "user://sapp...@gmail.com". I'm not stuck on it though...
Brad Fitzpatrick
Santosh Rajan
David Fuelling
Maybe we should turn to Jyte and draw out the lurkers on this list for their opinion....
Steven Livingstone-Perez
Eran Hammer-Lahav
But we don't have a good story about these email-like identifiers. My main concerns are:
1. Since we don't want to use actual email addresses, this has the potential to cause more confusion with users about what this thing is.
2. What does the UI look like? What questions are we actually going to ask users to answer to get to this identifier?
3. Is the appearance of a new scheme going to help or confuse more? What happens if the acct: prefix appears in front of users? A key argument against HTTP URIs is that they eventually leak out.
Bringing up postal address and telephone numbers goes both ways because internally, systems using those (as opposed to people) don't use them in that form. The USPS now encodes addresses into complex barcodes and Zip codes with extra digits (which in Manhattan brings you to a set of floors in a building). The phone system uses its own internal routing protocols, and many use TCP under the hood.
I am not trying to argue against this solution, nor am I suggesting we take a break until we figure it out. But we need to be able to clearly state what we are trying to do or we will never be able to clearly communicate this (which leads to bad press and protocol misuse).
My two requirements are:
1. Come up with an identifier format people can use to log-in, link, and claim web resources. This must be something that has a very good chance of being used and adopted. Email addresses have been working very well for many services which use them as username. They are also how most people identify themselves on the web (though the Facebook generation is now moving away from that).
2. Come up with an identifier machines can use to refer to the same user. This must be something that works with existing URI-enabled facilities like links and various XML schemas. Ideally, these identifiers have clear syntax which allows clients to differentiate them from other URIs that are not used to identify a user, and do not require minting new relation types just for the purpose of giving the target URI context.
There are pros and cons for trying to solve these two requirement using a single identifier. So far the only argument against addressing them separately is 'because they leak and cause confusion' isn't enough in my view to justify it.
EHL
> -----Original Message-----
> From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On
> Behalf Of Blaine Cook
> Sent: Thursday, August 20, 2009 4:12 AM
> To: webf...@googlegroups.com
> Subject: Re: Account URI scheme 'acct'
>
>
Steven Livingstone-Perez
sense I'll likely go back into my hole :-)
Well someone better tell Facebook as Vanity URL's may be part of their
business plan [1] and almost 6 million people on Facebook got their own URL
in one weekend [2]. Twitter are going that way to with verified accounts.
I'm not hugely bothered either way but i really don't there is fundamentally
any difference for a user between "us...@domain.com" and "domain.com/user"
and the question has to be asked what will be the future trend.
Your point 1 below around confusion is spot on - people will ask why it
*isn't* an email if it looks like one - can you imagine the number of people
sending emails to these "email like id's"? As for point 2 - well this is the
same questions that have been discussed about the UI/UX for OpenID URL's for
some time. It's tricky. And for 3 ... every client will recognize http and
can do something smart with it. Changing this to something brand new will
take years of adoption - not necessarily a reason not to do it of course.
steven
http://livz.org
[1] http://www.allfacebook.com/2009/04/facebook-vanity-urls/
[2] http://www.pcmag.com/article2/0,2817,2348799,00.asp
--------------------------------------------------
From: "Eran Hammer-Lahav" <er...@hueniverse.com>
Sent: Thursday, August 20, 2009 6:20 PM
To: <webf...@googlegroups.com>
Subject: RE: Account URI scheme 'acct'
John Panzer
We have a good story on why HTTP URIs don't work - because we tried them and failed to get any meaningful adoption. So we know we don't want to use HTTP URI for user data entry. That's the only part that we have figured out.
They work for some people (not the masses, but an important minority). The nice thing about making stuff accept URIs is that there no abandonment of URIs -- which will make a minority of Myspace and Facebook users who also happen to be intense web users happy.
But we don't have a good story about these email-like identifiers. My main concerns are:
1. Since we don't want to use actual email addresses, this has the potential to cause more confusion with users about what this thing is.
We don't want to _require_ actual email addresses, but it is fine for them to be an email address. And it's also fine for end users to think about them as email addresses in many contexts (e.g., when they are asked for their email address).
2. What does the UI look like? What questions are we actually going to ask users to answer to get to this identifier?
3. Is the appearance of a new scheme going to help or confuse more? What happens if the acct: prefix appears in front of users? A key argument against HTTP URIs is that they eventually leak out.
Bringing up postal address and telephone numbers goes both ways because internally, systems using those (as opposed to people) don't use them in that form. The USPS now encodes addresses into complex barcodes and Zip codes with extra digits (which in Manhattan brings you to a set of floors in a building). The phone system uses its own internal routing protocols, and many use TCP under the hood.
I am not trying to argue against this solution, nor am I suggesting we take a break until we figure it out. But we need to be able to clearly state what we are trying to do or we will never be able to clearly communicate this (which leads to bad press and protocol misuse).
Be able to put any of the things we want to use as user identifiers into slots that require URIs today.
My two requirements are:
1. Come up with an identifier format people can use to log-in, link, and claim web resources. This must be something that has a very good chance of being used and adopted. Email addresses have been working very well for many services which use them as username. They are also how most people identify themselves on the web (though the Facebook generation is now moving away from that).
There are three important cases today.
- j...@example.com should be able to type just that into a text box and the machines should be able to infer that it's really foo://j...@example.com.
- http://example.com should be able to type just "example.com" into a text box and the machines should be able to infer that it's really foo://example.com, and that lacking other discovery clues, what you get at http://example.com is a good representation of that person.
- http://example.com/joe should be able to type just "example.com/joe" into a text box and the machines should be able to infer that it's really foo://example.com/joe, and that lacking other discovery clues, what you get at http://example.com/joe is a good representation of that person.
2. Come up with an identifier machines can use to refer to the same user. This must be something that works with existing URI-enabled facilities like links and various XML schemas. Ideally, these identifiers have clear syntax which allows clients to differentiate them from other URIs that are not used to identify a user, and do not require minting new relation types just for the purpose of giving the target URI context.
There are pros and cons for trying to solve these two requirement using a single identifier. So far the only argument against addressing them separately is 'because they leak and cause confusion' isn't enough in my view to justify it.
The main, and strongest, argument is to not mutiply entities without necessity. When end users need to disambiguate for machines, they're going to get pointed at #2.
That's why I don't care too much what "foo" really is as long as it is unambiguous and easily searchable in this context. "URI scheme foo" on your favorite search engine should bring you to the Wikipedia article describing it (at least).
Blaine Cook
>
> I'm not hugely bothered either way but i really don't there is fundamentally
> any difference for a user between "us...@domain.com" and "domain.com/user"
> and the question has to be asked what will be the future trend.
The difference is that email addresses are almost universally
consistent. They are:
<some short identifier>@<some short domain name>
There are a few exceptions to this, but those are always reserved for
machine interactions (bounce processing, etc), and as such are hidden
in the envelopes of email, not exposed for viewing.
HTTP URIs, on the other hand, are wildly inconsistent. While:
is a perfectly valid and common form of URI, so is:
www.google.com/search?client=safari&rls=en&q=foo&ie=UTF-8&oe=UTF-8
or:
http://www.facebook.com/photo.php?pid=514960&op=1&o=global&view=global&subj=502411873&id=1350392534
Users constantly see these forms, and the inconsistency and complexity
mean that people can't figure out how they work (i.e., they don't
bother). For us, as web developers, they're really quite simple, but
the same can be said of the electrical wiring in your house. I have no
problem plugging in a kettle, but the internal wiring that allows me
to do it is way more complex. It's okay, though, because it's hidden
behind a wall. I'd be much more reticent to plug in a kettle if I
needed to attach bare wires together, even if it was simple in
principle.
b.
Steven Livingstone-Perez
Kevin Marks
> On Thu, Aug 20, 2009 at 10:20 AM, Eran Hammer-Lahav <er...@hueniverse.com>
> wrote:
>>
>> We have a good story on why HTTP URIs don't work - because we tried them
>> and failed to get any meaningful adoption. So we know we don't want to use
>> HTTP URI for user data entry. That's the only part that we have figured out.
>
> They work for some people (not the masses, but an important minority). The
> nice thing about making stuff accept URIs is that there no abandonment of
> URIs -- which will make a minority of Myspace and Facebook users who also
> happen to be intense web users happy.
I think the point is Eran's earlier one - URIs don't work, but URLs
do. If you use something that looks like a link to a webpage that
doesn't actually resolve to anything, it confuses people. If you use
something that is a link to a webpage to identify people, they get it.
If you make this something human readable, they love them, stay up all
night to get the one they want, laminate them on their shopfronts and
buy moocards to hand them out.
Unlike Eran, I think blogs, twitter, myspace and facebook are
meaningful adoption. Just because Yahoo and Google chose to use the
worlds worst URLs for user accounts originally doesn't make URLs a
failure as identifiers for people.
>>
>> But we don't have a good story about these email-like identifiers. My main
>> concerns are:
>>
>> 1. Since we don't want to use actual email addresses, this has the
>> potential to cause more confusion with users about what this thing is.
Exactly. The original point of this initiative was 'but people
[especially Blaine's grandma] don't like URLs, lets use email
addresses' Now you're doing to email addresses what URI mania did to
web addresses. "We don't want to use actual email addresses, so lets
make something indistinguishable by man or machine, but doesn't do
what you expect"
>
> We don't want to _require_ actual email addresses, but it is fine for them
> to be an email address. And it's also fine for end users to think about
> them as email addresses in many contexts (e.g., when they are asked for
> their email address).
just not to try to send email to them?
>>
>> 2. What does the UI look like? What questions are we actually going to ask
>> users to answer to get to this identifier?
>> 3. Is the appearance of a new scheme going to help or confuse more? What
>> happens if the acct: prefix appears in front of users? A key argument
>> against HTTP URIs is that they eventually leak out.
>>
>> Bringing up postal address and telephone numbers goes both ways because
>> internally, systems using those (as opposed to people) don't use them in
>> that form. The USPS now encodes addresses into complex barcodes and Zip
>> codes with extra digits (which in Manhattan brings you to a set of floors in
>> a building). The phone system uses its own internal routing protocols, and
>> many use TCP under the hood.
>>
>> I am not trying to argue against this solution, nor am I suggesting we
>> take a break until we figure it out. But we need to be able to clearly state
>> what we are trying to do or we will never be able to clearly communicate
>> this (which leads to bad press and protocol misuse).
>
> Be able to put any of the things we want to use as user identifiers into
> slots that require URIs today.
I am now getting XRI flashbacks.
>
>>
>> My two requirements are:
>>
>> 1. Come up with an identifier format people can use to log-in, link, and
>> claim web resources. This must be something that has a very good chance of
>> being used and adopted. Email addresses have been working very well for many
>> services which use them as username. They are also how most people identify
>> themselves on the web (though the Facebook generation is now moving away
>> from that).
>
> There are three important cases today.
>
> j...@example.com should be able to type just that into a text box and the
> machines should be able to infer that it's really foo://j...@example.com.
> http://example.com should be able to type just "example.com" into a text box
> and the machines should be able to infer that it's really foo://example.com,
> and that lacking other discovery clues, what you get at http://example.com
> is a good representation of that person.
> http://example.com/joe should be able to type just "example.com/joe" into a
> text box and the machines should be able to infer that it's really
> foo://example.com/joe, and that lacking other discovery clues, what you get
> at http://example.com/joe is a good representation of that person.
>
> End users don't care what "foo" is as long as these use cases are met, so I
> think the end user format doesn't need a lot of discussion.
This is eminently sensible; the empirical research on 'type your id in
here' is that email addresses and URLs is most of what people typed in
The basic argument is that you can put them in a browser and see what
they point to. You can't do that with email addresses. I thought the
point of this project was to fix that.
>> >
>> > Postal addresses, email, telephone numbers all follow a simple,
>> > consistent, and hierarchical format. There are so many more of these
>> > identifiers than there are HTTP URIs that are passed around on a daily
>> > basis that it seems outrageous to suggest that somehow the flexibility
>> > (and inconsistency) of HTTP is a win on the human level.
>> >
>> > b.
Simple consistent and hierarchical doesn't apply to postal addresses.
Really. Go try writing parsing code that handles UK, US, German and
Japanese ones. I'll wait. But you know what, they make sense to
people, much more so than geopoints
Phone numbers have a canonical hierarchic form that works, but what
you actually have to dial on any given phone (and thus what people
print out) is very locale specific. (Do you have to dial 7 to get an
outside line, or 9 at your office?)
Email addresses and web URLs are good examples of things that both
people and machines can cope with.
So, define a new protocol prefix, or use Brad's one if you like, but
don't overload email addresses again.
Steven Livingstone-Perez
form you mention below but we are moving away form that now i think.
I like the idea that the user can choose (in other words there seems to be
enough debate around this that either one isn't the universal answer).
In other words if you had either format which could resolve to the universal
format being discussed (personally i can't imagine people typing
acct:user@domain but i could be wrong) - i.e. an email-like identifier -
then that would be good for all.
steven
http://livz.org
--------------------------------------------------
From: "Blaine Cook" <rom...@gmail.com>
Sent: Thursday, August 20, 2009 8:03 PM
To: <webf...@googlegroups.com>
Subject: Re: Account URI scheme 'acct'
>
Steven Livingstone-Perez
I copied and pasted into Chrome and got straight to your profile. Not sure
what i'd do with the email-like format?
steven
http://livz.org
--------------------------------------------------
From: "Blaine Cook" <rom...@gmail.com>
Sent: Thursday, August 20, 2009 8:03 PM
To: <webf...@googlegroups.com>
Subject: Re: Account URI scheme 'acct'
>
Pete Warden
2009/8/20 Steven Livingstone-Perez <web...@hotmail.com>:> I'm not hugely bothered either way but i really don't there is fundamentallyThe difference is that email addresses are almost universally
> any difference for a user between "us...@domain.com" and "domain.com/user"
> and the question has to be asked what will be the future trend.
consistent. They are:
<some short identifier>@<some short domain name>
For my purposes it's extremely useful to have a consistent, machine-readable distinction between the local user identifier and the name of the service hosting that identity. The domain for profiles can vary a lot, especially with vanity URLs eg
http://petewarden.someservice.com
http://someservice.com/petewarden
http://profiles.someservice.com/petewarden
The consistency of petew...@someservice.com makes it a lot easier for me to do things like 'give me all the local identities of someservice I know about' with a simple query.
Just to contradict myself with a corner case though, there may be clashes between employee email addresses and our profile 'email addresses'. There's lots of existing b...@facebook.com accounts which don't necessarily match the http://facebook.com/bob user names.
Pete
Christian Scholz
Here are my €0.02
Am 20.08.2009 um 16:08 schrieb Brad Fitzpatrick:
> ... it's a good thing we chose web:// instead of http:// for user-
> friendliness, else that would've never been adopted!
I think it actually never got adopted because non-technical folks
usually just type in URLs without any http:// prefix, or am I wrong?
Esp. they never type in mailto: URIs.
This is IMHO also a reason why I am not so optimistic about the acct:
scheme for non-technical folks like grandmas (I personally also would
call it identity: as it points to a webfingerable list of service
which describe me).
I also wonder what the use case is for using acct: URIs. Is it a
simply technical use case where some social network is using an acct
URI in e.g. an XRD document or is this supposed to be typed in?
For distributed social networks I could imagine the following:
1. User enters new social networking site
2. Site asks user to provide her identity URI
3. Site reads the XRD associated with it
4. Site asks the user which services listed in that file she will give
access to for this new site.
5. some authorization game starts
...
Now the issue is probably in #2 in what that URI actually is. MySpace
users might think about their homepage URL, twitter users as well,
gmail users about their email address etc. No common user will
probably use any scheme in front of that URI though. Discovery needs
to be performed then anyway to e.g. find the webfinger endpoint or no
endpoint at all. I see the latter case as a huge usability problem.
This is basically why I am not sure what acct: will solve. Adding a
new technical concept is IMHO not solving the marketing problem in
which a user needs to directly understand what that identifier is like
one knows nowadays what to enter when being asked for an email
address. Even more problematic is IMHO that it actually looks like an
email address making it even harder to explain the difference.
I am also not sure if URLs will really not win because you have more
and more rememberable URLs these days (twitter, myspace, etc.).
Moreover I hear more and more that the new generation of internet
users do not really use email anymore. I have no statistics about it
but if it's true the question really is if an email based identifier
makes sense.
Nevertheless some experiments are not wrong as long as it does not
hinder other mechanisms to obtain that service catalogue.
-- Christian
>
> On Wed, Aug 19, 2009 at 9:06 PM, David Fuelling <sapp...@gmail.com>
> wrote:
> I agree with Brad that "acct" seems more general, and thus more of
> an accurate name. If I think about it, a "user" (e.g., Beth) is
> just part of the account "be...@example.com".
>
> That said, I think Grandma might understand the term "user" better
> than "account", because "account" is pretty generic (account could
> mean a variety of things, not to mention my bank account, etc,
> whereas "user" is pretty obvious).
>
> I could go either way, but for mass adoption I would pick "user://sapp...@gmail.com
> ". I'm not stuck on it though...
>
>
> On Wed, Aug 19, 2009 at 5:21 PM, Brad Fitzpatrick
> <brad...@google.com> wrote:
> I prefer acct/account (as it's more general and applicable to e.g.
> role/group/shared/non-human accounts), while 'user' implies one
> unique human.
>
> But I don't care enough to fight it.
>
>
> On Wed, Aug 19, 2009 at 2:00 PM, Eran Hammer-Lahav <er...@hueniverse.com
> > wrote:
>
> Also, how do you feel about 'user' vs. 'acct'?
>
> EHL
>
>
--
Christian Scholz Homepage: http://comlounge.net
COM.lounge GmbH blog: http://mrtopf.de/blog
Hanbrucher Str. 33 Skype: HerrTopf
52064 Aachen Video Blog: http://comlounge.tv
Tel: +49 241 400 730 0 E-Mail c...@comlounge.net
Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T
neuer Podcast: Der OpenWeb-Podcast (http://openwebpodcast.de)
new podcast: Data Without Borders (http://datawithoutborders.net)
Brad Fitzpatrick
Blaine Cook
>
> Now the issue is probably in #2 in what that URI actually is. MySpace
> users might think about their homepage URL, twitter users as well,
> gmail users about their email address etc. No common user will
> probably use any scheme in front of that URI though. Discovery needs
> to be performed then anyway to e.g. find the webfinger endpoint or no
> endpoint at all. I see the latter case as a huge usability problem.
It's worth noting that for most users, logins to Twitter, MySpace,
Facebook, etc, all happen using their email address; social discovery
happens using "search my addressbook", which is just a bulk proxy for
"use my friends' email addresses to identify them"
b.
Christian Scholz
> People won't type the "acct:" scheme prefix.
> And yes, some people will use email(-like) identifiers and some people
> will use URLs from their identity. That's known. The point of WebFinger
> is to level the playing field so we even *can* use email(-like)
> identifiers for discovery. (to find those service endpoints, usually
> requiring authentication, etc.) So debating what users will use for
> identity isn't really necessary.
that scheme now for being used in the Subject field of an XRD in order
to get a valid URI which is also semantically correct because mailto:
simply means something different and an identifier URI does not need to
be an email address as well.
Is this about correct?
-- Christian
> > I agree with Brad that "acct" seems more general, and thus more of
> > an accurate name. If I think about it, a "user" (e.g., Beth) is
> > That said, I think Grandma might understand the term "user" better
> > than "account", because "account" is pretty generic (account could
> > mean a variety of things, not to mention my bank account, etc,
> > whereas "user" is pretty obvious).
> >
> > I could go either way, but for mass adoption I would pick
> >
> >
> > On Wed, Aug 19, 2009 at 5:21 PM, Brad Fitzpatrick
> > <brad...@google.com <mailto:brad...@google.com>> wrote:
> > I prefer acct/account (as it's more general and applicable to e.g.
> > role/group/shared/non-human accounts), while 'user' implies one
> > unique human.
> >
> > But I don't care enough to fight it.
> >
> >
> > On Wed, Aug 19, 2009 at 2:00 PM, Eran Hammer-Lahav
> >
> > Also, how do you feel about 'user' vs. 'acct'?
> >
> > EHL
> >
> >
>
> --
> Christian Scholz Homepage: http://comlounge.net
> COM.lounge GmbH blog: http://mrtopf.de/blog
> Hanbrucher Str. 33 Skype: HerrTopf
> 52064 Aachen Video Blog: http://comlounge.tv
> Tel: +49 241 400 730 0 E-Mail
Eran Hammer-Lahav
EHL
> -----Original Message-----
> From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On
> Sent: Tuesday, August 25, 2009 6:29 AM
> To: webf...@googlegroups.com
> Subject: Re: Account URI scheme 'acct'
>
>
Christian Scholz
Be assured that I would love twitter, facebook, Google, MySpace etc.
even more if they would be OpenID consumers ;-)
And of course one could think of using e.g. OpenSocial/PoCo for syncing
contact lists if those user ids would be globally unique and it wouldn't
be based on email addresses (which I might not want to give out to that
third party).
But anyway. I guess we will see how much adoption and understanding that
scheme gets from developers. For the end user it's probably not relevant
anyway and here we will see what term for that identity URI will win.
-- Christian