Re: Application for a formal URN NID

Patrik Fältström <paf@frobbit.se> Wed, 27 March 2013 17:55 UTC

Return-Path: <paf@frobbit.se>
X-Original-To: urn-nid@ietfa.amsl.com
Delivered-To: urn-nid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CAC21F9291 for <urn-nid@ietfa.amsl.com>; Wed, 27 Mar 2013 10:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.695
X-Spam-Level:
X-Spam-Status: No, score=-0.695 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DEAR_SOMETHING=1.605, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k0I2trDMiaZ for <urn-nid@ietfa.amsl.com>; Wed, 27 Mar 2013 10:55:52 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 6C34C21F9290 for <urn-nid@apps.ietf.org>; Wed, 27 Mar 2013 10:55:50 -0700 (PDT)
Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) by mail.frobbit.se (Postfix) with ESMTPSA id 4393721938; Wed, 27 Mar 2013 18:55:49 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Subject: Re: Application for a formal URN NID
From: Patrik Fältström <paf@frobbit.se>
In-Reply-To: <23A64284-6B03-4B24-B680-54A61E96BECA@ittig.cnr.it>
Date: Wed, 27 Mar 2013 18:55:48 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <731D21DD-8474-485B-9E10-07CB68877A98@frobbit.se>
References: <23A64284-6B03-4B24-B680-54A61E96BECA@ittig.cnr.it>
To: Enrico Francesconi <francesconi@ittig.cnr.it>
X-Mailer: Apple Mail (2.1503)
Cc: Pierluigi Spinosa <pierluigi.spinosa@ittig.cnr.it>, urn-nid@apps.ietf.org
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <urn-nid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn-nid>
List-Post: <mailto:urn-nid@ietf.org>
List-Help: <mailto:urn-nid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Mar 2013 17:55:54 -0000

On 27 mar 2013, at 18:08, Enrico Francesconi <francesconi@ittig.cnr.it> wrote:

> Dear Sirs, 
>    as per RFC 3406, we are requesting a two-week review for a formal URN namespace (LEX) related to "Sources of Law". The 
> I-D application for our formal URN NID request is available at:
> http://datatracker.ietf.org/doc/draft-spinosa-urn-lex
> Since this Internet Draft is going to expire on April 4th, 2013, we would kindly ask you if, meanwhile, we have to upload the draft again (even if no changes have been made with respect to the current version (v.07)).

I have a few comments on this namespace, which I in general believe is a Very Good Idea:

1. Non-allocated TLD .LEX

I object to use of the non-allocated TLD .LEX

2. Casing

The text in section 3.3 must be much more clear as there is nothing called case insensitivity globally. Instead it must be clear whether the identifiers are lower case or upper case of whatever base string is chosen, and whether the base string or its case folded equivalent is to be used in the identifier.

More generically, it must be decided what normalisation form strings should be in to be used as tokens in this URN.

3. Use of Unicode codepoints

I do not think the full Unicode codespace should be allowed, even if the codepoints are %-encoded

4. Sub namespaces

Is there an intention to have a registry for for example <authority>?

5. Language tags

I think you should refer to BCP-47 instead of ISO 639-1.

6. Mapping from lex namespace tokens to DNS tokens

What is to be made when/if the lex namespace token include non-ascii?

7. Algorithm for the DNS resolution

In addition to [6], I see there is a mapping from '.' to '-'. Is there some formal syntax to be included?

8. Bidirectionality

There is no mention of potential implications of bidirectional codepoints, and/or the general directionality of the lex identifier itself.

   Patrik