Re: Policy URL -> Policy URI

David Shaw <dshaw@jabberwocky.com> Wed, 09 February 2005 04:03 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20554 for <openpgp-archive@lists.ietf.org>; Tue, 8 Feb 2005 23:03:36 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j193dNAT060906; Tue, 8 Feb 2005 19:39:23 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j193dNMt060905; Tue, 8 Feb 2005 19:39:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j193dMWk060897 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 19:39:23 -0800 (PST) (envelope-from dshaw@grover.jabberwocky.com)
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (rwcrmhc11) with ESMTP id <2005020903391701300d7kcue>; Wed, 9 Feb 2005 03:39:17 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j193dG7o012623 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 22:39:16 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j193dEse011898 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 22:39:14 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j193dE8c011897 for ietf-openpgp@imc.org; Tue, 8 Feb 2005 22:39:14 -0500
Date: Tue, 08 Feb 2005 22:39:14 -0500
From: David Shaw <dshaw@jabberwocky.com>
To: ietf-openpgp@imc.org
Subject: Re: Policy URL -> Policy URI
Message-ID: <20050209033914.GA11876@jabberwocky.com>
Mail-Followup-To: ietf-openpgp@imc.org
References: <20050207105021.GA17950@phantom.vanrein.org> <3c14e78650fa58b06576b2e617409837@callas.org> <874qgnqryp.fsf@deneb.enyo.de> <20050208183233.GC10858@jabberwocky.com> <20050208213445.GA56118@phantom.vanrein.org> <87ll9ymyn9.fsf@deneb.enyo.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87ll9ymyn9.fsf@deneb.enyo.de>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.7i
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Wed, Feb 09, 2005 at 12:15:38AM +0100, Florian Weimer wrote:
> 
> * Rick van Rein:
> 
> > Florian,
> >
> >> > Back then, the URI *identified* a resource, but this doesn't make much
> >> > sense in the OpenPGP context (were fingerprints are used to identify
> >> > keys).  The keyserver location is just that, a location.
> >> > 
> >> > The URI terminology has changed since then.
> >> 
> >> If URI doesn't mean what it used to, does it then make sense to change
> >> both the keyserver and policy URLs to URIs?
> >
> > Yes, please specify.  We don't want this to end up in a sort of FUD against
> > URIs.  To the best of my knowledge, it's all really simple, as summarised
> > here:
> >
> > http://rick.vanrein.org/blog/notes/urn-uri-url.2005-02-07-13-53.article
> 
> Ahem, STD 66 presents a slightly different view. 8-)
> 
> The problem is that it's impossible to distinguish identifiers and
> locators at the syntax level.  It's not possible to uphold the URN/URL
> distinction.

After giving reading STD 66 a quick once over (and it is indeed new -
less than a month old), I see your point.  Especially since there is
no way to tell them apart anyway, I think that the proper thing for
2440bis is to call *both* keyserver and policy URLs, URIs instead.

There are a number of reasons, but the main one as I see it is that it
is not our business (as OpenPGP people) to tell people what is
acceptable for their keyserver or policy fields to point to.  If
someone wants to point to a book, great.  Go ahead.  If some
implementation wants to support URNs, also great.

Making this change has no impact on any implementations since URLs are
URIs.

David