Re: [urn] [art] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice

Christian <cdel@firsthand.net> Tue, 07 January 2020 22:49 UTC

Return-Path: <cdel@firsthand.net>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCAC512085F; Tue, 7 Jan 2020 14:49:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Level:
X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=firsthand.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dc9Y9WfyBA1W; Tue, 7 Jan 2020 14:49:34 -0800 (PST)
Received: from tranquility.default.cdelarrinaga.uk0.bigv.io (tranquility.default.cdelarrinaga.uk0.bigv.io [IPv6:2001:41c8:51:8b8::184]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23A66120843; Tue, 7 Jan 2020 14:49:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=firsthand.net; s=tranquility; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=l3BqeZDh4QF5H1jBkVTSzGJNkwQgCM6w9+2U9m8feTo=; b=S0/Ei+GGCl87tWLGc61z8D2CKw/PSFmcPDm2dKkUND1gfQVpSq+zjDZwVO/1dZ6dDvKZ407YoMeUV21tKIaS+gIgJqPOu5tTn/39h6cvVVqIDv2MzgfH9rn6KbDvfEKQjN7MItMPCXz81ohxFZRoSe+p4jpvRm0hZGm/s1V3X00=;
Received: from 188.29.164.240.threembb.co.uk ([188.29.164.240] helo=[192.168.43.165]) by tranquility.default.cdelarrinaga.uk0.bigv.io with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <cdel@firsthand.net>) id 1ioxfH-0007Uo-B5; Tue, 07 Jan 2020 22:49:31 +0000
To: Phillip Hallam-Baker <ietf@hallambaker.com>
Cc: "General Area Review Team (gen-art@ietf.org)" <art@ietf.org>, urn@ietf.org, The IESG <iesg@ietf.org>, IETF Discussion Mailing List <ietf@ietf.org>
References: <87E116C31DAF1434C3C3937F@PSB> <CAMm+Lwi5tWUNK5nO4d8qoum03fV-1bchfP_Qu3ktANgRDd-RVg@mail.gmail.com> <29803.1578413742@localhost> <CAMm+LwjFUfayeeHmWTRiGiCBz-+afBOnoXVcF1PxzMibS6t-Uw@mail.gmail.com>
From: Christian <cdel@firsthand.net>
Message-ID: <86e1f21b-b594-b390-fe67-c5f495cffa64@firsthand.net>
Date: Tue, 7 Jan 2020 22:49:29 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <CAMm+LwjFUfayeeHmWTRiGiCBz-+afBOnoXVcF1PxzMibS6t-Uw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------279B353DDDBD3A4C1F8B6BB7"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/gKubfEw19bUXo-dh6X6bHZtcyLc>
Subject: Re: [urn] [art] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jan 2020 22:49:39 -0000

picking up as a post modern fag end...

On 07/01/2020 19:53, Phillip Hallam-Baker wrote:
> Resolution of many types of name is inherently ambiguous because the 
> context varies.. We cannot resolve a barcode on a physical object like 
> a can of beans. But we can ask for information on the can of beans and 
> we can order an instance of the can of beans for delivery. And both 
> forms of 'location' are going to be subjective and depend on the 
> context in which they are attempted.

I suppose the question is can a schema capture both identifier and 
locator contexts (my plural) unambiguously in all cases?

Should I take your post modernist interpretation as saying the answer is 
no - we have to live with ambiguity, even to the extent of the failure 
to resolve one or other or possibly both and do so without breaking wind?

But given this interpretation what language is needed if URI and URN 
linguistically don't meet the need?

Or is the other interpretation to offer a list of contexts that work and 
exclude application for the others?

In which case which is the more useful approach for building real world 
apps and their networks?

It rather kills the idea of hard coded registries for all eventualities 
I think. That I like. As I really like the import of post modernist 
sensibility. This argument is worth something.

best Christian