Request review of "alert" URN namespace identifier
worley@ariadne.com (Dale R. Worley) Thu, 03 October 2013 19:09 UTC
Return-Path: <worley@shell01.TheWorld.com>
X-Original-To: urn-nid@ietfa.amsl.com
Delivered-To: urn-nid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99EFA21F9D69 for <urn-nid@ietfa.amsl.com>; Thu, 3 Oct 2013 12:09:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.647
X-Spam-Level:
X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, J_CHICKENPOX_81=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgu3QeIU73KT for <urn-nid@ietfa.amsl.com>; Thu, 3 Oct 2013 12:09:38 -0700 (PDT)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE7621F8A7B for <urn-nid@ietf.org>; Thu, 3 Oct 2013 11:59:12 -0700 (PDT)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r93IwYxs020923; Thu, 3 Oct 2013 14:58:36 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r93IwXp62300796; Thu, 3 Oct 2013 14:58:33 -0400 (EDT)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r93IwXT12296687; Thu, 3 Oct 2013 14:58:33 -0400 (EDT)
Date: Thu, 03 Oct 2013 14:58:33 -0400
Message-Id: <201310031858.r93IwXT12296687@shell01.TheWorld.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: urn-nid@ietf.org
Subject: Request review of "alert" URN namespace identifier
X-Mailman-Approved-At: Fri, 04 Oct 2013 08:08:39 -0700
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <urn-nid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn-nid>
List-Post: <mailto:urn-nid@ietf.org>
List-Help: <mailto:urn-nid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Oct 2013 19:09:49 -0000
(as chair of the SALUD working group) This e-mail is to request a formal URN review of the "alert" URN namespace as defined in draft-ietf-salud-alert-info-urns-08. Introduction: The initial purpose of the "alert" URNs is to be used within SIP (Session Initiation Protocol, RFC 3261) to describe ring-tones and ring-back tones. A caller provides one or more "alert" URNs to describe how the callee should be signaled that the call has arrived. Additionally, the callee's device can return one or more "alert" URNs to the caller to describe the "ring-back" signal that should be presented to the caller (which may vary depending on the circumstances of the caller, e.g., call-waiting). The URN scheme is intended to be upward-compatible from the ring-tone systems used by the existing telephone and PBX products, and to allow successfully carrying ring specifications between existing products to the degree that it is possible. Because of this requirement, the URN scheme has some unusual features: - Each URN describes one *feature* of a ringing signal, rather than describing a complete ringing signal. - An endpoint provides a sequence of URNs to describe the nature of the ringing signal it wants the receiving endpoint to generate; the receiving endpoint uses the URNs in a "resolution" procedure to select one of the signals that it can produce, which should be the "best fit" to the specification provided by the URNs. - The URN scheme provides for both standardized and privately-defined extensions, including privately-defined semantic subdivisions of standardized URNs. - The URNs are not normally to be written or read by humans. Previous review: Alfred Hoenes provided an earlier informal review which raised a number of issues which prompted the working group to significantly revise the draft. The working group now believes that these issues have been adequately handled. - The need for a new namespace. - A part of the private-extension syntax includes representation of the domain name of the private party defining the extension, so the private-extension syntax must allow internationalized domain names. - Ownership of domain names is not stable over time, so a mechanism is needed to ensure that the time-instability of domain names does not prevent URNs from being stable and uniquely-defined. - The specification must clearly indicate what URNs (or parts thereof) are subject to IANA registration and what are not. Template: Following is the registration template for the "alert" URN namespace, section 4 of draft-ietf-salud-alert-info-urns-08: 4. URN Specification for the "alert" namespace identifier This section provides the registration template for the "alert" URN namespace identifier (NID) according to [RFC2141] and [RFC3406] Namespace ID: alert Registration Information: Registration version: 1 Registration date: TBD Declared registrant of the namespace: Registering organization: Real-time Applications and Infrastructure Area IETF Designated contact: RAI Area Director Designated contact email: rai at ietf.org Declaration of syntactic structure: The Namespace Specific String (NSS) for the "alert" URNs is called an <alert-identifier> and has a hierarchical structure. The first colon-separated part after "alert" is called the <alert-category>; the parts to the right of that are <alert-ind-part>s, and together form the <alert-indication>. The general form is urn:alert:<alert-category>:<alert-indication>. The following <alert-category> identifiers defined in [RFCXXXX]: "service" , "priority" , "source" , "duration", "delay" and "locale". The <alert-category> set can be extended in the future, either by standardization or by private action. The <alert- category>s describe distinct features of alerting signals. RFC EDITOR NOTE: Please change XXXX in [RFCXXXX] by the new RFC number, when assigned. Any "alert" URN defined in this specification is syntactically valid for ring and ringback tones and can be used in INVITE requests or in provisional 1xx responses excepting the 100 response. <alert-label>s MUST comply with the syntax for Non Reserved LDH- labels [RFC5890]. <domain-label>s MUST comply with the syntax for Non Reserved LDH-labels or the syntax for A-labels [RFC5890]. Registered URNs and components thereof MUST be transmitted as registered (including case). A new URN MUST NOT be registered if it is equal by the comparison rules to an already registered URN. The ABNF [RFC5234] for the "alert" URNs is shown below: alert-URN = "urn:alert:" alert-identifier alert-identifier = alert-category ":" alert-indication alert-category = alert-name alert-indication = alert-ind-part *(":" alert-ind-part) alert-ind-part = alert-name alert-name = alert-label / private-name private-name = alert-label "@" provider provider = provider-id ["(" date ")"] provider-id = 1*(domain-label ".") domain-label alert-label = let-dig [ *let-dig-hyp let-dig ] domain-label = let-dig [ *let-dig-hyp let-dig ] let-dig-hyp = let-dig / "-" let-dig = ALPHA / DIGIT date = [CC] YY [ "-" MM ["-" DD] ] CC = DIGIT DIGIT YY = DIGIT DIGIT MM = ( "0" %x31-39 ) / ( "1" %x30-32 ) DD = ( "0" %x31-39 ) / ( %x31-32 DIGIT ) / "30" / "31" ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9 Relevant ancillary documentation: [RFCXXXX] RFC EDITOR NOTE: Please change XXXX in [RFCXXXX] by the new RFC number, when assigned. Namespace considerations: This specification defines a URN namespace "alert" for URNs representing signals or renderings which are presented to users to inform them of events and actions. The initial usage is to specify ring tones and ringback tones when dialogs are established in SIP, but they can also be used for other commuication-initiation protocols (e.g., H.323), and more generally, in any situation (e.g., web pages or endpoint device software configurations) to describe how a user should be signaled. An "alert" URN does not describe a complete signal, but rather describes a particular characteristic of the event it is signaling or a feature of the signal to be presented. The complete specification of the signal is a sequence of "alert" URNs specifying the desired characteristics/significance of the signal in priority order, with the most important aspects specified by the earlier URNs. This allows the sender of a sequence of URNs to compose very detailed specifications from a restricted set of URNs, and to clearly specify which aspects of the specification it considers most important. The initial scope of usage is in the SIP Alert-Info header field, in initial INVITE requests (to indicate how the called user should be alerted regarding the call) and non-100 provisional (1xx) responses to those INVITE requests (to indicate the ringback, how the calling user should be alerted regarding the progress of the call). In order to assure widespread adoption of these URNs for indicating ring tones and ringback tones, the scheme must allow replication of the current diversity of these tones. Currently, these tones vary between the PSTNs of different nations and between equipment supplied by different vendors. Thus, the scheme must accommodate national variations and proprietary extensions in a way that minimizes the information that is lost during interoperation between systems that follow different national variations or that are supplied by different vendors. The scheme allows definition of private extension URNs that refine and extend the information provided by standard URNs. Private extension URNs can also refine and extend the information provided by other private extension URNs. Private extensions can also define entirely new categories of information about calls. We expect these extensions to be used extensively when existing PBX products are converted to support SIP operation. The device that receives an Alert-Info header field containing a sequence of "alert" URNs provides to the user a rendering that represents the semantic content of the URNs. The device is given great leeway in choosing the rendering, but it is constrained by rules that maximize interoperability between systems that support different sets of private extensions. In particular, earlier URNs in the sequence have priority of expression over later URNs in the sequence, and URNs that are not usable in their entirety (because they contain unknown extensions or are incompatible with previous URNs) are successively truncated in attempt to construct a URN that retains some information and is renderable in the context. Due to the practical importance of private extensions for the adoption of URNs for alerting calls and the very specific rules for private extensions and the corresponding processing rules that allow quality interoperation in the face of private extensions, the requirements of the "alert" URN schems cannot be met by a fixed enumeration of URNs and corresponding meanings. In particular, the existing namespace "urn:ietf:params" does not suffice (unless the private extension apparatus is applied to that namespace). [Note, to be deleted for the final version of this draft: Because the work on this draft has lasted for about four years, the new "alert" URN namespace is already used in finalized specifications of other SDOs (3GPP). There are already existing implementations in products and large carrier networks. <urn:alert:service:normal> is also specified for use in draft-ietf-bliss-shared-appearances.] There do not appear to be other URN namespaces that uniquely identify the semantic of a signal or rendering feature. Unlike most other currently registered URN namespaces, the "alert" URN does not identify documents and protocol objects (e.g., [RFC3044], [RFC3120], [RFC3187], [RFC3188], [RFC4179], [RFC4195], [RFC4198]), types of telecommunications equipment [RFC4152], people or organizations [RFC3043]. The <alert-URN>s are hierarchical identifiers. An <alert-URN> asserts some fact or feature of the offered SIP dialog, or some fact or feature of how it should be presented to a user, or of how it is being presented to a user. Removing an <alert-ind-part> from the end of an <alert-URN> (which has more than one <alert- ind-part>s) creates a shorter <alert-URN> with a less specific meaning; the set of dialogs to which the longer <alert-URN> applies is necessarily a subset of the set of dialogs to which the shorter <alert-URN> applies. (If the starting <alert-URN> contains only one <alert-ind-part>, and thus the <alert-ind-part> cannot be removed to make a shorter <alert-URN>, we can consider the set of dialogs to which the <alert-URN> applies to be a subset of the set of all dialogs.) The specific criteria defining the subset to which the longer <alert-URN> applies, within the larger set of dialogs, is considered to be the meaning of the final <alert-ind-part>. This meaning is relative to and depends upon the preceding <alert- category> and <alert-ind-part>s (if any). The meanings of two <alert-ind-part>s that are textually the same but are preceded by different <alert-category>s or <alert-ind-part>s have no necessary connection. (An <alert-category> considered alone has no meaning.) The organization owning the <provider> within a <private-name> specifies the meaning of that <private-name> when it is used as an <alert-ind-part>. (The organization owning a <provider> is determined by the rules in Section 7.2.) The organization owning the <provider> within a <private-name> (in either an <alert-category> or an <alert-ind-part>) specifies the meaning of each <alert-ind-part> which is an <alert-label> that follows that <private-name> and that precedes the next <alert-ind- part> which is a <private-name> (if any). The meaning of all other <alert-ind-part>s (i.e., those that are not <private-name>s and do not follow a <private-name>) is defined by standardization. Community considerations: The "alert" URNs are relevant to a large cross-section of Internet users, namely those that initiate and receive communication connections via the Session Initiation Protocol. These users include both technical and non-technical users, on a variety of devices and with a variety of perception capabilities. The "alert" URNs will allow Internet users to receive more information about offered calls and enable them to better make decisions about accepting an offered call, and to get better feedback on the progress of a call they have made. User interfaces for perception-impaired users can better render the ring and ringback tones based on the "alert" URNs because the URNs provide more detailed information regarding the intention of communications than is provided by current SIP mechanisms. Process of identifier assignment: Assignment of standardized "alert" URNs is by insertion into the IANA registry described in Section 6. This process defines the meanings of <alert-ind-part>s that have standardized meanings, as described in "Namespace Considerations". Private extensions are "alert" URNs that include <alert-ind-part>s that are <private-name>s and <alert-label>s that appear after a <private-name>s (either as an <alert-category> or an <alert- indication>). If such an <alert-ind-part> is a <private-name>, its meaning is defined by the organization that owns the <provider> that appears in the <private-name>. If the <alert-ind- part> is an <alert-label>, its meaning is defined by the organization that owns the <provider> that appears in the closest private-name> preceeding the <alert-label>. The rules for determining the organization that owns a <provider> are given in Section 7.2. Identifier uniqueness and persistence considerations: An "alert" URN identifies a semantic feature of a call or a sensory feature of how the call alerting should be a rendered at the caller's or callee's end device. For standardized <alert-ind-parts> in URNs, uniqueness and persistence of their meanings is guaranteed by the fact that they are registered with IANA in accordance with the procedures of Section 6; the feature identified by a particular "alert" URN is distinct from the feature identified by any other standardized "alert" URN. Assuring uniqueness and persistence of the meanings of private extensions is delegated to the organizations that define private extension <alert-ind-parts>. The organization responsible for a particular <alert-ind-part> in a particular "alert" URN is the owner of a syntactically-determined <provider> part within the URN. Once an organization obtains ownership of a particular <provider>, it retains ownership of it for all time, as described in Section 7.2. An organization SHOULD use only one <provider> value for all of the <private-name>s it defines. Process for identifier resolution: The process of identifier resolution is the process by which a rendering device chooses a rendering to represent a sequence of "alert" URNs. The device is allowed great leeway in making this choice, but the process must obey the rules of Section 8.1. The device is expected to provide renderings that users associate with the meanings assigned to the URNs within their cultural context. A non-normative example resolution algorithm is given in Section 9.1. Rules for lexical equivalence: "alert" URNs are compared according to case-insensitive string equality, except that every <provider> part is treated as if the <date> component is present and has all omitted components as specified by the defaults in Section 7.3, viz., an omitted <date> defaults to "2013-01-01", an omitted <CC> defaults to "20", and an omitted <MM> or <DD> defaults to "01". Conformance with URN syntax: All "alert" URNs must conform to the BNF in the 'Declaration of syntactic structure', which is a subset of the generic URN syntax. Note that "internationalized" DNS labels may appear in <provider-id>s, in which case they must appear as A-labels, that is, as transformed by Punycode. <alert- label>s, that is, components that are not DNS labels, are constrained to be Non Reserved LDH-labels, that is, "ordinary ASCII labels". Future standardization may allow <alert-label>s that are A-labels, and so interpreters of "alert" URNs must operate correctly when given such URNs as input. Validation mechanism: An "alert" URN containing no private extensions can be validated based on the IANA registry of standardized "alert" URNs. Validating an "alert" URN containing private extensions requires obtaining information regarding the private extensions defined by the organization that owns the <provider> in the relevant <private-name>. The identity of the organization can be determined from public registries of historical ownership of domain names, in accordance with the procedures of Section 7.2. However, if an "alert" URN contains at least one <alert-identifier> that precedes the first <private- name>, the portion of the "alert" URN that precedes the first <private-name> must itself be a valid standardized "alert" URN, which may be validated as above. Scope: The scope for this URN is public and global. Thanks for your feedback, Dale
- Request review of "alert" URN namespace identifier Dale R. Worley