From ghughes1138@gmail.com Tue Aug 20 09:17:43 2019 Return-Path: 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 1BB90120105 for ; Tue, 20 Aug 2019 09:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ez8jKn4R6HOs for ; Tue, 20 Aug 2019 09:17:40 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 C92B012082C for ; Tue, 20 Aug 2019 09:17:39 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id p28so6961300edi.3 for ; Tue, 20 Aug 2019 09:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=XoxZIFQ7nkFJ82dCFM2XQZVRyYM3C49C7XWstec0gSI=; b=bftAIbqPPu+79G888NQnzVIj4hhmcyD2fGwwrp5UDPKF5OCWnaN1RJwgtrbAz3d15+ 3RBR95JZoX5E5Joaq6FPB/pMhfTCCZeYjBdahh9Z6Sea1Bol/Rc8zoMTwMeyaPGuQWS9 bLXezuUrEizPYbSjjXvVnnSuY9yzrBHp4H2lrrKK56Xl8UmaLvaIUFaITKybOHeNoKAp ysPKM2nuNgIhQU0hffHwM13XCnCwiXpKhXBJFjGaV4kuMes01qNarHNoS2F5hmhDEV3b 0lVpDUt0dTNKqdp8IN1xh3ogTvWSnfTj4L/yKlyc7gdhUYo2JTeeK425y/pxYLy9zdwF Y2zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=XoxZIFQ7nkFJ82dCFM2XQZVRyYM3C49C7XWstec0gSI=; b=U6/80dg6eyGSI2IHoPM6N+HGsTV8PUKadE5IcLtMzB5aePenaCvwIK/r2TzmzJ42jA 5LX1MsYPZf9h4cNKz36Eoh1r7ljwpp46f0clNwsNrw8D/3JO0Edn0mA2C7I4X0BOCFga nLaXHuPVO2Y/ydhjKg7jq7vUFxoNzXAtBYN6cMXLDogOrfC77DS/00Lfy8hoB2cVqoAi svYMREVZJDOIFGV2lKZIRSlHLvueJPKq2JkJQcHCp2DbgKFaewIcv2tejvo2Hx7u+z5g 5yyQlmiC5hPc29HKOyMybRvoGpSDf7IgALUNM34M7/bZynARub19abT4j9X0SXcY7shI pqeg== X-Gm-Message-State: APjAAAWu6u1ZMKbiyLge6DcfVTbBUD1JjnKjPHiexjlvYtD5My4rH3Tu 1jvJlIqa43pyUntSZfIkQ16WcvVPS6ffmZ5aXH0AbZirJ18= X-Google-Smtp-Source: APXvYqw8MA2dS84XT5H/gHGtEqjSb+VfUdZjhMQSponazkuZeSTCD1IDEEAxWOrSudbiiPfwD1Y8ah7mmiCOpY82ySs= X-Received: by 2002:a50:b875:: with SMTP id k50mr31990168ede.232.1566317857652; Tue, 20 Aug 2019 09:17:37 -0700 (PDT) MIME-Version: 1.0 From: Gary Hughes Date: Tue, 20 Aug 2019 12:17:26 -0400 Message-ID: To: urn@ietf.org Cc: Paul Woidke , Dean Stoneback Content-Type: multipart/alternative; boundary="00000000000082c2a105908ecb36" Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 16:26:42 -0000 --00000000000082c2a105908ecb36 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The Society of Cable Telecommunications Engineers (SCTE), an ANSI-accredited SDO, is requesting fast track registration for the 'scte' namespace identifier. The completed template follows. regards, Gary Hughes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D IETF URN Registration for SCTE *Namespace Identifier*: scte *Version*: 1 *Date*:*.* 2019-08-19 *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 RFC8141, in full conformance with the NID registration process specified in RFC8141 [RFC8141] 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. *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]. SCTE publishes information regarding the registered resources in the corresponding SCTE standards. The =E2=80=9CSCTEresource=E2=80=9D may be use= d to identify the SCTE standard or the project which defined the URN. The =E2=80=9CResourceSpecificString=E2=80=9D specifies the name and optionally = the edition (year) of the standard that first defined the URN. For example: urn:scte:dash:essential-event:2015 Event essentiality, first defined in the 2015 edition of the SCTE DASH specifications urn:scte:scte35:2013:xml XML representation of SCTE 35 commands, 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. *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_specifi= cation.aspx) and updated as needed. The SANN specification will only document URNs defined in SCTE standards. *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 =E2=80=9Cscte=E2=80=9D 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 =E2=80=9Cscte=E2=80=9D namespace and procedures for requesting assig= nment of new resources and values in that namespace. This will be available at https://www.scte.org/SCTE/Standards/SCTE_Assigned_Names_and_Numbers_specifi= cation.aspx *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*: This application is a revision and resubmission of draft-dthakore-scte-urn-00 --00000000000082c2a105908ecb36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The Society of Cable Telecommunications Engineers (SCTE), an= ANSI-accredited SDO,=C2=A0is requesting fast track registration for= the 'scte' namespace identifier. The completed template follows.


regards,


Gary Hughes


=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

