Re: [urn] Benjamin Kaduk's Discuss on draft-hakala-urn-nbn-rfc3188bis-01: (with DISCUSS and COMMENT)
John C Klensin <john-ietf@jck.com> Fri, 08 June 2018 00:52 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 E5FE8131004; Thu, 7 Jun 2018 17:52:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 l2OPK61bWjLM; Thu, 7 Jun 2018 17:52:30 -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 CD39C130E04; Thu, 7 Jun 2018 17:52:30 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1fR5di-000Gel-KS; Thu, 07 Jun 2018 20:52:26 -0400
Date: Thu, 07 Jun 2018 20:52:21 -0400
From: John C Klensin <john-ietf@jck.com>
To: Peter Saint-Andre <stpeter@mozilla.com>, Adam Roach <adam@nostrum.com>, Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
cc: urn@ietf.org, draft-hakala-urn-nbn-rfc3188bis@ietf.org
Message-ID: <889191E8A3294673F32181B3@PSB>
In-Reply-To: <7aad7f1f-ca4c-51d3-a1f4-aefb919dae34@mozilla.com>
References: <152837409539.30768.4568779645299135020.idtracker@ietfa.amsl.com> <6a1a100c-3bc0-76d3-3ae4-047d37906bfc@mozilla.com> <7161340e-014b-3740-83ed-39f4db3a30c0@nostrum.com> <7aad7f1f-ca4c-51d3-a1f4-aefb919dae34@mozilla.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: <https://mailarchive.ietf.org/arch/msg/urn/FFK7qu5Pc1zmhjuW7M3dArR2vGE>
Subject: Re: [urn] Benjamin Kaduk's Discuss on draft-hakala-urn-nbn-rfc3188bis-01: (with DISCUSS and COMMENT)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.26
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: Fri, 08 Jun 2018 00:52:37 -0000
--On Thursday, June 7, 2018 16:29 -0600 Peter Saint-Andre <stpeter@mozilla.com> wrote: > Text along those lines seems appropriate. We might also > discourage people from defining their own canonical > transformation, but rather re-use one that's already defined > (say, a PRECIS profile such as UsernameCaseMapped). I started to write a much longer note and explanation, but maybe a summary is better for all concerned (i.e., if more is needed, it is readily available). IMO, there are two separate issues involved with this discussion. One is whether an Internationalization Considerations section is needed. It seems to me that it is, but that it should mostly be part of much clearer explanations in RFC 3986 about what rules, especially about canonical forms and matching, apply to all URI types, what is delegated to schemes/methods, and what can reasonably be further delegated by particular schemes to, e.g., for the URN case, particular namespaces. The URNBIS WG discussed whether to try to incorporate that type of explanation into what became RFC 8141 but concluded that would be unwise, in part because it would risk contradictions between the way some of those in the URN community interpreted (or wanted to interpret) 3986 and the way some of those in the more traditional web community (a subset of whom are offended at the whole idea of URNs interpret 3986. Pushing those issues and that debate into the definition of a particular namespace seems unwise and inappropriate. While the other is about i18n, it is less about what I would think of as internationalization considerations for NBNs in general then it is about free advice to those who are defining national sub-namespaces for NBNs. Make statements like that if you like (and please pay attention to whatever Juha, who is ultimately responsible for the text, has to say on the subject), but remember that the managers of those national sub-namespaces are mostly repository libraries who, in general, know far more about their names, their languages, and how Unicode relates to those languages than we can hope to. Remembering that NBNs are already deployed by some of those libraries and that they have hundreds of years of experience with the types of identifier, and identifier comparison rules, that work for them, I personally think that the IETF should be a little careful about hubris in giving advice on those issues, but whatever works. best, john
- Re: [urn] Benjamin Kaduk's Discuss on draft-hakal… Adam Roach
- Re: [urn] Benjamin Kaduk's Discuss on draft-hakal… Peter Saint-Andre
- Re: [urn] Benjamin Kaduk's Discuss on draft-hakal… Peter Saint-Andre
- Re: [urn] Benjamin Kaduk's Discuss on draft-hakal… John C Klensin
- Re: [urn] Benjamin Kaduk's Discuss on draft-hakal… Benjamin Kaduk
- Re: [urn] Benjamin Kaduk's Discuss on draft-hakal… Benjamin Kaduk
- Re: [urn] Benjamin Kaduk's Discuss on draft-hakal… Adam Roach
- Re: [urn] Benjamin Kaduk's Discuss on draft-hakal… Peter Saint-Andre
- Re: [urn] Benjamin Kaduk's Discuss on draft-hakal… John C Klensin
- Re: [urn] Benjamin Kaduk's Discuss on draft-hakal… Hakala, Juha E
- Re: [urn] Benjamin Kaduk's Discuss on draft-hakal… Benjamin Kaduk