Comments on draft-dthakore-scte-urn-00.txt (Dale R. Worley) Wed, 13 April 2016 19:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0FDC12E0D4 for <>; Wed, 13 Apr 2016 12:46:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SKlPKbttt4Dl for <>; Wed, 13 Apr 2016 12:46:44 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 9880412D8ED for <>; Wed, 13 Apr 2016 12:46:44 -0700 (PDT)
Received: from ([]) by comcast with SMTP id qQkGaOLpNLCmUqQkNaXhjc; Wed, 13 Apr 2016 19:46:43 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1460576803; bh=ltySiyQfrT/Nvq1SuKpLZOyhqmIe04P5Sv4f5jAxEKg=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=FSXtCSsie7y70jCHwVdQwWxTo2KpiEVhSuBIRpx/J02tPMtjL0sQWE3GLfmEbYZ8n /4qPHY8X+jbr+tbinNddfvAWbL1EhOZw5Fp/ktAH6WxEvqPJJn/9jvWZQuwo4NaomN F2bqbUz/y+mCu1oPlQLn8m7lHaHNDGz249HIME3AmGpjoFPigMzZgP4CiaunxggIcV SM6rUXFNxja8zSlMz9wJ61+Gq0J/j25uJD8k9n5E1e7VymaoTAWG/n18CX64Vu8wFv +Wtd9aiExmdeC9MNJrJqx+4zQmnbe4rco5JGMpxcooBKN9xDRREnLq8ZnBHjKrrAp6 VAX4tw6CAS2zg==
Received: from ([]) by with comcast id hvmj1s0051nMCLR01vmjX4; Wed, 13 Apr 2016 19:46:43 +0000
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id u3DJkg4m006288; Wed, 13 Apr 2016 15:46:42 -0400
Received: (from worley@localhost) by (8.14.7/8.14.7/Submit) id u3DJkfEe006285; Wed, 13 Apr 2016 15:46:41 -0400
X-Authentication-Warning: worley set sender to using -f
From: (Dale R. Worley)
To: Darshak Thakore <>
Subject: Comments on draft-dthakore-scte-urn-00.txt
In-Reply-To: <>
Sender: (Dale R. Worley)
Date: Wed, 13 Apr 2016 15:46:41 -0400
Message-ID: <>
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Apr 2016 19:46:46 -0000

Overall, the document looks fine, but there are a bunch of wording
improvements that should be done.

section 1

   SCTE standards work includes: data and telephony
   over cable; application platform development; digital video;
   emergency alert systems; network monitoring systems; cables,
   connectors and amplifiers; construction and maintenance practices;
   energy management, and more.

The final comma in this sentence should be a semicolon.

section 2

         Name: Society of Cable Telecommunications Engineers
         Address: 140 Philips Road, Exton, PA 19341-1318, USA
      Designated contact

         Role: Manager, Standards
         Email: TBD

It looks like there should be an empty line above "Designated contact".

As Ted noted, an e-mail address is needed.

   Declaration of syntactic structure:

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


      where the "SCTEresource" is a US-ASCII string that conforms to the
      URN syntax requirements of [RFC2141].
      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.

Is there supposed to be an empty line above "SCTE will maintain"?  The
flow of the words is interrupted.

The syntax you show is the structure of all "scte" URNs; the NSS has
the structure "{SCTEresource}:{ResourceSpecificString}".

The text should state that the string "{SCTEresource}" specifies the
resource class, and that "{ResourceSpecificString}" specifies the
resource within the class.

The phrase "conforms to the URN syntax requirements of [RFC2141]" is
vague; it would be better to say that it "conforms to <nonterminal> of
[RFC 2141]", where <nonterminal> is the syntax you desire.  A
specification like this needs to be given for both "{SCTEresource}"
and "{ResourceSpecificString}".  Beware that if the definition of
"{SCTEresource}" allows it to contain a colon, then a "scte" URN
cannot be uniquely parsed, and so you probably want to forbid that.

      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.

Since "SANN" is not a reference but an abbreviation of what preceeds
it, it should probably be put in (...) rather than [...].

The phrase "This specification" could refer either to the draft/RFC
or SANN.  It would be clearer to change it to "SANN".

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

The terms "class" and "type" seem to be used interchangeably for the
subsets of resources named by these URNs.  If so, one term should be
used throughout.

I think "SCTE may allow" is better than "SCTE could allow", since the
draft/RFC is to specifically allow SCTE to do so.

      Each such resource may have three types registration activities:

This sentence is ungrammatical.  In addition, it isn't resources that
have three registration activities; there are three types of
registration activities, some of which involve specific resources and
some of which involve sets of resources.

   1.  Registered values associated with SCTE documents or services
   2.  Registration of values or sub-trees to other entities
   3.  Name models for use in experimental purposes

These items are not grammatically parallel; one designates an scte
URN, one designates the act of registering a set of URNs, and one
designates a "name model".

      The namespace is not listed with a resolution discovery system;
      this is not applicable for this URN registration.

It would be simpler to say "the namespace does not have a resolution
discovery system."

section 3

   The following example represents a hypothetical URL that could be
   assigned by SCTE.

Better to say "following example is a".

Should be an empty line before "urn:scte:dash:2015", or indent that

   This example defines the URN to be used for for ANSI/SCTE 214-1 2015
   "MPEG DASH for IP-Based Cable Services Part 1: MPD Constraints and

"for for" should be "for", and might be clearer as "for the standard".

Missing full stop at the end of the sentence.

section 4

   SCTE develops specifications that may 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 think "URN Namespaces" here should be "URN namespaces".

It's not clear to me how URNs assist in the activities described in
the preceding two paragraphs.  Is it possible to rewrite them to
explain how?  Does the assistance extend beyond simply providing a set
of persistent and unique names for things?