IETF URN Registration for SCTE

=C2=A0

Namespace Identifier:

scte

=C2=A0

Version:

1

Date:.

2019-08-19

=C2=A0

Registrant:

=C2=A0

The Society of Cable Telecommunication= s Engineers (SCTE) standards program is an ANSI-accredited Standards Development Organization = for the development of technical specifications supporting cable telecommunicat= ions.=C2=A0 SCTE standards work includes: data and telephony over cable; application platform development; digital video; emergency aler= t systems; network monitoring systems; cables, connectors and amplifiers; construction and maintenance practices;=C2=A0 energy management, and more.

=C2=A0

Name:

Society of Cable Telecommunications En= gineers

140 Philips Road, Exton, PA 19341-1318= , USA

=C2=A0

Designated contact:

=C2=A0Role: Manager, Standards

=C2=A0Email: standards@scte.org

=C2=A0

Purpose:.

Occasionally, SCTE specification effor= ts require identifiers in a managed namespace so that they are unique and persistent.= =C2=A0 To ensure that the uniqueness is absolute, the registration of a specific Uniform Resource Name (URN) Namespace Identi= fier (NID) for use by SCTE is being specified in RFC8141, in full conformance wi= th the NID registration process specified in RFC8141 [RFC8141]

=C2=A0

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

=C2=A0

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

=C2=A0

Syntax:

=C2=A0

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

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 urn:scte:{SCTEresource}:{ResourceSpecificString}

=C2=A0

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

=C2=A0

SCTE publishes information regarding t= he registered resources in the corresponding SCTE standards. The =E2=80=9CSCTEresource=E2= =80=9D may be used to identify the SCTE standard or the project which defined the URN. The =E2= =80=9CResourceSpecificString=E2=80=9D specifies the name and optionally the edition (year) of the standard that f= irst defined the URN.

=C2=A0

For example:

urn:scte:dash:essential-event:20= 15

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

=C2=A0

urn:scte:scte35:2013:xml

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

=C2=A0

Published SCTE standards are freely do= wnloadable from the SCTE web site at: https://www.scte.org/SCTE/Standard= s/Download_SCTE_Standards.aspx.

