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

Phillip Hallam-Baker <hallam@gmail.com> Mon, 02 July 2012 15:42 UTC

Return-Path: <hallam@gmail.com>
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 3EAF921F86F4 for <apps-discuss@ietfa.amsl.com>; Mon, 2 Jul 2012 08:42:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.492
X-Spam-Level:
X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 B1BwuvvzBDNb for <apps-discuss@ietfa.amsl.com>; Mon, 2 Jul 2012 08:42:14 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 445CB21F86BE for <apps-discuss@ietf.org>; Mon, 2 Jul 2012 08:42:14 -0700 (PDT)
Received: by obbwc20 with SMTP id wc20so9716382obb.31 for <apps-discuss@ietf.org>; Mon, 02 Jul 2012 08:42:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3rpKDDp6sjjxgpcYjJH0Krh6hqauIqHWZsc7/U1n3Vg=; b=GR6pABoQg416Lko6OQOBQM6b5985/Hifvw2ydcK2ERk+QFfVjORVhBaEluJY42lgVY uwaN4KH+qmzV/uxxMqCqi6NusKWegQp4gjpc6gMh+gwgvj9Jfx1yRkVQnguF0KTkjKKg QYczNra7mv6cOpbg0O2mBz/SJw1sTupLU4gT1XGUZu7CEOp1tHNWhfELhHPndUgsA7EJ N0974P+Lja3sP5dSXOWtHD1FWX0JLo7TfLErkNXflcktcUSRMd1tQ5puJ73CvDyJfgf2 qX5EGT+6jDJHk2kMcpCB+ZJQRG3TL8sP83ACORbDSfpsV1nDz6uwkHl6EqKHI7XZl1HP qh9g==
MIME-Version: 1.0
Received: by 10.182.116.2 with SMTP id js2mr8812325obb.38.1341243739247; Mon, 02 Jul 2012 08:42:19 -0700 (PDT)
Received: by 10.182.64.166 with HTTP; Mon, 2 Jul 2012 08:42:19 -0700 (PDT)
In-Reply-To: <CAKaEYhJdbYN4O3GbBYw=mxe3GBL8q51w3YnkR2Y4=1Tn0ztCOA@mail.gmail.com>
References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <CAKaEYhKpeayOw4sN4=NYaoXKJQ2e5P+pP8SqJqnt-=Barb=WqA@mail.gmail.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>
Date: Mon, 02 Jul 2012 11:42:19 -0400
Message-ID: <CAMm+LwgazJL2rQjNhnGHgw3kYnR21--RzZ6pWVG5YjVabogRKQ@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
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: Mon, 02 Jul 2012 15:42:15 -0000

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. I expect that practice to go down over time. I
expect that deployment of technology that uses acct: will encourage
that. But trying to force the issue by excluding unbound accounts is
only going to hurt that transition by making acct: a special case of
account objects rather than a technology that can ease the transition.



On Mon, Jul 2, 2012 at 9:42 AM, Melvin Carvalho
<melvincarvalho@gmail.com> wrote:
>
>
> On 2 July 2012 15:31, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>>
>> 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
>> USENET.
>
>
> I enjoyed reading this.  Just a remark regarding universal vs uniform.
>
> FWIW, Tim is on record saying that he regrets not insisting to the IETF,
> that the original 'Universal' should be used in URI, instead of changed form
> 'Uniform'.  Depending on which circles you're in, I think informally, the
> two terms are used pretty interchangeably, these days.
>
>>
>>
>>
>>
>> On Mon, Jul 2, 2012 at 7:55 AM, Graham Klyne <GK@ninebynine.org> 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
>> > apps-discuss@ietf.org
>> > https://www.ietf.org/mailman/listinfo/apps-discuss
>>
>>
>>
>> --
>> Website: http://hallambaker.com/
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>



-- 
Website: http://hallambaker.com/