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

[Paul Kyzivat <[e-mail]>]

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