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

Phillip Hallam-Baker <> Mon, 02 July 2012 22:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 90A4A21F85A2 for <>; Mon, 2 Jul 2012 15:53:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.517
X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zMVDFuyheW4C for <>; Mon, 2 Jul 2012 15:53:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BB95821F85A1 for <>; Mon, 2 Jul 2012 15:53:18 -0700 (PDT)
Received: by obbwc20 with SMTP id wc20so10222400obb.31 for <>; Mon, 02 Jul 2012 15:53:24 -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=pb5l45uJs0UhHGOwXwL9vfTCBVzZsX3AJ9KeexhYuH8=; b=jfeYrIW7EHHy1bJWYpxt8YRmPLkuesgL2shkXWfEibpo/hwMkzvmy1ahXoJbFxjgoO 8Z7wm0ImhbWymvU2DKwBG2km0184O483CfwiIwtfkPFevxv5izP6YozgK79C3d4SqKi4 3nnCm056QrRsw7MB3ACafSEGOU5ZUOzKt+Oh2UMGiRE1YfpWJLszllYD9qr1I8qF4ZLB 3qqtlbEPW3in1bgEZUB7AijSy1mdIQqbSmy16rcQHbYG55uGL1BrKgK3LKbDPKBG3wZR vhjGkoXuvE+4N6brdH0bRbYQ1ZmjDXArUkqUmgG4Zs2DF4zvCas9ODkUegmmu2wTvCMS T5zg==
MIME-Version: 1.0
Received: by with SMTP id xg10mr10086047obb.76.1341269604626; Mon, 02 Jul 2012 15:53:24 -0700 (PDT)
Received: by with HTTP; Mon, 2 Jul 2012 15:53:24 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <043201cd54a5$79f2e170$6dd8a450$> <> <> <> <> <> <> <> <> <> <> <>
Date: Mon, 02 Jul 2012 18:53:24 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Bob Wyman <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: Graham Klyne <>, "" <>, "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 22:53:19 -0000

On Mon, Jul 2, 2012 at 1:57 PM, Bob Wyman <> wrote:
> On Mon, Jul 2, 2012 at 11:42 AM, Phillip Hallam-Baker <>
> wrote:
>> I think Tim regrets having been argued out of a lot of positions
>> relating to naming that he was subsequently proved right on.
>> Naming issues are an area where a lot of people have strong opinions
>> that really turn out to be a matter of taste rather than grounded in
>> semiotics.
>> The whole business of differentiating URLs and URNs as distinct
>> classes was bogus. Once the locator scheme has caching, a URL becomes
>> a name. Once an application provides a default action for a name (e.g.
>> look it up on Amazon) then a name becomes a locator.
>> A URI scheme should simply provide people with a well defined syntax
>> that allows them to express the concepts that applications that need
>> to interoperate need to exchange references to. Trying to decide how
>> people should use the identifiers is counterproductive. Trying to
>> enforce particular approaches is destructive.
>> The vast majority of computer systems that use accounts do not bind
>> them to domain names. So there is a place in the acct: scheme for
>> unbound references.
> It seems to me that an unbound acct: name would be useful only in a "local"
> case, not generally useful between otherwise inter-working machines. As I
> understand it, the IETF normally limits its scope to those issues that
> relate to interworking between systems. Thus, it seems to me that a feature
> that is purely local and does not, in fact, facilitate inter-working is one
> that should not appear in an IETF document. This, of course, would not
> prevent anyone from building a system, or even set of systems, that made
> private agreements or used private conventions concerning the use of acct:
> names which were unbound or contained no domain part. But, that is not, I
> think, a matter which need concern anyone while wearing an IETF standards
> hat.

That is not the case at all. IETF protocols have always been designed
to support local use in addition to Internet use where that makes

In this case accounts are currently a locally defined resource and the
objective is to make them an Internet resource. The transition from
one to the other requires a spec that can work equally well in both

Deployment is something that should always concern us. Scope arguments
are only ever relevant to the question of whether the IETF should
consider a problem in the first place. Once the problem is accepted
the design must address all the use cases and requirements that
reasonably apply whether they are deemed to be in IETF scope or not.

And in any case I think that you are completely wrong on the question
of scope in the first place. Please provide a citation for your claim
if you want to continue the argument.