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

"Paul E. Jones" <> Wed, 27 June 2012 20:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3838421F85D3 for <>; Wed, 27 Jun 2012 13:40:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q+mEkANSYrs0 for <>; Wed, 27 Jun 2012 13:40:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D117821F85D5 for <>; Wed, 27 Jun 2012 13:40:02 -0700 (PDT)
Received: from sydney ( []) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id q5RKdGCu016222 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 16:39:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=dublin; t=1340829557; bh=cra+Oj3kgW0Lo2JbQMs6lQUFttRo+v4n/VWhCnxhEvI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=LgdVQdfKhq7sV8/SiBqDBep8rpCQGCcoqP/VBZA9Td7CwolWQhnawh9JAYeZNWSKt GM9b2GpWl0KoB4af8rQAiA/V2rJe3RNQDt9PHPxc5PMypwoA4u3Dx2M+OsyxA7qHld vGaNvqucLPveDh186XO9JHBcomvejDLwPHCZDuuE=
From: "Paul E. Jones" <>
To: 'John Bradley' <>, 'Peter Saint-Andre' <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Date: Wed, 27 Jun 2012 16:39:24 -0400
Message-ID: <042501cd54a4$f0b054b0$d210fe10$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0426_01CD5483.699F9F10"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHACExhZgXedi2je/bJAOmWfz8jRwJIaUzKAl3mCNAByYqi0gHWboHrAbhZHT0Bauk3hpbN6yag
Content-Language: en-us
Cc:, "'Murray S. Kucherawy'" <>
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: Wed, 27 Jun 2012 20:40:07 -0000



That's correct, but not a function of the WebFinger draft, but one of RFC
6415.  The URI template accepts URIs, not bits and pieces of URIs.


We had discussed long ago to use only "", for example,
but the group decided to use URIs and "acct" was the preferred URI scheme to
refer to user accounts.


What I've been doing was trying to document the agreements various folks had
reached on WebFinger.  Don't shoot the messenger.  That said, I don't see a
good reason to backtrack at this point.  The "acct" URI scheme is out in the
wild, its use has a limited scope and specific purpose, etc.


If we were to separate them, we would have the question thrust upon us of
"what URI scheme do I use to refer to paulej's Twitter account?"  It's not
mailto.  It should not be http.  I do agree with the group who reached the
consensus before that "acct" is a reasonable way forward.  Nobody was in
love with "acct", but nothing else worked better.




From: []
On Behalf Of John Bradley
Sent: Tuesday, June 26, 2012 11:12 AM
To: Peter Saint-Andre
Cc:; Murray S. Kucherawy
Subject: Re: [apps-discuss] The acct: scheme question


The "resource" parameter is currently a fully qualified URI, and that is
normalized to acct:


The template paramater {uri} also precludes relative URI as near as I can


Perhaps Paul can correct me,  but I think that the request.


GET /.well-known/host-meta.json? HTTP/1.1


Is not allowed by the spec, or be interoperable.    The goal of SWD was to
make the above (slightly different syntax same idea) work.


There are a lot of places in the spec where the acct: uri and normalizing
things to it are baked in.


There are likely also issues with host-meta as that is where the template is


Paul's likely reaction will be that separating them is not trivial, and he
may be correct in that.


On the other hand it is probably the right thing to do, even if it touches a
bunch of things.


John B.


On 2012-06-26, at 10:40 AM, Peter Saint-Andre wrote:

On 6/26/12 8:37 AM, John Bradley wrote:

The current spec requires normalization of bare identifiers i.e.

That would also need to change if we separate the specs.

In what way would it need to change?


Peter Saint-Andre