Additional syntax for URNs

worley@ariadne.com (Dale R. Worley) Mon, 29 September 2014 16:03 UTC

Return-Path: <worley@ariadne.com>
X-Original-To: urn-nid@ietfa.amsl.com
Delivered-To: urn-nid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD7E1A8822 for <urn-nid@ietfa.amsl.com>; Mon, 29 Sep 2014 09:03:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham
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 gQmwPw-SxLaq for <urn-nid@ietfa.amsl.com>; Mon, 29 Sep 2014 09:03:24 -0700 (PDT)
Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91F0A1A8842 for <urn-nid@ietf.org>; Mon, 29 Sep 2014 09:03:24 -0700 (PDT)
Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-12v.sys.comcast.net with comcast id x43A1o0062LrikM0143P7W; Mon, 29 Sep 2014 16:03:23 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-12v.sys.comcast.net with comcast id x43N1o0151KKtkw0143Pr7; Mon, 29 Sep 2014 16:03:23 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s8TG3Mu7011506 for <urn-nid@ietf.org>; Mon, 29 Sep 2014 12:03:22 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s8TG3Mwh011505; Mon, 29 Sep 2014 12:03:22 -0400
Date: Mon, 29 Sep 2014 12:03:22 -0400
Message-Id: <201409291603.s8TG3Mwh011505@hobgoblin.ariadne.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: urn-nid@ietf.org
Subject: Additional syntax for URNs
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412006603; bh=/5UdPqvfV05iTmK/dCuT/+++auoRQQIkrumqGQ56oMY=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=Ux/xQCDf8JtBTMLGDmGKimBmG80NpExWt4aIBAFuIqZYgT8yS9Jh9NrOVKTUar8hR Y/Tcp5oXNjBzurd1UbBMiVH1fSlVEB3p7/wptmhcHydWe7qt5foQqLg5CAfrlQKdot 5wWhYdBIC1aAWe+7EGgOY6KxOnHCatXH9GxZhmZFidHIlF8IWYqvWGHrVy10ZLHPw9 ognfBg8jn6OGI+B0qc/gHwlkB23f2qQNnSMjNMGfgnHqkSM2+1xw4GS1lleD8f+XFC bCQ/fOi9Jx/IpCFlSgEaCMpTuL4pJ50tAF1+GX7UztTO7Zt+tCFSkL1UznrltPW3+o SKWtdq7Q2O6Rg==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn-nid/j40_4O82IdoxCE_OFnaoMIDwinI
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 29 Sep 2014 16:03:30 -0000

A lot of URN syntax defintions involve the category "a segment of one
or more URN characters not containing a colon" as part of the NSS
definition.  Each definition has to redefine this category, because it
is not in RFC 2141.  So I'd like to propose this addition to the
syntax, for use by all future URN definitions:

   <urn-segment>  ::= 1*<nc-urn-chars>
   		  ; one or more URN NSS characters, excluding colon ":"

   <nc-urn-chars> ::= <nc-trans> | "%" <hex> <hex>

   <nc-trans>     ::= <upper> | <lower> | <number> | <nc-other> | <reserved>

   <hex>          ::= <number> | "A" | "B" | "C" | "D" | "E" | "F" |
                      "a" | "b" | "c" | "d" | "e" | "f"

   <nc-other>     ::= "(" | ")" | "+" | "," | "-" | "." |
                      "=" | "@" | ";" | "$" |
                      "_" | "!" | "*" | "'"

Unfortunately, this is almost but not completely the same as
<segment-nz-nc> in RFC 3986, but the latter allows "&" and "~", which
are not permitted in NSSs.

Dale