draft-seantek-rdf-urn-00 and draft-seantek-xmlns-urn-00

worley@ariadne.com (Dale R. Worley) Thu, 13 November 2014 17:22 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 D42591A8AE9 for <urn-nid@ietfa.amsl.com>; Thu, 13 Nov 2014 09:22:51 -0800 (PST)
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, 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 BXUDgvjtMJVe for <urn-nid@ietfa.amsl.com>; Thu, 13 Nov 2014 09:22:44 -0800 (PST)
Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7A0C1A8B84 for <urn-nid@ietf.org>; Thu, 13 Nov 2014 09:22:44 -0800 (PST)
Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-10v.sys.comcast.net with comcast id F5NS1p0052Ka2Q5015NkbJ; Thu, 13 Nov 2014 17:22:44 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-11v.sys.comcast.net with comcast id F5Nj1p00A1KKtkw015NjYV; Thu, 13 Nov 2014 17:22:44 +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 sADHMgqS005206; Thu, 13 Nov 2014 12:22:42 -0500
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id sADHMgqR005203; Thu, 13 Nov 2014 12:22:42 -0500
Date: Thu, 13 Nov 2014 12:22:42 -0500
Message-Id: <201411131722.sADHMgqR005203@hobgoblin.ariadne.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: dev+ietf@seantek.com, urn-nid@ietf.org
In-reply-to: <201411130237.sAD2behU001729@hobgoblin.ariadne.com> (worley@ariadne.com)
Subject: draft-seantek-rdf-urn-00 and draft-seantek-xmlns-urn-00
References: <05E89947-5180-40BB-A14A-9D97E92DDAB1@seantek.com> <201411130237.sAD2behU001729@hobgoblin.ariadne.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1415899364; bh=gK05kH2BzNWugWEbwiIiGaIunaMcxqNimX85vHEfcFU=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=R9EE2BQVh3yzIuXBbdbaFfazq20OikM9Y8YGISa/xuQL0HSdjygM3iYB6SWRRfRy6 WVb0T2Fdm4iOAZe6nevaAxB6wkn39u0UxmHaf9tfNg1QLcooEtPg0v58SBF6TjNqUk Iq2n//N9nnZR5craS4RK0UWqVnQPlZHfASD0DBi98JMWiMr4q/wTCwtl7OEB4g2pVM eUwbUIJJjtXhftM5wTuPMm/gpq370mhRvfoMZE8Unq5KMYmBtsXWS5BjfzXlCnSQz8 QGKJ8r1efJDvFc39/ds2fH4po4w0GJ0G2b1o/8o+a0tDRAr7+W8s2TWKTLj5zkkSRD 2zMY9pFcI5TFA==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn-nid/HVvY5ahsFz2UwDoP-VMYxzBCJJI
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: Thu, 13 Nov 2014 17:22:53 -0000

I notice a strong similarity between these two drafts,
draft-seantek-rdf-urn-00 and draft-seantek-xmlns-urn-00, as they
propose two NIDs with the same syntax, registration procedures, and
resolution properties.  The only difference is what the resulting URNs
are intended to be used for.

It would seem to me to provide simplicity and more functionality if
the two drafts were combined to propose a single NID whose URNs could
be used as either XML namespace identifiers or RDF node identifiers --
or for identifying other things.

Combining the drafts would also avoid duplicate discussion of whether
there was enough value in the purpose of the NID:  to provide short,
memorable identifiers that do not depend on (or refer to) domain
registrations.

In regard to the registration of the URIs associated with URNs and the
resolution of the URNs into the associated URIs, let me propose that
this data be be retrievable from some suitable zone of the DNS along
the following lines:

    Some suitable domain name should be chosen, either under
    .IANA.ORG.  or .ARPA.  The information for any particular URN
    would be stored under the name <URN>.<domain-name>.  Or better,
    <NSS>.<domain-name>.  But since IANA assigns names in large
    top-level domains like .COM., it already has the facilities to
    maintain such a zone.

    This scheme does limit the URNs to the maximum DNS label length,
    which is 63 octets.  This seems to me to not be a serious
    restriction, given the goals of the NID definition.  But perhaps
    it would be troublesome for, e.g., NSSs made of CJK characters,
    which generally require 3 octets each in UTF-8, which is encoded
    as 9 characters in URNs.  Perhaps the NSS should be pre-processed
    by converting the %-escapes into the octets they represent?  That
    would allow 21 CJK characters.  Or a scheme can be devised to
    map longer NSSs into more than one level of DNS label.  We'd still
    be limited by the 255 octet limit on DNS names as a whole.

    The information associated with a URN is:  the description, the
    registrant, and the associated URIs.  Assuming that each of these
    data are short enough, they can be stored in DNS RRs with the
    suitable DNS name.  Since there is no shortage of DNS RR types
    (they are 16-bit integers) it would seem suitable to choose three
    new RR types to identify these records.

Dale