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

From: [email-masked] (Dale R. Worley)
Date: Fri, 8 Mar 2013 15:40:43 -0500 (EST)

This message is to correct the registration text that I have proposed.

Background:

The latest syntax, taken from Laura's message of 7 Mar:

      alert-URN         = "urn:alert:" alert-identifier
      alert-identifier  = alert-category ":" alert-indication
      alert-category    = alert-name
      alert-indication  = alert-name *(":" 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

My previous proposed registration text, talking about the "meaning" of
alert-URNs and how the meanings are defined, was:

>       The <alert-indication>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-identifier> from a URN creates shorter a URN with a less
>       specific meaning; the set of dialogs to which the longer URN
>       applies is necessarily a subset of the set of dialogs to which
>       the shorter URN applies.  (If first URN contains only one
>       <alert-indication>, then the larger set is considered to be the
>       set of all dialogs.)
>
>       The specific criteria defining the subset to which the longer
>       URN applies, within the larger set of dialogs, is considered to
>       be the meaning of the <alert-indication>.  This meaning is
>       relative to and depends upon the preceding <alert-category> and
>       <alert-indication>s (if any).  The meanings of two
>       <alert-indication>s that are textually the same but are
>       preceded by different <alert-category>s or <alert-indication>s
>       have no necessary connection.  (An <alert-category> considered
>       alone has no meaning.)
>
>       The entity owning <provider> defines the meaning of a <private-name>
>       that is used as an <alert-indication>.
>
>       The entity owning the <provider> within a <private-name> (in
>       either an <alert-category> or an <alert-indication>) defines the
>       meaning of each <alert-indication> which is a <label> that
>       follows that <private-name> and that precedes the next
>       <alert-indication> which is a <private-name> (if any).
>
>       The meaning of all other <alert-indication>s is defined by
>       standardization.

Discussion:

There are a number of errors in the above paragraphs.  In particular,
I've used <alert-indication> incorrectly in many places.  The
following is a rewrite to express what I intended.

To make this work, I have to introduce a new nonterminal into the
syntax, <alert-ind>, which is an <alert-name> that is part of an
<alert-indication>:

      alert-URN         = "urn:alert:" alert-identifier
      alert-identifier  = alert-category ":" alert-indication
      alert-category    = alert-name
      alert-indication  = alert-ind *(":" alert-ind)
      alert-ind         = alert-name
      alert-name        = alert-label / private-name

This is my proposed registration text, corrected to match the syntax
given above (and to fix some minor problems):

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

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

       The meaning of all other <alert-ind>s (i.e., those that are not
       <private-name>s and do not follow a <private-name>) is defined
       by standardization.

> Laura Liess writes:
>
> My problem here is with the usage of <alert-identifier> and
> <alert-indication> in the text above and in the rule 5 d).
> ...
> and <alert-identifier> and <alert-indication> are the full chains
> including or after the <alert-category>.
> 
> The text above and the rule 5 d) talk about <alert-identifier> and
> <alert-indication> as <labels> or subchains.

Yes, the earlier versions of these paragraphs and rule 5d) used
<alert-identifier> incorrectly.  The revised version of these
paragraphs uses <alert-ind>, and should be syntactically correct now.
Of course, these paragraphs are the full version of rule 5d).

> Laura Liess writes:
>
> I am not sure this is correct.  Are <alert-identifier>s with more than
> one <private-name>s a problem?

If we wish to allow <alert-URNs> with more than one <private-name>,
it is tricky to specify which organization is responsible for
defining the significance of each part of the <alert-URN>.  I think we
do want to allow <alert-URNs> with more than one <private-name>.

Let me revisit an example that is in
http://www.ietf.org/mail-archive/web/salud/current/msg00368.html

There is a standard <alert-URN>:

    urn:alert:source:internal

Suppose example.com wants to define a URN to describe an internal
source that is "secure" in some way:

    urn:alert:source:internal:[email-masked]

Now let us suppose that the US Army decides to augment a PBX purchased
from example.com to create a "top-secret" subcategory of
"[email-masked]":

    urn:alert:source:internal:[email-masked]:[email-masked]

