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

Phillip Hallam-Baker <> Mon, 02 July 2012 13:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E55B221F85DB for <>; Mon, 2 Jul 2012 06:31:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.483
X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pF2f4oM9-DhH for <>; Mon, 2 Jul 2012 06:31:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 18A2221F85D3 for <>; Mon, 2 Jul 2012 06:31:05 -0700 (PDT)
Received: by obbwc20 with SMTP id wc20so9554926obb.31 for <>; Mon, 02 Jul 2012 06:31:10 -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=x75eS5sRB8ymzgCY95FucFdeFGU+oHZlx89HsccwiWE=; b=Q01clwVgW2Lrgx+UDCa7k5kN6sePF5Z39uMReDRswKS7fLnMsuWiNUaj98JmjIGrCU vFxpDMCHv0T/fI51Cyi1cKeTGUWgG1jVa2N/hhnextBOtGJ6jTaWL5h/LklPtPBNB9I1 fkEGPwlAssTJuAek0g/GgHweVXNV/6qRqGThZI+2TKoHOgj0ESPcUvKOJ/bDpEKs7GvT tCtEqtGSYgFVbKb5/HZLJc9ZkgbR2QaBx0n26mAl3okx2s5nAz9gf5yyqOngS9vQ8l1N zg7skOF1WXdrK7O8u1LIj8Ofd3NF+QKn5Q282JWF3FUC+jD6yWYJOmRtpBfnf+3JzRq/ WY4A==
MIME-Version: 1.0
Received: by with SMTP id v5mr13633664oeb.25.1341235869911; Mon, 02 Jul 2012 06:31:09 -0700 (PDT)
Received: by with HTTP; Mon, 2 Jul 2012 06:31:09 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <043201cd54a5$79f2e170$6dd8a450$> <> <> <> <> <> <> <>
Date: Mon, 02 Jul 2012 09:31:09 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Graham Klyne <>
Content-Type: text/plain; charset="ISO-8859-1"
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: Mon, 02 Jul 2012 13:31:06 -0000

Relative URIs have existed from the start. That is one of the reasons
they had to be renamed 'uniform' rather than universal.

The idea is to have a uniform means of representing a name. If that
name is ambiguous, then the URI form needs to be able to capture that.

I don't think it helps in the slightest to argue over whether
/fred.html is a URI or a URI fragment. Tim's original proposal is in
my view rather better thought out than what others have proposed as
'improvements'. A name is merely a label for a concept and every URI
is a name, some happen to be resolvable via a default protocol, others
not, thats all.

Incompletely specified account names are inevitable. If you want to
use SAML or the like in a Windows environment then the Windows domain
is not bound to a unique DNS address and picking a random one is only
going to confuse matters.

An acct: name that does not have a domain name part is going to have
to be resolved in the same fashion as relative URIs are - by reference
to context and local state. I don't see anything wrong in that. In the
context of accounts, a domain name is not completely unambiguous
unless you also have time.

The real world is a fuzzy place. Trying to cope with the fuzzyness and
ambiguity by wishing it away only leads to broken specs. Accounts have
only recently come to be understood to have an intrinsic domain
component. It is better to accept that fact and to build
infrastructure that addresses the need than to pretend that the need
can be magicked away.

People who don't have a domain are going to drop it in any case. We
saw the same thing happen with the news: and nntp: URL. Tim thought
that the USENET space was uniform and tried to establish a URL that
didn't have the domain name. Engineers trying to solve real world
problems then added it back in because there is more to NNTP than

On Mon, Jul 2, 2012 at 7:55 AM, Graham Klyne <> wrote:
> On 01/07/2012 23:02, Peter Saint-Andre wrote:
>> On 7/1/12 9:38 AM, William Mills wrote:
>>> Section 4.3:  '"@" domainpart' should be optional.  It's reasonable
>>> to think this might be used with local account identifiers that
>>> don/t/need have a domain.
>> Making the domain name of the service provider implicit seems
>> ill-advised to me. What's the harm of including the domainpart?
> +1
> (URIs are intended to be a global namespace.)
> #g
> --
> _______________________________________________
> apps-discuss mailing list