Comments on draft-dthakore-scte-urn-00.txt

[[e-mail] (Dale R. Worley)]

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:

         urn:scte:{SCTEresource}:{ResourceSpecificString}

      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.
   urn:scte:dash:2015

Better to say "following example is a".

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

   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
   Extensions"

"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?

Dale