Again let us suppose that the US Army decides to define an even more
specialized category of "top-secret":

    urn:alert:source:internal:[email-masked]:[email-masked]:special

1) The set of dialogs to which <urn:alert:source:internal> can be
applied is defined by the standard, because of:

       The meaning of all other <alert-ind>s (i.e., those that are not
       <private-name>s and do not follow a <private-name>) is defined
       by standardization.

2) The set of dialogs to which
<urn:alert:source:internal:[email-masked]> can be applied is a
subset of the set of dialogs to which <urn:alert:source:internal> can
be applied.  The former set is defined by example.com, because of:

       The entity owning the <provider> within a <private-name>
       specifies the meaning of that <private-name> when it is used as
       an <alert-ind>.

3) The set of dialogs to which
<urn:alert:source:internal:[email-masked]:[email-masked]> can
be applied is a subset of the set of dialogs to which
<urn:alert:source:internal:[email-masked]> can be applied.  The
former set is defined by army.mil, for the same reason as in (2).

4) The set of dialogs to which
<urn:alert:source:internal:[email-masked]:[email-masked]:special>
can be applied is a subset of the set of dialogs to which
<urn:alert:source:internal:[email-masked]:[email-masked]> can
be applied.  The former set is defined by army.mil, because of:

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

This sort of analysis lets us separate the "meanings" of "internal",
"[email-masked]", "[email-masked]", and "special" and assign
which organization is responsible for defining each meaning.  But at
the same time, the meaning of each <alert-ind> is constrained by the
meanings of the preceding <alert-ind>s.

> Laura Liess writes:
>
> Additionally,  I found out that we use the word "label"  in the section 6.1
> in a way which would not be consistent with the syntax above.
> 
>   " Alert URN identifiers are identified by <label>s managed by IANA,
>    according to the processes outlined in [RFC5226] in a new registry
>    called "Alert URN Labels".  Thus, creating a new Alert-Info URN
>    identifier requires IANA action.  The policy for adding a new alert
>    category is 'Standards Action'.  (This document defines the alert
>    categories 'service', 'source', 'priority', 'duration', 'delay' and
>    'locale'. ) The policy for assigning <label>s to <alert-indication>s
>    and the rules to combine them may differ for each <alert-category>
>    and MUST be defined by the document describing the corresponding
>    alert category. "

I believe that wherever "label" appears in that paragraph, we intend
<alert-ind> (using the new terminology).

> Laura Liess writes:
>
> But why do you need the components of an <alert-indication>?
> Currently,  IMO they have no meaning and must be not managed as
> individuals, only whole <alert-indicators> must be managed.

The difficulty is that we want to allow private extensions to
standardized <alert-URN>s.  In order to do that, we have to have a
system for different organizations to define the meaning of different
*parts* of an <alert-URN>.

I believe that we already have such a system working, the only problem
is to explain it clearly in the URN registration.  The text I have
written above is a draft of such an explanation.

