Re: [urn] Feedback on draft-ietf-urnbis-semantics-clarif-03

John C Klensin <john-ietf@jck.com> Sun, 15 May 2016 15:44 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 3A43012D125 for <urn@ietfa.amsl.com>; Sun, 15 May 2016 08:44:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 c4E4i7r6eApa for <urn@ietfa.amsl.com>; Sun, 15 May 2016 08:44:11 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E5CD12D0F6 for <urn@ietf.org>; Sun, 15 May 2016 08:44:11 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1b1yDA-000JkI-Nr; Sun, 15 May 2016 11:44:08 -0400
Date: Sun, 15 May 2016 11:44:03 -0400
From: John C Klensin <john-ietf@jck.com>
To: Julian Reschke <julian.reschke@gmx.de>, urn@ietf.org
Message-ID: <1F5D414703BF94503600A5E3@JcK-HP8200.jck.com>
In-Reply-To: <c19ff352-cd49-d664-9365-28898cff3050@gmx.de>
References: <231532ef-e195-b73d-4a34-eb445bdd1900@gmx.de> <c19ff352-cd49-d664-9365-28898cff3050@gmx.de>
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
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/8PCQdJP8v3mcf4FSG0MTrMdPfAo>
Subject: Re: [urn] Feedback on draft-ietf-urnbis-semantics-clarif-03
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 15 May 2016 15:44:13 -0000


--On Sunday, May 15, 2016 14:48 +0200 Julian Reschke
<julian.reschke@gmx.de> wrote:

> Hi there,
> 
> I haven't seen any substantial feedback on what I wrote two
> weeks ago. Thus here's my attempt to rephrase this in order to
> get more people to think about it.

I have been waiting for the co-chairs to take a position on
whether you are reopening an old topic and will continue to
wait.  The difference between this topic and those to which I
have been responding (to at least a subset) is that, while I
believe we discussed those others and move on, my recollection
is that Andy made a formal consensus call and closed this one.
If we start revisiting old topics without substantial new
information, it very nearly guarantees that we will never get
finished.

Reluctantly and against my better judgment, but in the interests
of saving time, a clarification below.

> On draft-ietf-urnbis-semantics-clarif-03:
> 
> This currently updates RFC 3986. Of course we can do this, but
> RFC 3986 is a full standard, and thus this draft needs to be
> crystal clear about what exactly is being updated. I don't
> think it currently does that; it does some hand-waving with
> respect to what fragments and queries are (without saying
> exactly what's wrong in RFC 3986). It does *not* talk about
> changes to equivalence and relative resolution, although
> draft-ietf-urnbis-rfc2141bis-urn-16 seems to attempt to change
> them.

The update to 3986 is to remove URNs from the scope of URNs
except with regard to URI syntax.  3986 says, effectively, that
URNs are just like any other URIs; the "update" is that they
they are not.  The informal description of
draft-ietf-urnbis-semantics-clarif as "syntax only" is
consistent with that.

That particular "syntax only" decision has some fairly sweeping
implications, which were discussed at the time.  In particular,
it makes the definitions in 3986 --either whatever precise ones
appear or whatever oral tradition they have accumulated in other
forums -- irrelevant: they are not syntax.  So one can argue,
for example, that the way draft-ietf-urnbis-semantics-clarif
uses the term "resource" or distinctions it attempts to make
about it are undesirable, but one cannot appeal to inconsistency
with 3986 to support that view.   In addition, to the degree to
which the WG has already closed out this issue, an argument
about inappropriateness is presumably out of order unless it
includes fundamentally new arguments.  However, again, that
requires a judgment by the co-chairs.

Some of Juha's recent comments highlight another reason for
making the "syntax only" distinction and drawing a hard line
with it: the usage (I'm reluctant to say "definition") of the
term "identifier" in 3986 is incompatible with the meaning and
use of that term in the library and information sciences
community.  Making progress on URNs requires, at least IMO, not
trying to resolve that incompatibility but does require that the
terminology of 3986 not be treated as authoritative for URNs.

As to what should be in which document, the status of
draft-ietf-urnbis-semantics-clarif has, for a long time, been
"decide whether to fold all or part of this into 2141bis when
the WG has consensus about the substantive content of the
latter".   I've been reluctant to do a major merge because of
concern about introducing mistakes in the process, but am happy
to try to do whatever the WG actually wants. 

Finally, the "syntax only" separation is intended to remove the
implication that URNs (at least of the "urn:" scheme, but that
was deliberately left ambigious) are separate from all other
URIs (if one believes that the language of 3986 creates a
dichotomy, "all other URIs" == "URLs") and therefore that
questions like "how does this affect URL processors?" have a
uniform answer of "not at all, because even 3986 says that URNs
are not URLs".

    best,
      john