<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/rfc2629.dtd" [
<!ENTITY RFC1737 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1737.xml">
<!ENTITY RFC7749 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7749.xml">
<!ENTITY RFC4234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4234.xml">
<!ENTITY RFC3406 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3406.xml">
<!ENTITY RFC2141 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2141.xml">
<!ENTITY RFC6289 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6289.xml">

<!-- Fudge for XMLmind which doesn't have this built in -->
<!ENTITY nbsp "&#160;">
]>

<!-- Extra statement used by XSLT processors to control the output style. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Processing Instructions can be placed here but if you are editing 
     with XMLmind (and maybe other XML editors) they are better placed
     after the rfc element start tag as shown below. -->
<!-- Information about the document.
     category values: std, bcp, info, exp, and historic
     For Internet-Drafts, specify attribute "ipr".
     (ipr values are: full3667, noModification3667, noDerivatives3667),
     Also for Internet-Drafts, can specify values for
     attributes "docName" and, if relevant, "iprExtract".  Note
     that the value for iprExtract is the anchor attribute
     value of a section (such as a MIB specification) that can be 
     extracted for separate publication, and is only
     useful when the value of "ipr" is not "full3667". -->
<!-- TODO: verify which attributes are specified only
               by the RFC editor.  It appears that attributes
               "number", "obsoletes", "updates", and "seriesNo"
               are specified by the RFC editor (and not by
               the document author). -->
