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

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Tue, 03 July 2012 03:53 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568E511E8118 for <apps-discuss@ietfa.amsl.com>; Mon, 2 Jul 2012 20:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.57
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1w3DMbVQM-Pn for <apps-discuss@ietfa.amsl.com>; Mon, 2 Jul 2012 20:53:21 -0700 (PDT)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9173011E80EC for <apps-discuss@ietf.org>; Mon, 2 Jul 2012 20:53:21 -0700 (PDT)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q633rRPw022888 for <apps-discuss@ietf.org>; Tue, 3 Jul 2012 12:53:27 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 2a82_6376_a59d36b2_c4c2_11e1_a7b1_001d096c566a; Tue, 03 Jul 2012 12:53:27 +0900
Received: from [IPv6:::1] ([133.2.210.1]:44717) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S15DB6CB> for <apps-discuss@ietf.org> from <duerst@it.aoyama.ac.jp>; Tue, 3 Jul 2012 12:53:31 +0900
Message-ID: <4FF26CB4.4080203@it.aoyama.ac.jp>
Date: Tue, 03 Jul 2012 12:53:24 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Phillip Hallam-Baker <hallam@gmail.com>
References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <CAKaEYhL0NS=RZXTdyOMBM_q15P7D1KZ9kgUyMYYB06kA9f0w8Q@mail.gmail.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> <4FF18C30.2040902@ninebynine.org> <CAMm+LwgVKKHOTMnzLAnxvXFjb=F+e5acdk12fO5Nj-DjUq5uHQ@mail.gmail.com> <CAKaEYhJdbYN4O3GbBYw=mxe3GBL8q51w3YnkR2Y4=1Tn0ztCOA@mail.gmail.com> <CAMm+LwgazJL2rQjNhnGHgw3kYnR21--RzZ6pWVG5YjVabogRKQ@mail.gmail.com> <CAA1s49W-CpVbWm7zBPq=vWqCu06X33d9hkaDYjL=_9PL93DRvg@mail.gmail.com> <CAMm+Lwiry8WtaeT+Qjz2HMe4U_m3Uv65vMJa=tS7qqx7L2Jyfg@mail.gmail.c! om>
In-Reply-To: <CAMm+Lwiry8WtaeT+Qjz2HMe4U_m3Uv65vMJa=tS7qqx7L2Jyfg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Graham Klyne <GK@ninebynine.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "Murray S. Kucherawy" <msk@cloudmark.com>
Subject: Re: [apps-discuss] The acct: scheme question
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=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<bob@wyman.us>  wrote:
>>
>>
>> On Mon, Jul 2, 2012 at 11:42 AM, Phillip Hallam-Baker<hallam@gmail.com>
>> 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.
>