Re: [apps-discuss] The acct: scheme question

Melvin Carvalho <> Thu, 24 May 2012 14:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA52321F8643 for <>; Thu, 24 May 2012 07:18:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.387
X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, FRT_FOLLOW2=0.422, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JiX4joCks4lv for <>; Thu, 24 May 2012 07:18:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9AF5E21F863E for <>; Thu, 24 May 2012 07:18:34 -0700 (PDT)
Received: by vcqp1 with SMTP id p1so1780069vcq.31 for <>; Thu, 24 May 2012 07:18:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JSeYBLR1qzyYGA5oP9aHNuC31k4XICJXL7GM72wU5KI=; b=G4YPcBFs4uBZ7kDxQHP4ySk3TjUGFg8IrFkrxnzTtAhjKzZh+/VuRxBGKnv8e+FB2J +YnaGv5qzfIqtOtSzT6M7Hl9TuUc1jQLzYzRsKtJ/bhxCFlIcHT+2Yh5ToKs1MiLT/uO bpSwGnC47TlFUKNXqxJo7dvwyOkv1qqY3N43HJbXV0cByJvjmgN+TP1qrMKHkAZVTEoJ OBYGWv5bo9JOXGHN4FEwRjfDmTVAVA/BCayyS7XxkijflgIsudythASPpHqham2Vbce8 AZSGhJlyjYklz520A7vImqQ7yTHWa4+EM+xr1rwg0/6RAxBcVGVhkTJDTpGiRTpjBp03 UwMw==
MIME-Version: 1.0
Received: by with SMTP id cu5mr14217300vdb.125.1337869114069; Thu, 24 May 2012 07:18:34 -0700 (PDT)
Received: by with HTTP; Thu, 24 May 2012 07:18:33 -0700 (PDT)
In-Reply-To: <058101cd39b6$02a28990$07e79cb0$>
References: <> <> <> <> <> <> <> <> <> <> <04f601cd3957$14ea4d90$3ebee8b0$> <> <058101cd39b6$02a28990$07e79cb0$>
Date: Thu, 24 May 2012 16:18:33 +0200
Message-ID: <>
From: Melvin Carvalho <>
To: "Paul E. Jones" <>
Content-Type: multipart/alternative; boundary="bcaec50162cf4cd4a104c0c8ed92"
Subject: Re: [apps-discuss] The acct: scheme question
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 May 2012 14:18:36 -0000

On 24 May 2012 16:03, Paul E. Jones <> wrote:

> Henry,
> > Paul E. Jones writes:
> >
> > > The "acct" URI scheme has a narrow scope . . . I suspect appreciation
> > > for that URI scheme will grow with wider deployment of WebFinger,
> > > though.
> >
> > I find those two statements bordering on the contradictory.  It is
> > precisely because if it does indeed turn out that acct: URIs address a
> > real need, they will 'leak' out of WF and into wider contexts (i.e.
> > "appreciation . . . will grow"), and so acct: needs review as such in the
> > normal way any new URI scheme needs review.
> It wasn't intended to be.  Several have said before that they do not like
> "acct" and prefer something else.  However, I think that is because "acct"
> is presently not widely deployed and the novelty concerns people.  It has
> been suggested, for example, to use the URI scheme "mailto" instead.  So,
> my
> intent was just to say that once "acct" is adopted for querying for a
> user's
> account information using "acct", people will appreciate it more than they
> do now.  I think back on the examples I've given where I feel "mailto" just
> isn't right because it relates to email and some of my accounts on the
> Internet have no relationship to email.
> That's not to say that "mailto" could not be used.  If the OpenID spec
> declared that was the URI to use, then that's what that protocol mandates
> and I'd have no objection to it.  What I'd like to see mailto used for,
> though, is to provide information to my mail client so it can be
> provisioned.  Someone referred to RFC 6186 as a way to do that, but that
> only specifies what POP, IMAP, and SMTP servers to use globally.  Users are
> often clustered on certain machines and I'd personally like to see a link
> relation called "config-email" that has a URI that, when queried, would
> return JSON like this:
>  {
>    "imaps" : "",
>    "smtp-submission" : ""
>  }
> That link relation could be returned when querying for my account (via the
> "acct" URI), but if there was a document that defined mail
> auto-configuration, then it could specify the use of "mailto" and I believe
> that would be a perfectly good example of where "mailto:" would be more
> appropriate than "acct".
> The "acct" URI should be used to return a wide variety of information about
> a user's account.  I view it as information that is largely of interest to
> people other than the actual user.  That would include information like my
> contact list or my picture or other information.
> Anyway, we've discussed before that WebFinger can operate on a variety of
> URIs.  The one that should relate to the users account we put a stake in
> the
> ground and declare to be "acct".  If we want to specify other URIs for a
> subset of that information or instead of "acct" (e.g., mailto for mail
> configuration), that would be a reasonable thing to do.

Let me make an analogy with a relational database:

Consider you had a database table of information about a user.  One field
in the table is a (unique) email address and you wish to get the whole row,
which may contain things like blog and name, but could be any number of

The acct: protocol says the folloiwng:  'we should look up the table record
by the primary key, which is not the email address'.  Since we dont know
what the primary key is, let's give it a name : 'acct:user@host'.  Then we
can look things up.

There's a few challenges with this:

- it assumes lookup by "foreign" key (email) is problematic, which it need
not be

- if there is an existing primary key the acct: scheme may not be needed or

- it transitions the social web to a world where users will necessarily
have a keyring of multiple identifiers to carry out a cross platform lookup
(for example facebook already use http uris in their graph) making
implementations more complex

- developers and implementors may get confused of when to use mailt: acct:
or just user@host

- it's going to take many years (both time and work) for this to become
anywhere near as mainstream as http: or mailto:

If the payoff is considered worth the effort, then I think that's probably
fine.  Personally I think acct: should have it's own document.  Perhaps if
it's ultra simple (under 1 page as it is now) it can get approved very

> Paul