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

On 2/18/13 6:53 PM, DRAGE, Keith (Keith) wrote:
> I am not sure I understand fully the issue here, but surely what matters is that the URN that is inserted has the semantics that are defined by the owner at the time given for the URN, not that they inserted it themselves, or that they owned the domain name at the time.
>
> Thus the owner defines the semantics of the URN, but anyone can use it.

Yes. The thing is that this does not define any normative behavior.

The person that inserts the URN can put in anything they like, and then 
it means what it means. If you inserted a URN without a date, then it 
has some meaning, even if it is not the meaning that you intended.

E.g. when you insert a URN you may omit the date, thinking that the 
current owner is the first owner. Its meaning is then defined by the 
first owner. If the current owner is not the first owner, then the only 
error is that you referred to a different meaning than you intended.

And if the person that defines the actual alert that this URN maps to 
makes the same mistake, then all is well.

	Thanks,
	Paul

> Regards
>
> Keith
>
>> -----Original Message-----
>> From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf Of
>> Paul Kyzivat
>> Sent: 18 February 2013 21:39
>> To: Dale R. Worley
>> Cc: salud@ietf.org
>> Subject: Re: [salud] New version of the ABNF-syntax
>>
>> On 2/18/13 4:05 PM, Dale R. Worley wrote:
>>>> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
>>>>
>>>> I've been trying to explain why this sort of wording doesn't work for
>>>> me, several times.  [...]
>>>
>>> I tried to avoid this problem by describing which <provider>s a given
>>> entity "owns", and thus has the right to define the meaning of
>>> <label>s that are governed by that <provider>:
>>>
>>>      http://www.ietf.org/mail-archive/web/salud/current/msg00341.html
>>>
>>>      5) Definition of meaning of <label>s:
>>>
>>>      5a) A <provider> has an "owner", which is the entity that was the
>>>          registered owner of the domain name <provider-id> on the date
>>>          <date> (with respect to rule (2)).
>>>
>>>      5b) If an entity is the first registrant of a domain name
>>>          <provider-id>, it owns all <provider>s with that <provider-id>
>> and
>>>          all <date>s preceding when it registered the domain name.
>>>
>>>      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>.
>>>
>>>      5e) Entities SHOULD use only one <provider> value for all <private-
>> name>s
>>>          that they define.
>>>
>>> Does that approach work for you?
>>
>> The issue isn't who is the "owner" of the label, but rather what rights
>> are restricted to owners.
>>
>> It is possible that the "owner" of a label neither inserts the URN into
>> an Alert-Info nor defines the actual alert data structures in an
>> endpoint that are selected by the Alert-Info URN. It may just strike
>> some agreements with others about these things.
>>
>> For instance, example.com may make it known that Bob and Carol work for
>> the foo department with label foo@example.com, while Ted and Alice work
>> for the bar department with label bar@example.com. Then I may configure
>> my incoming proxy to identify calls from Bob, Carol, Ted, and Alice, and
>> insert a corresponding Alert-Info for them. And I may configure my
>> devices to map foo@example.com and bar@example.com to the alerts I want
>> to hear when getting calls from people in those departments.
>>
>> I guess an alternative to the above is that I use my own private labels
>> for those cases. But in any case, somebody other than the owner may be
>> inserting the alert-info.
>>
>> 	Thanks,
>> 	Paul
>>
>> _______________________________________________
>> salud mailing list
>> salud@ietf.org
>> https://www.ietf.org/mailman/listinfo/salud
>