(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