=C2=A0

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 eac= h resource class.=C2=A0 This specification will be published on the SCTE Standards Program website (https://www.scte.org/SCTE/Standards/SCTE_Assigned_Nam= es_and_Numbers_specification.aspx) and updated as needed.

=C2=A0

The SANN specification will only docum= ent URNs defined in SCTE standards.

=C2=A0

Security and Privacy:

There are no additional security co= nsiderations other than those normally associated with the use and resolution of URNs in general, w= hich are described in [RFC8141].

Interoperability:

SCTE standards are referenced by ot= her SDOs and industry groups. Formally registering the =E2=80=9Cscte=E2=80=9D NID will help ensur= e 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:

=C2=A0

The SCTE Assigned Names and Numbers [S= ANN] specification will describe the use of =E2=80=9Cscte=E2=80=9D namespace and procedures fo= r requesting assignment of new resources and values in that namespace. This will be available at https://www.scte.= org/SCTE/Standards/SCTE_Assigned_Names_and_Numbers_specification.aspx

=C2=A0

Additional Information:

Participants involved in the develo= pment and usage of SCTE specifications and cable industry deployments will benefit from the publica= tion of this namespace by providing consistent and reliable=C2=A0=C2=A0 names fo= r the XML namespaces, schema locations, and similar identifiers of physical data models published within SCTE specifications.

The SCTE specifications are publicl= y available and are licensed to manufacturers on a nondiscriminatory basis.=C2=A0 SCTE will mai= ntain the corresponding specifications where the registered resources are referenced or used.

Revision Information:

This application is a revision and = resubmission of draft-dthakore-scte-urn-00

--00000000000082c2a105908ecb36-- From nobody Wed Aug 21 18:39:26 2019 Return-Path: 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 ; 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 ; 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 ; 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 (Dale R. Worley) To: Gary Hughes Cc: urn@ietf.org, dstoneback@scte.org, paul.woidke@icloud.com In-Reply-To: (ghughes1138@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 21 Aug 2019 21:39:18 -0400 Message-ID: <87h86ayo55.fsf@hobgoblin.ariadne.com> Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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] From nobody Thu Aug 22 03:27:25 2019 Return-Path: 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 E6C0B120288 for ; Thu, 22 Aug 2019 03:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=helsinkifi.onmicrosoft.com 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 LNIkK06duu2F for ; Thu, 22 Aug 2019 03:27:19 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10098.outbound.protection.outlook.com [40.107.1.98]) (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 844211200B2 for ; Thu, 22 Aug 2019 03:27:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l5kx0/YH94iVBuQhL/J5QJTwKkhpftBVmoIV/5XaqE9vP8OsKp1l2mpAMBlQL4P0ZM2RkvnLGz0nrXuV+MGTqwqs0rFE9vmaPnOkxIAPlHYtiuJfoPIq/KAVzWBglRqiT4Nc8eVewQpMASWKG4aA0/awjqiTaE+bxerl0vikW56MkvSiyQWxu/NsXYISa7g0tveNkEyuZVBEcUGX1KqYpyp28xd54bN2H4/YMfXCpvoapZAwxcT44EOAfUANyVGEuM2VMw0PAGX1gLmv6vAS6CuFdid2ObBRMhowEhXLcUuvv7LwolJUUUAyfpbkSga566pCGz8R4gLBUKNqzr4tPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yhDmgzgyhsoiT7EQ/Owpwr13if8idBnia81lo3Zf7sM=; b=FXAyAxZ13I2Vhepre2etQyukfPa24GHBc/19EB72aZTMy3SAhnrttH5h6+mmijXI00SlPeyezhDGwBIwmVkY8hjoMUscZn8spKXVps1t2ysprkvp2jgNofGrmOUd/LcOP2osDUakRGmQER+4+n7Fok1Xa8kEm4ety/dCvOHALbo3XWloEwJYYRi4Td+wibeB1LWBPxpvP1w8aBN/R6Lu68Fxtqe25KxvEAHJIeoRIJSkR1ofqwqp1nlLAsYniBhmGv4c9o4zOfF8M4hPqsw3LnnsnAWwBmnf09qXIcxD6P8oEPpyvybTZx7rZLMAymeWDs0dDrFD0YPp/FZuE8rCgg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=helsinki.fi; dmarc=pass action=none header.from=helsinki.fi; dkim=pass header.d=helsinki.fi; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector2-HelsinkiFI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yhDmgzgyhsoiT7EQ/Owpwr13if8idBnia81lo3Zf7sM=; b=ah/j/2ILQ/bi94JtPCt+0VMcgVkrux02ek+DIEyZtDbEyhPyKwsWwUhKaN8WcnK1Q3w44haqVxByTkEDXeHothNCLMJoskOzWCY2UhEhby3fg2ONzWU0OkWtjkK698WytF34H6fWmgIg3DZC1anmALZ68AibokHxfEM2Dt8vUdI= Received: from HE1PR07MB3097.eurprd07.prod.outlook.com (10.170.244.159) by HE1PR07MB4153.eurprd07.prod.outlook.com (20.176.166.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.10; Thu, 22 Aug 2019 10:27:14 +0000 Received: from HE1PR07MB3097.eurprd07.prod.outlook.com ([fe80::1d31:5725:d8f3:af8f]) by HE1PR07MB3097.eurprd07.prod.outlook.com ([fe80::1d31:5725:d8f3:af8f%6]) with mapi id 15.20.2199.011; Thu, 22 Aug 2019 10:27:14 +0000 From: "Hakala, Juha E" To: "Dale R. Worley" , Gary Hughes CC: "dstoneback@scte.org" , "urn@ietf.org" , "paul.woidke@icloud.com" Thread-Topic: [urn] URN registration request for SCTE Thread-Index: AQHVWIp5kfl3cE1GZEKt5C2MrgKYJKcG9Xeg Date: Thu, 22 Aug 2019 10:27:14 +0000 Message-ID: References: (ghughes1138@gmail.com) <87h86ayo55.fsf@hobgoblin.ariadne.com> In-Reply-To: <87h86ayo55.fsf@hobgoblin.ariadne.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-originating-ip: [128.214.147.95] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 25641984-493b-4576-cd44-08d726eb4d15 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB4153; x-ms-traffictypediagnostic: HE1PR07MB4153: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01371B902F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(376002)(366004)(136003)(396003)(346002)(189003)(13464003)(199004)(446003)(7696005)(11346002)(476003)(53936002)(76176011)(25786009)(71190400001)(71200400001)(229853002)(66556008)(86362001)(256004)(305945005)(9686003)(7736002)(64756008)(66446008)(66476007)(55016002)(14444005)(6306002)(6436002)(66066001)(478600001)(786003)(966005)(316002)(52536014)(8676002)(486006)(14454004)(3846002)(6116002)(2906002)(76116006)(66946007)(4326008)(8936002)(54906003)(110136005)(6246003)(99286004)(81166006)(26005)(6506007)(33656002)(81156014)(74316002)(186003)(102836004)(5660300002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB4153; H:HE1PR07MB3097.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: B1cvQllEPkVKvVz0A94DbLHjp8N6QDPiv4pX6B/4vPDXEe0QsUUWkp/CrS/5y3lLVnRUz7U3c5a2Y6+hWQNgioxR2eAAAzCXeNkVY/AOsxmOpu08yVFioawym9lxnNxiGNms7C1bnHhKQnpuSWbsVQiVJ1G4KFuBUjVUoICD1ghVRk6ra9qydX/DIYnrP4SDoBF91h+WniYqrAAAjCV8h/o2XfSp4AJPRdCFFZagNdnTAZFMHhy8ceRK7RzurSnx96qoqWdOK/loD1kyhg04Ysgsg2FeClHLQ/QgKcXO9AoGWEJR95TdpD50fzf0YNH5AvKbF0fErKmG5Wgbj6w2/YSzh4sX+WOnhRepWWpUTsVu0Ic4bwRtXhzRvDIC6c47vRd/fWXMPQoZQ66HMxHMZvfpDhyq9rUg/kF9W1ZhGHg= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-Network-Message-Id: 25641984-493b-4576-cd44-08d726eb4d15 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2019 10:27:14.6770 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5GNFqDEgENRQIlnly/PWJjrjKlSlE/TlJzWkN8C1joFtyWZFBBRqwP48eaKQEeVDzKSFtomt1+P/KBiCP9TGKg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4153 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 10:27:23 -0000 Hello,=20 I have only one additional comment to what Dale has already said.=20 "When SCTE specifications require the use of data models, URN Namespaces ar= e key constructs to manage the definitions of those data models reliably wi= th persistence and uniqueness." You are registering (and you will only ever need) a single URN Namespace wh= ich can be sub-divided further according to SCTE requirements. So you could= say something like=20 "When SCTE specifications require the use of data models, a registered URN = Namespace which can sub-divided according to our requirements is a key cons= truct to manage the definitions of those data models reliably with persiste= nce and uniqueness." Best regards,=20 Juha -----Original Message----- From: urn On Behalf Of Dale R. Worley Sent: torstai 22. elokuuta 2019 4.39 To: Gary Hughes Cc: dstoneback@scte.org; urn@ietf.org; paul.woidke@icloud.com Subject: Re: [urn] URN registration request for SCTE 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 manag= ed 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 specifie= d in RFC8141, in full conformance with the NID registration process specifie= d in RFC8141 [RFC8141] There are some extra words in that last sentence. I think you can omit "RF= C8141, 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 differe= nt versions of SCTE specifications if they so wish. I'm not sure, but I think you want to replace "different versions of URNs a= nd dependencies between URNs" with "different versions of identifiers and d= ependencies 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 *identifi= ers* 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. (T= he definition of NSS is in RFC 8141, but it's not particularly well pointed= out. The critical parts are: assigned-name =3D "urn" ":" NID ":" NSS ["assigned-name" is roughtly the same as "URN" as used here] NID =3D (alphanum) 0*30(ldh) (alphanum) ldh =3D alphanum / "-" NSS =3D 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 SCTEre= source and ResourceSpecificString. And if that restriction is true, it wou= ld be helpful to state it here. It would be particularly helpful to give a specific grammar for SCTEresourc= e and ResourceSpecificString. In SCTE's case, I think this is what you wan= t: SCTEresource =3D ( unreserved / pct-encoded / sub-delims / "@" ) *( unreserved / pct-encoded / sub-delims / "@" / "/" ) ResourceSpecificString =3D *( pchar / "/" ) -- SCTE publishes information regarding the registered resources in the corresponding SCTE standards. The "SCTEresource" may be used to identif= y 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* v= ersion.) 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 desc= ribed here? If so, it would help to say "A URN which designates the proper= ty 'event essentiality' of XYZs ...". urn:scte:scte35:2013:xml XML representation of SCTE 35 commands, first defined in the 2013 editi= on 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 Numb= ers [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 Prog= ram website ( https://www.scte.org/SCTE/Standards/SCTE_Assigned_Names_and_Numbers_spe= cification.aspx) and updated as needed. The SANN specification will only document URNs defined in SCTE standard= s. Is this meant to imply that SCTE URNs can only be assigned via SCTE standar= ds -- or can they also be assigned in other ways, but only the ones assigne= d in standards will be documented at https://www.scte.org/SCTE/Standards/SC= TE_Assigned_Names_and_Numbers_specification.aspx? This needs to be clarified both here and in the Purpose and Documentation s= ections. And if the latter is intended, you need to clarify how assignment= of URNs not defined in standards is managed. [END] _______________________________________________ urn mailing list urn@ietf.org https://www.ietf.org/mailman/listinfo/urn From nobody Fri Aug 23 03:44:08 2019 Return-Path: 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 6AC0C12080E for ; Fri, 23 Aug 2019 03:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, 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 EtVxdwxnSNJk for ; Fri, 23 Aug 2019 03:44:04 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.12]) (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 59CA9120810 for ; Fri, 23 Aug 2019 03:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1566557041; bh=Uox1UWXAc2VL8D4Nk2Ej0qmUmEhNSdvcnp6kl+syfQ0=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=TbEIMFizgp6BYvaZm6SBXhbaFdpZHUx3+HYgxhhtJ53r1hBPVhjTHebHTiMsyWvN6 lppxndGlgVSZ+eMcvrUvBPiPeY4f8dY7xg035bBgs8ylHT9ezq8J+iFP4bM0tU35xb T+GW+1oYTAxzfqRPOnlRowu6YwgrOQCeo07sKAW8= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from [77.87.224.104] ([77.87.224.104]) by web-mail.web.de (3c-app-webde-bap48.server.lan [172.19.172.48]) (via HTTP); Fri, 23 Aug 2019 12:30:52 +0200 MIME-Version: 1.0 Message-ID: From: lars.svensson@web.de To: urn@ietf.org Cc: "Gary Hughes" , dstoneback@scte.org, paul.woidke@icloud.com Content-Type: text/plain; charset=UTF-8 Date: Fri, 23 Aug 2019 12:30:52 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <87h86ayo55.fsf@hobgoblin.ariadne.com> References: <87h86ayo55.fsf@hobgoblin.ariadne.com> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:QMuqmnrqSLDUOZ7GDx5jSymTUmQLeNIvQFGlHKTP5IvMlIysmsoR4mQaCeU6o9xTBOqFJ VV7CSUyifz0O+wYA5ph2DBE3cCGqNCFnMq8/TmumC2o0f8BAcTpMg3X9o8nVfOxXuaJz4nzW2BTs +rEZrOx92CPl0QdtsTek34PDrZtBU1vyjxql6EvJPMsqg2DlWjJ5g9Iw3O+rJzfytUqadIMpKygl h8Z3EFVR7jeaiR+Jid9DEPFSiXSzVVOIrSzyLKdD+vXh+FNIlkrJE8ku6JdLT90Yy5f144ux6Mi+ Pk= X-UI-Out-Filterresults: notjunk:1;V03:K0:neKqe0nQXus=:PSHqqVa0QAbR3BxubboURJ OuFTO+YZJxxokPBg5C5jUttZfB0CKYhak2LuOoUGFh5+pK+4G2xS+WPqjmi260cxRGDzNWriY YYeTwgZyeJfBugkzkT1pjkTMAt3Af5cjSDrfLD5iAk4/k4m3kMF8hyXPHnA+AlGJVMvDzq2ho TbymGZ0nujyEWsSNb4Dxp2lu3mdiUAzZiibnd8wxyLPjrGWxQa0u+cNijBSyC8zf90fpIMm29 QPGd/9EsgKu6A7UgjGEZBuRcAbNp0DT5OXJfC7RTxwWgjM7jKaPb6EMY4+35lffMpMWgfx0Bc KJbrxzS84kkUMc1MueiHC79tu41L/s4GcPmBBiI5fHO5/SrK6oEKii3subFBRR68BcRHSH9Tc XiNlAtDV9owMaMEYpZyHzTnugaxWDyhCbuUrghUKPO/kKO6L3MgWG82zFxcTTRv5cZEQyetgT XJ0FPhFsiqOxyqcPEI0PuKRVNoTkSzwhBrQBauQFeVB61PBxR8/Ln50vQhzIxbgoW13iLPbWG ccsipbPByknbtBtTFROlnVoZp0BedcgZg7RScOCZzLQgGIfE5CHiimjDYQG7RN746R/3veDtD MEqYY1kXmQQrmXNPLuSeEh0l+hBm2c+yQ4Jl6O9P6JETs/HtdslzU75J6KwjPKOj3XVoFfVwd 6uoz8vqZc1/xCjZReUkAcaLTlrABweXDn77B7Ql7PzrZAGg== Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 10:44:07 -0000 =46rom me just a minor comment on Dale's comment: On Donnerstag, 22. August 2019 um 03:39 Uhr "Dale R. Worley" scripsit: > The use of URNs should also help specification authors to maintain > different versions of URNs and dependencies between URNs across diff= erent > 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 "dif= ferent versions of specifications [identified by identifiers/URNs]", so cl= arification really seems needed here. Apart from that I agree with Dale's and Juha's comments. Best, Lars From nobody Mon Aug 26 09:52:59 2019 Return-Path: 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 E3AC1120A84 for ; Mon, 26 Aug 2019 09:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 C4___Zo0twMb for ; Mon, 26 Aug 2019 09:52:55 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 30E1C120A7A for ; Mon, 26 Aug 2019 09:52:55 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id w5so27373708edl.8 for ; Mon, 26 Aug 2019 09:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UWRPxRN7hFsty1XnrYVF7NX4trKwM49CdheWqn3z1M0=; b=jVazLwW4SLmRvnBWxfF7S8xs7P7KOneBge0KzcxyPp4rkOZYvl1qHm1auaqcY8Iro0 s4jgQrOOYw0C3q2TMhzEA5TQsUx+zHRkoy8AOaunH028axFQii9A16y1zpRnAtCwfQZT +ejoMVAPUAxJ2EB1Fk8zYZ7OX8xKVWSaOMa490qJmS6OwIvMvbpJGBOiNu7EYe58jMb6 Igtz51edtRYaDQLwFrBuzqLc4MscPcOfV25SYBOIc45fzL8prX2jhLLH8g0hxUF1F0vY UlVSRfLVaNBeux5CGPaNVI9ye3xtIe4pTYFP3TFG1w0XkAGvYWzw1Bv+iLLueAtFI+1n T6sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UWRPxRN7hFsty1XnrYVF7NX4trKwM49CdheWqn3z1M0=; b=H23TbziR7JRHthjw6fUTSO6U47uHVWpqcK5QMfxjIfRHWPh/iTwE/6hlJ/rKU2MC9B nbyNjSyZuUIfmIf9WZUpXD57IKDp58pjnHPlxSsF87i2qt9goglrK6HhLRY51jATT92b uRyOCBmeuaV4Olc6r5pNSMtHWDIlAXZoj8RKf41eS0QuamGgYgmxIKuf6yvFWWgEAbYR l7uPnFf1ojjdsw+snrK7Qns+t+kjJFADSiEYQgHecvc6IrPY9PMdXJ2caMjI8Efy1j1M 59PCP5d57fLc5tZXZmDA+ojWIefmMWuzpfcx1iONw0H4qly8OYUcUirXSTFCcYJiawZ2 s4/w== X-Gm-Message-State: APjAAAV5YEeqcn0SdFwJohr+9hbnB9SsBc7aHCchVb41igkRkfUJBFwV cmpHCXmnK4PjzNf0bopLdQ2Iu5R8bCtm/Vvz78c= X-Google-Smtp-Source: APXvYqxjdMVuH9824gJ3CH2ddqxqi3DU+GWcb8vQX9adtixvFYGvIfQMTUW5exJCBr5RYQ/+q6kHOi2EVHz6RM4hufU= X-Received: by 2002:a50:b875:: with SMTP id k50mr19774781ede.232.1566838373384; Mon, 26 Aug 2019 09:52:53 -0700 (PDT) MIME-Version: 1.0 References: <87h86ayo55.fsf@hobgoblin.ariadne.com> In-Reply-To: From: Gary Hughes Date: Mon, 26 Aug 2019 12:52:42 -0400 Message-ID: To: lars.svensson@web.de Cc: urn@ietf.org, Dean Stoneback , Paul Woidke Content-Type: multipart/alternative; boundary="000000000000aa8419059107fc82" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 16:52:57 -0000 --000000000000aa8419059107fc82 Content-Type: text/plain; charset="UTF-8" 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 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 > --000000000000aa8419059107fc82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dale, Juha, Lars,

thank you for the fee= dback and suggestions. I will shortly post a revised version incorporating = those changes.

Regarding the examples, my intent w= as to show examples of syntax, but I will try to add some context without
going too far into the weeds.

Regarding &= quot;Is this meant to imply that SCTE URNs can only be assigned via SCTEstandards"

Yes. This ensures that URN assignment= s 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 Dal= e's comment:

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

>=C2=A0 =C2=A0 =C2=A0The use of URNs should also help specification auth= ors to maintain
>=C2=A0 =C2=A0 =C2=A0different versions of URNs and dependencies between= URNs across different
>=C2=A0 =C2=A0 =C2=A0versions of SCTE specifications if they so wish. >
> I'm not sure, but I think you want to replace "different vers= ions of
> URNs and dependencies between URNs" with "different versions= of
> identifiers and dependencies between ideentifiers" -- because of<= br> > course, the use of URNs is helpful in maintaining different versions > *of URNs*.=C2=A0 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" bu= t 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
--000000000000aa8419059107fc82-- From nobody Tue Aug 27 12:52:20 2019 Return-Path: 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 3496D12012E for ; Tue, 27 Aug 2019 12:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4hUCf8FnX3HP for ; Tue, 27 Aug 2019 12:52:15 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 8576E120113 for ; Tue, 27 Aug 2019 12:52:14 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id h13so214339edq.10 for ; Tue, 27 Aug 2019 12:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hF4dSMB91FWjMK4BdM71S9fHjtNPGdL1PGazz/xBxnc=; b=Te4wnS6AOvaWk7NMYLyd5tAV30NslomM03jWvb6m5NPWm77AG/iS7s4C+hHCdGFD/i BMyhI4eavaCkdzb8yYeXWauW3gDTb3c8a/sVnsC6+Q5MXtutfCOyOK+YrEkhOUKVa4w/ 2lG8Zd8kds//J72iqgkVRF9hjhO1iqdfTvVShBC0kAGVfj83XfrTyfM6OgPmrxbdm/O4 s6+UaCbGVMv3u77Rsx1Ly44ES3sRJflLvwZUdg5UVyVQTMpP95iBM06u9LKnb7nykxie h21tjIbXrr21E+GqWYJwtZ3idfXsL0WZzR5xx4kMQ9ZWzjuBc7XikCMEiuadzRMWExkK sD0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hF4dSMB91FWjMK4BdM71S9fHjtNPGdL1PGazz/xBxnc=; b=jWNvS7usGL+71ccPE+HjP6Lu2sEtam6LgJqYyFXFaJdxUpZjfCnNTRrQd/NYHqyCqy Z0lRimHOz4+CA0vFe+XBOSyYamh2riFS44T/wZf2rz3gy+j224vtcQLvq9tx0kbjqSJE Qu3s8u9039Y0ggjKbaQrgNhiqQ22vKswf+gsdjHpD5JNFIoIrkcWpFPgnZpMi6Lpfvv0 DnLoGopavTZjL/VdOHYVxq8TFrow0ScsENRbCZKvCPdlbKL056d9RoK8avK71uYmoCKX aVsdXSAHntnI0ezZkgdu+IIpRyHM05T74RJ9fE533GiNwNzLXNn4h1341X2XKwS0f9Cb E72A== X-Gm-Message-State: APjAAAWxy6keRBoyOWfOwIyRcMausQnTFRXzEzmEwQCWvh1XR1XjkJoo BKRIBMVZqauwNKab3aP7HcMYwUyI3NGT79Z/vvI= X-Google-Smtp-Source: APXvYqwzz31/t7+RD7LcVcJ/lPAH682Ul5wcwZshBgvLdT7RMbroXu9kuMn8Z4w30fcDlsEOLBmYObMKKwi8c6a0p60= X-Received: by 2002:aa7:c712:: with SMTP id i18mr400132edq.213.1566935532794; Tue, 27 Aug 2019 12:52:12 -0700 (PDT) MIME-Version: 1.0 References: <87h86ayo55.fsf@hobgoblin.ariadne.com> In-Reply-To: From: Gary Hughes Date: Tue, 27 Aug 2019 15:52:00 -0400 Message-ID: To: lars.svensson@web.de Cc: urn@ietf.org, Dean Stoneback , Paul Woidke Content-Type: multipart/alternative; boundary="000000000000d1783705911e9bcd" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 19:52:18 -0000 --000000000000d1783705911e9bcd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Below is a revised version of the SCTE URN request form, hopefully incorporating all of the comments and feedback. regards, gary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D 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 =E2=80=98scte=E2=80=99 namespace are document= ed in the defining SCTE standards. Syntax: Identifiers assigned in the =E2=80=98scte=E2=80=99 namespace will have the = format Identifier =3D =E2=80=9Curn=E2=80=9D =E2=80=9C:=E2=80=9D =E2=80=9Cscte=E2= =80=9D =E2=80=9C:=E2=80=9D 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 =E2=80=9C{ResourceSpecificString}=E2=80=9D a= re US-ASCII strings such that the URN conforms to syntax requirements of [RFC8141]. The grammar for SCTEresource and ResourceSpecificString is as follows: SCTEresource =3D unreserved *( unreserved / pct-encoded / sub-delim= s / "@" / "/" ) ResourceSpecificString =3D *( pchar / "/" ) This precludes the use of =E2=80=9C:=E2=80=9D in =E2=80=9CSCTEresource=E2= =80=9D. SCTE publishes information regarding the registered resources in the corresponding SCTE standards. The =E2=80=9CSCTEresource=E2=80=9D may be use= d to identify the SCTE standard or the project which defined the URN. The =E2=80=9CResourceSpecificString=E2=80=9D specifies the resource name and op= tionally 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. Assignment: All URNs that use the =E2=80=98scte=E2=80=99 NID are defined in SCTE standa= rds. 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_specifi= cation.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 =E2=80=9Cscte=E2=80=9D 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 =E2=80=98scte=E2=80=99 namespace and assigned identifiers in the =E2= =80=98scte=E2=80=99 namespace and the defining SCTE standard. This will be available at https://www.scte.org/SCTE/Standards/SCTE_Assigned_Names_and_Numbers_specifi= cation.aspx Details of URNs assigned in the =E2=80=98scte=E2=80=99 namespace are docume= nted 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 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 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 >> > --000000000000d1783705911e9bcd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Below is a revised version of the SCTE URN request form, h= opefully incorporating all of the comments and feedback.

regards,

gary

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
IETF URN Registration for SCTE

Namespace Identifier: <= br>scte

Version:
2

Date:
2019-08-27

Registrant:=
The Society of Cable Telecommunications Engineers (SCTE) standards pro= gram is an ANSI-accredited Standards Development Organization for the devel= opment of technical specifications supporting cable telecommunications.=C2= =A0 SCTE standards work includes: data and telephony over cable; applicatio= n platform development; digital video; emergency alert systems; network mon= itoring systems; cables, connectors and amplifiers; construction and mainte= nance practices; energy management, and more.

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

Designated contact:
=C2=A0Role: Manager, Standards
=C2= =A0Email: standards@scte.org
<= br>Purpose:
Occasionally, SCTE specification efforts require identifiers= in a managed namespace so that they are unique and persistent.=C2=A0 To en= sure that the uniqueness is absolute, the registration of a specific Unifor= m Resource Name (URN) Namespace Identifier (NID) for use by SCTE is being s= pecified 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 o= ur requirements is a key construct to manage the definitions of those data = models reliably with persistence and uniqueness.

The use of URNs sho= uld also help specification authors to maintain different versions of ident= ifiers and dependencies between identifiers across different versions of SC= TE specifications if they so wish.

Specific URNs assigned in the =E2= =80=98scte=E2=80=99 namespace are documented in the defining SCTE standards= .

Syntax:

Identifiers assigned in the =E2=80=98scte=E2=80=99= namespace will have the format
Identifier =3D =E2=80=9Curn=E2=80=9D = =E2=80=9C:=E2=80=9D =E2=80=9Cscte=E2=80=9D =E2=80=9C:=E2=80=9D NSS

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

=C2=A0 = =C2=A0 =C2=A0 =C2=A0{SCTEresource}:{ResourceSpecificString}

where th= e "{SCTEresource}" and =E2=80=9C{ResourceSpecificString}=E2=80=9D= are US-ASCII strings such that the URN conforms to syntax requirements of = [RFC8141].

The grammar for SCTEresource and ResourceSpecificString i= s as follows:

=C2=A0 =C2=A0 =C2=A0 =C2=A0SCTEresource =3D unreserved= =C2=A0*( unreserved / pct-encoded / sub-delims / "@" / "/&q= uot; )

=C2=A0 =C2=A0 =C2=A0 =C2=A0ResourceSpecificString =3D *( pcha= r / "/" )

This precludes the use of =E2=80=9C:=E2=80=9D in= =E2=80=9CSCTEresource=E2=80=9D.

SCTE publishes information regardin= g the registered resources in the corresponding SCTE standards. The =E2=80= =9CSCTEresource=E2=80=9D may be used to identify the SCTE standard or the p= roject which defined the URN. The =E2=80=9CResourceSpecificString=E2=80=9D = specifies the resource name and optionally the edition (year) of the standa= rd that first defined the URN.

For example:
urn:scte:224:audien= ce
Identifier of an XML namespace for audience-related metadata= , defined in ANSI/SCTE 224.

urn:scte:dash:essent= ial-event:2015
Identifier used in an MPEG DASH EssentialProper= ty element to indicate that a specified event stream is essential to the me= dia presentation, first defined in the 2015 edition of the SCTE DASH speci= fications

urn:scte:scte35:2013:xml
= Identifier used in an MPEG DASH EventStream element to indicate that the ev= ent message payloads are XML representations of SCTE 35 commands, as first = defined in the 2013 edition of ANSI/SCTE 35

Publ= ished SCTE standards are freely downloadable from the SCTE web site at: h= ttps://www.scte.org/SCTE/Standards/Download_SCTE_Standards.aspx.
Assignment:
All URNs that use the =E2=80=98scte=E2=80=99 NID are defin= ed in SCTE standards.

SCTE will maintain a naming authority, the SCT= E Assigned Names and Numbers [SANN] specification, that will document the a= ssignment of SCTE resource classes and the specific registration values ass= igned for each resource class along with references to the defining specifi= cation(s).=C2=A0 The SANN =C2=A0specification will be published on the SCTE= Standards Program website (https://www.scte.org/SC= TE/Standards/SCTE_Assigned_Names_and_Numbers_specification.aspx).
The SANN specification will be updated as needed after the defining speci= fication(s) have been balloted and approved.

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

Interoperability:
SCTE standards are refere= nced by other SDOs and industry groups. Formally registering the =E2=80=9Cs= cte=E2=80=9D NID will help ensure that collisions do not occur.

Reso= lution:
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 th= e use of =E2=80=98scte=E2=80=99 namespace and assigned identifiers in the = =E2=80=98scte=E2=80=99 namespace and the defining SCTE standard. This will = be available at https://www.scte.org/SCTE/Standards= /SCTE_Assigned_Names_and_Numbers_specification.aspx

Details of U= RNs assigned in the =E2=80=98scte=E2=80=99 namespace are documented in the = defining SCTE standards.

Additional Information:
Participants in= volved in the development and usage of SCTE specifications and cable indust= ry deployments will benefit from the publication of this namespace by provi= ding consistent and reliable =C2=A0 names for the XML namespaces, schema lo= cations, and similar identifiers of physical data models published within S= CTE specifications.
The SCTE specifications are publicly available and a= re licensed to manufacturers on a nondiscriminatory basis. SCTE will mainta= in the corresponding specifications where the registered resources are refe= renced or used.

Revision Information:
v2: revised to incorporate = feedback
v1: This application is a revision and resubmission of draft-d= thakore-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 an= d suggestions. I will shortly post a revised version incorporating those ch= anges.

Regarding the examples, my intent was to sh= ow 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
stand= ards"

Yes. This ensures that URN assignments are su= bject to the same review and voting process as the standard. I
wi= ll clarify that.

regards,

gary

On Fri, Aug 23, 2019 at 6:30 AM <lars.svensson@web.de> wrote:
=
From me just a minor comm= ent on Dale's comment:

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

>=C2=A0 =C2=A0 =C2=A0The use of URNs should also help specification auth= ors to maintain
>=C2=A0 =C2=A0 =C2=A0different versions of URNs and dependencies between= URNs across different
>=C2=A0 =C2=A0 =C2=A0versions of SCTE specifications if they so wish. >
> I'm not sure, but I think you want to replace "different vers= ions of
> URNs and dependencies between URNs" with "different versions= of
> identifiers and dependencies between ideentifiers" -- because of<= br> > course, the use of URNs is helpful in maintaining different versions > *of URNs*.=C2=A0 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" bu= t 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
--000000000000d1783705911e9bcd-- From nobody Wed Aug 28 00:37:21 2019 Return-Path: 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 ; 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 ; 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 ; 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: From: lars.svensson@web.de To: "Gary Hughes" Cc: "Dean Stoneback" , urn@ietf.org, "Paul Woidke" Content-Type: text/html; charset=UTF-8 Date: Wed, 28 Aug 2019 09:37:01 +0200 Importance: normal Sensitivity: Normal In-Reply-To: References: <87h86ayo55.fsf@hobgoblin.ariadne.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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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>, 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.

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

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

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