Re: [salud] New version of the ABNF-syntax

[[e-mail] (Dale R. Worley)]

I was looking at inserting the updated ABNF into -07, as well as
adding the expanded explanation I gave of which organizations have the
right to define the meaning of which components of a URN.  As far as I
can tell, both of these go into the "Namespace registration template",
which is in section 4.

Looking at the template in -07, it seems to me that it did not relfect
many of our recent decisions, and in some places information should be
moved to other sections.  So I edited the template into what seems to
me to be a better organization.  The revised text is below.

In particular, I explained why we need such a complex scheme
definition.  (We need to provide private extensions to accommodate the
existing practice of equipment vendors.)

During the editing, I listed some open questions regarding how we
write the text:

1. Should we use the notation <xxx> for nonterminals?  We generally do
now, but we don't do it completely consistently.

2. Should we remove the initial "alert-" from nonterminals other than
"alert-URN"?  There does not seem to be much benefit from the prefix,
and we already use (e.g.) "category" in some places.

3. The nonterminal name <indication-part> is a bit awkward, but I
don't know of anything better.  <alert-indication-part> would be more
consistent with current usage, but is very long.  Using
<indicatin-part> makes more sense if we change <alert-indication> into
<indication>.

4. In the template, we say '"alert" URN'.  This makes sense, but is it
   the standard way to describe URNs which are of a particular scheme.

My revision could probably use some additional editing.

----------------------------------------------------------------------
4.  Namespace Registration Template

   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:  IETF

      Designated contact:  Laura Liess

      Designated contact email:  [e-mail]

   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
      the <alert-indication>.  The general form is
      urn:alert:{alert-category}:{alert-indication}.

      In this specification, the following <alert-category> identifiers are
      described: "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 categories are orthogonal.  Any Alert-Info 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.




Liess, et al.             Expires April 5, 2013                [Page 12]

Internet-Draft               Alert-Info URNs                October 2012


      <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 for A-labels [RFC5890].  Comparisons MUST follow the
      comparison rules for the corresponding type of label.  Registered
      URNs MUST be transmitted as registered.  A new name MUST NOT be
      registered if it is equal by the comparison rules above to an
      already registered name.

      The ABNF [RFC5234] for the Alert -Info URNs is shown below:

           alert-URN        = "urn:alert:" alert-identifier
           alert-URN        = "urn:alert:" alert-identifier
           alert-identifier = alert-category ":" alert-indication
           alert-category   = alert-name
           alert-indication = indication-part *(":" indication-part)
	   indication-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:  [this RFC]

   Namespace considerations:

      This specification proposes a new URN
      namespace "alert" for URNs representing the semantics of
      signals or renderings used for alerting of users when a call
      arrives via the Session Initiation Protocol.  The particular
      rendering of an "alert" URN
      identifier depends on the context in which the rendering is done.

      The initial scope of usage is in the SIP Alert-Info header,
      in initial INVITE requests (to indicate how the called user
      should be alerted regarding the call) and non-100 provisional
      responses to those INVITE requests (to indicate the ringback,
      how the calling user should be alerted regarding the progress of
      the call).

      The "alert" URN namespace is designed for more general usage.
      The URN may appear in any protocols that allow general URIs (e.g.
      also in ITU-T protocols), in web pages or in any end device's
      software.

      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 containing a
      sequence of "alert" URNs provides to the user a rendering to
      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 already finalized specifications
      of other SDOs (3GPP) and 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.

      Also, 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 <indication-part>
      from the end of an <alert-URN> (which has more than one
      <indication-part>) 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 <indication-part>, and thus the <indication-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 <indication-part>.  This
      meaning is relative to and depends upon the preceding
      <alert-category> and <indication-part>s (if any).  The meanings of
      two <indication-part>s that are textually the same but are preceded
      by different <alert-category>s or <indication-part>s have no
      necessary connection.  (An <alert-category> considered alone
      has no meaning.)

      The entity owning the <provider> within a <private-name>
      specifies the meaning of that <private-name> when it is used as
      an <indication-part>.  (The entity owning a <provider> is
      determined by the rules in Section 7.2 of [this RFC].)

      The entity owning the <provider> within a <private-name> (in
      either an <alert-category> or an <indication-part>) specifies the
      meaning of each <indication-part> which is an <alert-label> that
      follows that <private-name> and that precedes the next
      <indication-part> which is a <private-name> (if any).

      The meaning of all other <indication-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 URN is believed to be 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' URN will
      allow Internet users to receive more information and enable them
      to better make decisions about accepting an offered call, or get
      better feedback on the progress of a call they have made.  User
      interfaces for perception-impaired users can better render the
      ringback tone indication based on the Alert-Info URN.

   Process of identifier assignment:

      Assignment of standardized "alert" URNs is by insertion into the
      IANA registry described in Section 6 of [this RFC].  This
      process defines the meanings of <indication-part>s that have
      standardized meanings, as described in "Namespace Considerations".

      Private extensions are "alert" URNs that include
      <indication-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
      <indication-part> is a <private-name>, its meaning is defined by
      the entity that owns the <provider> that appears in the
      <private-name>.  If the <indication-part> is an <alert-label>,
      its meaning is defined by the entity that owns the <provider>
      that appears in the closest <private-name> preceeding the
      <alert-label>.  The rules for determining the entity that owns a
      <provider> are given in Section 7.2 of [this RFC].

   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 <indication-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 of [this RFC]; 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 entities that define private
      extension <indication-parts>.  The entity responsible for a
      particular <indication-part> in a particular "alert" URN is the
      owner of a syntactically-determined <provider> part within the
      URN.  Once an entity obtains ownership of a particular
      <provider>, it retains ownership of it for all time, as
      described in Section 7.2 of [this RFC].

   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 of
      [this RFC].  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 of [this RFC].

   Rules for lexical equivalence:  Alert-Info URNs are compared
      according to case-insensitive string equality, as described
      under "Namespace Considerations".

   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.
      [insert reference to appropriate RFC]  <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-Info URNs.

      Validating an "alert" URN containing private extensions requires
      obtaining information regarding the private extensions defined
      by the entity that owns the <provider> in the relevant
      <private-name>.  The identity of the entity can be determined
      from public registries of historical ownership of domain names,
      in accordance with the procedures of Section 7.2 of [this RFC].

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

Dale