[urn] ISSNs, ISBNs, and automatic definition upgrading (was: Re: editorial comments on draft-ietf-urnbis-ns-reg-transition-01)

John C Klensin <john-ietf@jck.com> Fri, 28 February 2014 20:15 UTC

Return-Path: <john-ietf@jck.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 E923F1A0349 for <urn@ietfa.amsl.com>; Fri, 28 Feb 2014 12:15:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] autolearn=ham
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 UZW2IoIOa1oz for <urn@ietfa.amsl.com>; Fri, 28 Feb 2014 12:15:54 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id DB7551A0316 for <urn@ietf.org>; Fri, 28 Feb 2014 12:15:50 -0800 (PST)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1WJTqW-000PCA-RB; Fri, 28 Feb 2014 15:15:48 -0500
Date: Fri, 28 Feb 2014 15:15:23 -0500
From: John C Klensin <john-ietf@jck.com>
To: Peter Saint-Andre <stpeter@stpeter.im>, urn@ietf.org
Message-ID: <1B1D296F042C7A4C9A15F2E8@JcK-HP8200.jck.com>
In-Reply-To: <52FB9D0C.3070508@stpeter.im>
References: <52FB9D0C.3070508@stpeter.im>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/tnWdD9u2STYNHEufMNEzrJ65MDY
Subject: [urn] ISSNs, ISBNs, and automatic definition upgrading (was: Re: editorial comments on draft-ietf-urnbis-ns-reg-transition-01)
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: Fri, 28 Feb 2014 20:15:56 -0000

The other note I promised...

--On Wednesday, February 12, 2014 09:10 -0700 Peter Saint-Andre
<stpeter@stpeter.im> wrote:

> 5. This text might be slightly ambiguous:
> 
>     For both ISSN and ISBN URNs, it is intended that the
> registrations
>     track the evolution of ISO standardization without
> requiring
>     resubmission of the templates or other formal IETF or IANA
>     registration update approval procedures.
> 
> I assume that refers to the current registrations, not any
> future registrations.

As I said, this needs WG thought and input.

As we have seen with the revisions that specified the longer
identifiers for ISBNs, these underlying ISO standards change.
The good news is that, at least in my opinion, changes that
would make older identifiers invalid are just not going to
happen: they would be extremely disruptive and costly to a
community that is very dependent on stability over periods the
IETF has trouble thinking about.  My instinct is to trust that
and allow a registration that does not require revision or
updating to move from one version of an underlying ISO standard
for the identifier to another.  The current reference version
of the underlying standard, syntax, assignment rules, etc., are
what ISO says they are with no IETF, Expert, or registrant
action being required (even though I'm sure we would welcome
explanatory updates).  

I don't know whether that generalizes beyond ISSNs and ISBNs
(and, maybe, if the IAB decides to go in that direction, the
ISO version of DOIs).  We would certainly want to have a very
serious discussion if someone wanted to register a URN
namespace that was dependent on a possibly more volatile set of
references.  But, for this case, it makes sense to me and would
eliminate possible uncertainties between the time an ISO
standard is updated and published and when someone gets around
to updating the URN registration.  Experience leds me to hate
those sorts of timing dependencies, especially when they can be
avoided.

So, two questions (I'll try to interpret the answers, but the
decision about agreement, as I noted earlier, belongs to Andy):

(1) Does the WG agree with my analysis and believe that having
the registration based on the "current version" of the ISO
standard, whatever that version is at a given time, is wise?

(2) If so, how should this be said?  Note that it might (or
might now) require some tuning to 3507bis to get an explicit
statement in the registration template as to whether the
referenced external standard is the version as of some specific
date (and/or version number) or whether it always follows the
versions of the external standard as I'm suggesting here.

thanks,
    john