Re: [urn] URN registration request for SCTE

worley@ariadne.com (Dale R. Worley) Thu, 22 August 2019 01:39 UTC

Return-Path: <worley@alum.mit.edu>
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 D87FA120169 for <urn@ietfa.amsl.com>; Wed, 21 Aug 2019 18:39:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.684
X-Spam-Level:
X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net
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 C_Kby6mxGzSO for <urn@ietfa.amsl.com>; Wed, 21 Aug 2019 18:39:23 -0700 (PDT)
Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1EA12010D for <urn@ietf.org>; Wed, 21 Aug 2019 18:39:22 -0700 (PDT)
Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-03v.sys.comcast.net with ESMTP id 0bSSi9slpewmG0c4PiS3mm; Thu, 22 Aug 2019 01:39:21 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1566437961; bh=XJt9EYpDUPDuqZiQU50NCUUA6enqPpxjk4YojdUnCwM=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=ArpbHHVDH1mO3K8J88LL3udyz+5hlA9vajL8DMZ/bIrGZ8gSl4NAZSBsBqxERx5Hz xUNzxWJOuKTV+rjAsVwKHtTvsm1HdJqw8WoMLFyBNRMQDh+o9DgrFOykyR7q6RkJq4 +1si3z2ZqZLR3zeN1TnRbJ2oo2rHKhiUWbgWKxwo8LuGs4rOMDfyDSbthHl3kOc8rU NeBd4gwbqnys3NirZiaOp9H70Bk8vHmmQLue71sl9tQucYNIPfYngS24wQ34qXWqrc Mg9C9AUTpkANlSt6lMstkvt9DZYKJlzMS5F01MeyDMBrHgNYHPBHuspUAQivb7SlJz JC6rEyBWXeeew==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-11v.sys.comcast.net with ESMTPA id 0c4Oiz7WCRpok0c4OixudD; Thu, 22 Aug 2019 01:39:21 +0000
X-Xfinity-VMeta: sc=-100;st=legit
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 x7M1dJ4u031568; Wed, 21 Aug 2019 21:39:19 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id x7M1dJTP031563; Wed, 21 Aug 2019 21:39:19 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Gary Hughes <ghughes1138@gmail.com>
Cc: urn@ietf.org, dstoneback@scte.org, paul.woidke@icloud.com
In-Reply-To: <CAMDWyD+nMDEf8+YdNW6i5rGzRUC4Pur1rj6ghm4pbugLsXJqrA@mail.gmail.com> (ghughes1138@gmail.com)
Sender: worley@ariadne.com
Date: Wed, 21 Aug 2019 21:39:18 -0400
Message-ID: <87h86ayo55.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/-mqCBUoOlv9ibVKZ8caTc6UPZP8>
Subject: Re: [urn] URN registration request for SCTE
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 22 Aug 2019 01:39:25 -0000

Here are my comments on the registration.  There are a few places where
the text could be clarified.

Dale

    Occasionally, SCTE specification efforts require identifiers in a managed
    namespace so that they are unique and persistent.  To ensure that the
    uniqueness is absolute, the registration of a specific Uniform Resource
    Name (URN) Namespace Identifier (NID) for use by SCTE is being specified in
    RFC8141, in full conformance with the NID registration process specified in
    RFC8141 [RFC8141]

There are some extra words in that last sentence.  I think you can
omit "RFC8141, in".

    When SCTE specifications require the use of data models, URN Namespaces are
    key constructs to manage the definitions of those data models reliably with
    persistence and uniqueness.

    The use of URNs should also help specification authors to maintain
    different versions of URNs and dependencies between URNs across different
    versions of SCTE specifications if they so wish.

