Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)

Nico Williams <nico@cryptonector.com> Thu, 17 April 2014 15:42 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC241A01B9; Thu, 17 Apr 2014 08:42:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level:
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no
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 tjPpJgWkfJ_t; Thu, 17 Apr 2014 08:42:21 -0700 (PDT)
Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 577F31A01CD; Thu, 17 Apr 2014 08:42:13 -0700 (PDT)
Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id D0C56318064; Thu, 17 Apr 2014 08:42:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=BkDYJ8xnQ2pAbFEJxuy9 szH5/aI=; b=FsmGL+Sn2F/aQerToUxqrrhXJycRaEQc7eQWUCU9vdeWpazX3YuQ VOYix4Vp4+ixIvyd0wtJD9ES87Ec84H+zof9iu3t3ZnDAxiXAnAWSzz2F74Wk5jx aVE3l+Ojin3d0Q1ABmhNpXdhdi7j3561DReeXyXJA/ukaoOgenVVNrM=
Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 54FA2318059; Thu, 17 Apr 2014 08:42:09 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id k14so592372wgh.23 for <multiple recipients>; Thu, 17 Apr 2014 08:42:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.160.166 with SMTP id xl6mr12886369wib.42.1397749327929; Thu, 17 Apr 2014 08:42:07 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Thu, 17 Apr 2014 08:42:07 -0700 (PDT)
In-Reply-To: <534FE7BC.4070002@gmx.de>
References: <C93A34DBE97565AD96CEC321@JcK-HP8200.jck.com> <CAMm+Lwia99RdyO4RFScSwCaVHLsr_BRzmXK18eUoxGFti79Vog@mail.gmail.com> <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <CAMm+Lwiz1nyT6khGqa693E8Tq9Srrd3kaETRN=K0NUq-SsX1Vw@mail.gmail.com> <534FE7BC.4070002@gmx.de>
Date: Thu, 17 Apr 2014 10:42:07 -0500
Message-ID: <CAK3OfOjTtcsuu2DU7N5pWaUAS2weemV7oajHeT24fQfbXbjzcg@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Julian Reschke <julian.reschke@gmx.de>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/sxZZj58q6DeTXa9rYy9ctMd4fi4
X-Mailman-Approved-At: Thu, 17 Apr 2014 08:48:11 -0700
Cc: urn@ietf.org, Phillip Hallam-Baker <hallam@gmail.com>, General discussion of application-layer protocols <apps-discuss@ietf.org>
Subject: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 17 Apr 2014 15:42:25 -0000

On Thu, Apr 17, 2014 at 9:39 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2014-04-16 20:58, Phillip Hallam-Baker wrote:
>> The real difference is that a URL must contains a DNS name and a URN
>> probably does not.
>> ...
>
> Not true. It doesn't need to be a DNS name.

The difference is blurry, but I like to think of it as: a URN is just
a name and there needn't even be a mechanism to resolve one to a
resource -- heck, there needn't even be a resource.  Whereas a URL is
a name that indicates how to resolve it in order to locate a resource;
the location part might not -need not- be stable.

Nico
--