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