[urn] Open letter to WG participants (was: Re: Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt)

John C Klensin <john-ietf@jck.com> Thu, 19 September 2013 15:10 UTC

Return-Path: <john-ietf@jck.com>
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 123B721F992A for <urn@ietfa.amsl.com>; Thu, 19 Sep 2013 08:10:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.493
X-Spam-Level:
X-Spam-Status: No, score=-104.493 tagged_above=-999 required=5 tests=[AWL=1.106, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 JvHAeS36RvXL for <urn@ietfa.amsl.com>; Thu, 19 Sep 2013 08:10:16 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 418AE21F991E for <urn@ietf.org>; Thu, 19 Sep 2013 08:10:16 -0700 (PDT)
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 1VMfry-000FDq-Lv; Thu, 19 Sep 2013 11:10:14 -0400
Date: Thu, 19 Sep 2013 11:10:09 -0400
From: John C Klensin <john-ietf@jck.com>
To: urn@ietf.org
Message-ID: <DE0C252DDFED432BE55C5809@JcK-HP8200.jck.com>
In-Reply-To: <523A89F6.8040603@helsinki.fi>
References: <24637769D123E644A105A0AF0E1F92EFA4378BCB@dnbf-ex1.AD.DDB.DE> <522096F9.5000609@helsinki.fi> <A3C12A020F3F60A0D8906654@JcK-HP8200.jck.com> <5226A326.909@stpeter.im> <8C4C9A1E61F8B275809A92C9@JcK-HP8200.jck.com> <523A89F6.8040603@helsinki.fi>
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
Subject: [urn] Open letter to WG participants (was: Re: Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Sep 2013 15:10:21 -0000

Hi.   This note started as part of a reply to 

To be clear, I've got two personal goals in this.  I hope most
of the WG shares them, but I have no way to tell.  

One is to get the core set of URN specs far enough along that
the WG can finish them and get them through the process and
published.  Because of necessary interdependencies, I think that
list is 2141bis (syntax), 3406bis (namespace definition and
registration), last month's ns-reg-transition document, and,
probably, 3188bis (NBN).   I'm concerned that, if we don't get
on with this, various parties will make assumptions about what
we will do or should do and go off on their own, leading to
future compatibility and interoperability problems.  In
addition, there are a number of URN registrations in various
pending states now (including one that stirred up a lot of noise
on the IETF list in the last weeks).  We would be far better off
if they could get approved/registered under 3188bis.  Otherwise,
we will need to worry about whether or not they need to be
upgraded.  

The WG will be three years old in late November.  I hope and
wish we could set a target of having the documents in the hands
of the IESG well before that, ideally before Vancouver.   

Second, it seems obvious to me that we need to future-proof
2141bis and, to the extent necessary, 3406bis.  There have been
several incidents around the IETF in recent years in which
people have said things equivalent to "cannot change or expand
that feature because it was specified a different way once and
has to be that way forever".  The discussions that follow are
always complex and unpleasant because the tradeoffs between
stability and increased functionality or interoperability are
difficult; usually the results are "least bad" solutions.  

In particular for queries, 2141 was wise in reserving "?" and
therefore queries, but, if we even allow "?" in the syntax, we
need to be careful that we don't create a future trap for
ourselves.   A registry of query keywords would be a big step
and almost certainly not in the spirit of 3986.  It is pretty
clear to me that, if we want to do it, we need to do it now, not
just to create the registry and rules for it but probably to
define a way of distinguishing, by syntax, between keywords that
are intended to have global meaning and those that are to be
interpreted locally.  I don't see reserving a specific keyword
or two to have nearly the same implications as trying to give
still-unspecified keywords global meanings but either approach
becomes part of the critical path and interferes with my "swift
completion" fantasies, especially given the speed at which this
WG seems to hold discussions.

best,
   john

p.s. the supposed WG LC that started this thread was announced
for two weeks starting 13 August and was supposed to terminate
on 27 August
(http://www.ietf.org/mail-archive/web/urn/current/msg02062.html).
It is now over three weeks since the closing date and I, at
least, have no idea where we are.  Do the WG Chair(s) think we
have consensus?  Is a new version of 2141bis to reflect the many
comments expected and, if so, when?  Given the dependencies
between 2141bis and 3406bis and the risk that details of the
latter will require changes to the former, when do we expect the
promised new version of 3406bis?