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

[Paul Kyzivat <[e-mail]>]

On 2/21/13 3:27 PM, Dale R. Worley wrote:
> (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).

I'm slightly concerned about this, for perhaps poor reasons.

1) allowing internationalized private labels but not for standard labels 
might bias some against defining a new standard label because they want 
to use internationalized names. I would rather not give that incentive 
for non-standard behavior.

2) allowing internationalized names will open Pandora's box for all 
sorts of issues about comparison of labels. Not permitting them will 
avoid the need to go down that rat hole.

	Thanks,
	Paul

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