<rfc category="info" docName="draft-dthakore-scte-urn-00"
     ipr="trust200902" >
  <!-- Processing Instructions- PIs (for a complete list and description,
          see file http://xml.resource.org/authoring/README.html and below... -->

  <!-- Some of the more generally applicable PIs that most I-Ds might want to use -->

  <!-- Try to enforce the ID-nits conventions and DTD validity -->
  <?rfc strict="yes" ?>

  <!-- Items used when reviewing the document -->
  <?rfc comments="no" ?>

  <!-- Controls display of <cref> elements -->
  <?rfc inline="no" ?>

  <!-- When no, put comments at end in comments section,
                                 otherwise, put inline -->
  <?rfc editing="no" ?>

  <!-- When yes, insert editing marks: editing marks consist of a 
                                 string such as <29> printed in the blank line at the 
                                 beginning of each paragraph of text. -->

  <!-- Create Table of Contents (ToC) and set some options for it.  
         Note the ToC may be omitted for very short documents,but idnits insists on a ToC 
         if the document has more than 15 pages. -->
  <?rfc toc="yes"?>
  
  <!-- If "yes" eliminates blank lines before main section entries. -->
  <?rfc tocompact="yes"?>

  <!-- Sets the number of levels of sections/subsections... in ToC -->
  <?rfc tocdepth="3"?>

  <!-- Choose the options for the references. 
         Some like symbolic tags in the references (and citations) and others prefer 
         numbers. The RFC Editor always uses symbolic tags.
         The tags used are the anchor attributes of the references. -->
  <?rfc symrefs="yes"?>
  <?rfc sortrefs="yes" ?>
  <!-- If "yes", causes the references to be sorted in order of tags.
                                 This doesn't have any effect unless symrefs is "yes" also. -->

  <!-- These two save paper: Just setting compact to "yes" makes savings by not starting each 
         main section on a new page but does not omit the blank lines between list items. 
         If subcompact is also "yes" the blank lines between list items are also omitted. -->
  <?rfc compact="yes" ?>
  <?rfc subcompact="yes" ?>

  <!-- end of list of popular I-D processing instructions -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 42 characters -->
    <title abbrev="SCTE-URN">
      A Uniform Resource Name (URN) Namespace for SCTE
    </title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <author fullname="Darshak Thakore" initials="D." role="editor"
            surname="Thakore">
      <!-- abbrev not needed but can be used for the header
             if the full organization name is too long -->
      <organization abbrev="CableLabs">CableLabs</organization>
      <address>
        <postal>
          <street>858 Coal Creek Circle</street>
          <city>Louisville</city>
          <region>CO</region>
          <code>80023</code>
          <country>US</country>
        </postal>
        <email>d.thakore@cablelabs.com</email>
        <uri>http://www.cablelabs.com</uri>
      </address>
    </author>

    <author fullname="Niem Dang" initials="N." surname="Dang">
      <organization abbrev="SCTE">
        Society of Cable Telecommunications Engineers
      </organization>
      <address>
        <postal>
          <street>140 Philips Road</street>
          <city>Exton</city>
          <region>PA</region>
          <code>19341-1318</code>
          <country>US</country>
        </postal>
        <email>ndang@scte.org</email>
        <uri>http://www.scte.org</uri>
      </address>
    </author>
    
    <author fullname="Gary Hughes" initials="G." surname="Hughes">
      <organization abbrev="SeaChange">SeaChange International Inc.</organization>
      <address>
        <postal>
          <street>50 Nagog Park</street>
          <city>Acton</city>
          <region>MA</region>
          <code>01720</code>
          <country>US</country>
        </postal>
        <email>gary.hughes@schange.com</email>
        <uri>http://www.schange.com</uri>
      </address>
    </author>
    
    <date year="2016"/>
    <!-- month="March" is no longer necessary
                                           note also, day="30" is optional -->
    <!-- WARNING: If the month and year are the current ones, xml2rfc will fill in the day for 
         you. If only the year is specified, xml2rfc will fill in the current day and month 
         irrespective of the day.  This silliness should be fixed in v1.31. -->

    <!-- Meta-data Declarations -->

    <area>Applications and Real-Time</area>

    <!-- WG name at the upperleft corner of the doc,
         IETF fine for individual submissions.  You can also
         omit this element in which case in defaults to "Network Working Group" -
         a hangover from the ancient history of the IETF! -->
    <workgroup>ART Area General Applications Working Group</workgroup>

    <!-- The DTD allows multiple area and workgroup elements but only the first one has any
         effect on output.  -->

    <!-- You can add <keyword/> elements here.  They will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff output. -->
    <keyword />

    <abstract>
      <t>This document describers the Namespace Identifier (NID) 'scte' for
      Uniform Resource Names (URNs) used to identify resources published by
      the Society of Cable Telecommunications Engineers (SCTE). SCTE specifies
      and manages resources that utilize this URN identification model.
      Management activities for these and other resource types are handled by
      the SCTE.</t>
    </abstract>

    <note title="Requirements Language">
      <t>
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119"></xref>.
      </t>
    </note>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>The SCTE standards program is an ANSI-accredited forum for the development 
        of technical specifications supporting cable telecommunications. 
        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.</t>

      <t>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
      speified in this document, in full conformance with the NID registration
      process specified in <xref target="RFC3406">RFC3406</xref></t>
    </section>

    <section anchor="main" title="URN Specification for SCTE">
      <t>
        Namespace ID:
        <list>
          <t>scte</t>
        </list>
      </t>
      
      <t>
        Registration Information:
        <list>
          <t>registration version number: 1</t>
          <t>registration date: 2016-03-20</t>
        </list>
      </t>
      
      <t>
        Declared registrant of the namespace:
        <list>
          <t>
            Registering organization
            <list>
              <t>Name: Society of Cable Telecommunications Engineers</t>
              <t>Address: 140 Philips Road, Exton, PA 19341-1318, USA</t>
            </list>
          </t>
          <t>
            Designated contact
            <list>
              <t>Role: Manager, Standards</t>
              <t>Email: TBD</t>
            </list>
          </t>
        </list>
      </t>
      
      <t>
        Declaration of syntactic structure:
        <list>
          <t>
            The Namespace Specific String (NSS) of all URNs that use the
            "scte" NID will have the following structure:
            <list>
              <t>
                urn:scte:{SCTEresource}:{ResourceSpecificString}
              </t>
            </list>
            where the "SCTEresource" is a US-ASCII string that conforms to the URN syntax
            requirements of <xref target="RFC2141"></xref>.
          </t>
          
          <t>
            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.
          </t>
        </list>
      </t>
      
      <t>
        Relevant ancillary documentation:
        <list>
          <t>
            SCTE publishes information regarding the registered resources in the corresponding
            SCTE standards.
          </t>
        </list>
      </t>
      
      <t>
        Identifier uniqueness considerations:
        <list>
          <t>
            SCTE will manage resource classes using the "scte" NID and will be the authority
            for managing resources and associated subsequent strings. SCTE is expected to 
            guarantee the uniqueness of the strings themselves.
          </t>
          <t>
            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.
          </t>
        </list>
      </t>
      
      <t>
        Identifier persistence considerations:
        <list>
          <t>
            SCTE will update the SCTE Assigned Names and Numbers specification to document the 
            registered resources that use the "scte" NID.
          </t>
        </list>
      </t>
      
      <t>
        Process of identifier assignment:
        <list>
          <t>
            SCTE will provide procedures for registration of each type of resource that it maintains. Each such
            resource may have three types registration activities:
          </t>
        </list>
        <list style="numbers">
          <t>
            Registered values associated with SCTE documents or services
          </t>
          <t>
            Registration of values or sub-trees to other entities
          </t>
          <t>
            Name models for use in experimental purposes
          </t>
        </list>
      </t>
      
      <t>
        Process of identifier resolution:
        <list>
          <t>
            The namespace is not listed with a resolution discovery system; this is not applicable for this URN
            registration.
          </t>
        </list>
      </t>
      
      <t>
        Rules for lexical equivalence:
        <list>
          <t>
            No special considerations; the rules for lexical equivalence of <xref target="RFC2141"></xref> apply.
           </t>
        </list>
      </t>
      
      <t>
        Validation mechanism:
        <list>
          <t>
            None specified. URN assignment will be handled by procedures implemented in support of SCTE activities.
          </t>
        </list>
      </t>
      
      <t>
        Scope:
        <list>
          <t>
            Global
          </t>
        </list>
      </t>
    </section>
    
    <section anchor="example" title="Example">
      <t>
        The following example represents a hypothetical URL that could be assigned by SCTE.
        <vspace/>
        urn:scte:dash:2015
      </t>
      <t>
        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”
      </t>
    </section>
    
    <section title="Namespace Considerations">
      <t>
        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. 
      </t>
      
      <t>
        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.
      </t>
    </section>
    
    <section title="Community Considerations">
      <t>
        Participants involved in the development and usage of SCTE specifications and cable industry deployments
        will benefit from the publication of this namespace by providing consistent and reliable names for the XML
        namespaces, schema locations, and similar identifiers of physical data models published within SCTE 
        specifications.
      </t>
      <t>
        The SCTE specifications are publicly available and are licensed to manufacturers on a nondiscriminatory basis.
        SCTE will maintain the corresponding specifications where the registered resources are referenced or used.
      </t>
    </section>


    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
      <t>This document adds a new entry ("scte") in the urn-namespaces
      registry. This is the defining document for the entry. The entry can be
      found in the <xref target="IANA-URN">Uniform Resource Names
      (URN) Namespaces</xref> Registry.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>There are no additional security considerations other than those
      normally associated with the use and resolution of URNs in general,
      which are described in <xref target="RFC1737"/>, <xref
      target="RFC2141"/>, <xref target="RFC3406"/></t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors acknowledge that the text from <xref target="RFC6289"/>
      formed the basis for the initial version of this document.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split to informative and normative -->

    <references title="Normative References">
      <!-- A *really* full, totally OTT reference - Note, the "target" attribute of the 
	     "reference": if you want a URI printed in the reference, this is where it goes. -->

      <reference anchor="RFC2119"
                 target="http://xml.resource.org/public/rfc/html/rfc2119.html">
        <front>
          <title abbrev="RFC Key Words">
            Key words for use in RFCs to Indicate Requirement Levels
          </title>
          <author fullname="Scott Bradner" initials="S." surname="Bradner">
            <organization>Harvard University</organization>
            <address>
              <postal>
                <street>1350 Mass. Ave.</street>
                <city>Cambridge</city>
                <region>MA</region>
                <code>02138</code>
              </postal>
              <phone>- +1 617 495 3864</phone>
              <email>sob@harvard.edu</email>
            </address>
          </author>
          <date month="March" year="1997"/>
          <area>General</area>
          <keyword>keyword</keyword>
          <abstract>
            <t>In many standards track documents several words are used to
            signify the requirements in the specification. These words are
            often capitalized. This document defines these words as they
            should be interpreted in IETF documents. Authors who follow these
            guidelines should incorporate this phrase near the beginning of
            their document: <list>
                <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
                "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
                "OPTIONAL" in this document are to be interpreted as described
                in RFC 2119.</t>
              </list></t>

            <t>Note that the force of these words is modified by the
            requirement level of the document in which they are used.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <format octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt"
                type="TXT"/>
        <format octets="14486"
                target="http://xml.resource.org/public/rfc/html/rfc2119.html"
                type="HTML"/>
        <format octets="5661"
                target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"
                type="XML"/>
      </reference>
      
      &RFC7749;

      <!-- A reference written by by an organization not a person. -->

      <reference anchor="IANA-URN"
                 target="http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml">
        <front>
          <title abbrev="iana-urn-registry">
            Uniform Resource Names (URN) Namespaces
          </title>
          <author>
            <organization>IANA</organization>
          </author>
          <date/>
        </front>
        <format target="http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml"
                type="HTML"/>
      </reference>

      <!-- Right back at the beginning we defined an entity which (we asserted) would contain
             XML needed for a reference... this is where we use it. -->

      &RFC3406;
      &RFC2141;
    </references>

    <references title="Informative References">
      &RFC4234;
      &RFC6289;
      &RFC1737;
      
      <reference anchor="SANN">
        <front>
          <title abbrev="scte-name-registry">
            SCTE Assigned Name and Number Registry
          </title>
          <author>
            <organization>Society of Cable Telecommunications Engineers</organization>
          </author>
          <date/>
        </front>
      </reference>
      
    </references>
    
  </back>
</rfc>
