Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
WebFinger
Home
+ new post
About this group
Join this group
Message from discussion The Case for a Simplification of Webfinger
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Bob Wyman  
View profile  
 More options Feb 29 2012, 11:20 am
From: Bob Wyman <b...@wyman.us>
Date: Wed, 29 Feb 2012 11:20:25 -0500
Local: Wed, Feb 29 2012 11:20 am
Subject: Re: The Case for a Simplification of Webfinger
Print | View thread | Show original | Report this message | Find messages by this author

I too see value in the "acct" scheme and believe it will help satisfy an
important need -- the ability to have and use an easily understood
user-identifier without being required to adopt or provide any services
other than those provided by the identity service itself.

It is true that acct: identifiers look very much like email (mailto:)
identifiers, but this is too be expected and is, I think, a desirable
attribute -- not something to be bemoaned for avoided. In both cases, what
you have is a string of the form (local-name @ global-name) or, for
example: "Alice AT SiteA"... At this level of abstraction, the only
alternative pattern available would be something like the (global-name /
local-name) pattern of URIs, but people have learned to intuitively expect
that identifiers which provide the global name first are used primarily for
"resources" or "things" rather than persons. (Note: The distinction between
things and people may not be considered terribly relevant to technical
folk, but non-technical folk see the world differently.)

Certainly, it should be possible to have an acct: identifier without having
an email service. It should also be possible to have email without an
acct:. And, it should be possible to have acct and mailto addresses which
are dissimilar. (in fact, one thing that you should be able to use
WebFinger for is to discover the mailto for someone identified with an
acct...) It is true that, in general, those who manage globally named
resources should be careful to ensure that when mailto and acct identifiers
are similar, they should be assigned to what one would normally consider to
be the "same person." However, it may be that this doesn't make sense in
all cases.

The local-name@global-name identifier pattern is too useful, too widely
understood, too easy to use, for it to be reserved to mail and XMPP usage
alone. This pattern is the one that normal people will intuitively believe
is what an identifier *should* look like. It would be a disservice to force
billions of people to learn a new identifier syntax without some truly
compelling reason.

bob wyman

On Tue, Feb 28, 2012 at 11:44 PM, Paul E. Jones <pau...@packetizer.com>wrote:

> I believe people see value in the “acct” scheme.  We need something, after
> all, to identify a user.  A person’s profile at Google or Facebook or
> anywhere else, for example, is not (necessarily) and email address.
> Webfinger identifiers likely will be of the same form as an email ID since
> that’s what users will enter.  The use of “acct:” should be behind the
> scenes, IMO.  However, it should be valid for a user to enter
> acct:pau...@packetizer.com if they wanted.  It my case, that is also my
> email ID.  It likely would be for most, but we should not build a system
> that requires an email ID.****

> ** **

> There are some who view email as obsolete and unnecessary.  They might use
> services like Twitter or perhaps even a distributed microblogging protocol
> (that I’ve never seen defined anywhere, but would be cool) where
> communication between users shifts from email to short messages delivered
> publicly or privately though this distributed microblogging system,
> effectively replacing email.   In that case, one would need an account
> identifier that is not an email scheme.****

> ** **

> In short, I think there is value in having acct:.  It does not have to be
> something we push to users.  We can assume that user@domain is
> acct:user@domain without the user having to know or care.****

> ** **

> Paul****

> ** **

> *From:* webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] *On
> Behalf Of *Melvin Carvalho
> *Sent:* Tuesday, February 28, 2012 7:15 PM
> *To:* webfinger@googlegroups.com
> *Subject:* Re: The Case for a Simplification of Webfinger****

> ** **

> ** **

> On 28 February 2012 17:48, Paul E. Jones <pau...@packetizer.com> wrote:***
> *

> Melvin,****

>  ****

> Have you seen this draft?****

> http://tools.ietf.org/html/draft-jones-appsawg-webfinger****

>  ****

> There is still work to do, but things like JSON are a requirement in this
> new draft.  We’re trying to define the acct: URI type in this draft.  It
> should be clearer as we progress the document.****

>  ****

> I have no idea what benefit there is in using something like
> gmail.com/@/joe. That just seems backwards and does not solve the issue
> you’re describing where there is confusion between the various URI types.
> A URI is just a URI.  Users should generally not have to know or understand
> a URI type.  Nobody enters “mailto:” into their email client.  It’s just
> an address.  Likewise, software “behind the scenes” should use “acct:” as
> appropriate.****

> Thanks Paul, imho, great to see that the latest draft has moved to JSON!

> The second part is regarding the creation of the acct: scheme.  Has there
> any pushback from IETF / IANA?

> From a user perspective the scheme will normally be hidden, but the actual
> scheme is relevant to architects and standards people.

> I am wondering the motivation behind acct:, or if it is still needed at
> all?
>  ****

>  ****

> Paul****

>  ****

> *From:* webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] *On
> Behalf Of *Melvin Carvalho
> *Sent:* Sunday, February 26, 2012 5:07 AM
> *To:* webfinger@googlegroups.com****

> *Subject:* The Case for a Simplification of Webfinger****

>  ****

> Webfinger has come a long way in the last 2 years.  Having reviewed the
> latest spec I'm convinced that it's a high quality piece of writing that
> fills a very important gap.****

> The adoption, in particular, of wefinger has been impressive.  But have
> there been lessons learnt over the past two years?

> 1. I think we've seen an acceleration in the shift away from XML to JSON.
> Some say syntax is not important, and is covered by MIME types anyway, but
> I do think JSON is what developers like working with now, that's a trend
> that's set to stay (famous last words).

> 2. Almost no one understands the difference between mailto: acct: and a
> 'normal' email address.  Although this is critical to the spec and web
> scalability, I think that the subtlety is going to be too much for the
> average developer and potentially cause confusion for years to come.  The
> question arises, do we even need acct: ?

> Possible Simplification
> =================

> In a nutshell why not take :

> j...@gmail.com and translate to ->  gmail.com/@/joe

> Serve it as JSON, and we're pretty much done (ive skipped a couple of
> details for brevity).

> We have a few world class, scalable, JSON formats now that we didnt have 2
> years ago.

> Analysis
> =========

> Pros: simplicity, remove need for acct:

> Cons: involves changing the spec, developer tools, less flexibility of path

> I must admit the last point is a biggie ... so I'm just throwing this out
> there, im undecided in my mind whether this will fly.

> Given that much of the webfinger support is still a work in progress,
> would it be worth considering weighing the pros and cons based on from what
> we've learnt?****

> ** **


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google