[urn] draft-ietf-urnbis-rfc2141bis-urn-19

John C Klensin <john-ietf@jck.com> Sat, 31 December 2016 16:31 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 F07331294A0 for <urn@ietfa.amsl.com>; Sat, 31 Dec 2016 08:31:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5
X-Spam-Level:
X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 pWqLaLVgOL3Y for <urn@ietfa.amsl.com>; Sat, 31 Dec 2016 08:31:27 -0800 (PST)
Received: from bsa2.jck.com (ns.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 B3F38129490 for <urn@ietf.org>; Sat, 31 Dec 2016 08:31:27 -0800 (PST)
Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1cNMZ4-000K5M-Lt for urn@ietf.org; Sat, 31 Dec 2016 11:31:26 -0500
Date: Sat, 31 Dec 2016 11:31:19 -0500
From: John C Klensin <john-ietf@jck.com>
To: urn@ietf.org
Message-ID: <C39D7B0C7841906AF86E94AD@PSB>
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.70
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/KCTTcWdoesvx8Mi2IvMZh4abuW0>
Subject: [urn] draft-ietf-urnbis-rfc2141bis-urn-19
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: Sat, 31 Dec 2016 16:31:29 -0000

Hi.

Ok, draft-ietf-urnbis-rfc2141bis-urn-19 has been posted.  It
incorporates the changes to the definition and use of "lcoator"
discussed on this list over the last 48 hours as well as a
number of editorial changes to improve clarity and readability.
For example, there are now several more explicit inter-sectional
cross-reference and some redundant text has been eliminate.  In
some case, the revisions make the text a bit more tedious, but
we have concluded that a bit of tediousness is preferable to
user confusion.

There has also been a small change in tone wrt 3986.   The
existence of conceptual, and sometimes confusing, differences
between 3986 -- a URL document with some URN aspects and
inclusions [1] -- and 2141bis have been called out explicit.
There are two reasons for this, neither of which is an attack on
3986:  (i) to reduce opportunities for endless discussions about
apparent, but small, differences in terminology between this
specification and 3986, as discussed on this list over the last
couple of weekss; (ii) to try to protect the URN definition
against the apparent likelihood that, whether the decision is
made in the marketplace or other SDOs, we seem to be in danger
of ending up with at least three different, even if mostly
consistent, specifications of URIs or subsets of them: 3986, the
WHATWG URL definition effort, and statements in various W3C
specs (notably related to HTML).

It is possible that a similar comment should be made about the
relationship between this document, its terminology, and other
specifications (whether internal or external to the IETF).   If
that is true, please send references and recommended text to the
list.

For Section 4.3(2), Henry suggested slightly different text; I
(and Peter) believe what is now present does the job and fits
better with the surrounding sections.  Anyone who believes
otherwise and thinks the debate is wroth reopening should say so.

Peter and I believe this draft is suitable for WGLC and that it
would be appropriate for the co-Chairs and WG to take a
"showstoppers and major issues only" position relative to
further comments.  We (and, as I understand it, Barry and
alexey) would really like to get this tied up before the Chicago
IETF.  The only way I can see to accomplish that is to stop
nit-picking about, e.g., minor issues of terminology.

best,
    john




[1] See the 2141bis text for details and references..