[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..
- [urn] draft-ietf-urnbis-rfc2141bis-urn-19 John C Klensin
- Re: [urn] draft-ietf-urnbis-rfc2141bis-urn-19 Barry Leiba
- Re: [urn] draft-ietf-urnbis-rfc2141bis-urn-19 Julian Reschke
- Re: [urn] draft-ietf-urnbis-rfc2141bis-urn-19 Barry Leiba