I'm not sure, but I think you want to replace "different versions of
URNs and dependencies between URNs" with "different versions of
identifiers and dependencies between ideentifiers" -- because of
course, the use of URNs is helpful in maintaining different versions
*of URNs*.  It's more interesting that use of URNs is helpful in
maintaining different versions of *identifiers* generally.

    *Syntax*:

    The Namespace Specific String (NSS) of all URNs that use the "scte" NID
    will have the following structure:

	     urn:scte:{SCTEresource}:{ResourceSpecificString}

    where the "SCTEresource" is a US-ASCII string that conforms to the URN
    syntax requirements of [RFC8141].

The NSS is the part after "urn:scte:", so the above needs to be
edited.  (The definition of NSS is in RFC 8141, but it's not
particularly well pointed out.  The critical parts are:
      assigned-name = "urn" ":" NID ":" NSS
      ["assigned-name" is roughtly the same as "URN" as used here]
      NID           = (alphanum) 0*30(ldh) (alphanum)
      ldh           = alphanum / "-"
      NSS           = pchar *(pchar / "/")

One correct alternative is:
    All URNs that use the "scte" NID will have the following structure:

	     urn:scte:{SCTEresource}:{ResourceSpecificString}

    where "{SCTEresource}" and "{ResourceSpecificString}" are
    US-ASCII strings such that the URN conforms to the syntax
    requirements of [RFC8141].

Is it intended that "SCTEresource" will never contain ":"?  If that is
true, then it is guaranteed that an SCTE URN can be uniquely parsed
into SCTEresource and ResourceSpecificString.  And if that restriction
is true, it would be helpful to state it here.

It would be particularly helpful to give a specific grammar for
SCTEresource and ResourceSpecificString.  In SCTE's case, I think this
is what you want:

    SCTEresource = ( unreserved / pct-encoded / sub-delims / "@" )
        *( unreserved / pct-encoded / sub-delims / "@" / "/" )

    ResourceSpecificString = *( pchar / "/" )

--

    SCTE publishes information regarding the registered resources in the
    corresponding SCTE standards. The "SCTEresource" may be used to identify
    the SCTE standard or the project which defined the URN. The
    "ResourceSpecificString" specifies the name and optionally the edition
    (year) of the standard that first defined the URN.

    For example:

The examples would be easier to read if the two example lines were
indented.  (Note that the recorded version of the registration will be
the *text* version.)

    urn:scte:dash:essential-event:2015

    Event essentiality, first defined in the 2015 edition of the SCTE DASH
    specifications

This is unclear.  Is "event essentiality" a property of some thing not
described here?  If so, it would help to say "A URN which designates
the property 'event essentiality' of XYZs ...".

    urn:scte:scte35:2013:xml

    XML representation of SCTE 35 commands, first defined in the 2013 edition
    of ANSI/SCTE 35

This is unclear.  In what sense is "XML representation" to be taken?
As phrased, it sounds like an abstract concept.  I suspect what you
mean is "The name of an XML namespace used to represent SCTE 35
commands".

    Published SCTE standards are freely downloadable from the SCTE web site at:
    https://www.scte.org/SCTE/Standards/Download_SCTE_Standards.aspx.

    *Assignment**: *

    SCTE will maintain a naming authority, the SCTE Assigned Names and Numbers
    [SANN] specification, that will contain the assignment of SCTE resource
    classes and the specific registration values assigned for each resource
    class.  This specification will be published on the SCTE Standards Program
    website (
    https://www.scte.org/SCTE/Standards/SCTE_Assigned_Names_and_Numbers_specification.aspx)
    and updated as needed.

    The SANN specification will only document URNs defined in SCTE standards.

Is this meant to imply that SCTE URNs can only be assigned via SCTE
standards -- or can they also be assigned in other ways, but only the
ones assigned in standards will be documented at
https://www.scte.org/SCTE/Standards/SCTE_Assigned_Names_and_Numbers_specification.aspx?
This needs to be clarified both here and in the Purpose and
Documentation sections.  And if the latter is intended, you need to
clarify how assignment of URNs not defined in standards is managed.

[END]