Re: [urn] Thread about urnbis-semantics-clarif-03 in the context of updating 3986

John C Klensin <john-ietf@jck.com> Tue, 31 May 2016 17:11 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 4905A12D63A for <urn@ietfa.amsl.com>; Tue, 31 May 2016 10:11:25 -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 pPCxqxw51OHu for <urn@ietfa.amsl.com>; Tue, 31 May 2016 10:11:18 -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 7A6B812D520 for <urn@ietf.org>; Tue, 31 May 2016 10:11:18 -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 1b7nCE-000AW1-Kh; Tue, 31 May 2016 13:11:14 -0400
Date: Tue, 31 May 2016 13:11:09 -0400
From: John C Klensin <john-ietf@jck.com>
To: Sean Leonard <dev+ietf@seantek.com>
Message-ID: <E438B36A07F723A65D839E02@JcK-HP8200.jck.com>
In-Reply-To: <2c9b4833-2893-f40a-de06-0f55c8ff468e@seantek.com>
References: <2c9b4833-2893-f40a-de06-0f55c8ff468e@seantek.com>
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/zIPPnP7IXDR_9NX2qe1RZvTqRbQ>
Cc: urn@ietf.org
Subject: Re: [urn] Thread about urnbis-semantics-clarif-03 in the context of updating 3986
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: Tue, 31 May 2016 17:11:25 -0000

Just one reminder on this subject...

The WG has always (or more or less always) considered
urnbis-semantics-clarif as primarily a working document for its
own convenience in developing 2141bis and anything else
relevant.  We've agreed (I think several times) to defer the
question of whether to actually publish it as an RFC until we
were winding up our work (that might be now -- now my call).  If
the WG concludes that it is no longer needed (or, in retrospect,
never was), I'd be the first one to applaud and take it out of
my queue.

That "maybe we will publish and maybe we won't" approach has
almost certainly resulted in a more casual attitude toward
precise text than would have been the case for a draft that was
clearly going to be standards-track or RFC-publication-track.
The assumption, perhaps unrealistic or wrong in retrospect, has
been that, if the WG decided to publish it or its offspring as
an RFC, we would go over it and clean details up at that point.
The approach also dictated at least two other sets of decisions
that have been raised (again) recently:

(1) The reference to it from 2141bis is Informative, not
Normative.  If 2141bis is not constructed well enough to justify
that distinction, it is a problem with it (2141bis) and
suggestions about text are welcome.

(2) There is some, perhaps a good deal, of text in
urnbis-semantics-clarif that is intended to convey the general
sense that the WG isn't sure (and doesn't have clear consensus)
whether there is are issues between 2141bis (etc.?) and 3986 or
not; if there are conflicts, read this document and 2141bis as
authoritative for URNs and not 3986; if there are not, you can
ignore this document.  Section 2, which, as Sean points out, was
carried forward largely unchanged from the "URNs are not URIs"
document (see below), attempts to cover that point.  In
rereading it, it occurs to me that an entirely different
approach could be taken, which would be to say just that, i.e.,
to start from "Some people in the community think there is a
conflict between these URN specs and 3986.  Others disagree.  If
readers find apparent conflicts, especially in the
scheme-specific syntax for URNs, then 2141bis should be treated
as authoritative for URNs independent of what they believe 3986
says."   Such a statement, I'd hope with better wording, could
easily be incorporated into 2141bis and this whole "semantics
versus syntax" discussion and all of the baggage associated with
it discarded.  Or, if someone thinks a separate document is
needed, replacing urnbis-semantics-clarif, as far as I'm
concerned, please have at it.

Finally, not because I'm particularly attached to either
document, but because it might be important, one clarification:
the "URNs are not URIs" proposal came about after some fairly
extensive discussions within the WG about both the apparent
substantive issues involved and about how to change the WG
discussion focus back to URNs and away from
seemingly-interminable discussions about the relationship
between URNs and whatever people thought 3986 said, a set of
discussions that also included examination of places where 3986
appeared to change or constrain 2141 and/or 3406 without
explicitly discussing or updating those documents, leaving all
three in an ambiguous state.    I no longer remember how much of
those discussions were on the mailing list, in formal meetings,
and in sequences of small group conversations, but note that
draft-ietf-urnbis-urns-are-not-uris really was a WG document for
which I drew the short straw to assemble and edit -- fwiw, the
original idea was not mine although I think the syntax split one
might have been.  At a subsequent meeting, the WG decided on the
narrower approach that draft-ietf-urnbis-semantics-clarif
attempts to capture.  I drew that short straw too and, being
lazy (and, IIR, on instructions from that meeting), reused as
much text as I thought feasible.   I hope that the "URNs are not
URIs" approach is part of our past and we can concentrate on
moving forward, but it was a WG document, did have some level of
consensus (although obviously not enough) and I don't think
dismissing it as "John's polemic" is at all helpful.  

That earlier approach could become relevant again in one
particular situation that I hope won't arise.  The in-meeting
conclusion and subsequent list discussion that discarded "URNs
are not URIs" in favor of the syntax-semantics separation was, I
believe, ultimately tentative and experimental wrt the question
of whether the latter separation could be made to work.   If the
WG were to conclude that a distinction is needed and the
syntax-semantics separation is not feasible in practice, unless
we simply decided to abandon URNs, the result would presumably
be a return to the "URNs are not URIs" approach.  That approach
would require updating 3896 as well, but only to the extent of
removing the example at the end of Section 1.1.2, modifying the
example in Section 3, and modifying the discussion in 1.1.3 to
remove the discussion of URNs and maybe non-locator names.  One
of the attractions of that updating relationship was that there
was never any question of its documentary effect on 3986 (unlike
the current discussion about the much finer distinction of the
"semantics-clarif" approach).

  best,
     john