Re: URN Namespace for MEF

worley@ariadne.com (Dale R. Worley) Fri, 06 November 2015 22:57 UTC

Return-Path: <worley@alum.mit.edu>
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 C89FD1A8A6A for <urn-nid@ietfa.amsl.com>; Fri, 6 Nov 2015 14:57:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 yVH4tR3wabp1 for <urn-nid@ietfa.amsl.com>; Fri, 6 Nov 2015 14:57:10 -0800 (PST)
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.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C32F01A8AB3 for <urn-nid@apps.ietf.org>; Fri, 6 Nov 2015 14:57:08 -0800 (PST)
Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-12v.sys.comcast.net with comcast id eNwl1r00A2Ka2Q501Nx7xN; Fri, 06 Nov 2015 22:57:07 +0000
Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-11v.sys.comcast.net with comcast id eNx61r00L1nMCLR01Nx7A1; Fri, 06 Nov 2015 22:57:07 +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 tA6Mv66Z007408; Fri, 6 Nov 2015 17:57:06 -0500
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id tA6Mv50A007405; Fri, 6 Nov 2015 17:57:05 -0500
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Subject: Re: URN Namespace for MEF
In-Reply-To: <DC9B6641-378A-4605-8A42-905115DBE389@gmail.com> (mjethanandani@gmail.com)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Fri, 06 Nov 2015 17:57:05 -0500
Message-ID: <87y4ea20u6.fsf@hobgoblin.ariadne.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1446850627; bh=fd2bhWEr51H4Cj8FLWTiUxZh9wU2tYKIQul6jCRdPd0=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Oi77cafq6+2tKZSOz69uRWpSMH+dhpgifO3hbKtvTx9DwAVRMxQ5Jlf+OJiW9/bbG vKE/JZkgcrVYy9WDDwYpLsEpBY6Wbx9IH2kgZxrUqJLuWkZlyHTlJ0uXZ9yCP4SX7e UI+0RC3JaRgFqu3p613bV9USRjdPdJZIwmBxvBemClExpZZMRpfhbcxQsQp85QqWpv v9hBMp+rjkkypXxD68OLOMxMAqQMNjELCrrPbXlI5fcFwuZohGBahV1JnfI+QdOycp 6KagGAqR3aPO80Pm7Ou5V6mQzRxejDrWbo+W33lwtWjIyFt/ZQY9vp+BWuCAUm2YjN 6EIwZ3vDK/U4g==
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn-nid/vS9Yl3IpfNe-hpP-5tud4dsukTs>
Cc: urn-nid@apps.ietf.org
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 06 Nov 2015 22:57:12 -0000

Section 2:

   Declaration of syntactic structure:

      The Namespace Specific String (NSS) of all URNs that use the MEF
      NID will be maintained by MEF Assigned Names and Numbers (MANN)
      registry.

This doesn't specify the syntactic structure.  I assume that the
intention is that this registration is to allow MANN to assign any NSS
that would be allowed by the generic URN specification.  But you should
say that.  I think you could say

      The syntax of namespace specific strings for the 'mef' namespace
      is <NSS> in RFC 2141.

The statement you now have in the section describes who manages mef
URNs, which is a useful thing, but doesn't belong in this section, I
think.  But I can't spot the place in the registration template where it
should go.

   Identifier uniqueness considerations:

      MEF could allow for use of experimental type values for testing
      purposes only.  Note that using experimental types may create
      collision as multiple users may use the same values for resources
      and specific strings.

First, you should say "for *different* resources ...".  If multiple
users use the same value for the same resources, there is nothing
unusual about that.

This provision doesn't bother me, but is likely to be objected to by
others.  And there can be practical problems -- experimental uses of
protocols by one user sometimes "leak" into experimental environments
operated by another use, causing unexpected results.  You should give
some though to avoiding this, IMO.  Perhaps:

1) Devise a system for allocating experimental values that allows each
user to generate values that will not be allocated by other users.
E.g., the pattern "urn:mef:experimental:foobar.com:..."; or

2) Define the "value" of an experimental URN in terms of its *function*
or high-level *meaning* ("denotes the string to be returned when
conditions X and Y occur"), allowing different users to have it be
translated in different manners or cause different effects, but always
with the same higher-level significance.

Dale