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

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 18 February 2013 21:39 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0E621F8C50 for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 13:39:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.342
X-Spam-Level:
X-Spam-Status: No, score=-0.342 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvCXQ7rAjk2z for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 13:39:02 -0800 (PST)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 8222E21F8C45 for <salud@ietf.org>; Mon, 18 Feb 2013 13:39:02 -0800 (PST)
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta04.westchester.pa.mail.comcast.net with comcast id 1xbw1l0031HzFnQ54xf2GM; Mon, 18 Feb 2013 21:39:02 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id 1xf11l00Z3ZTu2S3axf12K; Mon, 18 Feb 2013 21:39:01 +0000
Message-ID: <51229F75.809@alum.mit.edu>
Date: Mon, 18 Feb 2013 16:39:01 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "Dale R. Worley" <worley@ariadne.com>
References: <CACWXZj2WhAsmQ3Ku7bVpiNhbFxX7-vx9d9wWzzKgiVLSeKk__g@mail.gmail.com> <201302132105.r1DL5BM01801234@shell01.TheWorld.com> <CACWXZj0Qq=Q=7necdgCPLeFAMbr3gg-WmBb-8UzegseEd_b_Qw@mail.gmail.com> <51225C60.9050201@alum.mit.edu> <201302182105.r1IL5S7O2079509@shell01.TheWorld.com>
In-Reply-To: <201302182105.r1IL5S7O2079509@shell01.TheWorld.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361223542; bh=pCYUehEF1wlajpMCdO6UN7sQDhJ7y3QLCUSSHFXgwUo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=S0IeiqOilc6mGqVNDN91kWemc40/Bck5b6YY/uHJMd4yiPA36B2cRHoIn3XOSsA0j aSSN9vu9dvOX7EbYXRpfRBXCZRHlA3xbitXLi7UXkWEH3iQWdQJvgNH0IHglX86fmB JqV23bBE/xAF0erbmPiJcB7iBW8uIJYVriFad4qpfc8xT+NVmoAsAWckqUncBKgEU4 6XSTGFadOxhI4eZSiq2FQkFsDr9OnBpaXCYKz/I3ax6I9sLKyq/IXIobA3U8DrhEFS PhZRmzoH1ehISV0kWbswjMAzxwfsUnwVbZpHMedt9HyzlkfpKMLfpCmRYoZkrkx+nJ 1RvsBhPOos0qA==
Cc: salud@ietf.org
Subject: Re: [salud] New version of the ABNF-syntax
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list <salud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/salud>, <mailto:salud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/salud>
List-Post: <mailto:salud@ietf.org>
List-Help: <mailto:salud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/salud>, <mailto:salud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Feb 2013 21:39:03 -0000

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