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

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

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:[e-mail]

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

    urn:alert:source:internal:[e-mail]:[e-mail]

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

    urn:alert:source:internal:[e-mail]:[e-mail]: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:[e-mail]> 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:[e-mail]:[e-mail]> can
be applied is a subset of the set of dialogs to which
<urn:alert:source:internal:[e-mail]> 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:[e-mail]:[e-mail]:special>
can be applied is a subset of the set of dialogs to which
<urn:alert:source:internal:[e-mail]:[e-mail]> 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",
"[e-mail]", "[e-mail]", 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