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

John Bradley <> Fri, 25 May 2012 11:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AFE8921F85D3 for <>; Fri, 25 May 2012 04:40:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nw7SLWHorLml for <>; Fri, 25 May 2012 04:40:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D264121F85D2 for <>; Fri, 25 May 2012 04:40:02 -0700 (PDT)
Received: by qcsq13 with SMTP id q13so588705qcs.31 for <>; Fri, 25 May 2012 04:40:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Y0Iy8wIEvgoZa/eWhi2cI9An7rYhrEEmReI4KMkF+Tw=; b=YD+GnXxES87jvSrFXZlae8r/YbWbEBX1RzSB4E9dd461wCtCU8B1R50zjVnHzamkMX xDwUXdRAaf+yQFuih73qzON4kMit8Z2uAhhCO89XklKaUdAuDM7p0AeiUFUFEMG5/mFK 7OihAtA0JE1eGqkkKPysOmIzbzfA1t1PdluJkyIa3wHM6vhDmbjaru0p5GM56QqgVQjB BV5jNpdfGWkSX0YLLrWGff0DYJl2QMjK5ckgIpT3vyYDy5RLnDRO85tZk5c7MZSm+/aQ P5jkx+KQi8Sf5QgrHyT3Y8g52Llkm2iHN29Z3HToutoGdkwwMaE4GYWnrAnw0MDq6YY/ JuEg==
Received: by with SMTP id dz7mr14781541qab.65.1337946002238; Fri, 25 May 2012 04:40:02 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id bs9sm12658349qab.2.2012. (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 May 2012 04:40:01 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="windows-1252"
From: John Bradley <>
In-Reply-To: <>
Date: Fri, 25 May 2012 07:39:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <04f601cd3957$14ea4d90$3ebee8b0$> <> <058101cd39b6$02a28990$07e79cb0$> <> <>
To: Michiel de Jong <>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQn84chfcE84M2G8j7r2E1kC9US6V6lgTao4gnRcaA5oDic99u+GkG6sNLiQE0SA/L1lIJSV
Cc: " Discuss" <>
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: Fri, 25 May 2012 11:40:03 -0000

> 1) say the parameter takes "any URI or user@host"

Also move acct: tp a different spec.  If it gets approved that's fine.  If people use an un-appoved scheme name as an identifier for computability with existing deployments that is fine as well, but it should not be in the WF spec.

I think Blane and I agree on the point that the server not the client is in the best position to figure out what the user intended if they type in   The client is adding acct: to say that it doesn't know.  sending a relative URI as we do in SWD and letting the server figure it out is probably the best thing.

It is a parameter, I don't see any reason that a relative URI would not be valid, as long as a authority is present.

John B.

On 2012-05-25, at 7:06 AM, Michiel de Jong wrote:

> On Thu, May 24, 2012 at 2:27 PM, John Bradley <> wrote:
>> Until acct: is an approved URI I am not keen to have openID Connect take a normative reference to it.
> Indeed I think we can conclude:
> - an acct: scheme would be helpful
> - it does not currently exist
> - we have to think about what to do until it exists
> On Wed, May 16, 2012 at 4:34 PM, Blaine Cook <> wrote:
>> I'm completely and totally opposed to webfinger not accepting
>> scheme-less addresses.
>> Please start from the user experience – no-one in the history of the
>> internet has typed "http://" into a browser window address bar (I may
>> be overstating that, but statistically speaking it's true).
>> Likewise, no-one will ever type "acct" or "mailto" or "xmpp" or
>> anything else into a form field.
>> To require clients to convert "" into
>> "" is just pedantry of the worst sort. If I had it
>> my way, webfinger (not host-meta) wouldn't even resolve URIs; it would
>> only resolve scheme-less email identifiers, because that's what we're
>> doing.
>> I *understand* that there *should* be an URI for these things;
>> however, there is prior art for not having an URI – DNS is a core
>> piece of internet infrastructure that uses "bare" identifiers all the
>> time precisely to find *resolvable* resources that *do* use URIs.
>> I'm not going to stand in the way of consensus, but if the IETF
>> specification ends up stating that bare identifiers are not supported,
>> then I will personally consider this work a failure as I believe
>> strongly enough that URIs are not necessarily appropriate here. :-/
>> b.
> And this was +1'ed by Mike Jones. So I pointed out that:
> Once acct: is a URI scheme, you'll be able to say the parameter takes
> "any URI". Until then, you'll have two options:
> 1) say the parameter takes "any URI or user@host"
> 2) say the parameter takes "any existing URI scheme or acct:user@host"
> I think we agree that as Blaine said, there *should* be an URI, but I
> think we also can agree that the limbo period would be too long to say
> "let's first wait to see if acct: gets accepted, and then decide what
> we do". So we have to make a choice about the period between now and
> the 'verdict'. For that period, I would vote for option 1. I think
> it's clear that option 1 has a down-side:
> - it deviates from host-meta as such
> but option 2 has three downsides:
> - in relying on a scheme that does not *yet* exist, it also deviates
> from host-meta, so that doesn't change
> - it could lead to rejection-domino, should acct: get rejected
> - it involves dropping bare user addresses, and Blaine already said
> he's "completely and utterly" opposed to that.
> I'm in favour of option 1, and from what i read, some more people are.
> Some other people have stated they are simply not interested in making
> the scheme-less case work, which is fair enough. I don't think anybody
> is in favour of suspending production use until we get an answer about
> the proposed URI scheme, although I might be wrong. There are probably
> some other positions which i'm underrepresenting here, sorry if that's
> the case.
> But when phrased this way, is anybody in favour of option 2?