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

"Martin J. Dürst" <> Tue, 03 July 2012 03:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 568E511E8118 for <>; Mon, 2 Jul 2012 20:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.57
X-Spam-Status: No, score=-99.57 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1w3DMbVQM-Pn for <>; Mon, 2 Jul 2012 20:53:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9173011E80EC for <>; Mon, 2 Jul 2012 20:53:21 -0700 (PDT)
Received: from ([]) by (secret/secret) with SMTP id q633rRPw022888 for <>; Tue, 3 Jul 2012 12:53:27 +0900
Received: from (unknown []) by with smtp id 2a82_6376_a59d36b2_c4c2_11e1_a7b1_001d096c566a; Tue, 03 Jul 2012 12:53:27 +0900
Received: from [IPv6:::1] ([]:44717) by with [XMail 1.22 ESMTP Server] id <S15DB6CB> for <> from <>; Tue, 3 Jul 2012 12:53:31 +0900
Message-ID: <>
Date: Tue, 03 Jul 2012 12:53:24 +0900
From: "\"Martin J. Dürst\"" <>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Phillip Hallam-Baker <>
References: <> <> <> <> <043201cd54a5$79f2e170$6dd8a450$> <> <> <> <> <> <> <> <> <> <> <> <! om>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Tue, 03 Jul 2012 03:53:22 -0000

After reading Phillip's mails, I agree with him that it makes sense to 
allow an account id without a domain name. The document should be clear 
that such use won't work internet-wide, and should be avoided wherever 
possible. It should also be clear that relative resolution won't work, 
because it's the wrong syntax.

Regards,    Martin.

On 2012/07/03 7:53, Phillip Hallam-Baker wrote:
> 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
> sense.
> 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
> circumstances.
> 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.