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

[Laura Liess <[e-mail]>]

Dale,

2013/3/8 Dale R. Worley <[e-mail]>

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

>
>
> > 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
> _______________________________________________
> salud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/salud
>