Re: [urn] URN registration request for SCTE

lars.svensson@web.de Wed, 28 August 2019 07:37 UTC

Return-Path: <lars.svensson@web.de>
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 9499E1200C7 for <urn@ietfa.amsl.com>; Wed, 28 Aug 2019 00:37:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=web.de
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 V8A8YJW5-_ej for <urn@ietfa.amsl.com>; Wed, 28 Aug 2019 00:37:15 -0700 (PDT)
Received: from mout.web.de (mout.web.de [212.227.15.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42FA91200C4 for <urn@ietf.org>; Wed, 28 Aug 2019 00:37:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1566977821; bh=ILjubRxP9DEXoZXybdXmjVdPjoxzOMrPykfuQat7lQU=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=qRrnoubn+2v7m/NP+7QiRjpHJ674CqItiXCVtK+iTxHhnYIEG6X1qR73TrPU6kcyp 6/nB9yBnDEO1ipjJyzlk32vgXFDHCoxdoheumxhbShwnGTfr9agML7k5x6JLQjh+ZA 8fh/VlyCEFUjzQPvBaoggGPrIcCZZQRlTSLIu5iI=
X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9
Received: from [77.87.224.101] ([77.87.224.101]) by web-mail.web.de (3c-app-webde-bs44.server.lan [172.19.170.44]) (via HTTP); Wed, 28 Aug 2019 09:37:01 +0200
MIME-Version: 1.0
Message-ID: <trinity-f54437a5-b01a-4d73-af23-d6907bca9b7c-1566977821292@3c-app-webde-bs44>
From: lars.svensson@web.de
To: "Gary Hughes" <ghughes1138@gmail.com>
Cc: "Dean Stoneback" <dstoneback@scte.org>, urn@ietf.org, "Paul Woidke" <paul.woidke@icloud.com>
Content-Type: text/html; charset=UTF-8
Date: Wed, 28 Aug 2019 09:37:01 +0200
Importance: normal
Sensitivity: Normal
In-Reply-To: <CAMDWyDKUUmoB=JBu-3aCztc_iSOsfHumkJwb5hv-AJwN+6+OgQ@mail.gmail.com>
References: <CAMDWyD+nMDEf8+YdNW6i5rGzRUC4Pur1rj6ghm4pbugLsXJqrA@mail.gmail.com> <87h86ayo55.fsf@hobgoblin.ariadne.com> <trinity-7c3bbfe7-673a-4a7a-b2cc-daf46d7b7c6c-1566556252199@3c-app-webde-bap48> <CAMDWyDJeFGuKS9sS2D4Tqz1dTgpnEC2jibCmkZX6_jA57Y7aXw@mail.gmail.com> <CAMDWyDKUUmoB=JBu-3aCztc_iSOsfHumkJwb5hv-AJwN+6+OgQ@mail.gmail.com>
X-UI-Message-Type: mail
X-Priority: 3
X-Provags-ID: V03:K1:0TSMiaAdmAB9wn1WFoTKsnaYPqQKXcPKiiYj7o7VfjYkO2Vew3X/FbQYs+hu9BZdujM05 8T5+dUL/ky6OyRdsth5cFbDOuKSNG6hTRlSB6fMpDNoGn6I4JmRfcRYmsJxOVuMyl0kb8arqX8Nu ZK2FIW28PBqGKMd3kq7QQZKliVrkotNd4gi+3fA7LutytBIoVEISDy+KqvvEo3pXUBX2FJfJGBcJ t+wmkiQtJi/aWrB4mwTvTf/zMzX8+P7oXtjQ2tfrk2+/xLuIPM8iRwC1/MhegX8Z6gN18RDlbGkZ Rk=
X-UI-Out-Filterresults: notjunk:1;V03:K0:lNCd/XHTU8o=:uudcHU6yOovN+EscXi3zsD kwbjBV0/Om5VubFjxy2HTHN8cf+lYOcvcBmEjAEX80peCQKpNFEHeWm2vfijHU8eN8VkbWTyz 5prArvZY4plyvdKQt+F2OuuZ7KnDeYIKzoBWd8bUKUjSeE3bz3NgKp7sZekHwTruQfyWNN9vP +jouV7h2aXMo8POCbono5zHPXJJxQCt2iywl9egJeWxbPa9JSDGcIQMGoAba3zcyctcVhwg9D gfBMyijQg8EGqSEFIE6yVP0UlPLP5CbXoZnwXEiSuk/1jTwDMlPdyq/vE8RLSaH3mjDRbakXX 12kPLSp1+Wryiynx9CZlTQjY5trsjWdyjfp4fDNhjbFGfir8zo6RfJ2r/Z9F4uW8zqHptY8yP QBlkwLQYGMj/zrtOt/KWD9um7roHns6x5sPM6uMH+2kWhiyTgsHsE9TecDz9V0gzQJgg8u5Vy CUSGQu9V7/tuCd8XPmdciB3f7ut+h7N+tx+XPSJa4kCuD37IDqJRgNRdYLePilt6xFBvfj4Cg +MSBHfqNvHX4O/di8SrZNWmABqArs54lub31eZ6JLlLDYp8K7VIOmGOHcJmkLuGt9fe7p6yEp iLZVK+Duo6rSw10aFgWZK+xgv6a009OpqTAMb9Xjm7Yqlx2KhvTXveN9pyWq/3nOwCrSplc8W IWWv/lefMfJeYQ9VNpFmxJhJ3lsabT+u4mK0KHrQoz7apAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/_fpPMst4cko3d-24AFcnUmKcbYY>
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: Wed, 28 Aug 2019 07:37:19 -0000

Gary,
 
My comment has been addressed and I have no further comments.
 
Best,
 
Lars
 
Gesendet: Dienstag, 27. August 2019 um 21:52 Uhr
Von: "Gary Hughes" <ghughes1138@gmail.com>
An: lars.svensson@web.de
Cc: "Dean Stoneback" <dstoneback@scte.org>rg>, urn@ietf.org, "Paul Woidke" <paul.woidke@icloud.com>
Betreff: Re: [urn] URN registration request for SCTE
Below is a revised version of the SCTE URN request form, hopefully incorporating all of the comments and feedback.
 
regards,
 
gary
 
===============================================================================
IETF URN Registration for SCTE

Namespace Identifier:
scte

Version:
2

Date:
2019-08-27

Registrant:
The Society of Cable Telecommunications Engineers (SCTE) standards program is an ANSI-accredited Standards Development Organization 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.

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

Designated contact:
 Role: Manager, Standards
 Email: standards@scte.org

Purpose:
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 full conformance with the NID registration process specified in RFC8141 [RFC8141].

When SCTE specifications require the use of data models, a registered URN Namespace which can be sub-divided according to our requirements is a key construct 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 identifiers and dependencies between identifiers across different versions of SCTE specifications if they so wish.

Specific URNs assigned in the ‘scte’ namespace are documented in the defining SCTE standards..

Syntax:

Identifiers assigned in the ‘scte’ namespace will have the format
Identifier = “urn” “:” “scte” “:” NSS

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

       {SCTEresource}:{ResourceSpecificString}

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

The grammar for SCTEresource and ResourceSpecificString is as follows:

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

       ResourceSpecificString = *( pchar / "/" )

This precludes the use of “:” in “SCTEresource”.

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 resource name and optionally the edition (year) of the standard that first defined the URN.

For example:
urn:scte:224:audience
Identifier of an XML namespace for audience-related metadata, defined in ANSI/SCTE 224.
 
urn:scte:dash:essential-event:2015
Identifier used in an MPEG DASH EssentialProperty element to indicate that a specified event stream is essential to the media presentation, first defined in the 2015 edition of the SCTE DASH specifications
 
urn:scte:scte35:2013:xml
Identifier used in an MPEG DASH EventStream element to indicate that the event message payloads are XML representations of SCTE 35 commands, as first defined in the 2013 edition of ANSI/SCTE 35

Published SCTE standards are freely downloadable from the SCTE web site at: https://www.scte.org/SCTE/Standards/Download_SCTE_Standards.aspx" target="_blank" rel="nofollow">https://www.scte.org/SCTE/Standards/Download_SCTE_Standards.aspx.

Assignment:
All URNs that use the ‘scte’ NID are defined in SCTE standards.

SCTE will maintain a naming authority, the SCTE Assigned Names and Numbers [SANN] specification, that will document the assignment of SCTE resource classes and the specific registration values assigned for each resource class along with references to the defining specification(s).  The SANN  specification will be published on the SCTE Standards Program website (https://www.scte.org/SCTE/Standards/SCTE_Assigned_Names_and_Numbers_specification.aspx" target="_blank" rel="nofollow">https://www.scte.org/SCTE/Standards/SCTE_Assigned_Names_and_Numbers_specification.aspx).

The SANN specification will be updated as needed after the defining specification(s) have been balloted and approved.

Security and Privacy:
There are no additional security considerations other than those normally associated with the use and resolution of URNs in general, which are described in [RFC8141].

Interoperability:
SCTE standards are referenced by other SDOs and industry groups. Formally registering the “scte” NID will help ensure that collisions do not occur.

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

Documentation:
The SCTE Assigned Names and Numbers [SANN] specification will describe the use of ‘scte’ namespace and assigned identifiers in the ‘scte’ namespace and the defining SCTE standard. This will be available at https://www.scte.org/SCTE/Standards/SCTE_Assigned_Names_and_Numbers_specification.aspx" target="_blank" rel="nofollow">https://www.scte.org/SCTE/Standards/SCTE_Assigned_Names_and_Numbers_specification.aspx

Details of URNs assigned in the ‘scte’ namespace are documented in the defining SCTE standards.

Additional Information:
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.
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.

Revision Information:
v2: revised to incorporate feedback
v1: This application is a revision and resubmission of draft-dthakore-scte-urn-00
 
On Mon, Aug 26, 2019 at 12:52 PM Gary Hughes <ghughes1138@gmail.com> wrote:
Dale, Juha, Lars,
 
thank you for the feedback and suggestions. I will shortly post a revised version incorporating those changes.
 
Regarding the examples, my intent was to show examples of syntax, but I will try to add some context without
going too far into the weeds.
 
Regarding "Is this meant to imply that SCTE URNs can only be assigned via SCTE
standards"
 
Yes. This ensures that URN assignments are subject to the same review and voting process as the standard. I
will clarify that.
 
regards,
 
gary
 
On Fri, Aug 23, 2019 at 6:30 AM <lars.svensson@web.de> wrote:
From me just a minor comment on Dale's comment:

On Donnerstag, 22. August 2019 um 03:39 Uhr "Dale R. Worley" <worley@ariadne.com> scripsit:

>     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.

I read this not so much as "different versions of identifiers" but as "different versions of specifications [identified by identifiers/URNs]", so clarification really seems needed here.

Apart from that I agree with Dale's and Juha's comments.

Best,

Lars
_______________________________________________ urn mailing list urn@ietf.org https://www.ietf.org/mailman/listinfo/urn" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/urn