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

[Laura Liess <[e-mail]>]

Dale,

2013/2/21 Dale R. Worley <[e-mail]>:
> (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).

This was also my opinion. But after reading Paul's e-mail I have
doubts if we should do this. I would think we should keep it simpe if
we can.

Note:
Maybe the "prosa" could also become more simple if we have the same
syntactic rules for the  <label>s which do not apear in the
<provider-id>. We could then just distinguish in the syntax between
"alert-labels" and "domain-labels", like:

      alert-name        = alert-label / private-name
      private-name     = alert-label "@" provider
      provider            = provider-id ["(" date ")"]
      provider-id         = 1*(domain-label ".") toplabel

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

What do you think?
I don't have any strong opinion about splitting the <label>s in
<alert-label> and  <domain-label> or not.

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

This is exactly my point.  And I don't have any idea,  either.  I
don't have any problems with the text myself, I just suspect we have
to be very accurate with our text to pass through the URNBIS and IESG
review.

Thank you
Laura



5d) The entity owning <provider> within an <ALERT-CATEGORY> or
<ALERT-IDENTIFIER> ntifierCATEGORY>which is a <label> following that
>      <private-name> and preceding the next <ALERT-NAME> which is
>      a <private-name>.
>
> Dale