The text in sections 8.1 ("Priority Rules") and 9.1 ("Algorithm
Description") probably have to be corrected to match the current names
of the nonterminals.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 09 Mar 2013 10:45:41 +0800

Dale,

Thank you! You have grokked what I have been trying to get at for some 
time. I understood it, more or less, in my head but could not find a way 
to express it clearly in words. I think you now have found the words.

	Thanks,
	Paula

On 3/9/13 4:40 AM, Dale R. Worley wrote:
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: Laura Liess <[email-masked]>
Date: Mon, 11 Mar 2013 11:11:48 +0100

Dale,

2013/3/8 Dale R. Worley <[email-masked]>

> This is a very good text. Thank you.  We add this text to section 4 after
the updated syntax, don't we?

We still have to agree on the text we add to Section 6.1 based on your
examples below and  on  additional text in Section 4 , under "Identifier
uniqueness considerations"  (as required by Alfred Hoenes).

Thank you
Laura

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 11 Mar 2013 21:03:05 -0400 (EDT)

[as individual]

> From: Laura Liess <[email-masked]>
> 

Given the various revisions to the ABNF, I am wondering how close the
current draft (which is in Laura's possession) is to the -07 version.
I am hesitant to provide detailed suggestions regarding changing the
-07 text for fear that the -07 text is already obsolete and my
suggestions would be incomprehensible.

Laura, could you either assure me that the current text is close to
the -07 (in which case I will refer to -07), or submit the current
text as -08 (so we can use that as a common base)?

Dale

---

From: Laura Liess <[email-masked]>
Date: Tue, 12 Mar 2013 12:37:52 +0100

Dale,

I begun with a 08 version some weeks ago but we changed the stuff again and
again since then. I think we should  use 07 as a base for the new text.

Thank you
Laura

2013/3/12 Dale R. Worley <[email-masked]>

[as individual]

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 13 Mar 2013 17:34:05 -0400 (EDT)

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:  [email-masked]

   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-indication = indication-part *(":" indication-part)
	   indication-part  = alert-name

   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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Mar 2013 11:45:12 +0800

Some comments inline

> now, but we don't do it completely consistently.

To me this is a natural thing to do. But abnf has a different meaning 
for <...>. I'm still inclined to do it, but I'm not certain.

> and we already use (e.g.) "category" in some places.

IMO the first criterion is to avoid using any non-terminal name that 
conflicts with anything in 3261. (Because if we did it would mean a 
complete for 3261 with the extension would require renaming.)

The next criterion would be to not use any names that would conflict 
with any other existing extension to 3261, for the same reason. Actually 
checking this is hard. So choosing names unlikely to conflict is a 
simpler alternative for this.

Next, don't use names that might conflict with other future extensions 
to 3261. In general this isn't possible, but choosing names unikely to 
conflict is again a decent alternative.

So, putting an alert- prefix on all the symbols is perhaps wise.

>     the standard way to describe URNs which are of a particular scheme.

Don't know, but this seems reasonable to me.

> My revision could probably use some additional editing.

I read it all, and I'm impressed! It sounds excellent to me.

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Fri, 15 Mar 2013 02:17:21 +0100

Dale,

Thank you for doing this. The text looks realy good :-).

I agree with Paul, we should not remove the initial"alert-".

I also have only one remark:
The first paragraph in both "Namespace considerations" and "Comunity
considerations" states very clear that the "alert"  URN  is defined for
SIP.  If we state this, we probably will have to change to urn:ietf:params,
as Alfred required.
Alfred required us to either describe very clear why we can not use
urn:ietf:params or to switch to urn:ietf:params. In version 07, I to
changed the 06 text trying to express that the "alert" URN is not just for
SIP but is targeted to be used for signals or renderings in general.  The
text itself is not important to me, I don't even know if it would help, I
just want to remind you about Alfred's requirement.

Thank you
Laura

2013/3/13 Dale R. Worley <[email-masked]>

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 15 Mar 2013 15:19:58 -0400 (EDT)

> just want to remind you about Alfred's requirement.

I'll look into this question.  I tried to explain in detail why the
*management* of the URN space requires a separate scheme.  (Or
alternatively, applying all our management rules into a subtree of
urn:ietf:params.)

I'm not sure that use of URNs outside SIP is sufficient to show that
urn:ietf:params is not suitable.

What uses outside SIP are we contemplating?  My understanding is that
the URNs are defined to indicate facts about SIP dialogs, or about how
a user is to be told about a dialog.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 16 Mar 2013 07:40:22 +0800

> a user is to be told about a dialog.

They seem applicable to alerting regardless of signaling protocol.
But of course there are only a few such protocols.

I only looked briefly at the rules for registering ietf params, but that 
left me questioning if our syntax would be permitted, even ignoring 
private names. Those private names certainly wouldn't fit.

I don't think we should spend too much more time worrying about this. If 
they are going to reject on that basis I doubt there is much we can do 
to spin this to avoid it. Rather, I think we might have to raise an appeal.

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Mon, 18 Mar 2013 16:07:52 +0100

> a user is to be told about a dialog.

My opinion was that the urn could be used in H.323 or without a protocol in
web pages or in device software. I am not sure this makes sense or helps.

Laura

---

From: Laura Liess <[email-masked]>
Date: Mon, 18 Mar 2013 16:13:23 +0100

2013/3/16 Paul Kyzivat <[email-masked]>

> left me questioning if our syntax would be permitted, even ignoring private
> names. Those private names certainly wouldn't fit.
>
> they are going to reject on that basis I doubt there is much we can do to
> spin this to avoid it. Rather, I think we might have to raise an appeal.
>

This is OK for me.

Thank you
Laura

>
>         Thanks,
>         Paul
>
>
> ______________________________**_________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/salud<https://www.ietf.org/mailman/listinfo/salud>
>

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 20 Mar 2013 10:22:59 -0400 (EDT)

I'm revising the registration template based on your feedback.  So
far, it's been straightforward to apply your suggestions.  Looking
at it I see:

Should we have the contact be RAI in some form?  I assume that
revisions will always be in the hands of some RAI working group.

Looking at existing registrations, there seems to be no convention for
who the declared registrant is.  In some cases, it is a person at the
organization that is sponsoring the namespace.  In other cases, it
appears to be an individual who is not strongly connected to the
organization that I think would be involved.  For example, the
registrant of the "ietf" namespace is:

            Ryan Moats
            [email-masked]
            AT&T
            15621 Drexel Circle
            Omaha, NE 68135-2358

Dale

---

From: Laura Liess <[email-masked]>
Date: Wed, 20 Mar 2013 15:55:24 +0100

Dale,

    >revisions will always be in the hands of some RAI working group.

If this is possible, it is sure the better way to do it.

Thank you
Laura

2013/3/20 Dale R. Worley <[email-masked]>

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 21 Mar 2013 16:12:47 -0400 (EDT)

I've revised the registration template again.  It covers the questions
we've been discussing.  I've discussed more fully that alert URNs can
be used in other signaling situations and with H.323, etc.  I've
changed the registration contact to the RAI Area Director.  (I'm not
sure that that will be approved, but as a question of fact, "the RAI
Area Director" is a more stable reference than any single human
being.)

Following is detailed responses to the questions that I've seen, and
then the revised section 4 text.

I've changed the section title to match the common usage in recent RFCs.

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

> Kyzivat: 

Dale:  I've looked at some recent namespace definitions.  Many of them
use <...>, {...}, or "..." for quoting nonterminals.  So let's use
<...>, at least in the namespace registration template.

Should we remove the "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.

> Kyzivat:

> Liess:

<indication-part> is a bit awkward, but I don't know of anything
better.  It makes more sense if <alert-indication> becomes
<indication>.

Dale:
I've changed <indication-part> to <alert-ind-part>, which follows the
alert-* pattern, and yet is not excessively long.

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.

> Kyzivat:

Dale:
I've consistently used ("alert" URN) in place of (alert URN)
and ('alert' URN).

Liess:
considerations" states very clearly that the "alert"  URN  is defined for

> Kyzivat:

> Liess:

Dale:
Done.

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 version:  1

      Registration date:  TBD

      Registering organization:  
          Real-time Applications and Infrastructure Area
	  IETF

      Designated contact:  RAI Area Director

      Designated contact email:  [email-masked]

      <alert-ind-part>s, and together form 

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

           alert-indication = alert-ind-part *(":" alert-ind-part)
	   alert-ind-part  = alert-name

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

      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>) 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 entity owning the <provider> within a <private-name>
      specifies the meaning of that <private-name> when it is used as
      an <alert-ind-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 <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.

      The "alert" URNs are 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" 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.

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

      For standardized <alert-ind-parts> in URNs, uniqueness and

      Assuring uniqueness and persistence of the meanings of private
      extensions is delegated to the entities that define private
      extension <alert-ind-parts>.  The entity 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 entity obtains ownership of a particular
      <provider>, it retains ownership of it for all time, as
      described in Section 7.2 of [this RFC].

   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:

Dale

---

From: Laura Liess <[email-masked]>
Date: Sat, 23 Mar 2013 16:55:33 +0100

Dale,

The new text is great :-). Thank you.

Laura

2013/3/21 Dale R. Worley <[email-masked]>