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

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

(as an individual)

> From: Laura Liess <[e-mail]>
> 
> a) Let me try to find out if I understood you correctly:
> 
> -  We want to allow internationalized <label>s for the <provider-id>,
> this means Non Reserved LDH-labels or A-labels
> 
> -  We want to allow internationalized <label>s for "private alert
> labels" (labels within the <private-name> preceding the "@" or lables
> following a <private-name>).  This means Non Reserved LDH-labels or
> A-labels.
> 
> - We want to allow only ASCII-labels for "standardised/registred alert
> labels".  This means Non Reserved LDH-labels.
> 
> Is this correct or did I get something wrong?

Yes, that is what I suggest.

The second point assumes that we want to allow private alert labels to
be internationalized.  I don't know if we have discussed that point,
but it seems like a good idea to me; it allows private labels in
users' own languages, and it won't cause any operational problems
(since A-labels are processed essentially the same way as
NR-LDH-labels).

> b)
> 
> >     5c) The entity owning <provider> defines the meaning of a
> >      <private-name>, whether it is used as an <alert-category> or an
> >      <alert-indication>.
> 
>  >  5d) The entity owning <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> following that
>  > <private-name> and preceding the next <alert-indication> which is
>  > a <private-name>.
> 
> Maybe I got something wrong, but it seems to me that the text above is
> not completely consistent to the definitions in the draft:
>  -  It seems to me that in your text the term "<alert-indication>" is
> used for a string between two ":" which is a  single label  or a
> <private-name>). In the draft, an <alert-indication> is a chain of
> <lables>.

(Based on the original version of "New version of the ABNF-syntax":)
Yes, you are correct.  I should have said <alert-name> rather than
<alert-indication>.  That changes (5d) to:

     5d) The entity owning <provider> within a <private-name> (in either an
     <alert-category> or an <ALERT-NAME>) defines the meaning of
     each <ALERT-NAME> which is a <label> following that
     <private-name> and preceding the next <ALERT-NAME> which is
     a <private-name>.

>   - In your talk about the "meaning"  for <private-name>s and <label>s
> (<alert-indication>s), while according to the draft only an
> <alert-category> or an <alert-identifier> as a whole has a "meaning"
> or a "description".

You are correct.  Let me try to describe what I mean...  There is a
standard 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 UA army decides to augment a PBX purchased
from example.com to include a "top-secret" subcategory:

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

I want to express:

1) The meaning of "urn:alert:source:internal" is defined by the standard.

2) The additional meaning when "[e-mail]" is added to
"urn:alert:source:internal" is defined by example.com.

3) The additional meaning when "[e-mail]" is added to
"urn:alert:source:internal:[e-mail]" is defined by army.mil.

Of course, meaning 2 is dependent on meaning 1, and meaning 3 is
dependent on meaning 2.

I don't quite know how to express this, because, as you point out,
"[e-mail]" and "[e-mail]" have no meaning in
isolation.

Dale