
From laura.liess.dt@googlemail.com  Fri Feb  8 06:16:44 2013
Return-Path: <laura.liess.dt@googlemail.com>
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 7E1A921F8814 for <salud@ietfa.amsl.com>; Fri,  8 Feb 2013 06:16:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 Ac7u2B4qnGqf for <salud@ietfa.amsl.com>; Fri,  8 Feb 2013 06:16:43 -0800 (PST)
Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 5097D21F87F6 for <salud@ietf.org>; Fri,  8 Feb 2013 06:16:43 -0800 (PST)
Received: by mail-lb0-f179.google.com with SMTP id j14so3031111lbo.10 for <salud@ietf.org>; Fri, 08 Feb 2013 06:16:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=O4/WSBaucGCYsdvbDcWXXXKatpFfRXogZL4+pfvesDc=; b=USoO36TURSAVv7BBS6noeAMWFlr9ZwPuCCHLT8M+TH2ANQ7ESqwmOVcUtOOy51LWIt hT8ABgsUwCn4n0ayNXkZIulXTp6GP3NuqTdblz3cKTTtPKqZy5DaGyrc8ehyDGfpcGFf H3AVd8a/IjwTfQ8ZNb3Np1jXalMLd0b3yyDHb7pl05VuNibUDtwb8y3IvkHvKCqXE3/U 5VscIH41sNCOJ2QGo/ux/OUqEoSGSRjlIyeP1kcvaDVPmINztxnusU60QWJKBR+wfjQv bzGYAapxow4ORB0Ve4NvD879BmrIJG1iHYkiQte4o2ul50vYD+r78EXPiiqyz70I5qgo IRHw==
MIME-Version: 1.0
X-Received: by 10.112.84.228 with SMTP id c4mr2291656lbz.113.1360333002069; Fri, 08 Feb 2013 06:16:42 -0800 (PST)
Received: by 10.114.95.99 with HTTP; Fri, 8 Feb 2013 06:16:41 -0800 (PST)
In-Reply-To: <057.7a5f62e2602eb6d273497968d68ec4cc@trac.tools.ietf.org>
References: <057.7a5f62e2602eb6d273497968d68ec4cc@trac.tools.ietf.org>
Date: Fri, 8 Feb 2013 15:16:41 +0100
Message-ID: <CACWXZj27NPVPaZeLT0gJ5X+_VSXiYe3NEKms6BJBdcL7fwOA7g@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: salud issue tracker <trac+salud@trac.tools.ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: draft-ietf-salud-alert-info-urns@tools.ietf.org, dworley@avaya.com, salud@ietf.org
Subject: Re: [salud] #4: Using <private-name>s as <alert-categories>
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: Fri, 08 Feb 2013 14:16:44 -0000

I think this is a good idea.  I think it is no problem to change the
ABNF-syntax accordingly.

By the way, it seems to me that your mail didn't go to the salud ML,
also salud@ietf.org was in your CC.

Thank you
Laura



2013/1/28 salud issue tracker <trac+salud@trac.tools.ietf.org>:
> #4: Using <private-name>s as <alert-categories>
>
>  Should private-names be usable as alert-categories as well as components
>  alert-indications (alternatives with an alert-category)?
>
>  Allowing this would allow private definitions of entire alert-categories.
>  Disallowing this would constrain private definitions to be further
>  refinement of standard categories.
>
> --
> -------------------------+-------------------------------------------------
>  Reporter:               |      Owner:  draft-ietf-salud-alert-info-
>   dworley@avaya.com      |  urns@tools.ietf.org
>      Type:  defect       |     Status:  new
>  Priority:  major        |  Milestone:
> Component:  alert-info-  |    Version:
>   urns                   |   Keywords:
>  Severity:  -            |
> -------------------------+-------------------------------------------------
>
> Ticket URL: <http://trac.tools.ietf.org/wg/salud/trac/ticket/4>
> salud <http://tools.ietf.org/salud/>
>

From laura.liess.dt@googlemail.com  Mon Feb 11 06:35:21 2013
Return-Path: <laura.liess.dt@googlemail.com>
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 33C4F21F87D2 for <salud@ietfa.amsl.com>; Mon, 11 Feb 2013 06:35:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 czFrQycygeaD for <salud@ietfa.amsl.com>; Mon, 11 Feb 2013 06:35:20 -0800 (PST)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCD121F87C3 for <salud@ietf.org>; Mon, 11 Feb 2013 06:35:20 -0800 (PST)
Received: by mail-la0-f48.google.com with SMTP id fq13so5882283lab.35 for <salud@ietf.org>; Mon, 11 Feb 2013 06:35:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=SPTjdR4G1LGpuX+TKhd8Gbk81ut9h67KxV/m3s84ExA=; b=WeyWc8t5qo+xMYaoUxa8GGprI/nNgu2p96FSceXxPkQH3XrhXm9Fo5EcdocUwdwGky BvrRcibSbFTkjCt/z1RnEDX61IvChyKUh48IQkdBnQzP+fi/Ea+bPnvgm2UxgtMvLHfK TdbA1fXbBPWQ+KOYlTqYqO46tc6tTMoUcS+p1R0drRBRKfvfEBFzBeF+G5AW/pzHLco0 zql5evdKouYOBI9ALIYNN5mytYD5kJPhnOAzJAvCnGXw9aJ+tUBxUd5RvHzQ5rWNVms8 MAABdGbD85B8FDqtqPPIRhNcLnzUWzdC9yO4z9xYlsXuMINT2znPFv3ux4HVTEB98bF6 OaWA==
MIME-Version: 1.0
X-Received: by 10.112.40.129 with SMTP id x1mr5855305lbk.95.1360593319213; Mon, 11 Feb 2013 06:35:19 -0800 (PST)
Received: by 10.114.95.99 with HTTP; Mon, 11 Feb 2013 06:35:19 -0800 (PST)
Date: Mon, 11 Feb 2013 15:35:19 +0100
Message-ID: <CACWXZj2X893ZWiD=ZEJNxCN2Km3Xk-uHxUACT9WAOmyUhrFQPw@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: salud@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [salud] Do we need the FQDN to be followed by at least one label?
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, 11 Feb 2013 14:35:21 -0000

Hi,

We agreed that the FQDN must be followed by at least
one label, because the FQDN alone does not
specify anything in particular (it  was my own proposal at some time.)
  See  5) in Dale's message
http://www.ietf.org/mail-archive/web/salud/current/msg00290.html

However, it seems to me that this is no longer true. We changed the
syntax for some times since then. E.g.
<urn:alert:source:foo@example.com(2013)> or
<urn:alert:source:foo@example.com> make sense.

Note: Paul already agreed to this statement.


Thanks a lot
Laura

From worley@shell01.TheWorld.com  Mon Feb 11 09:26:23 2013
Return-Path: <worley@shell01.TheWorld.com>
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 52F5C21F87D4 for <salud@ietfa.amsl.com>; Mon, 11 Feb 2013 09:26:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.705
X-Spam-Level: 
X-Spam-Status: No, score=-2.705 tagged_above=-999 required=5 tests=[AWL=0.275,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 pxy89a7-UKkZ for <salud@ietfa.amsl.com>; Mon, 11 Feb 2013 09:26:22 -0800 (PST)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id B6DE421F86F5 for <salud@ietf.org>; Mon, 11 Feb 2013 09:26:22 -0800 (PST)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1BHQDLJ027340; Mon, 11 Feb 2013 12:26:15 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1BHQDV11661797; Mon, 11 Feb 2013 12:26:13 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1BHQC3N1651824; Mon, 11 Feb 2013 12:26:12 -0500 (EST)
Date: Mon, 11 Feb 2013 12:26:12 -0500 (EST)
Message-Id: <201302111726.r1BHQC3N1651824@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: Laura Liess <laura.liess.dt@googlemail.com>
In-reply-to: <CACWXZj2X893ZWiD=ZEJNxCN2Km3Xk-uHxUACT9WAOmyUhrFQPw@mail.gmail.com> (laura.liess.dt@googlemail.com)
References: <CACWXZj2X893ZWiD=ZEJNxCN2Km3Xk-uHxUACT9WAOmyUhrFQPw@mail.gmail.com>
Cc: salud@ietf.org
Subject: Re: [salud] Do we need the FQDN to be followed by at least one label?
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, 11 Feb 2013 17:26:23 -0000

> From: Laura Liess <laura.liess.dt@googlemail.com>
> 
> We agreed that the FQDN must be followed by at least
> one label, because the FQDN alone does not
> specify anything in particular (it  was my own proposal at some time.)
>   See  5) in Dale's message
> http://www.ietf.org/mail-archive/web/salud/current/msg00290.html
> 
> However, it seems to me that this is no longer true. We changed the
> syntax for some times since then. E.g.
> <urn:alert:source:foo@example.com(2013)> or
> <urn:alert:source:foo@example.com> make sense.
> 
> Note: Paul already agreed to this statement.

Yes, I agree.  The real condition is that if there is an FQDN, there
must be at least one label that logically follows it.  But of course,
in the syntax "...:foo@example.com:...", the label "foo" does
*logically* follow the FQDN (although it is *written* first).

(I have some memory that I said something incorrect about this in the
past.)

Dale

From laura.liess.dt@googlemail.com  Tue Feb 12 07:25:58 2013
Return-Path: <laura.liess.dt@googlemail.com>
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 C539B21F8EFC for <salud@ietfa.amsl.com>; Tue, 12 Feb 2013 07:25:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_52=0.6, NO_RELAYS=-0.001]
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 nAHzjgSjnRQy for <salud@ietfa.amsl.com>; Tue, 12 Feb 2013 07:25:58 -0800 (PST)
Received: from mail-la0-x234.google.com (la-in-x0234.1e100.net [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id E404C21F8EF0 for <salud@ietf.org>; Tue, 12 Feb 2013 07:25:57 -0800 (PST)
Received: by mail-la0-f52.google.com with SMTP id fs12so190514lab.25 for <salud@ietf.org>; Tue, 12 Feb 2013 07:25:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=zSH27J9IHmnehkBN3eZwTEccbsptH2RI6pf0q/0MyIo=; b=neQgT437C/v2sUpELIxcgO4XF03Ufj0xtpSAunhP5yaq+JDR1XBaIGjXendVdJSb/J 3US07BMji1mlCaw3/quYkCvft2EmyiSJCx320VVJFXPCfRA1NUWCuKgVHToyUXLYD1EU raameRFzc6Yjmq7wPtBKzZbtGqa7ac/+rx8txPRBn7Eq7xlSpWCGw2oPPhoTMf8V6XMN PhUN5a+00hPZPXfuiJl0i8rLL1bc336m05oNneI4rznZgCcDzpeikbthX3wZdbU0nLik dw0fJDDPLzM/Wne4TAzWcvYkz0dVxhSIXp6xO2auMn5v+j97Y2y4XVHzg9SXsX8S0/T+ 1OjA==
MIME-Version: 1.0
X-Received: by 10.152.104.36 with SMTP id gb4mr17088455lab.13.1360682756699; Tue, 12 Feb 2013 07:25:56 -0800 (PST)
Received: by 10.114.95.99 with HTTP; Tue, 12 Feb 2013 07:25:56 -0800 (PST)
Date: Tue, 12 Feb 2013 16:25:56 +0100
Message-ID: <CACWXZj0vqAyX4LvsBuhKzSmMNCMTfMEi0Upo29eYS6W6CiFEYw@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: salud@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [salud] Opinion concerning ticket #1 issues
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: Tue, 12 Feb 2013 15:25:58 -0000

Hi,

Here are my personal view/opinions on the issues in ticket #1:

(1)We already agreed on (1b), didnt'we?

(2) It seems that we couldn't get an agreement on using "~", Paul
doesn't like it. I am OK with Paul's proposal to use "(...)" e.g.,
"telephone.com(2013)". Other opinions?

(3) I think we should try with (3a1). At least a domain owner who
owned the domain at the default date should be allowed to omit the
date.

(4) Let's try with (4c).

(5) (5b)  because of (4c). The syntax would be DATE = [CC] YY ["-" MM
["-" DD] ].

(6) Maximizing the number of current users who can use the default
date is a good argument in favor of  (6b), so I would say let's take
(6b).

(7) I would propose to add Paul's proposal from
http://www.ietf.org/mail-archive/web/salud/current/msg00295.html to
the draft text and then discuss it with Alfred Hoenes. Maybe he knows
how reliable domaintools.com is.

Thank you
Laura

From pkyzivat@alum.mit.edu  Tue Feb 12 07:39:00 2013
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 71F0121F8EDB for <salud@ietfa.amsl.com>; Tue, 12 Feb 2013 07:39:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.062
X-Spam-Level: 
X-Spam-Status: No, score=-0.062 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_52=0.6, 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 jiSKzGouwfE5 for <salud@ietfa.amsl.com>; Tue, 12 Feb 2013 07:38:56 -0800 (PST)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id D0C1021F8ED8 for <salud@ietf.org>; Tue, 12 Feb 2013 07:38:55 -0800 (PST)
Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta03.westchester.pa.mail.comcast.net with comcast id zPeJ1k0031YDfWL53Tevx3; Tue, 12 Feb 2013 15:38:55 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id zTeu1k01D3ZTu2S3gTevRo; Tue, 12 Feb 2013 15:38:55 +0000
Message-ID: <511A620E.50407@alum.mit.edu>
Date: Tue, 12 Feb 2013 10:38:54 -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: salud@ietf.org
References: <CACWXZj0vqAyX4LvsBuhKzSmMNCMTfMEi0Upo29eYS6W6CiFEYw@mail.gmail.com>
In-Reply-To: <CACWXZj0vqAyX4LvsBuhKzSmMNCMTfMEi0Upo29eYS6W6CiFEYw@mail.gmail.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=1360683535; bh=41GMqf3v/UKzHcWNAg5vgSHhx/SafEICQV7P3rt6vQQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UyidXIsTNVZjsh4b5ubsZODverut/x5haKxmttLbMgOXYU1idSTnCswGXB01n6O07 11j0oWLnsCZbwNhViQl3+9zFyRspq0km5JzDP1imaJkia3lCMkuGbaayCgyQuyKKKc HPqqx+ig4rXWb2V58Ps3P5KcNGonUcxVlVm6MdUgqXyJYCih8ItgweKLKgSmZWnfe/ 9GBgHV+TUBnamxdhz75NST0rDBN6JWpsbBY1QpeXqr0MYheVPU8E8nSnVwZ2alhEzz OSya62+1EEQcbcyfgedYz6GDhj4FvqEWNaa3R0luVE80t5MLgxSU0PLGOw82Wz1TIR shgezPPQnmtqA==
Subject: Re: [salud] Opinion concerning ticket #1 issues
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: Tue, 12 Feb 2013 15:39:00 -0000

I'm fine with everything here.

	Thanks,
	Paul

On 2/12/13 10:25 AM, Laura Liess wrote:
> Hi,
>
> Here are my personal view/opinions on the issues in ticket #1:
>
> (1)We already agreed on (1b), didnt'we?
>
> (2) It seems that we couldn't get an agreement on using "~", Paul
> doesn't like it. I am OK with Paul's proposal to use "(...)" e.g.,
> "telephone.com(2013)". Other opinions?
>
> (3) I think we should try with (3a1). At least a domain owner who
> owned the domain at the default date should be allowed to omit the
> date.
>
> (4) Let's try with (4c).
>
> (5) (5b)  because of (4c). The syntax would be DATE = [CC] YY ["-" MM
> ["-" DD] ].
>
> (6) Maximizing the number of current users who can use the default
> date is a good argument in favor of  (6b), so I would say let's take
> (6b).
>
> (7) I would propose to add Paul's proposal from
> http://www.ietf.org/mail-archive/web/salud/current/msg00295.html to
> the draft text and then discuss it with Alfred Hoenes. Maybe he knows
> how reliable domaintools.com is.
>
> Thank you
> Laura
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>


From laura.liess.dt@googlemail.com  Wed Feb 13 00:15:16 2013
Return-Path: <laura.liess.dt@googlemail.com>
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 BF4E121F8A6F for <salud@ietfa.amsl.com>; Wed, 13 Feb 2013 00:15:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pAcc0L18lnk for <salud@ietfa.amsl.com>; Wed, 13 Feb 2013 00:15:16 -0800 (PST)
Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id EF17321F89D5 for <salud@ietf.org>; Wed, 13 Feb 2013 00:15:12 -0800 (PST)
Received: by mail-lb0-f169.google.com with SMTP id m4so761526lbo.0 for <salud@ietf.org>; Wed, 13 Feb 2013 00:15:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=ADpgbL7p4mXFlHCxHBpvH1lkhHvci8OudOztt7NPnfQ=; b=Z338t02Bn4zHJLDJ2dBCEM6o+4NYuuu8vynvvR/WuM7YSgkD94B+HhIHnrIhH8NrtU Cf3+HRMGglPOv1NK6cOpEVL10dlZV5IYA8Pt7fYLAK+Fh5TwTQJvfJ9zUM2eky9GLJS5 LXRFwyZOHmLa5A9198J9GbkkUZqakEaNQK3yeFfr4DA+Ero3xgfSKTyPtJO7vkCMCrjK liXS+GBruRCmbZ6WBOJCTABv7HhWqqTA/aHsUkTPoZB7TCGkOcgxk+ykvfJxvkHxdm2r CwT8Srrpaw6muokVeVXII+nMqPTtD4HeFxSa9FjRMJEddQg9qh76Rex7eHPaEoKWsMkp y3AQ==
MIME-Version: 1.0
X-Received: by 10.152.104.36 with SMTP id gb4mr19404258lab.13.1360743311845; Wed, 13 Feb 2013 00:15:11 -0800 (PST)
Received: by 10.114.95.99 with HTTP; Wed, 13 Feb 2013 00:15:11 -0800 (PST)
Date: Wed, 13 Feb 2013 09:15:11 +0100
Message-ID: <CACWXZj1ixz9aix+w8ayk8HTqbUNnz1uakHYZY3mU0BQ6tm6Q2A@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: salud@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [salud] Ticket #2
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: Wed, 13 Feb 2013 08:15:16 -0000

Hi,

It seem to me that we already have a general agreement that the lables
should be in the ordinary order.  Any other opinions?

Thank you
laura

From laura.liess.dt@googlemail.com  Wed Feb 13 06:46:44 2013
Return-Path: <laura.liess.dt@googlemail.com>
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 C4BC821F871D for <salud@ietfa.amsl.com>; Wed, 13 Feb 2013 06:46:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.827
X-Spam-Level: 
X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkoUk81Eshj6 for <salud@ietfa.amsl.com>; Wed, 13 Feb 2013 06:46:44 -0800 (PST)
Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id CFD3021F86FC for <salud@ietf.org>; Wed, 13 Feb 2013 06:46:43 -0800 (PST)
Received: by mail-lb0-f177.google.com with SMTP id go11so1002561lbb.36 for <salud@ietf.org>; Wed, 13 Feb 2013 06:46:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=fR35KN+UtrcujZOZ3m0UUlvo+Q3Nyt41bpNCOGWGTIE=; b=JJbpY9rpf0YsdbDFguKsmnDP7NKxc0ZWHk7YEIZStFM6tnTR8w5xNsjXCcaP5Ytqb9 o/AV8XaTI4lN0b8bGJvy1nFG3TRQeLE74eoX+n7unHv2j7szmqU+RhDgMaanvSSdaUHo c3RiS4RyKh9EALwoj3dD6dfBUmF0L0wiIAsp8D3YdXD+q1D2wQn2iDXScc3P22Z1GgQ4 jjKH6sCS2KdWAefyJ5dr3h7a1U03oQqyEeX8B6MPgR97LA1sAUfuo/OIvsxRmGzOJ5z8 6H47VpnQ+BwmUOjnwJNUq7Sxu5br4BVCrtt/rqQGB7QTCBPsVJmcuVcqHxhcTQlKL01y RaXg==
MIME-Version: 1.0
X-Received: by 10.152.125.239 with SMTP id mt15mr20423388lab.26.1360766802841;  Wed, 13 Feb 2013 06:46:42 -0800 (PST)
Received: by 10.114.95.99 with HTTP; Wed, 13 Feb 2013 06:46:42 -0800 (PST)
Date: Wed, 13 Feb 2013 15:46:42 +0100
Message-ID: <CACWXZj2WhAsmQ3Ku7bVpiNhbFxX7-vx9d9wWzzKgiVLSeKk__g@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: salud@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [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: Wed, 13 Feb 2013 14:46:44 -0000

Hi,

Because we had several changes and discussions which affect the
syntax,  I send a new version to the list, including the rules for
<date>.  I used the <provider-id>,  <MM> and <DD> definitions from the
RFC 4198.
Please let me know what you think of it.

       alert-URN         = "urn:alert:" alert-identifier
       alert-identifier    = alert-category ":" alert-indication
       alert-category    = name/private-name
       alert-indication   = alert-name *(":" alert-name)
       alert-name         = name/private-name
       name                = label
       private-name      = label"@"provider-id["(" date ")"]
       provider-id          = 1*(label ".") toplabel
       date                  = [CC] YY ["-" MM ["-" DD] ]
       label                  = let-dig [ *let-dig-hyp let-dig ]
       let-dig-hyp          = let-dig / "-"
       let-dig                = ALPHA / DIGIT
       YY                    = CC
       CC                    = DIGIT DIGIT
      MM                    = ("0" %x31-39) / ("1" %x30-32)
      DD                     = ("0" %x31-39) / (%x31-32 DIGIT) / "30" / "31"
      ALPHA               = %x41-5A / %x61-7A   ; A-Z / a-z
      DIGIT                  = %x30-39 ; 0-9
      DIGIT-1-9             = %x31-39 ; 1-9
      DIGIT-2-9             = %x32-39 ; 2-9

    Following rules apply to the <date> usage:
       a) A provider is permitted to use any <date> within its domain
name ownership time period.
       b) If the <date> is absent, it defaults to 2013-01-01.
       c) If <DD> or <MM> are absent each defaults to 01.
       d)  If <CC> is absent it defaults to 20.
       e)  Comparison is based on the full <CCYY-MM-DD> after defaults
have been filled in.
       f)   A provider is allowed to use a domain name without a date
if he owns the domain at the default year 2013 or if he is able to
verify that he is the first owner of the domain, e.g. by checking
reliable domain history tools.   Note: We assume that the domain
ownership does not change during the same year.


Thank you
Laura

From keith.drage@alcatel-lucent.com  Wed Feb 13 07:13:48 2013
Return-Path: <keith.drage@alcatel-lucent.com>
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 10A9E21F8753 for <salud@ietfa.amsl.com>; Wed, 13 Feb 2013 07:13:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.628
X-Spam-Level: 
X-Spam-Status: No, score=-108.628 tagged_above=-999 required=5 tests=[AWL=1.321, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bP1Xw+F4LNd for <salud@ietfa.amsl.com>; Wed, 13 Feb 2013 07:13:47 -0800 (PST)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id EDB4F21F86C5 for <salud@ietf.org>; Wed, 13 Feb 2013 07:13:46 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1DFDeIW022242 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Feb 2013 16:13:45 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 13 Feb 2013 16:13:42 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Laura Liess <laura.liess.dt@googlemail.com>, "salud@ietf.org" <salud@ietf.org>
Date: Wed, 13 Feb 2013 16:13:40 +0100
Thread-Topic: [salud] New version of the ABNF-syntax
Thread-Index: Ac4J+PmS2xiFvaTHRYus67Spab2ziAAA1Y1w
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE2106FF5D58F@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
References: <CACWXZj2WhAsmQ3Ku7bVpiNhbFxX7-vx9d9wWzzKgiVLSeKk__g@mail.gmail.com>
In-Reply-To: <CACWXZj2WhAsmQ3Ku7bVpiNhbFxX7-vx9d9wWzzKgiVLSeKk__g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13
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: Wed, 13 Feb 2013 15:13:48 -0000

Not clear from this extract what associated normative references you have.=
=20

They need to at least cover which calendar is in use, and how sequences of =
digits or letter digits are converted into days or months (for example is J=
anuary "01" or "10" and indeed is January the 1st month.

Keith

> -----Original Message-----
> From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf Of
> Laura Liess
> Sent: 13 February 2013 14:47
> To: salud@ietf.org
> Subject: [salud] New version of the ABNF-syntax
>=20
> Hi,
>=20
> Because we had several changes and discussions which affect the
> syntax,  I send a new version to the list, including the rules for
> <date>.  I used the <provider-id>,  <MM> and <DD> definitions from the
> RFC 4198.
> Please let me know what you think of it.
>=20
>        alert-URN         =3D "urn:alert:" alert-identifier
>        alert-identifier    =3D alert-category ":" alert-indication
>        alert-category    =3D name/private-name
>        alert-indication   =3D alert-name *(":" alert-name)
>        alert-name         =3D name/private-name
>        name                =3D label
>        private-name      =3D label"@"provider-id["(" date ")"]
>        provider-id          =3D 1*(label ".") toplabel
>        date                  =3D [CC] YY ["-" MM ["-" DD] ]
>        label                  =3D let-dig [ *let-dig-hyp let-dig ]
>        let-dig-hyp          =3D let-dig / "-"
>        let-dig                =3D ALPHA / DIGIT
>        YY                    =3D CC
>        CC                    =3D DIGIT DIGIT
>       MM                    =3D ("0" %x31-39) / ("1" %x30-32)
>       DD                     =3D ("0" %x31-39) / (%x31-32 DIGIT) / "30" /
> "31"
>       ALPHA               =3D %x41-5A / %x61-7A   ; A-Z / a-z
>       DIGIT                  =3D %x30-39 ; 0-9
>       DIGIT-1-9             =3D %x31-39 ; 1-9
>       DIGIT-2-9             =3D %x32-39 ; 2-9
>=20
>     Following rules apply to the <date> usage:
>        a) A provider is permitted to use any <date> within its domain
> name ownership time period.
>        b) If the <date> is absent, it defaults to 2013-01-01.
>        c) If <DD> or <MM> are absent each defaults to 01.
>        d)  If <CC> is absent it defaults to 20.
>        e)  Comparison is based on the full <CCYY-MM-DD> after defaults
> have been filled in.
>        f)   A provider is allowed to use a domain name without a date
> if he owns the domain at the default year 2013 or if he is able to
> verify that he is the first owner of the domain, e.g. by checking
> reliable domain history tools.   Note: We assume that the domain
> ownership does not change during the same year.
>=20
>=20
> Thank you
> Laura
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud

From pkyzivat@alum.mit.edu  Wed Feb 13 10:03:42 2013
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 3825C21F8589 for <salud@ietfa.amsl.com>; Wed, 13 Feb 2013 10:03:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.796
X-Spam-Level: 
X-Spam-Status: No, score=0.796 tagged_above=-999 required=5 tests=[AWL=-1.067,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  MANGLED_TOOL=2.3, 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 I0Zma3rdvk34 for <salud@ietfa.amsl.com>; Wed, 13 Feb 2013 10:03:41 -0800 (PST)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 244D021F8501 for <salud@ietf.org>; Wed, 13 Feb 2013 10:03:37 -0800 (PST)
Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta13.westchester.pa.mail.comcast.net with comcast id zo5P1k0011swQuc5Du3diX; Wed, 13 Feb 2013 18:03:37 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id zu3d1k00S3ZTu2S3bu3doB; Wed, 13 Feb 2013 18:03:37 +0000
Message-ID: <511BD578.5090001@alum.mit.edu>
Date: Wed, 13 Feb 2013 13:03:36 -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: salud@ietf.org
References: <CACWXZj2WhAsmQ3Ku7bVpiNhbFxX7-vx9d9wWzzKgiVLSeKk__g@mail.gmail.com>
In-Reply-To: <CACWXZj2WhAsmQ3Ku7bVpiNhbFxX7-vx9d9wWzzKgiVLSeKk__g@mail.gmail.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=1360778617; bh=ontV9kPqwOwR0qzKX70ckcelGWwAa47kpye0k3vxm04=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fhh8FM1xRHuPx0BlHwb3yqAyZffcRPSNnRweO9BXNr4ueiu5+ZtC20trs7kvYVtK5 zvK6borK59Gqux3smpEtDUVVV4mjqYK+l21zmiqNsdSR7q1WrLfVCNZ4c6hKf1Gd2E EGNCrKuRt8hwqwQDgH2OwQTBejuDxvRxAujWNSh32qPVfwxwXsuJju3ECDeW5O8pHC +GLaVhEtEKwgUKJYdmgBDSmYjalnC3d/gnIhu3ePlKeGaCN2AAEQna23VuzXnboObc fRR6gBTuFdvc39N2e6aQqyG5AyQ1/NxwkkiyAcj2Mhbw8AnnbpzRTURgwH3+EBDr/p BQIn9EoTSYF3Q==
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: Wed, 13 Feb 2013 18:03:42 -0000

On 2/13/13 9:46 AM, Laura Liess wrote:
> Hi,
>
> Because we had several changes and discussions which affect the
> syntax,  I send a new version to the list, including the rules for
> <date>.  I used the <provider-id>,  <MM> and <DD> definitions from the
> RFC 4198.
> Please let me know what you think of it.
>
>         alert-URN         = "urn:alert:" alert-identifier
>         alert-identifier    = alert-category ":" alert-indication
>         alert-category    = name/private-name
>         alert-indication   = alert-name *(":" alert-name)
>         alert-name         = name/private-name
>         name                = label

Since private-name is now allowed as a category as well as an 
alert-name, the above can be simplified further:

        alert-URN         = "urn:alert:" alert-identifier
        alert-identifier  = alert-category ":" alert-indication
        alert-category    = alert-name
        alert-indication  = alert-name *(":" alert-name)
        alert-name        = label/private-name

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

Definition of toplabel is missing.

>         date                  = [CC] YY ["-" MM ["-" DD] ]
>         label                  = let-dig [ *let-dig-hyp let-dig ]
>         let-dig-hyp          = let-dig / "-"
>         let-dig                = ALPHA / DIGIT
>         YY                    = CC
>         CC                    = DIGIT DIGIT
>        MM                    = ("0" %x31-39) / ("1" %x30-32)
>        DD                     = ("0" %x31-39) / (%x31-32 DIGIT) / "30" / "31"
>        ALPHA               = %x41-5A / %x61-7A   ; A-Z / a-z
>        DIGIT                  = %x30-39 ; 0-9
>        DIGIT-1-9             = %x31-39 ; 1-9
>        DIGIT-2-9             = %x32-39 ; 2-9
>
>      Following rules apply to the <date> usage:
>         a) A provider is permitted to use any <date> within its domain
> name ownership time period.
>         b) If the <date> is absent, it defaults to 2013-01-01.
>         c) If <DD> or <MM> are absent each defaults to 01.
>         d)  If <CC> is absent it defaults to 20.
>         e)  Comparison is based on the full <CCYY-MM-DD> after defaults
> have been filled in.
>         f)   A provider is allowed to use a domain name without a date
> if he owns the domain at the default year 2013 or if he is able to
> verify that he is the first owner of the domain, e.g. by checking
> reliable domain history tools.   Note: We assume that the domain
> ownership does not change during the same year.

I'd like to propose a major change to (f):

"The meaning of a private-name with a particular domain name and date is 
specified by the owner of the domain at that date. The first owner of a 
domain may specify the meaning of private-names with dates prior to 
first ownership. As a consequence, the first owner of a domain may 
specify the meaning of a private-name that contains no date."

(My point is that anybody can *use* a private name with any date they 
want. The only issue is what (if anything) it *means*. Since there is no 
registration for private-names, we can just talk about it in a general way.)

I'm not entirely satisfied with the above. A private-name out of context 
doesn't really have a meaning. It is the whole alert-identifier that has 
a meaning. But I don't know how to say this in a comprehensible way.

	Thanks,
	Paul


From worley@shell01.TheWorld.com  Wed Feb 13 11:57:13 2013
Return-Path: <worley@shell01.TheWorld.com>
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 D974921E8051 for <salud@ietfa.amsl.com>; Wed, 13 Feb 2013 11:57:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.727
X-Spam-Level: 
X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=0.253,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 grpm8lJ0CSFY for <salud@ietfa.amsl.com>; Wed, 13 Feb 2013 11:57:13 -0800 (PST)
Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 4B22021E8037 for <salud@ietf.org>; Wed, 13 Feb 2013 11:57:07 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1DJuvL4004994; Wed, 13 Feb 2013 14:56:59 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1DJuuEB1794289; Wed, 13 Feb 2013 14:56:56 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1DJusJI1795782; Wed, 13 Feb 2013 14:56:54 -0500 (EST)
Date: Wed, 13 Feb 2013 14:56:54 -0500 (EST)
Message-Id: <201302131956.r1DJusJI1795782@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
In-reply-to: <EDC0A1AE77C57744B664A310A0B23AE2106FF5D58F@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> (keith.drage@alcatel-lucent.com)
References: <CACWXZj2WhAsmQ3Ku7bVpiNhbFxX7-vx9d9wWzzKgiVLSeKk__g@mail.gmail.com> <EDC0A1AE77C57744B664A310A0B23AE2106FF5D58F@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
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: Wed, 13 Feb 2013 19:57:14 -0000

> From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
> 
> Not clear from this extract what associated normative references you have. 

Yeah, we need to put in a reference to RFC 3339 in somewhere.  But for
discussion purposes, you can safely assume that's what we mean.

Dale


From worley@shell01.TheWorld.com  Wed Feb 13 13:06:08 2013
Return-Path: <worley@shell01.TheWorld.com>
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 8F36E21F8777 for <salud@ietfa.amsl.com>; Wed, 13 Feb 2013 13:06:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.587
X-Spam-Level: 
X-Spam-Status: No, score=-1.587 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 s1QF3PFoOxIT for <salud@ietfa.amsl.com>; Wed, 13 Feb 2013 13:06:06 -0800 (PST)
Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id CE03121F8770 for <salud@ietf.org>; Wed, 13 Feb 2013 13:06:05 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1DL5Ena019573 for <salud@ietf.org>; Wed, 13 Feb 2013 16:05:16 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1DL5Ept1790455 for <salud@ietf.org>; Wed, 13 Feb 2013 16:05:14 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1DL5BM01801234; Wed, 13 Feb 2013 16:05:11 -0500 (EST)
Date: Wed, 13 Feb 2013 16:05:11 -0500 (EST)
Message-Id: <201302132105.r1DL5BM01801234@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
In-reply-to: <CACWXZj2WhAsmQ3Ku7bVpiNhbFxX7-vx9d9wWzzKgiVLSeKk__g@mail.gmail.com> (laura.liess.dt@googlemail.com)
References: <CACWXZj2WhAsmQ3Ku7bVpiNhbFxX7-vx9d9wWzzKgiVLSeKk__g@mail.gmail.com>
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: Wed, 13 Feb 2013 21:06:08 -0000

(as an individual)

OK, we can see that this is going well because the ABNF is quite
simple and clear.  I've made the following adjustments in the version
below:

- aligned the columns and normalized the spacing between elements
- put blank lines to break the rules in to sections, and reordered the rules
- applied Paul's simplification
- changed the rule "YY=CC" to "YY=DIGIT DIGIT", because YY is
    semantically different from CC
- removed DIGIT-1-9 and DIGIT-2-9, because they are not used
- added a rule for "toplabel"
- broken private-name into two parts, because one of the rules needs
  to refer to the provider-id-and-date part

      alert-URN         = "urn:alert:" alert-identifier
      alert-identifier  = alert-category ":" alert-indication
      alert-category    = alert-name
      alert-indication  = alert-name *(":" alert-name)
      alert-name        = label / private-name
      name              = label
      private-name      = label "@" provider
      provider          = provider-id ["(" date ")"]
      provider-id       = 1*(label ".") toplabel
[I'm not sure I like the names of the two preceding rules.]

      toplabel          = ALPHA [ *let-dig-hyp let-dig ]
      label             = let-dig [ *let-dig-hyp let-dig ]
      let-dig-hyp       = let-dig / "-"
      let-dig           = ALPHA / DIGIT

      date              = [CC] YY [ "-" MM ["-" DD] ]
      CC                = DIGIT DIGIT
      YY                = DIGIT DIGIT
      MM                = ( "0" %x31-39 ) / ( "1" %x30-32 )
      DD                = ( "0" %x31-39 ) / ( %x31-32 DIGIT ) / "30" / "31"
      ALPHA             = %x41-5A / %x61-7A   ; A-Z / a-z
      DIGIT             = %x30-39 ; 0-9

I want to make two modifications so that the ABNF symbols can be used
to describe the semantics more easily:

1. I want to have a symbol that refers to the component of the URN that
can be removed during the resolution algorithm.  Currently, alert-name
is used for both alert-category and as a component of
alert-indication.

2. I want to have a syntactic distinction between alert-names which have
standard meanings and alert-names which are privately defined.

However, both of these changes are messy and unclear when written in
ABNF.  So I will see if I can use semantic specifications to achieve
the same result.

The semantic rules are:

1) provider-id:  This is intended to match the allowed ABNF for domain
names.  (What is the correct normative reference?  With
internationalization, is our syntax still correct?)

2) date:  <date> syntax is a subset of ??? in RFC 3339.

2a) If <date> is absent from <private-name>, it defaults to 2013-01-01.
2b) If <DD> or <MM> are absent, each defaults to 01.
2c) If <CC> is absent, it defaults to 20.

In all situations, including comparison of URNs and determining which
entity defines the meanings of <alert-name>s, <provider>s are
interpreted as if they contain <date> values with a full "CCYY-MM-DD"
value, which is determined according to the above rules.

3) Comparison of URNs:

   Comparison is case-insensitive, considering the URNs as character
   strings (but with respect to rule (2)).

4) Removing components when interpreting URNs:
   (section 8.1 step (b))

   The <alert-name>s of the URN are removed sequentially from back to
   front, until the first <alert-name> in the <alert-indication> is
   removed, at which point the URN is discarded from consideration.

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.

Dale

From pkyzivat@alum.mit.edu  Wed Feb 13 19:24:04 2013
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 E0A6121E80D4 for <salud@ietfa.amsl.com>; Wed, 13 Feb 2013 19:24:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.832
X-Spam-Level: 
X-Spam-Status: No, score=0.832 tagged_above=-999 required=5 tests=[AWL=-1.031,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  MANGLED_TOOL=2.3, 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 1C-YBgn8Xsjp for <salud@ietfa.amsl.com>; Wed, 13 Feb 2013 19:24:04 -0800 (PST)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id F008621E80D3 for <salud@ietf.org>; Wed, 13 Feb 2013 19:24:00 -0800 (PST)
Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta13.westchester.pa.mail.comcast.net with comcast id 02x51l0010Fqzac5D3Q0fK; Thu, 14 Feb 2013 03:24:00 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id 03Q01l0083ZTu2S3U3Q0pP; Thu, 14 Feb 2013 03:24:00 +0000
Message-ID: <511C58CF.80600@alum.mit.edu>
Date: Wed, 13 Feb 2013 22:23:59 -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: salud@ietf.org
References: <CACWXZj2WhAsmQ3Ku7bVpiNhbFxX7-vx9d9wWzzKgiVLSeKk__g@mail.gmail.com> <201302132105.r1DL5BM01801234@shell01.TheWorld.com>
In-Reply-To: <201302132105.r1DL5BM01801234@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=1360812240; bh=7HF4Hq0VgWMkNRVfh69uOSgOtZ+ugRB7QpcPEOAAiGE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QQWG2+z/UpqXrsHcEU1kYSTrLRY6JvSIOUoYbnpnV33eML5T7B6EGc0DWqW651OVe gHyZTOO/fzLh6q1J8IC8XMvHXrb6+SLWRN8FgPmLnoT4ieCb794UIcFTkQJdCIwlqe FrF3v6aMJJm5J5f/ssWomja1l/OtIhh3lpqN9V6rPO+aj8NeD3SxtE4mgKUg4/o/3b xF7RYkETY5axuG18WkLYaqSSbaxfOGk0rbVAzOmtunNdUZU9T8Rytg2tsZgh743toQ DeLmoOcR2WB1vcOEdmmO7uxeERmdJhmqO849i55JvCuvQl7YArdlnGX4Sds1/I9Tem Lp99qv+Hjas6A==
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: Thu, 14 Feb 2013 03:24:05 -0000

Thanks Dale! That cleans things up well, and resolves the problem I had.

One thing: the rule defining 'name' is never used, so it can be omitted.

	Thanks,
	Paul

On 2/13/13 4:05 PM, Dale R. Worley wrote:
> (as an individual)
>
> OK, we can see that this is going well because the ABNF is quite
> simple and clear.  I've made the following adjustments in the version
> below:
>
> - aligned the columns and normalized the spacing between elements
> - put blank lines to break the rules in to sections, and reordered the rules
> - applied Paul's simplification
> - changed the rule "YY=CC" to "YY=DIGIT DIGIT", because YY is
>      semantically different from CC
> - removed DIGIT-1-9 and DIGIT-2-9, because they are not used
> - added a rule for "toplabel"
> - broken private-name into two parts, because one of the rules needs
>    to refer to the provider-id-and-date part
>
>        alert-URN         = "urn:alert:" alert-identifier
>        alert-identifier  = alert-category ":" alert-indication
>        alert-category    = alert-name
>        alert-indication  = alert-name *(":" alert-name)
>        alert-name        = label / private-name
>        name              = label
>        private-name      = label "@" provider
>        provider          = provider-id ["(" date ")"]
>        provider-id       = 1*(label ".") toplabel
> [I'm not sure I like the names of the two preceding rules.]
>
>        toplabel          = ALPHA [ *let-dig-hyp let-dig ]
>        label             = let-dig [ *let-dig-hyp let-dig ]
>        let-dig-hyp       = let-dig / "-"
>        let-dig           = ALPHA / DIGIT
>
>        date              = [CC] YY [ "-" MM ["-" DD] ]
>        CC                = DIGIT DIGIT
>        YY                = DIGIT DIGIT
>        MM                = ( "0" %x31-39 ) / ( "1" %x30-32 )
>        DD                = ( "0" %x31-39 ) / ( %x31-32 DIGIT ) / "30" / "31"
>        ALPHA             = %x41-5A / %x61-7A   ; A-Z / a-z
>        DIGIT             = %x30-39 ; 0-9
>
> I want to make two modifications so that the ABNF symbols can be used
> to describe the semantics more easily:
>
> 1. I want to have a symbol that refers to the component of the URN that
> can be removed during the resolution algorithm.  Currently, alert-name
> is used for both alert-category and as a component of
> alert-indication.
>
> 2. I want to have a syntactic distinction between alert-names which have
> standard meanings and alert-names which are privately defined.
>
> However, both of these changes are messy and unclear when written in
> ABNF.  So I will see if I can use semantic specifications to achieve
> the same result.
>
> The semantic rules are:
>
> 1) provider-id:  This is intended to match the allowed ABNF for domain
> names.  (What is the correct normative reference?  With
> internationalization, is our syntax still correct?)
>
> 2) date:  <date> syntax is a subset of ??? in RFC 3339.
>
> 2a) If <date> is absent from <private-name>, it defaults to 2013-01-01.
> 2b) If <DD> or <MM> are absent, each defaults to 01.
> 2c) If <CC> is absent, it defaults to 20.
>
> In all situations, including comparison of URNs and determining which
> entity defines the meanings of <alert-name>s, <provider>s are
> interpreted as if they contain <date> values with a full "CCYY-MM-DD"
> value, which is determined according to the above rules.
>
> 3) Comparison of URNs:
>
>     Comparison is case-insensitive, considering the URNs as character
>     strings (but with respect to rule (2)).
>
> 4) Removing components when interpreting URNs:
>     (section 8.1 step (b))
>
>     The <alert-name>s of the URN are removed sequentially from back to
>     front, until the first <alert-name> in the <alert-indication> is
>     removed, at which point the URN is discarded from consideration.
>
> 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.
>
> Dale
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>


From worley@shell01.TheWorld.com  Thu Feb 14 11:54:13 2013
Return-Path: <worley@shell01.TheWorld.com>
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 601A121F88F5 for <salud@ietfa.amsl.com>; Thu, 14 Feb 2013 11:54:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level: 
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 IDIFuCnAmbgb for <salud@ietfa.amsl.com>; Thu, 14 Feb 2013 11:54:12 -0800 (PST)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id D0E3721F88F0 for <salud@ietf.org>; Thu, 14 Feb 2013 11:54:11 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1EJrmnQ012967 for <salud@ietf.org>; Thu, 14 Feb 2013 14:53:50 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1EJrmGu1848884 for <salud@ietf.org>; Thu, 14 Feb 2013 14:53:48 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1EJrmIw1849222; Thu, 14 Feb 2013 14:53:48 -0500 (EST)
Date: Thu, 14 Feb 2013 14:53:48 -0500 (EST)
Message-Id: <201302141953.r1EJrmIw1849222@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
In-reply-to: <CACWXZj0vqAyX4LvsBuhKzSmMNCMTfMEi0Upo29eYS6W6CiFEYw@mail.gmail.com> (laura.liess.dt@googlemail.com)
References: <CACWXZj0vqAyX4LvsBuhKzSmMNCMTfMEi0Upo29eYS6W6CiFEYw@mail.gmail.com>
Subject: [salud] Ticket issues
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: Thu, 14 Feb 2013 19:54:13 -0000

(as an individual)

I think everyone who cares is in agreement with your proposed
solutions to issue #1 (versioning and dates) and issue #2 (order of
labels in domain names).

The latest BNF proposals all agree on #3 (syntax connecting the first
private label is to the FQDN) as well.

Regarding issue #4, the latest BNF proposals allow <private-name>s to
be used as <alert-categories>.  I support this (to allow private
alert-categories to be defined).  Do other people agree with this?

Regarding issue #5, the BNF proposals allow multiple <private-name>s
in a URN, and I believe people generally agree with this.

We're doing well here, as I think we have general agreement on all the
open issues.

Dale

From worley@shell01.TheWorld.com  Thu Feb 14 11:55:18 2013
Return-Path: <worley@shell01.TheWorld.com>
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 1CB1E21F895B for <salud@ietfa.amsl.com>; Thu, 14 Feb 2013 11:55:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.675
X-Spam-Level: 
X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=-0.655, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 FOqiSKZt2vSb for <salud@ietfa.amsl.com>; Thu, 14 Feb 2013 11:55:16 -0800 (PST)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9BC21F8953 for <salud@ietf.org>; Thu, 14 Feb 2013 11:55:16 -0800 (PST)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1EJswox015611 for <salud@ietf.org>; Thu, 14 Feb 2013 14:55:00 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1EJsw1i1846357 for <salud@ietf.org>; Thu, 14 Feb 2013 14:54:58 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1EJswWa1845811; Thu, 14 Feb 2013 14:54:58 -0500 (EST)
Date: Thu, 14 Feb 2013 14:54:58 -0500 (EST)
Message-Id: <201302141954.r1EJswWa1845811@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
Subject: [salud] Definition of "first owner"
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: Thu, 14 Feb 2013 19:55:18 -0000

(as an individual)

In a previous message:

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

Should we change "first registrant" to "first registered owner on or
after 2013-01-01"?

For example:  Company X registers example.com from 2010-01-01 to
2011-12-31, and then allows the registration to lapse.  Company Y then
registers example.com from 2014-01-01 onward.  Under the rule in the
previous message, Company Y has to use "example.com(14)" as a
<provider>.  But I think it would be sensible to allow Company Y to
use "example.com" as well, because nobody owned "example.com" from
2013-01-01 to 2013-12-31.  (Company X can still use
"example.com(10)"!)

Dale

From worley@shell01.TheWorld.com  Thu Feb 14 11:56:03 2013
Return-Path: <worley@shell01.TheWorld.com>
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 6B03E21F8958 for <salud@ietfa.amsl.com>; Thu, 14 Feb 2013 11:56:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.653
X-Spam-Level: 
X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 6VvNAeYwerns for <salud@ietfa.amsl.com>; Thu, 14 Feb 2013 11:56:03 -0800 (PST)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id BF35821F84C7 for <salud@ietf.org>; Thu, 14 Feb 2013 11:56:02 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1EJsgfh000325 for <salud@ietf.org>; Thu, 14 Feb 2013 14:54:44 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1EJsfaE1851109 for <salud@ietf.org>; Thu, 14 Feb 2013 14:54:42 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1EJsfND1825792; Thu, 14 Feb 2013 14:54:41 -0500 (EST)
Date: Thu, 14 Feb 2013 14:54:41 -0500 (EST)
Message-Id: <201302141954.r1EJsfND1825792@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
In-reply-to: <51071AB2.6050204@alum.mit.edu> (pkyzivat@alum.mit.edu)
References: <CACWXZj2KuWjxRj0nmJVR0R3Q9URtV=pMLEkqS6SoZ0VXd7uBxQ@mail.gmail.com> <50EF163C.5020103@alum.mit.edu> <CACWXZj2vTKcrAzcoMJg8ffzWYZUr70XrEqtgSh=8vuGfyqwZ5g@mail.gmail.com> <50F041B3.2080004@alum.mit.edu> <CACWXZj1rqyUp_Re643SJ92kB-EJBJioH18fvFnB0kNFFhLfhCw@mail.gmail.com> <201301150309.r0F39ohG5179371@shell01.TheWorld.com> <50F58261.9050302@alum.mit.edu> <201301252234.r0PMYc3m523413@shell01.TheWorld.com> <51068A4F.1040801@alum.mit.edu> <201301282213.r0SMDr4d741030@shell01.TheWorld.com> <51071AB2.6050204@alum.mit.edu>
Subject: Re: [salud] <private-name> format
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: Thu, 14 Feb 2013 19:56:03 -0000

(as an individual)

> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
> 
> In fact, I could assign the same alert to a *range* of dates. And if I 
> *choose* to assign the same alert without regard to the date part of the 
> label, that is also my right. This is *policy*, so I can do as I wish.
> 
> And if somebody built an implementation that supported such policies, so 
> much the better.

In my latest proposal, I included a rule that an organization SHOULD
use only one date (actually, only one <provider>) for its
<private-name>s, to increase the consistency of URNs.  That would
discourage using ranges of dates in the way you're describing.

What do people think of that?

Dale

From worley@shell01.TheWorld.com  Thu Feb 14 13:04:20 2013
Return-Path: <worley@shell01.TheWorld.com>
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 2660821F8A8E for <salud@ietfa.amsl.com>; Thu, 14 Feb 2013 13:04:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.332
X-Spam-Level: 
X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[AWL=-0.912, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 XB7N8szUPRJL for <salud@ietfa.amsl.com>; Thu, 14 Feb 2013 13:04:19 -0800 (PST)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1F68621F87F6 for <salud@ietf.org>; Thu, 14 Feb 2013 13:04:18 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1EL4B4i025555 for <salud@ietf.org>; Thu, 14 Feb 2013 16:04:13 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1EL4BS01848863 for <salud@ietf.org>; Thu, 14 Feb 2013 16:04:11 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1EL4Ae61853571; Thu, 14 Feb 2013 16:04:10 -0500 (EST)
Date: Thu, 14 Feb 2013 16:04:10 -0500 (EST)
Message-Id: <201302142104.r1EL4Ae61853571@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
Subject: [salud] Default alert-indications for each alert-category
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: Thu, 14 Feb 2013 21:04:20 -0000

(as an individual)

There are a number of URNs that we have defined which specify the
ordinary or default alternative of an alert-category.  The examples I
find are:

    urn:alert:service:normal
    urn:alert:source:unclassified
    urn:alert:priority:normal
    urn:alert:priority:normal
    urn:alert:duration:normal
    urn:alert:delay:none
    urn:alert:locale:default

For example, for urn:alert:service, there are these choices:

   - normal
   - call-waiting
   - forward
   - recall:callback
   - recall:hold
   - recall:transfer

(I do not list <private-name>, because all categories include private
names, and we have specified how <private-name>s are to be handled in
various situations.)

I expect that the effect of <urn:alert:service:normal> is the same as
having no urn:alert:service:* URN.

The question I am discussing here is whether this is somehow an
"incorrect" way to organize the URNs, whether we should remove the
definition of these "ordinary" URNs, because they do not specify any
particular information about the call, so if the user does not want to
specify a "service" classification, they should omit any such URN.

One argument in favor of keeping these URNs is that they correspond
well to how people think about choices like this; people tend to think
of any choice as having a specific choice which is also a default, and
that specifying no choice is the same as specifying the default.

The big question:  How does having a default alternative interact with
the rules and algorithms for rendering signals?

In regard to the rules of section 8.1, I do not see any difficulty, as
the UA is given great freedom to determine which signals are indicated
by which combinations of URNs.

In regard to the non-normative algorithm of section 9, I believe that
the proper handling is this:

Let us assume that there is one signal for the default service:
NORMAL.  There are also signals for all the non-default services:
CALL-WAITING, FORWARD, RECALL-CALLBACK, RECALL-HOLD, and
RECALL-TRANSFER.

There is a tree for the category "service", and we place each signal
in the proper place to show its meaning and correspondence with URNs:

    service----+----normal
    NORMAL     |
               |
               +----call-waiting
               |    CALL-WAITING
               |
               +----forward
               |    FORWARD
               |
               +----recall----+----callback
	                      |    RECALL-CALLBACK
	                      |
	                      +----hold
	                      |    RECALL-HOLD
	                      |
	                      +----transfer
                                   RECALL-TRANSFER

The reason that NORMAL is placed at the root of the "service" tree is
that NORMAL isn't specific, you can render NORMAL even when there is
no urn:alert:service:* URN.  All of the other signals are selected
only when there is a URN specifically for their category.

The result of this assignment is if no service URN is present, NORMAL
is selected in preference to the other signals because it is "less
specific" than the others.  However, if one of the other service URNs
is present, then its signal is sorted before NORMAL, and it will be
selected in preference to NORMAL.

OK, now that I look for it, the example in section 9.2.5 shows exactly
this construction.

This discussion convinces me that there is no difficulty with the
rules and algorithms if we define the "default" URNs.  (Using the
algorithm in section 9 requires properly setting up the signals, but
we have given the users an example of that.)  And I believe that it is
psychologically nicer to provide a way of specifying the default
condition.

Do other people agree?

Dale

From worley@shell01.TheWorld.com  Thu Feb 14 13:06:04 2013
Return-Path: <worley@shell01.TheWorld.com>
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 B133721F8B62 for <salud@ietfa.amsl.com>; Thu, 14 Feb 2013 13:06:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.604
X-Spam-Level: 
X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 qcC5irbDmtcF for <salud@ietfa.amsl.com>; Thu, 14 Feb 2013 13:06:03 -0800 (PST)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFA821F89DC for <salud@ietf.org>; Thu, 14 Feb 2013 13:06:03 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1EL4Vk3014082 for <salud@ietf.org>; Thu, 14 Feb 2013 16:04:33 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1EL4VIs1837691 for <salud@ietf.org>; Thu, 14 Feb 2013 16:04:31 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1EL4VkX1850810; Thu, 14 Feb 2013 16:04:31 -0500 (EST)
Date: Thu, 14 Feb 2013 16:04:31 -0500 (EST)
Message-Id: <201302142104.r1EL4VkX1850810@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
Subject: [salud] The consequences of alert-indications with two labels
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: Thu, 14 Feb 2013 21:06:04 -0000

(as an individual)

There are a two standard alert-categories which have alert-indications
that consist of two labels.  The examples I find are:

    urn:alert:service:recall:*
    urn:alert:locale:country:*

(I do not list <private-name>, because all categories include private
names, and we have specified how <private-name>s are to be handled in
various situations.)

This allows us to construct the syntactically correct but undefined
URNs:

    urn:alert:service:recall
    urn:alert:locale:country

The question I am discussing here is whether there will be a problem
if a UA specifies one of these URNs -- Will this prevent the receiving
UA from making sensible renderings?

In regard to the rules of section 8.1, I do not see any difficulty.
The interpreting UA will not recognize the URN, and will attempt to
remove the final label.  That eliminates the alert-indication
entirely, and the URN will be discarded from interpretation.

In regard to the non-normative algorithm of section 9, let us take
<urn:alert:locale:country> as an example:  This URN specifies the
"country" node in the "locale" tree, which is a child of the root
node.  We assume that there are no signals that are positioned at that
node, although locale-specific signals are positioned at child nodes
of the "country" node, and all other signals are positioned at the
root node:

                    urn:alert:locale:country
                       |
                       V
    locale-----+----country----+----ad      	  
    DEFAULT     	       |    RING-ANDORRA   
    PRIORITY-HIGH	       |			  
    CALL-WAITING               +----de    
    ...                        |    RING-GERMANY
                	       |			  
                               +----us
                                    RING-US
	                  
Then the processing of <urn:alert:locale:country> would cause all
signals to be eliminated from the set of signals that are considered
for rending if they are not positioned at the root node of "locale".
This is the same effect as would happen from a URN for an unknown
locale, such as <urn:alert:locale:country:es>.

This discussion convinces me that there is no difficulty with the
rules and algorithms if we define two-label alert-indications, and
thus make it possible to construct URNs that have no meaning.

Do other people agree?

Dale

From pkyzivat@alum.mit.edu  Thu Feb 14 14:41:19 2013
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 0CCB721F8621 for <salud@ietfa.amsl.com>; Thu, 14 Feb 2013 14:41:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.298
X-Spam-Level: 
X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[AWL=0.139,  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 kCUXvCRTl91D for <salud@ietfa.amsl.com>; Thu, 14 Feb 2013 14:41:18 -0800 (PST)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7A521F862B for <salud@ietf.org>; Thu, 14 Feb 2013 14:41:18 -0800 (PST)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta12.westchester.pa.mail.comcast.net with comcast id 0L921l0050QuhwU5CNhHfk; Thu, 14 Feb 2013 22:41:17 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id 0NhH1l0043ZTu2S3NNhHsK; Thu, 14 Feb 2013 22:41:17 +0000
Message-ID: <511D680D.5080507@alum.mit.edu>
Date: Thu, 14 Feb 2013 17:41:17 -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: salud@ietf.org
References: <CACWXZj2KuWjxRj0nmJVR0R3Q9URtV=pMLEkqS6SoZ0VXd7uBxQ@mail.gmail.com> <50EF163C.5020103@alum.mit.edu> <CACWXZj2vTKcrAzcoMJg8ffzWYZUr70XrEqtgSh=8vuGfyqwZ5g@mail.gmail.com> <50F041B3.2080004@alum.mit.edu> <CACWXZj1rqyUp_Re643SJ92kB-EJBJioH18fvFnB0kNFFhLfhCw@mail.gmail.com> <201301150309.r0F39ohG5179371@shell01.TheWorld.com> <50F58261.9050302@alum.mit.edu> <201301252234.r0PMYc3m523413@shell01.TheWorld.com> <51068A4F.1040801@alum.mit.edu> <201301282213.r0SMDr4d741030@shell01.TheWorld.com> <51071AB2.6050204@alum.mit.edu> <201302141954.r1EJsfND1825792@shell01.TheWorld.com>
In-Reply-To: <201302141954.r1EJsfND1825792@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=1360881677; bh=2fXoLl/VBMGBNvEsyQhhNXK5sOjfde5Y83M6pOlAH1o=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=E/AdKTCUWPz7IO81SBF9aMA7vpsg5sI+ZmIbFyZmhq7MdGBoI/uTHOFd9jxuHbXo7 alRhQa+5GxO6SFsva0eBFcMW0oLoZNwYqrpQXsUuVhOIM38ByzOJKbidEbuBmlLU1r OLXEHAp3/2GFbva7+Z8zwJSahAWX/RZ8o2HXkHgDk+RW11D6o0lqvTjL+dJ5vB1L4X 7gBQjHslp08Q1TGeWy6RS1vazsO0rNz5YHtJU5RcuKN5qW5PVQ9Y7nbwSTFfQSmTfP 0CB89KrU5PMCxAlqOW0jalS4OTNdATPM4Xl1mUsL+kdfAVI3uUJXbq++0C//S+Vm+U IPBw8aWLOV/Fw==
Subject: Re: [salud] <private-name> format
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: Thu, 14 Feb 2013 22:41:19 -0000

On 2/14/13 2:54 PM, Dale R. Worley wrote:
> (as an individual)
>
>> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
>>
>> In fact, I could assign the same alert to a *range* of dates. And if I
>> *choose* to assign the same alert without regard to the date part of the
>> label, that is also my right. This is *policy*, so I can do as I wish.
>>
>> And if somebody built an implementation that supported such policies, so
>> much the better.
>
> In my latest proposal, I included a rule that an organization SHOULD
> use only one date (actually, only one <provider>) for its
> <private-name>s, to increase the consistency of URNs.  That would
> discourage using ranges of dates in the way you're describing.

I'm ok with SHOULD.

	Thanks,
	Paul

From pkyzivat@alum.mit.edu  Thu Feb 14 14:48:07 2013
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 2414B21F8E79 for <salud@ietfa.amsl.com>; Thu, 14 Feb 2013 14:48:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.303
X-Spam-Level: 
X-Spam-Status: No, score=-0.303 tagged_above=-999 required=5 tests=[AWL=0.134,  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 Ik+tNX1+8gAY for <salud@ietfa.amsl.com>; Thu, 14 Feb 2013 14:48:06 -0800 (PST)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 8078021F8E18 for <salud@ietf.org>; Thu, 14 Feb 2013 14:48:06 -0800 (PST)
Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta15.westchester.pa.mail.comcast.net with comcast id 0DPq1l0021ei1Bg5FNo6LN; Thu, 14 Feb 2013 22:48:06 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id 0No51l0153ZTu2S3kNo52e; Thu, 14 Feb 2013 22:48:06 +0000
Message-ID: <511D69A5.5030307@alum.mit.edu>
Date: Thu, 14 Feb 2013 17:48:05 -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: salud@ietf.org
References: <201302141954.r1EJswWa1845811@shell01.TheWorld.com>
In-Reply-To: <201302141954.r1EJswWa1845811@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=1360882086; bh=BIdjh/ueLiZB7YEkwq8VriFE+YtxvbKXkGpKViVzBKY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=noT4dzjIpfX2yzhi66YlEtQLh33KHo4Ctu8ItajyOKoCNgiGIkMFOaChmQmlQTx7r jv9gUznNoYKgg6t9+XLxUf4LO3mVXN3zvNCHolDGWZpsHMYaYMwIlKs9BlcFhZwsRO il9kkQ2y9/K6OTDPFUhOD5fjIuK+ohRcwsK3FQIurXl5lknvz8geDah1pGd0+JJl0E NN3CdNYcVf1SEm8+dRz+q1rGZ+u+2XQWmrzTqUQVdV5nTTLbJ9tcT8wuZEqKbiBr0A rx0v7Y8XOJxAkGbtLugApx5kR4l7NRfhV6gqk+Af5WT32fQ9T0+6RkM+VTOfdGG96i sNAY6xRQZyZ2Q==
Subject: Re: [salud] Definition of "first owner"
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: Thu, 14 Feb 2013 22:48:07 -0000

On 2/14/13 2:54 PM, Dale R. Worley wrote:
> (as an individual)
>
> In a previous message:
>
>> 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.
>
> Should we change "first registrant" to "first registered owner on or
> after 2013-01-01"?
>
> For example:  Company X registers example.com from 2010-01-01 to
> 2011-12-31, and then allows the registration to lapse.  Company Y then
> registers example.com from 2014-01-01 onward.  Under the rule in the
> previous message, Company Y has to use "example.com(14)" as a
> <provider>.  But I think it would be sensible to allow Company Y to
> use "example.com" as well, because nobody owned "example.com" from
> 2013-01-01 to 2013-12-31.  (Company X can still use
> "example.com(10)"!)

I don't like the conclusion of that use case. IMO a use without a date 
should apply to Company X's definition, not company Y. Even though 
nobody could have minted an alert urn back in 2011, after the fact 
nobody will remember that date.

	Thanks,
	Paul


From pkyzivat@alum.mit.edu  Thu Feb 14 14:56:30 2013
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 1913121F86C8 for <salud@ietfa.amsl.com>; Thu, 14 Feb 2013 14:56:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.012
X-Spam-Level: 
X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_64=0.6, 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 Ayrtf+OMo1Bv for <salud@ietfa.amsl.com>; Thu, 14 Feb 2013 14:56:29 -0800 (PST)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 468C721F886B for <salud@ietf.org>; Thu, 14 Feb 2013 14:56:29 -0800 (PST)
Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id 0Bo41l0031ap0As53NwUpw; Thu, 14 Feb 2013 22:56:28 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id 0NwU1l00G3ZTu2S3iNwUlf; Thu, 14 Feb 2013 22:56:28 +0000
Message-ID: <511D6B9B.1020507@alum.mit.edu>
Date: Thu, 14 Feb 2013 17:56:27 -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: salud@ietf.org
References: <201302142104.r1EL4Ae61853571@shell01.TheWorld.com>
In-Reply-To: <201302142104.r1EL4Ae61853571@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=1360882588; bh=/QWdUzZbfrpGmgbkU2GgvyefyY3V9O/u3PcBygQPEXs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=V1709zyEgMoMlISIKhIHM7pFkieu5f/xvxvPCWkM8NUohybyl0TfoXkRmBlIeVm2a MXFnwb19cTA1+EktM8qLXqj/fcyUkcvnOehN0d9OgZjHHPWDRnlNtd+YA/dmuHNHkf 1hIL0Cd6jVBB8lJowp7b12n11uX6DgRD3M+oquHgCs+tdfJy57O9lFm0Y+Jbvh8AUG MywtTZwkwzL84uszONrcuE2mw/8b1ZCMK6x04f0nKl2mrem5JxTBxewrhazLiUyouK zWwgJBQxcjmVFC/Xptv2Zv+PuT2rDWBoWNK7qfzWaaFZOq7I1AfRg8u2w+DmdJdtkD 5ppFbI0Wiq/3Q==
Subject: Re: [salud] Default alert-indications for each alert-category
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: Thu, 14 Feb 2013 22:56:30 -0000

What you say here seems reasonable to me.

But a new issue is introduced by allowing private-names as categories.
Is there some similar sort of defaulting in that case? If so, now is it 
specified?

	Thanks,
	Paul

On 2/14/13 4:04 PM, Dale R. Worley wrote:
> (as an individual)
>
> There are a number of URNs that we have defined which specify the
> ordinary or default alternative of an alert-category.  The examples I
> find are:
>
>      urn:alert:service:normal
>      urn:alert:source:unclassified
>      urn:alert:priority:normal
>      urn:alert:priority:normal
>      urn:alert:duration:normal
>      urn:alert:delay:none
>      urn:alert:locale:default
>
> For example, for urn:alert:service, there are these choices:
>
>     - normal
>     - call-waiting
>     - forward
>     - recall:callback
>     - recall:hold
>     - recall:transfer
>
> (I do not list <private-name>, because all categories include private
> names, and we have specified how <private-name>s are to be handled in
> various situations.)
>
> I expect that the effect of <urn:alert:service:normal> is the same as
> having no urn:alert:service:* URN.
>
> The question I am discussing here is whether this is somehow an
> "incorrect" way to organize the URNs, whether we should remove the
> definition of these "ordinary" URNs, because they do not specify any
> particular information about the call, so if the user does not want to
> specify a "service" classification, they should omit any such URN.
>
> One argument in favor of keeping these URNs is that they correspond
> well to how people think about choices like this; people tend to think
> of any choice as having a specific choice which is also a default, and
> that specifying no choice is the same as specifying the default.
>
> The big question:  How does having a default alternative interact with
> the rules and algorithms for rendering signals?
>
> In regard to the rules of section 8.1, I do not see any difficulty, as
> the UA is given great freedom to determine which signals are indicated
> by which combinations of URNs.
>
> In regard to the non-normative algorithm of section 9, I believe that
> the proper handling is this:
>
> Let us assume that there is one signal for the default service:
> NORMAL.  There are also signals for all the non-default services:
> CALL-WAITING, FORWARD, RECALL-CALLBACK, RECALL-HOLD, and
> RECALL-TRANSFER.
>
> There is a tree for the category "service", and we place each signal
> in the proper place to show its meaning and correspondence with URNs:
>
>      service----+----normal
>      NORMAL     |
>                 |
>                 +----call-waiting
>                 |    CALL-WAITING
>                 |
>                 +----forward
>                 |    FORWARD
>                 |
>                 +----recall----+----callback
> 	                      |    RECALL-CALLBACK
> 	                      |
> 	                      +----hold
> 	                      |    RECALL-HOLD
> 	                      |
> 	                      +----transfer
>                                     RECALL-TRANSFER
>
> The reason that NORMAL is placed at the root of the "service" tree is
> that NORMAL isn't specific, you can render NORMAL even when there is
> no urn:alert:service:* URN.  All of the other signals are selected
> only when there is a URN specifically for their category.
>
> The result of this assignment is if no service URN is present, NORMAL
> is selected in preference to the other signals because it is "less
> specific" than the others.  However, if one of the other service URNs
> is present, then its signal is sorted before NORMAL, and it will be
> selected in preference to NORMAL.
>
> OK, now that I look for it, the example in section 9.2.5 shows exactly
> this construction.
>
> This discussion convinces me that there is no difficulty with the
> rules and algorithms if we define the "default" URNs.  (Using the
> algorithm in section 9 requires properly setting up the signals, but
> we have given the users an example of that.)  And I believe that it is
> psychologically nicer to provide a way of specifying the default
> condition.
>
> Do other people agree?
>
> Dale
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>


From laura.liess.dt@googlemail.com  Fri Feb 15 06:20:47 2013
Return-Path: <laura.liess.dt@googlemail.com>
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 B2BF221F867A for <salud@ietfa.amsl.com>; Fri, 15 Feb 2013 06:20:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.828
X-Spam-Level: 
X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 IqDG4h5VENz6 for <salud@ietfa.amsl.com>; Fri, 15 Feb 2013 06:20:47 -0800 (PST)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E3D0121F856F for <salud@ietf.org>; Fri, 15 Feb 2013 06:20:18 -0800 (PST)
Received: by mail-la0-f45.google.com with SMTP id er20so3428362lab.4 for <salud@ietf.org>; Fri, 15 Feb 2013 06:20:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=SCU99Hk7M4tCF8aTZA/Vd8+l7EJ3cZgCwGT36zA8zAk=; b=hEyNVKcT9xo83eoAqxdkJfxMXsTNRI+drIygdxNVUQgQIjkZRzOFcdi5ohcCPXvYNG 97CKPv5vXTjj96hzeK75dW9hpQ3/uxBWJIn7v5701VaJeUKkmUwxs1ji1OlZX5S2hpS7 Mgsc++1Effrq/XgwZWS+XEq+9aDmqwvCp15p00Uq0e+ZPeBmumG4wElfSNPgHsoNg97b wsVSmM8zYLg1SHdDRZgAU1KvvTzRM9pdmGPlkSReUaT3YLJofDS9Bgc+zE3cI35DMkkE lIKSj8KFBWg1S8KhzCZ3rXB9pzFpv07kDp1YOi9cbxQKAclxdUGOeMYctjrzHTJtXhlb ZX1w==
MIME-Version: 1.0
X-Received: by 10.152.147.36 with SMTP id th4mr2424378lab.19.1360938015322; Fri, 15 Feb 2013 06:20:15 -0800 (PST)
Received: by 10.114.95.99 with HTTP; Fri, 15 Feb 2013 06:20:15 -0800 (PST)
In-Reply-To: <201302141954.r1EJswWa1845811@shell01.TheWorld.com>
References: <201302141954.r1EJswWa1845811@shell01.TheWorld.com>
Date: Fri, 15 Feb 2013 15:20:15 +0100
Message-ID: <CACWXZj2k66pi1S__WqpzPEf-FYDTtndi9p+cTgNoSHV3QEXQWQ@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: salud@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [salud] Definition of "first owner"
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: Fri, 15 Feb 2013 14:20:47 -0000

Dale,

For me, this is quite confusing and may lead to failures when people
implement it. "Leaving out the date" is a a critical issue anyway and
I think if we want to get it approved by the URNBIS we should use it
only in cases where there is no room for confusion and have rules
which are clear and almost obvious.  I would not try to leave out the
date in cases like this.

Thank you
Laura









2013/2/14 Dale R. Worley <worley@ariadne.com>:
> (as an individual)
>
> In a previous message:
>
>> 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.
>
> Should we change "first registrant" to "first registered owner on or
> after 2013-01-01"?
>
> For example:  Company X registers example.com from 2010-01-01 to
> 2011-12-31, and then allows the registration to lapse.  Company Y then
> registers example.com from 2014-01-01 onward.  Under the rule in the
> previous message, Company Y has to use "example.com(14)" as a
> <provider>.  But I think it would be sensible to allow Company Y to
> use "example.com" as well, because nobody owned "example.com" from
> 2013-01-01 to 2013-12-31.  (Company X can still use
> "example.com(10)"!)
>
> Dale
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud

From worley@shell01.TheWorld.com  Fri Feb 15 13:27:15 2013
Return-Path: <worley@shell01.TheWorld.com>
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 8991321F869A for <salud@ietfa.amsl.com>; Fri, 15 Feb 2013 13:27:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.578
X-Spam-Level: 
X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.402,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 ja7oXP8LX1Ip for <salud@ietfa.amsl.com>; Fri, 15 Feb 2013 13:27:15 -0800 (PST)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id EDA9F21F8634 for <salud@ietf.org>; Fri, 15 Feb 2013 13:27:14 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1FLR5eg029126 for <salud@ietf.org>; Fri, 15 Feb 2013 16:27:07 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1FLR5BM1901046 for <salud@ietf.org>; Fri, 15 Feb 2013 16:27:05 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1FLR4qP1901298; Fri, 15 Feb 2013 16:27:04 -0500 (EST)
Date: Fri, 15 Feb 2013 16:27:04 -0500 (EST)
Message-Id: <201302152127.r1FLR4qP1901298@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
In-reply-to: <201302141954.r1EJswWa1845811@shell01.TheWorld.com> (worley@ariadne.com)
References: <201302141954.r1EJswWa1845811@shell01.TheWorld.com>
Subject: Re: [salud] Definition of "first owner"
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: Fri, 15 Feb 2013 21:27:15 -0000

(as an individual)

> From: worley@ariadne.com (Dale R. Worley)
> 
> In a previous message:
> 
> > 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.
> 
> Should we change "first registrant" to "first registered owner on or
> after 2013-01-01"?

Nobody else likes this idea, so let's not make this change.

Dale

From worley@shell01.TheWorld.com  Fri Feb 15 13:28:02 2013
Return-Path: <worley@shell01.TheWorld.com>
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 B701621F869A for <salud@ietfa.amsl.com>; Fri, 15 Feb 2013 13:28:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.390,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 Vc8WKJEHqbam for <salud@ietfa.amsl.com>; Fri, 15 Feb 2013 13:28:02 -0800 (PST)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 234E121F8634 for <salud@ietf.org>; Fri, 15 Feb 2013 13:28:02 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1FLRUog017179 for <salud@ietf.org>; Fri, 15 Feb 2013 16:27:33 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1FLRU5U1908064 for <salud@ietf.org>; Fri, 15 Feb 2013 16:27:30 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1FLRU961907973; Fri, 15 Feb 2013 16:27:30 -0500 (EST)
Date: Fri, 15 Feb 2013 16:27:30 -0500 (EST)
Message-Id: <201302152127.r1FLRU961907973@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
In-reply-to: <511D6B9B.1020507@alum.mit.edu> (pkyzivat@alum.mit.edu)
References: <201302142104.r1EL4Ae61853571@shell01.TheWorld.com> <511D6B9B.1020507@alum.mit.edu>
Subject: Re: [salud] Default alert-indications for each alert-category
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: Fri, 15 Feb 2013 21:28:02 -0000

(as an individual)

> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
> 
> But a new issue is introduced by allowing private-names as categories.
> Is there some similar sort of defaulting in that case? If so, now is it 
> specified?

As we have described things now, there is no guaranteed default for
alert-categories that are private-names.  No default default, as it
were.

But whoever defines such a category can define a label to be the
alert-indication that is the default value.  Of course, to obtain the
correct effect, the UA interpreting the URNs has to understand the
structure of the alert-category, and in particular, the meaning of
that alert-indication.

Hmmm...  I suppose one can always construct a URN whose
alert-indication is guaranteed to not be defined by the definer of the
private-name by using one's own private-name!  Example:  Assume that
example.com defines an alert-category foo@example.com, defining URNs
of this form:

    urn:alert:foo@example.com:...

I, the owner of example.net, can create this URN:

    urn:alert:foo@example.com:unknown@example.net

An interpreting UA will process that much like it will process
urn:alert:locale:country, because example.com never defined the
alert-indication unknown@example.net for the alert-category
foo@example.com.

I'm not sure there is any practical use for such a URN.  I suppose you
could add it to the beginning of the Alert-Info values to prevent any
later urn:alert:foo@example.com:* URNs from having any effect.  But it
would be simpler to remove any such URNs from the list of values.

Dale

From laura.liess.dt@googlemail.com  Mon Feb 18 06:24:48 2013
Return-Path: <laura.liess.dt@googlemail.com>
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 6EEC621F8946 for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 06:24:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.728
X-Spam-Level: 
X-Spam-Status: No, score=-0.728 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_TOOL=2.3, NO_RELAYS=-0.001]
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 XVNU20A-CgTB for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 06:24:47 -0800 (PST)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0D321F87DF for <salud@ietf.org>; Mon, 18 Feb 2013 06:24:41 -0800 (PST)
Received: by mail-la0-f46.google.com with SMTP id fq12so5539990lab.19 for <salud@ietf.org>; Mon, 18 Feb 2013 06:24:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5KEi28Yx1N0NBF38q6ffENeJ6yDcpNktJsRYDDJUXsE=; b=BfNZ3Wu8JLoqd9PmQa5U0rpvUhqHoTaaZ8vAME+iYWn1gBTbuYCHo7j+kOLLInEIwt z/jafml/XgOiI8YlXpIiCOGyxepX4VCRuwMkVeXxgQ00Ml6scROxuaVwoTUgLev/5Yp9 N3lVto0A2PCbhAAdvuto9iuhD69jAsiR9Jm/Syy/zZrAEMkAPluni+GJLyPMApSBwbac PCh6rccCY6cIt0lqzscfxxbos1shdGFESNk6Qv6ZO7g19En/prRdQtPE52b+blcgcpm0 oCXNIJS2DNxld4QM1nkX6vIodTBSei2k1+WHidrlcU0yNEJx2SLsS29C6Ti9aJTLMWs/ /sxw==
MIME-Version: 1.0
X-Received: by 10.112.25.194 with SMTP id e2mr5674634lbg.124.1361197480259; Mon, 18 Feb 2013 06:24:40 -0800 (PST)
Received: by 10.114.95.99 with HTTP; Mon, 18 Feb 2013 06:24:40 -0800 (PST)
In-Reply-To: <201302132105.r1DL5BM01801234@shell01.TheWorld.com>
References: <CACWXZj2WhAsmQ3Ku7bVpiNhbFxX7-vx9d9wWzzKgiVLSeKk__g@mail.gmail.com> <201302132105.r1DL5BM01801234@shell01.TheWorld.com>
Date: Mon, 18 Feb 2013 15:24:40 +0100
Message-ID: <CACWXZj0Qq=Q=7necdgCPLeFAMbr3gg-WmBb-8UzegseEd_b_Qw@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: "Dale R. Worley" <worley@ariadne.com>
Content-Type: text/plain; charset=ISO-8859-1
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 14:24:48 -0000

Dale,

Thank you for adding the rules. I like them :-). I have following
proposals on the two open items.

> 2) date:  <date> syntax is a subset of ??? in RFC 3339.

I would propose following text, which is a modification of the
corresponding text in the rfc 4198:

"<date> is a date in ISO 8601 Extended Format ([CC]YY["-"MM["-"DD]]),
and MUST correspond to a specific day on which the organization
allocating the URN owned the domain name specified in the provider-id.
 If not included, the default value for MM and DD is "01". "



> 1) provider-id:  This is intended to match the allowed ABNF for domain
> names.  (What is the correct normative reference?  With
> internationalization, is our syntax still correct?)

This reminds me of Alfred's comment #1 and the discussion
http://www.ietf.org/mail-archive/web/salud/current/msg00260.html and
previous threads.

By then, we (also Alfred) agreed on the following text, based on the RFC 5890:

"The <alert-indication>s are hierarchical identifiers.  The set of
allowable characters is the same as that for domain names [RFC1123].
Labels used in <standard-name> MUST comply with the syntax for Non
Reserved LDH-labels [RFC5890].  Labels used in <private-name> 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."

However, we changed the syntax since then. IMO, with Dale's the syntax
after "name" is deleted,  the second and third sentences in the above
text should be modified as follows:

" <Label>s used in && <alert-name>s excepting <label>s used in
<provider-id>s && MUST comply with the syntax for Non Reserved
LDH-labels [RFC5890].  Labels used in &&<provider-id>s&& MUST
comply with the syntax for Non Reserved LDH-labels or for A-labels
[RFC5890]. " (I put the modified text  between  &&..&&.)

We also could used different names for the two types of labels, e.g.
"label" and ""provider-id-label", but I am niot sure we want this.


Thank you
Laura


2013/2/13 Dale R. Worley <worley@ariadne.com>:
> (as an individual)
>
> OK, we can see that this is going well because the ABNF is quite
> simple and clear.  I've made the following adjustments in the version
> below:
>
> - aligned the columns and normalized the spacing between elements
> - put blank lines to break the rules in to sections, and reordered the rules
> - applied Paul's simplification
> - changed the rule "YY=CC" to "YY=DIGIT DIGIT", because YY is
>     semantically different from CC
> - removed DIGIT-1-9 and DIGIT-2-9, because they are not used
> - added a rule for "toplabel"
> - broken private-name into two parts, because one of the rules needs
>   to refer to the provider-id-and-date part
>
>       alert-URN         = "urn:alert:" alert-identifier
>       alert-identifier  = alert-category ":" alert-indication
>       alert-category    = alert-name
>       alert-indication  = alert-name *(":" alert-name)
>       alert-name        = label / private-name
>       name              = label
>       private-name      = label "@" provider
>       provider          = provider-id ["(" date ")"]
>       provider-id       = 1*(label ".") toplabel
> [I'm not sure I like the names of the two preceding rules.]
>
>       toplabel          = ALPHA [ *let-dig-hyp let-dig ]
>       label             = let-dig [ *let-dig-hyp let-dig ]
>       let-dig-hyp       = let-dig / "-"
>       let-dig           = ALPHA / DIGIT
>
>       date              = [CC] YY [ "-" MM ["-" DD] ]
>       CC                = DIGIT DIGIT
>       YY                = DIGIT DIGIT
>       MM                = ( "0" %x31-39 ) / ( "1" %x30-32 )
>       DD                = ( "0" %x31-39 ) / ( %x31-32 DIGIT ) / "30" / "31"
>       ALPHA             = %x41-5A / %x61-7A   ; A-Z / a-z
>       DIGIT             = %x30-39 ; 0-9
>
> I want to make two modifications so that the ABNF symbols can be used
> to describe the semantics more easily:
>
> 1. I want to have a symbol that refers to the component of the URN that
> can be removed during the resolution algorithm.  Currently, alert-name
> is used for both alert-category and as a component of
> alert-indication.
>
> 2. I want to have a syntactic distinction between alert-names which have
> standard meanings and alert-names which are privately defined.
>
> However, both of these changes are messy and unclear when written in
> ABNF.  So I will see if I can use semantic specifications to achieve
> the same result.
>
> The semantic rules are:
>
> 1) provider-id:  This is intended to match the allowed ABNF for domain
> names.  (What is the correct normative reference?  With
> internationalization, is our syntax still correct?)
>
> 2) date:  <date> syntax is a subset of ??? in RFC 3339.
>
> 2a) If <date> is absent from <private-name>, it defaults to 2013-01-01.
> 2b) If <DD> or <MM> are absent, each defaults to 01.
> 2c) If <CC> is absent, it defaults to 20.
>
> In all situations, including comparison of URNs and determining which
> entity defines the meanings of <alert-name>s, <provider>s are
> interpreted as if they contain <date> values with a full "CCYY-MM-DD"
> value, which is determined according to the above rules.
>
> 3) Comparison of URNs:
>
>    Comparison is case-insensitive, considering the URNs as character
>    strings (but with respect to rule (2)).
>
> 4) Removing components when interpreting URNs:
>    (section 8.1 step (b))
>
>    The <alert-name>s of the URN are removed sequentially from back to
>    front, until the first <alert-name> in the <alert-indication> is
>    removed, at which point the URN is discarded from consideration.
>
> 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.
>
> Dale
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud

From pkyzivat@alum.mit.edu  Mon Feb 18 08:52:51 2013
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 3347821F87E0 for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 08:52:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.332
X-Spam-Level: 
X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[AWL=0.105,  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 SiQlMLx071dj for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 08:52:50 -0800 (PST)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id BEA3421F874C for <salud@ietf.org>; Mon, 18 Feb 2013 08:52:49 -0800 (PST)
Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id 1rsL1l00A1swQuc55sspa3; Mon, 18 Feb 2013 16:52:49 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id 1ssp1l0083ZTu2S3bsspuc; Mon, 18 Feb 2013 16:52:49 +0000
Message-ID: <51225C60.9050201@alum.mit.edu>
Date: Mon, 18 Feb 2013 11:52:48 -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: salud@ietf.org
References: <CACWXZj2WhAsmQ3Ku7bVpiNhbFxX7-vx9d9wWzzKgiVLSeKk__g@mail.gmail.com> <201302132105.r1DL5BM01801234@shell01.TheWorld.com> <CACWXZj0Qq=Q=7necdgCPLeFAMbr3gg-WmBb-8UzegseEd_b_Qw@mail.gmail.com>
In-Reply-To: <CACWXZj0Qq=Q=7necdgCPLeFAMbr3gg-WmBb-8UzegseEd_b_Qw@mail.gmail.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=1361206369; bh=QG0jZ+doG3WqDZHoXu9EZJk/X6Mz7YgMpBbPILdOwRg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KCyFVUe9qEBqaRtpqdewOhANwL/xa5RrzC/Uy7Ft93j/Tm0YkaxNRlUZCUHRC1Vsg y1UWCdCHvoa695oanuxg8Tm+TAQqRwnNelnrdq2Bi2SBxFLdArXxsC7E8MSedkv96K QxdlfPDrSXnB/Xv1rWY+6YR2aAKWvAv4XPSCEzToLjB/49kXuaVpjHjgJoa5v1HJyU 3KVYxE24nvKcPJio4WXWcj0bsiJbblfSF3CsC4XaDgT1HN47Ff/74faX5Oa9c2R/FS FTxPMBkFCMPMbhsDubXMPKY2ySWfy9RT4uPx7QeufB6xrtT8jEMbtlQvgT28qXbyqo uhZAZ+veMr6+w==
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 16:52:51 -0000

On 2/18/13 9:24 AM, Laura Liess wrote:
> Dale,
>
> Thank you for adding the rules. I like them :-). I have following
> proposals on the two open items.
>
>> 2) date:  <date> syntax is a subset of ??? in RFC 3339.
>
> I would propose following text, which is a modification of the
> corresponding text in the rfc 4198:
>
> "<date> is a date in ISO 8601 Extended Format ([CC]YY["-"MM["-"DD]]),
> and MUST correspond to a specific day on which the organization
> allocating the URN owned the domain name specified in the provider-id.
>   If not included, the default value for MM and DD is "01". "

I've been trying to explain why this sort of wording doesn't work for 
me, several times.

The problem is that the URN is a *reference*. Typically it won't be 
written by the owner of the domain. Rather it will be written by someone 
who wants to take some special alerting action. So it isn't the 
allocation of the URN that is restricted - it is the *meaning* of that 
URN. For example, it may be that example.com was owned by a startup in 
2013, but then they go bankrupt and cease owning the domain. Then in 
2014 example.com is bought by a different company. I may have a business 
relationship with this second company, and so define some special 
alerting for calls from them, tagging my alert with "foo@example.com(2014)".

Of course somebody needs to insert the alert-info header with the URN in 
the call. It *could* be the caller (example.com) in which case the 
language you have above would apply. But it could also be a server on my 
receiving side, that authorizes incoming calls and assigns alert URNs. 
This server is free to use whatever URN it wants, but the meaning will 
vary. IMO this usage is much more likely - I am not likely to trust 
Alert-Info URNs assigned by the caller. Or if I do I will most likely 
screen/filter them.

	Thanks,
	Paul

From worley@shell01.TheWorld.com  Mon Feb 18 10:56:04 2013
Return-Path: <worley@shell01.TheWorld.com>
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 0BE5921F8BE9 for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 10:56:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.624
X-Spam-Level: 
X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=0.356,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 0HPHxCQfIeH6 for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 10:56:03 -0800 (PST)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id D7D3521F8BCE for <salud@ietf.org>; Mon, 18 Feb 2013 10:56:02 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1IIsOWo014784; Mon, 18 Feb 2013 13:54:26 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1IIsNWg2077372; Mon, 18 Feb 2013 13:54:23 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1IIsNFG2067515; Mon, 18 Feb 2013 13:54:23 -0500 (EST)
Date: Mon, 18 Feb 2013 13:54:23 -0500 (EST)
Message-Id: <201302181854.r1IIsNFG2067515@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: Laura Liess <laura.liess.dt@googlemail.com>
In-reply-to: <CACWXZj0Qq=Q=7necdgCPLeFAMbr3gg-WmBb-8UzegseEd_b_Qw@mail.gmail.com> (laura.liess.dt@googlemail.com)
References: <CACWXZj2WhAsmQ3Ku7bVpiNhbFxX7-vx9d9wWzzKgiVLSeKk__g@mail.gmail.com> <201302132105.r1DL5BM01801234@shell01.TheWorld.com> <CACWXZj0Qq=Q=7necdgCPLeFAMbr3gg-WmBb-8UzegseEd_b_Qw@mail.gmail.com>
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 18:56:04 -0000

(as an individual)

> From: Laura Liess <laura.liess.dt@googlemail.com>
> 
> Thank you for adding the rules. I like them :-). I have following
> proposals on the two open items.

Thanks!

> > 2) date:  <date> syntax is a subset of ??? in RFC 3339.
> 
> I would propose following text, which is a modification of the
> corresponding text in the rfc 4198:
> 
> "<date> is a date in ISO 8601 Extended Format ([CC]YY["-"MM["-"DD]]),
> and MUST correspond to a specific day on which the organization
> allocating the URN owned the domain name specified in the provider-id.
>  If not included, the default value for MM and DD is "01". "

This looks good to me.  RFC 3339 Appendix A contains the BNF from ISO
8061 for comparison.  It might be helpful to include a reference to
RFC 3339, since it seems to be the RFC people use as a reference for
date syntax and semantics.

However, there are two parts to this issue.  One is the syntax, which
you write as:

> "<date> is a date in ISO 8601 Extended Format ([CC]YY["-"MM["-"DD]]),
> [...]
>  If not included, the default value for MM and DD is "01". "

We want to add the default for the century as well.  This encompasses
what I wrote as (2b) and (2c).

And the other is the semantics:

> MUST correspond to a specific day on which the organization
> allocating the URN owned the domain name specified in the provider-id.

But the semantics is more complicated than that, it includes what I
wrote as (5a) and (5b):

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

> > 1) provider-id:  This is intended to match the allowed ABNF for domain
> > names.  (What is the correct normative reference?  With
> > internationalization, is our syntax still correct?)
> 
> This reminds me of Alfred's comment #1 and the discussion
> http://www.ietf.org/mail-archive/web/salud/current/msg00260.html and
> previous threads.
> 
> By then, we (also Alfred) agreed on the following text, based on the RFC 5890:
> 
> "The <alert-indication>s are hierarchical identifiers.  The set of
> allowable characters is the same as that for domain names [RFC1123].
> Labels used in <standard-name> MUST comply with the syntax for Non
> Reserved LDH-labels [RFC5890].  Labels used in <private-name> 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."
> 
> However, we changed the syntax since then. IMO, with Dale's the syntax
> after "name" is deleted,  the second and third sentences in the above
> text should be modified as follows:
> 
> " <Label>s used in && <alert-name>s excepting <label>s used in
> <provider-id>s && MUST comply with the syntax for Non Reserved
> LDH-labels [RFC5890].  Labels used in &&<provider-id>s&& MUST
> comply with the syntax for Non Reserved LDH-labels or for A-labels
> [RFC5890]. " (I put the modified text  between  &&..&&.)
> 
> We also could used different names for the two types of labels, e.g.
> "label" and ""provider-id-label", but I am niot sure we want this.

Ah, yes, I'm starting to remember that discussion.

I examine this text (as you have edited it) in detail:

> "The <alert-indication>s are hierarchical identifiers.  The set of
> allowable characters is the same as that for domain names [RFC1123].

I just looked at RFC 1123, and it doesn't seem to have any BNF.  So
it's a background reference for domain names, but not really
normative.  We may want to remove the reference, as the references to
RFC 5890 below tell the real syntax.

> <Label>s used in <alert-name>s excepting <label>s used in
> <provider-id>s MUST comply with the syntax for Non Reserved
> LDH-labels [RFC5890].  Labels used in <provider-id>s MUST
> comply with the syntax for Non Reserved LDH-labels or for A-labels
> [RFC5890].

(I use RFC 5890 figure 1 on page 10 as a reference for terms like
"A-label".)

There are three sorts of strings that we may want to treat separately:

One sort are domain names.  These are called <provider-id> in the
current BNF.  As far as I can tell from RFC 5890, valid domain names
(when represented on the wire) must be composed of:

- NR-LDH labels (ordinary ASCII labels that meet certain validity
  rules, especially not starting with "xn--", which indicates an
  A-label), and
- A-labels (non-ASCII labels encoded with Punycode).

The second sort are "privately-defined labels", that is, the <label>
part of a <private-name> and the <alert-indication>s that are <label>s
that follow it before the next <private-name>.  These are the ones
covered by:

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

We probably want to allow these to be internationalized as well.  If
so, we would define these as "NR-LDH / A-label".

The third sort are the "standardized labels", the <labels> that aren't
covered by the preceding two categories.  We probably want to
restrict these to traditional ASCII labels, so their syntax is
"NR-LDH".

OK, now that I've thought that through, I can compare it with your
text.  I make the following observations:

- In my listing of rules 1, 2, 3, etc. in
  http://www.ietf.org/mail-archive/web/salud/current/msg00341.html,
  though I specify when a <label> *is* defined by a private entity, I
  don't state when a <label> *is not*, that is, when its definition
  must be standard.  That would be accomplished by:  "(5x) The meaning
  of a <label> whose meaning is not defined by an entity according to
  the rules (5c) and (5d) is defined by standardization."  (That
  wording is not quite correct.)

- It would make discussion easier if the <label>s within a
  <provider-id> were a different nonterminal symbol.  Then we could
  say (taking an example from your text above), "<Label>s MUST comply
  with the syntax for Non Reserved LDH-labels [RFC5890]." rather than
  "<Label>s used in <alert-name>s excepting <label>s used in
  <provider-id>s MUST comply with the syntax for Non Reserved
  LDH-labels [RFC5890]."

- Your wording "<Label>s ... MUST comply with the syntax for Non
  Reserved LDH-labels [RFC5890]" means that only "ASCII labels" can be
  used for privately-defined alert-names.  Do we want this
  restriction?  Or do we want to allow entities to define
  "internationalized" alert-names?  To allow internationalization, we
  would say, "<labels> MUST comply with the syntax for Non Reserved
  LDH-labels or for A-labels [RFC5890]."

- I'm sure we want to restrict the standardized <label>s to be NR-LDH
  labels, i.e., ASCII.  We can state such a restriction in the RFC, or
  we can just assume that we will never define non-ASCII standardized
  labels.

> Comparisons MUST follow the comparison rules for the
> corresponding type of label.

I'm taking the comparison rule for internationalized domain names from
RFC 3490 section 2:

   In IDNA, equivalence of labels is defined in terms of the ToASCII
   operation, which constructs an ASCII form for a given label, whether
   or not the label was already an ASCII label.  Labels are defined to
   be equivalent if and only if their ASCII forms produced by ToASCII
   match using a case-insensitive ASCII comparison.  ASCII labels
   already have a notion of equivalence: upper case and lower case are
   considered equivalent.  The IDNA notion of equivalence is an
   extension of that older notion.  Equivalent labels in IDNA are
   treated as alternate forms of the same label, just as "foo" and "Foo"
   are treated as alternate forms of the same label.

That seems to mean that internationalized labels are compared by first
converting them into ASCII strings and then comparing the ASCII
strings case-insensitively.  Since Alert-Info URN domain names are
already in their ASCII form, this means that the URN domain names can
just be compared case-insensitively.

And the <label>s that are not part of domain names are also to be
compared case-insensitively.

So I think we can safely reduce all that to the statement that all
comparisons are to be done case-insensitively.  It would certainly
make life easier for implementers if we state that directly.  (I
suppose we need a reference to RFC 3490 in regard to comparing
internationalized domain names.)

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

We probably want to make it clear what we are concerned about:

    > Registered URNs MUST be transmitted with the case in which they are
    > registered. A new name MUST NOT be registered if it is
    > case-insensitively equal to an already registered name."

(I see that I am using "standardized" where the draft uses
"registered".)

Dale

From keith.drage@alcatel-lucent.com  Mon Feb 18 12:20:40 2013
Return-Path: <keith.drage@alcatel-lucent.com>
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 182F421F8CB5 for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 12:20:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.204
X-Spam-Level: 
X-Spam-Status: No, score=-109.204 tagged_above=-999 required=5 tests=[AWL=1.045, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 Me1ZqjajLQvv for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 12:20:39 -0800 (PST)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id B57A821F8CB3 for <salud@ietf.org>; Mon, 18 Feb 2013 12:20:38 -0800 (PST)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1IKKIee029007 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 18 Feb 2013 21:20:18 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 18 Feb 2013 21:20:18 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: "Dale R. Worley" <worley@ariadne.com>, Laura Liess <laura.liess.dt@googlemail.com>
Date: Mon, 18 Feb 2013 21:20:16 +0100
Thread-Topic: [salud] New version of the ABNF-syntax
Thread-Index: Ac4OCZ9/q0128K/sSRmTGXDKX9/J9AAC0iZQ
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE2107016088A@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
References: <CACWXZj2WhAsmQ3Ku7bVpiNhbFxX7-vx9d9wWzzKgiVLSeKk__g@mail.gmail.com> <201302132105.r1DL5BM01801234@shell01.TheWorld.com> <CACWXZj0Qq=Q=7necdgCPLeFAMbr3gg-WmBb-8UzegseEd_b_Qw@mail.gmail.com> <201302181854.r1IIsNFG2067515@shell01.TheWorld.com>
In-Reply-To: <201302181854.r1IIsNFG2067515@shell01.TheWorld.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Cc: "salud@ietf.org" <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 20:20:40 -0000

Aside from the rest of this discussion, I believe we need the ISO 8601 refe=
rence to at least express:

1)	Gregorian calendar
2)	"31" represents the 31st rather than 13th

Keith

> -----Original Message-----
> From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf Of
> Dale R. Worley
> Sent: 18 February 2013 18:54
> To: Laura Liess
> Cc: salud@ietf.org
> Subject: Re: [salud] New version of the ABNF-syntax
>=20
> (as an individual)
>=20
> > From: Laura Liess <laura.liess.dt@googlemail.com>
> >
> > Thank you for adding the rules. I like them :-). I have following
> > proposals on the two open items.
>=20
> Thanks!
>=20
> > > 2) date:  <date> syntax is a subset of ??? in RFC 3339.
> >
> > I would propose following text, which is a modification of the
> > corresponding text in the rfc 4198:
> >
> > "<date> is a date in ISO 8601 Extended Format ([CC]YY["-"MM["-"DD]]),
> > and MUST correspond to a specific day on which the organization
> > allocating the URN owned the domain name specified in the provider-id.
> >  If not included, the default value for MM and DD is "01". "
>=20
> This looks good to me.  RFC 3339 Appendix A contains the BNF from ISO
> 8061 for comparison.  It might be helpful to include a reference to
> RFC 3339, since it seems to be the RFC people use as a reference for
> date syntax and semantics.
>=20
> However, there are two parts to this issue.  One is the syntax, which
> you write as:
>=20
> > "<date> is a date in ISO 8601 Extended Format ([CC]YY["-"MM["-"DD]]),
> > [...]
> >  If not included, the default value for MM and DD is "01". "
>=20
> We want to add the default for the century as well.  This encompasses
> what I wrote as (2b) and (2c).
>=20
> And the other is the semantics:
>=20
> > MUST correspond to a specific day on which the organization
> > allocating the URN owned the domain name specified in the provider-id.
>=20
> But the semantics is more complicated than that, it includes what I
> wrote as (5a) and (5b):
>=20
> > > 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> an=
d
> > >     all <date>s preceding when it registered the domain name.
>=20
> > > 1) provider-id:  This is intended to match the allowed ABNF for domai=
n
> > > names.  (What is the correct normative reference?  With
> > > internationalization, is our syntax still correct?)
> >
> > This reminds me of Alfred's comment #1 and the discussion
> > http://www.ietf.org/mail-archive/web/salud/current/msg00260.html and
> > previous threads.
> >
> > By then, we (also Alfred) agreed on the following text, based on the RF=
C
> 5890:
> >
> > "The <alert-indication>s are hierarchical identifiers.  The set of
> > allowable characters is the same as that for domain names [RFC1123].
> > Labels used in <standard-name> MUST comply with the syntax for Non
> > Reserved LDH-labels [RFC5890].  Labels used in <private-name> 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."
> >
> > However, we changed the syntax since then. IMO, with Dale's the syntax
> > after "name" is deleted,  the second and third sentences in the above
> > text should be modified as follows:
> >
> > " <Label>s used in && <alert-name>s excepting <label>s used in
> > <provider-id>s && MUST comply with the syntax for Non Reserved
> > LDH-labels [RFC5890].  Labels used in &&<provider-id>s&& MUST
> > comply with the syntax for Non Reserved LDH-labels or for A-labels
> > [RFC5890]. " (I put the modified text  between  &&..&&.)
> >
> > We also could used different names for the two types of labels, e.g.
> > "label" and ""provider-id-label", but I am niot sure we want this.
>=20
> Ah, yes, I'm starting to remember that discussion.
>=20
> I examine this text (as you have edited it) in detail:
>=20
> > "The <alert-indication>s are hierarchical identifiers.  The set of
> > allowable characters is the same as that for domain names [RFC1123].
>=20
> I just looked at RFC 1123, and it doesn't seem to have any BNF.  So
> it's a background reference for domain names, but not really
> normative.  We may want to remove the reference, as the references to
> RFC 5890 below tell the real syntax.
>=20
> > <Label>s used in <alert-name>s excepting <label>s used in
> > <provider-id>s MUST comply with the syntax for Non Reserved
> > LDH-labels [RFC5890].  Labels used in <provider-id>s MUST
> > comply with the syntax for Non Reserved LDH-labels or for A-labels
> > [RFC5890].
>=20
> (I use RFC 5890 figure 1 on page 10 as a reference for terms like
> "A-label".)
>=20
> There are three sorts of strings that we may want to treat separately:
>=20
> One sort are domain names.  These are called <provider-id> in the
> current BNF.  As far as I can tell from RFC 5890, valid domain names
> (when represented on the wire) must be composed of:
>=20
> - NR-LDH labels (ordinary ASCII labels that meet certain validity
>   rules, especially not starting with "xn--", which indicates an
>   A-label), and
> - A-labels (non-ASCII labels encoded with Punycode).
>=20
> The second sort are "privately-defined labels", that is, the <label>
> part of a <private-name> and the <alert-indication>s that are <label>s
> that follow it before the next <private-name>.  These are the ones
> covered by:
>=20
>     5c) The entity owning <provider> defines the meaning of a
> 	<private-name>, whether it is used as an <alert-category> or an
> 	<alert-indication>.
>=20
>     5d) The entity owning <provider> within a <private-name> (in either a=
n
> 	<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>.
>=20
> We probably want to allow these to be internationalized as well.  If
> so, we would define these as "NR-LDH / A-label".
>=20
> The third sort are the "standardized labels", the <labels> that aren't
> covered by the preceding two categories.  We probably want to
> restrict these to traditional ASCII labels, so their syntax is
> "NR-LDH".
>=20
> OK, now that I've thought that through, I can compare it with your
> text.  I make the following observations:
>=20
> - In my listing of rules 1, 2, 3, etc. in
>   http://www.ietf.org/mail-archive/web/salud/current/msg00341.html,
>   though I specify when a <label> *is* defined by a private entity, I
>   don't state when a <label> *is not*, that is, when its definition
>   must be standard.  That would be accomplished by:  "(5x) The meaning
>   of a <label> whose meaning is not defined by an entity according to
>   the rules (5c) and (5d) is defined by standardization."  (That
>   wording is not quite correct.)
>=20
> - It would make discussion easier if the <label>s within a
>   <provider-id> were a different nonterminal symbol.  Then we could
>   say (taking an example from your text above), "<Label>s MUST comply
>   with the syntax for Non Reserved LDH-labels [RFC5890]." rather than
>   "<Label>s used in <alert-name>s excepting <label>s used in
>   <provider-id>s MUST comply with the syntax for Non Reserved
>   LDH-labels [RFC5890]."
>=20
> - Your wording "<Label>s ... MUST comply with the syntax for Non
>   Reserved LDH-labels [RFC5890]" means that only "ASCII labels" can be
>   used for privately-defined alert-names.  Do we want this
>   restriction?  Or do we want to allow entities to define
>   "internationalized" alert-names?  To allow internationalization, we
>   would say, "<labels> MUST comply with the syntax for Non Reserved
>   LDH-labels or for A-labels [RFC5890]."
>=20
> - I'm sure we want to restrict the standardized <label>s to be NR-LDH
>   labels, i.e., ASCII.  We can state such a restriction in the RFC, or
>   we can just assume that we will never define non-ASCII standardized
>   labels.
>=20
> > Comparisons MUST follow the comparison rules for the
> > corresponding type of label.
>=20
> I'm taking the comparison rule for internationalized domain names from
> RFC 3490 section 2:
>=20
>    In IDNA, equivalence of labels is defined in terms of the ToASCII
>    operation, which constructs an ASCII form for a given label, whether
>    or not the label was already an ASCII label.  Labels are defined to
>    be equivalent if and only if their ASCII forms produced by ToASCII
>    match using a case-insensitive ASCII comparison.  ASCII labels
>    already have a notion of equivalence: upper case and lower case are
>    considered equivalent.  The IDNA notion of equivalence is an
>    extension of that older notion.  Equivalent labels in IDNA are
>    treated as alternate forms of the same label, just as "foo" and "Foo"
>    are treated as alternate forms of the same label.
>=20
> That seems to mean that internationalized labels are compared by first
> converting them into ASCII strings and then comparing the ASCII
> strings case-insensitively.  Since Alert-Info URN domain names are
> already in their ASCII form, this means that the URN domain names can
> just be compared case-insensitively.
>=20
> And the <label>s that are not part of domain names are also to be
> compared case-insensitively.
>=20
> So I think we can safely reduce all that to the statement that all
> comparisons are to be done case-insensitively.  It would certainly
> make life easier for implementers if we state that directly.  (I
> suppose we need a reference to RFC 3490 in regard to comparing
> internationalized domain names.)
>=20
> > 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."
>=20
> We probably want to make it clear what we are concerned about:
>=20
>     > Registered URNs MUST be transmitted with the case in which they are
>     > registered. A new name MUST NOT be registered if it is
>     > case-insensitively equal to an already registered name."
>=20
> (I see that I am using "standardized" where the draft uses
> "registered".)
>=20
> Dale
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud

From worley@shell01.TheWorld.com  Mon Feb 18 13:05:48 2013
Return-Path: <worley@shell01.TheWorld.com>
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 8155A21F8CB4 for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 13:05:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level: 
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.348,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 1EluE6CKy8HL for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 13:05:47 -0800 (PST)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id ABFA621F8CB3 for <salud@ietf.org>; Mon, 18 Feb 2013 13:05:47 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1IL5SGj013647; Mon, 18 Feb 2013 16:05:30 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1IL5Sl12062974; Mon, 18 Feb 2013 16:05:28 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1IL5S7O2079509; Mon, 18 Feb 2013 16:05:28 -0500 (EST)
Date: Mon, 18 Feb 2013 16:05:28 -0500 (EST)
Message-Id: <201302182105.r1IL5S7O2079509@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
In-reply-to: <51225C60.9050201@alum.mit.edu> (pkyzivat@alum.mit.edu)
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>
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:05:48 -0000

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

Dale

From worley@shell01.TheWorld.com  Mon Feb 18 13:06:30 2013
Return-Path: <worley@shell01.TheWorld.com>
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 04CC421F8CC2 for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 13:06:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.648
X-Spam-Level: 
X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.332,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 96grymrOHZEx for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 13:06:29 -0800 (PST)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 78E7021F8CC5 for <salud@ietf.org>; Mon, 18 Feb 2013 13:06:29 -0800 (PST)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1IL5Ab1024239; Mon, 18 Feb 2013 16:05:13 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1IL5ASs2080854; Mon, 18 Feb 2013 16:05:10 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1IL59Ce2082192; Mon, 18 Feb 2013 16:05:09 -0500 (EST)
Date: Mon, 18 Feb 2013 16:05:09 -0500 (EST)
Message-Id: <201302182105.r1IL59Ce2082192@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
In-reply-to: <EDC0A1AE77C57744B664A310A0B23AE2107016088A@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> (keith.drage@alcatel-lucent.com)
References: <CACWXZj2WhAsmQ3Ku7bVpiNhbFxX7-vx9d9wWzzKgiVLSeKk__g@mail.gmail.com> <201302132105.r1DL5BM01801234@shell01.TheWorld.com> <CACWXZj0Qq=Q=7necdgCPLeFAMbr3gg-WmBb-8UzegseEd_b_Qw@mail.gmail.com> <201302181854.r1IIsNFG2067515@shell01.TheWorld.com> <EDC0A1AE77C57744B664A310A0B23AE2107016088A@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
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:06:30 -0000

> From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
> 
> Aside from the rest of this discussion, I believe we need the ISO
> 8601 reference to at least express:
> 
> 1)	Gregorian calendar
> 2)	"31" represents the 31st rather than 13th

RFC 3339 references ISO 8601, so I don't think we *need* to reference
ISO 8601 as long as we reference RFC 3339.

Dale

From pkyzivat@alum.mit.edu  Mon Feb 18 13:11:53 2013
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 DA09521F8CBB for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 13:11:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.337
X-Spam-Level: 
X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[AWL=0.100,  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 gmSy07FUHeHF for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 13:11:52 -0800 (PST)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 8B82721F8CCD for <salud@ietf.org>; Mon, 18 Feb 2013 13:11:52 -0800 (PST)
Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta03.westchester.pa.mail.comcast.net with comcast id 1oNl1l0040EZKEL53xBqxe; Mon, 18 Feb 2013 21:11:50 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id 1xBq1l00l3ZTu2S3MxBq9t; Mon, 18 Feb 2013 21:11:50 +0000
Message-ID: <51229915.7040209@alum.mit.edu>
Date: Mon, 18 Feb 2013 16:11:49 -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: salud@ietf.org
References: <CACWXZj2WhAsmQ3Ku7bVpiNhbFxX7-vx9d9wWzzKgiVLSeKk__g@mail.gmail.com> <201302132105.r1DL5BM01801234@shell01.TheWorld.com> <CACWXZj0Qq=Q=7necdgCPLeFAMbr3gg-WmBb-8UzegseEd_b_Qw@mail.gmail.com> <201302181854.r1IIsNFG2067515@shell01.TheWorld.com> <EDC0A1AE77C57744B664A310A0B23AE2107016088A@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE2107016088A@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.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=1361221910; bh=ywgdV6tPoeK1HHPOlgXapjFn/fOjU75Ft26jFEjiuc4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VWQn6+/RgXRwr83c4SOUurMjEe6ACcEzmzKQusqQ3+kXCClrcwadHojyP82eU2nNf QfYPs75w1T9f0h1jippEOgyfTtu6b1pwXn6mfKCSpjRO21CAPJt4mpmqUqnsL4uumH wWPobtPQ0lwMhcjvAZ8hxQzwiqUTpWauz64Q/l1mUvlFll+B1zbbXv89NHwB66owkD UwpUPJ8ZVLcy+dIJvlGT5fXJd+6dH2U3GRCkzE1e/nQo+x7ISe9m/7oeJI2rR+DPx1 EHApg+SaWzZAECjQbqdiVYEiAra1tzXiG1lW5Ga8gVZ6c5hwhY2biMWFtaK9ffdo38 Mf58Z4vGC7rdQ==
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:11:54 -0000

On 2/18/13 3:20 PM, DRAGE, Keith (Keith) wrote:
> Aside from the rest of this discussion, I believe we need the ISO 8601 reference to at least express:
>
> 1)	Gregorian calendar
> 2)	"31" represents the 31st rather than 13th

No. I think we should specify that we are using the Mayan calendar and 
Mayan base-20 arithmetic.

	Thanks,
	Paul

> Keith
>
>> -----Original Message-----
>> From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf Of
>> Dale R. Worley
>> Sent: 18 February 2013 18:54
>> To: Laura Liess
>> Cc: salud@ietf.org
>> Subject: Re: [salud] New version of the ABNF-syntax
>>
>> (as an individual)
>>
>>> From: Laura Liess <laura.liess.dt@googlemail.com>
>>>
>>> Thank you for adding the rules. I like them :-). I have following
>>> proposals on the two open items.
>>
>> Thanks!
>>
>>>> 2) date:  <date> syntax is a subset of ??? in RFC 3339.
>>>
>>> I would propose following text, which is a modification of the
>>> corresponding text in the rfc 4198:
>>>
>>> "<date> is a date in ISO 8601 Extended Format ([CC]YY["-"MM["-"DD]]),
>>> and MUST correspond to a specific day on which the organization
>>> allocating the URN owned the domain name specified in the provider-id.
>>>   If not included, the default value for MM and DD is "01". "
>>
>> This looks good to me.  RFC 3339 Appendix A contains the BNF from ISO
>> 8061 for comparison.  It might be helpful to include a reference to
>> RFC 3339, since it seems to be the RFC people use as a reference for
>> date syntax and semantics.
>>
>> However, there are two parts to this issue.  One is the syntax, which
>> you write as:
>>
>>> "<date> is a date in ISO 8601 Extended Format ([CC]YY["-"MM["-"DD]]),
>>> [...]
>>>   If not included, the default value for MM and DD is "01". "
>>
>> We want to add the default for the century as well.  This encompasses
>> what I wrote as (2b) and (2c).
>>
>> And the other is the semantics:
>>
>>> MUST correspond to a specific day on which the organization
>>> allocating the URN owned the domain name specified in the provider-id.
>>
>> But the semantics is more complicated than that, it includes what I
>> wrote as (5a) and (5b):
>>
>>>> 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.
>>
>>>> 1) provider-id:  This is intended to match the allowed ABNF for domain
>>>> names.  (What is the correct normative reference?  With
>>>> internationalization, is our syntax still correct?)
>>>
>>> This reminds me of Alfred's comment #1 and the discussion
>>> http://www.ietf.org/mail-archive/web/salud/current/msg00260.html and
>>> previous threads.
>>>
>>> By then, we (also Alfred) agreed on the following text, based on the RFC
>> 5890:
>>>
>>> "The <alert-indication>s are hierarchical identifiers.  The set of
>>> allowable characters is the same as that for domain names [RFC1123].
>>> Labels used in <standard-name> MUST comply with the syntax for Non
>>> Reserved LDH-labels [RFC5890].  Labels used in <private-name> 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."
>>>
>>> However, we changed the syntax since then. IMO, with Dale's the syntax
>>> after "name" is deleted,  the second and third sentences in the above
>>> text should be modified as follows:
>>>
>>> " <Label>s used in && <alert-name>s excepting <label>s used in
>>> <provider-id>s && MUST comply with the syntax for Non Reserved
>>> LDH-labels [RFC5890].  Labels used in &&<provider-id>s&& MUST
>>> comply with the syntax for Non Reserved LDH-labels or for A-labels
>>> [RFC5890]. " (I put the modified text  between  &&..&&.)
>>>
>>> We also could used different names for the two types of labels, e.g.
>>> "label" and ""provider-id-label", but I am niot sure we want this.
>>
>> Ah, yes, I'm starting to remember that discussion.
>>
>> I examine this text (as you have edited it) in detail:
>>
>>> "The <alert-indication>s are hierarchical identifiers.  The set of
>>> allowable characters is the same as that for domain names [RFC1123].
>>
>> I just looked at RFC 1123, and it doesn't seem to have any BNF.  So
>> it's a background reference for domain names, but not really
>> normative.  We may want to remove the reference, as the references to
>> RFC 5890 below tell the real syntax.
>>
>>> <Label>s used in <alert-name>s excepting <label>s used in
>>> <provider-id>s MUST comply with the syntax for Non Reserved
>>> LDH-labels [RFC5890].  Labels used in <provider-id>s MUST
>>> comply with the syntax for Non Reserved LDH-labels or for A-labels
>>> [RFC5890].
>>
>> (I use RFC 5890 figure 1 on page 10 as a reference for terms like
>> "A-label".)
>>
>> There are three sorts of strings that we may want to treat separately:
>>
>> One sort are domain names.  These are called <provider-id> in the
>> current BNF.  As far as I can tell from RFC 5890, valid domain names
>> (when represented on the wire) must be composed of:
>>
>> - NR-LDH labels (ordinary ASCII labels that meet certain validity
>>    rules, especially not starting with "xn--", which indicates an
>>    A-label), and
>> - A-labels (non-ASCII labels encoded with Punycode).
>>
>> The second sort are "privately-defined labels", that is, the <label>
>> part of a <private-name> and the <alert-indication>s that are <label>s
>> that follow it before the next <private-name>.  These are the ones
>> covered by:
>>
>>      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>.
>>
>> We probably want to allow these to be internationalized as well.  If
>> so, we would define these as "NR-LDH / A-label".
>>
>> The third sort are the "standardized labels", the <labels> that aren't
>> covered by the preceding two categories.  We probably want to
>> restrict these to traditional ASCII labels, so their syntax is
>> "NR-LDH".
>>
>> OK, now that I've thought that through, I can compare it with your
>> text.  I make the following observations:
>>
>> - In my listing of rules 1, 2, 3, etc. in
>>    http://www.ietf.org/mail-archive/web/salud/current/msg00341.html,
>>    though I specify when a <label> *is* defined by a private entity, I
>>    don't state when a <label> *is not*, that is, when its definition
>>    must be standard.  That would be accomplished by:  "(5x) The meaning
>>    of a <label> whose meaning is not defined by an entity according to
>>    the rules (5c) and (5d) is defined by standardization."  (That
>>    wording is not quite correct.)
>>
>> - It would make discussion easier if the <label>s within a
>>    <provider-id> were a different nonterminal symbol.  Then we could
>>    say (taking an example from your text above), "<Label>s MUST comply
>>    with the syntax for Non Reserved LDH-labels [RFC5890]." rather than
>>    "<Label>s used in <alert-name>s excepting <label>s used in
>>    <provider-id>s MUST comply with the syntax for Non Reserved
>>    LDH-labels [RFC5890]."
>>
>> - Your wording "<Label>s ... MUST comply with the syntax for Non
>>    Reserved LDH-labels [RFC5890]" means that only "ASCII labels" can be
>>    used for privately-defined alert-names.  Do we want this
>>    restriction?  Or do we want to allow entities to define
>>    "internationalized" alert-names?  To allow internationalization, we
>>    would say, "<labels> MUST comply with the syntax for Non Reserved
>>    LDH-labels or for A-labels [RFC5890]."
>>
>> - I'm sure we want to restrict the standardized <label>s to be NR-LDH
>>    labels, i.e., ASCII.  We can state such a restriction in the RFC, or
>>    we can just assume that we will never define non-ASCII standardized
>>    labels.
>>
>>> Comparisons MUST follow the comparison rules for the
>>> corresponding type of label.
>>
>> I'm taking the comparison rule for internationalized domain names from
>> RFC 3490 section 2:
>>
>>     In IDNA, equivalence of labels is defined in terms of the ToASCII
>>     operation, which constructs an ASCII form for a given label, whether
>>     or not the label was already an ASCII label.  Labels are defined to
>>     be equivalent if and only if their ASCII forms produced by ToASCII
>>     match using a case-insensitive ASCII comparison.  ASCII labels
>>     already have a notion of equivalence: upper case and lower case are
>>     considered equivalent.  The IDNA notion of equivalence is an
>>     extension of that older notion.  Equivalent labels in IDNA are
>>     treated as alternate forms of the same label, just as "foo" and "Foo"
>>     are treated as alternate forms of the same label.
>>
>> That seems to mean that internationalized labels are compared by first
>> converting them into ASCII strings and then comparing the ASCII
>> strings case-insensitively.  Since Alert-Info URN domain names are
>> already in their ASCII form, this means that the URN domain names can
>> just be compared case-insensitively.
>>
>> And the <label>s that are not part of domain names are also to be
>> compared case-insensitively.
>>
>> So I think we can safely reduce all that to the statement that all
>> comparisons are to be done case-insensitively.  It would certainly
>> make life easier for implementers if we state that directly.  (I
>> suppose we need a reference to RFC 3490 in regard to comparing
>> internationalized domain names.)
>>
>>> 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."
>>
>> We probably want to make it clear what we are concerned about:
>>
>>      > Registered URNs MUST be transmitted with the case in which they are
>>      > registered. A new name MUST NOT be registered if it is
>>      > case-insensitively equal to an already registered name."
>>
>> (I see that I am using "standardized" where the draft uses
>> "registered".)
>>
>> Dale
>> _______________________________________________
>> salud mailing list
>> salud@ietf.org
>> https://www.ietf.org/mailman/listinfo/salud
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>


From pkyzivat@alum.mit.edu  Mon Feb 18 13:39:03 2013
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


From worley@shell01.TheWorld.com  Mon Feb 18 15:05:45 2013
Return-Path: <worley@shell01.TheWorld.com>
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 307AC21F8CE3 for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 15:05:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.656
X-Spam-Level: 
X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5 tests=[AWL=0.324,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 U7hQpGzVxa3g for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 15:05:44 -0800 (PST)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id D6B2921F8CE0 for <salud@ietf.org>; Mon, 18 Feb 2013 15:05:43 -0800 (PST)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1IN5F0e022374; Mon, 18 Feb 2013 18:05:17 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1IN5Fdt2089099; Mon, 18 Feb 2013 18:05:15 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1IN5EBd2088017; Mon, 18 Feb 2013 18:05:14 -0500 (EST)
Date: Mon, 18 Feb 2013 18:05:14 -0500 (EST)
Message-Id: <201302182305.r1IN5EBd2088017@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
In-reply-to: <51229F75.809@alum.mit.edu> (pkyzivat@alum.mit.edu)
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> <51229F75.809@alum.mit.edu>
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 23:05:45 -0000

> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
> 
> 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.

Well, yes, that's why I phrase it, "The entity owning <provider>
... defines the meaning of ...".  The right that is restricted to
owners is to declare what that part of the URN means.

Dale

From pkyzivat@alum.mit.edu  Mon Feb 18 15:12:51 2013
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 2BEF121E805F for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 15:12:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.35
X-Spam-Level: 
X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[AWL=0.087,  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 o6WTKfydlNFV for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 15:12:50 -0800 (PST)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEF121E8050 for <salud@ietf.org>; Mon, 18 Feb 2013 15:12:50 -0800 (PST)
Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta15.westchester.pa.mail.comcast.net with comcast id 1xg01l0060xGWP85FzCpsT; Mon, 18 Feb 2013 23:12:49 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id 1zCp1l00d3ZTu2S3YzCp5i; Mon, 18 Feb 2013 23:12:49 +0000
Message-ID: <5122B571.4090300@alum.mit.edu>
Date: Mon, 18 Feb 2013 18:12:49 -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> <51229F75.809@alum.mit.edu> <201302182305.r1IN5EBd2088017@shell01.TheWorld.com>
In-Reply-To: <201302182305.r1IN5EBd2088017@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=1361229169; bh=quTiAtnZahgV0c0A6ojXVeLPltdgOTmGng5iv/cBnAU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VrSqI9Pxqxn829qEqh/COCswFcqpDlEtovzyGcXVYWCydUPnKY3nvONvgqin6Hgnj YvKj2tJEGqDo3FMmBZymf6SFomVmfOUmojnk5Q+J/oVdkSTIllsBwcLcEs0uwh8T5m cF4/PI2Rv0sjyspP/Fr2+h9ObdVvhOgsbSmEX8fyT4veIXSZSBOST3Vk/Zb5R6fstm FsP62xuQSqRjlqUGkgATnxR6KbOgVoqPdxdOZ1R3XhHvV9xFIgAgtRhrF263Xmo4km xKwNMk9ekIFLOzKX5+iinU4zYT/YLLvwCnZVRueM+4UKHdWm38ozqiweP4LtIctXZW 2JqemSvtKJHaw==
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 23:12:51 -0000

On 2/18/13 6:05 PM, Dale R. Worley wrote:
>> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
>>
>> 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.
>
> Well, yes, that's why I phrase it, "The entity owning <provider>
> ... defines the meaning of ...".  The right that is restricted to
> owners is to declare what that part of the URN means.

OK. WFM.

	Thanks,
	Paul


From keith.drage@alcatel-lucent.com  Mon Feb 18 15:53:33 2013
Return-Path: <keith.drage@alcatel-lucent.com>
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 28B0521E8099 for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 15:53:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.999
X-Spam-Level: 
X-Spam-Status: No, score=-106.999 tagged_above=-999 required=5 tests=[AWL=-1.350, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 1B5By-Q+KUrF for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 15:53:31 -0800 (PST)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6D43021E8087 for <salud@ietf.org>; Mon, 18 Feb 2013 15:53:30 -0800 (PST)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1INr5cm015227 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Feb 2013 00:53:13 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 19 Feb 2013 00:53:11 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "Dale R. Worley" <worley@ariadne.com>
Date: Tue, 19 Feb 2013 00:53:10 +0100
Thread-Topic: [salud] New version of the ABNF-syntax
Thread-Index: Ac4OIGFwf3dswSltS+GnKZokBXUvqAAESxmg
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE2107016089A@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.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> <51229F75.809@alum.mit.edu>
In-Reply-To: <51229F75.809@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Cc: "salud@ietf.org" <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 23:53:33 -0000

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 ow=
ner 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.

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
>=20
> 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?
>=20
> The issue isn't who is the "owner" of the label, but rather what rights
> are restricted to owners.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 	Thanks,
> 	Paul
>=20
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud

From pkyzivat@alum.mit.edu  Mon Feb 18 16:02:52 2013
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 EE66521F86C8 for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 16:02:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.055
X-Spam-Level: 
X-Spam-Status: No, score=-0.055 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_41=0.6, 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 Tsmds026hZ8O for <salud@ietfa.amsl.com>; Mon, 18 Feb 2013 16:02:51 -0800 (PST)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id F20B521F85DC for <salud@ietf.org>; Mon, 18 Feb 2013 16:02:50 -0800 (PST)
Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id 201J1l00P0cZkys5302qQm; Tue, 19 Feb 2013 00:02:50 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id 202p1l00W3ZTu2S3W02qGz; Tue, 19 Feb 2013 00:02:50 +0000
Message-ID: <5122C129.1040507@alum.mit.edu>
Date: Mon, 18 Feb 2013 19:02:49 -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: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.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> <51229F75.809@alum.mit.edu> <EDC0A1AE77C57744B664A310A0B23AE2107016089A@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE2107016089A@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.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=1361232170; bh=/3v+1LnOhZ8hY4lVAB//RViJATnq6LdLZlqJK1zyKpE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=H1afFOBil6+Mc0bnCc7HswuaWKWk5pk4GFgtAw+rcJMgeJ0V4frgTFZ9prInZb684 Ggn4AfMXBOl4/sLkl7YB4CEnNy07zuOfpYVnQLgex1hBl7XIfmOCdDqCJrF/2M50AJ 3u7ot62ltG2n2WGHreBgnW694VXJ9KSj/TXiMvMO3YQsiNUJlBjC+Uiw9zTajLWZOP GfcrYmHOHKRiiMRVE7EGjEbTtCoEKqoOybjUPNSDsfHV8yV1CSak/JImevTwf+5LgM FEHdDltHJE8PDws4LgfFXFOv8eUIPWuBwbNlWCRo66WDKqI7rlftO2G9Xbso378xf2 Qf/2V09rUxpNQ==
Cc: "salud@ietf.org" <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: Tue, 19 Feb 2013 00:02:52 -0000

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
>


From worley@shell01.TheWorld.com  Wed Feb 20 07:43:12 2013
Return-Path: <worley@shell01.TheWorld.com>
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 08C0C21F8887 for <salud@ietfa.amsl.com>; Wed, 20 Feb 2013 07:43:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.67
X-Spam-Level: 
X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=0.310,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 d4CQQzuCDdHa for <salud@ietfa.amsl.com>; Wed, 20 Feb 2013 07:43:11 -0800 (PST)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 55A5921F8886 for <salud@ietf.org>; Wed, 20 Feb 2013 07:43:11 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1KFgL4p000715; Wed, 20 Feb 2013 10:42:23 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1KFgKTn2193254; Wed, 20 Feb 2013 10:42:20 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1KFgJUC2214689; Wed, 20 Feb 2013 10:42:19 -0500 (EST)
Date: Wed, 20 Feb 2013 10:42:19 -0500 (EST)
Message-Id: <201302201542.r1KFgJUC2214689@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
In-reply-to: <5122C129.1040507@alum.mit.edu> (pkyzivat@alum.mit.edu)
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> <51229F75.809@alum.mit.edu> <EDC0A1AE77C57744B664A310A0B23AE2107016089A@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <5122C129.1040507@alum.mit.edu>
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: Wed, 20 Feb 2013 15:43:12 -0000

> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
> 
> 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.

That is, I think, an unavoidable problem here.  We can set up a
framework that defines who is permitted to "define the meaning" of a
URN, but "defining the meaning" of a URN has no conseqences at the
level of the operation of the protocol.  All we are doing is providing
guidance to the implementers who they should ask to learn the social
content of a particular URN.  (And we define a bunch of rules
regarding how certain URNs relate to other URNs, which URN is the most
important when processing a set of URNs, etc.)

This is somewhat like priority levels.  We define "emergency",
"urgent", etc., but there are no protocol consequences of those words,
their meaning has an effect only at higher levels of processing.

Dale

From laura.liess.dt@googlemail.com  Thu Feb 21 02:41:00 2013
Return-Path: <laura.liess.dt@googlemail.com>
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 4B57C21F8E5E for <salud@ietfa.amsl.com>; Thu, 21 Feb 2013 02:41:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.69
X-Spam-Level: 
X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[AWL=0.287,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 WjSwdOpG33B4 for <salud@ietfa.amsl.com>; Thu, 21 Feb 2013 02:40:59 -0800 (PST)
Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8977B21F8DDC for <salud@ietf.org>; Thu, 21 Feb 2013 02:40:58 -0800 (PST)
Received: by mail-lb0-f181.google.com with SMTP id gm6so6577545lbb.26 for <salud@ietf.org>; Thu, 21 Feb 2013 02:40:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PC0SWENO+krIJqnCrgzoorGr/YiG6K1TiTi81bDAKLo=; b=LCCb+YFmiOqjLaQnSgaH663L9nMJEyf3Ht+Zx5+5mP/kyp7zDjTLDDKiNWSfOyXZnI 5pSOqceFjbqnIWDP4AsfC4KWdx7CbvaVQmoFbJ53pvho5PV68DlLPNUqVuym8swJtDdC w8s6RXzGSfdLiWR1dQ5md+DBixZRSMSfIQFyj2DP6aBQXHmmqpgMbbGw5eJoX51ARrI+ eEu8IGcAgKXl4rW/pHLV7O1dQ/F5rh6h8MX+6gemLsNXtrQBphY44SEcpV1xTFabZcsY q76pbj21arm+KDE8tHPE08jXnDB8snWu9ddRHXU2DxwBhQHWxB4wBRS8gfXLX0HfxhHk HyxA==
MIME-Version: 1.0
X-Received: by 10.152.123.34 with SMTP id lx2mr20709140lab.52.1361443257388; Thu, 21 Feb 2013 02:40:57 -0800 (PST)
Received: by 10.114.95.99 with HTTP; Thu, 21 Feb 2013 02:40:57 -0800 (PST)
In-Reply-To: <201302181854.r1IIsNFG2067515@shell01.TheWorld.com>
References: <CACWXZj2WhAsmQ3Ku7bVpiNhbFxX7-vx9d9wWzzKgiVLSeKk__g@mail.gmail.com> <201302132105.r1DL5BM01801234@shell01.TheWorld.com> <CACWXZj0Qq=Q=7necdgCPLeFAMbr3gg-WmBb-8UzegseEd_b_Qw@mail.gmail.com> <201302181854.r1IIsNFG2067515@shell01.TheWorld.com>
Date: Thu, 21 Feb 2013 11:40:57 +0100
Message-ID: <CACWXZj2P58HXJUAYQyB_mp9z_-qCCVwKD1jHhcJg6kGxJ5xVng@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: "Dale R. Worley" <worley@ariadne.com>
Content-Type: text/plain; charset=ISO-8859-1
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: Thu, 21 Feb 2013 10:41:00 -0000

Dale,

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?


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

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

Thank you
Laura


2013/2/18 Dale R. Worley <worley@ariadne.com>:
> (as an individual)
>
>> From: Laura Liess <laura.liess.dt@googlemail.com>
>>
>> Thank you for adding the rules. I like them :-). I have following
>> proposals on the two open items.
>
> Thanks!
>
>> > 2) date:  <date> syntax is a subset of ??? in RFC 3339.
>>
>> I would propose following text, which is a modification of the
>> corresponding text in the rfc 4198:
>>
>> "<date> is a date in ISO 8601 Extended Format ([CC]YY["-"MM["-"DD]]),
>> and MUST correspond to a specific day on which the organization
>> allocating the URN owned the domain name specified in the provider-id.
>>  If not included, the default value for MM and DD is "01". "
>
> This looks good to me.  RFC 3339 Appendix A contains the BNF from ISO
> 8061 for comparison.  It might be helpful to include a reference to
> RFC 3339, since it seems to be the RFC people use as a reference for
> date syntax and semantics.
>
> However, there are two parts to this issue.  One is the syntax, which
> you write as:
>
>> "<date> is a date in ISO 8601 Extended Format ([CC]YY["-"MM["-"DD]]),
>> [...]
>>  If not included, the default value for MM and DD is "01". "
>
> We want to add the default for the century as well.  This encompasses
> what I wrote as (2b) and (2c).
>
> And the other is the semantics:
>
>> MUST correspond to a specific day on which the organization
>> allocating the URN owned the domain name specified in the provider-id.
>
> But the semantics is more complicated than that, it includes what I
> wrote as (5a) and (5b):
>
>> > 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.
>
>> > 1) provider-id:  This is intended to match the allowed ABNF for domain
>> > names.  (What is the correct normative reference?  With
>> > internationalization, is our syntax still correct?)
>>
>> This reminds me of Alfred's comment #1 and the discussion
>> http://www.ietf.org/mail-archive/web/salud/current/msg00260.html and
>> previous threads.
>>
>> By then, we (also Alfred) agreed on the following text, based on the RFC 5890:
>>
>> "The <alert-indication>s are hierarchical identifiers.  The set of
>> allowable characters is the same as that for domain names [RFC1123].
>> Labels used in <standard-name> MUST comply with the syntax for Non
>> Reserved LDH-labels [RFC5890].  Labels used in <private-name> 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."
>>
>> However, we changed the syntax since then. IMO, with Dale's the syntax
>> after "name" is deleted,  the second and third sentences in the above
>> text should be modified as follows:
>>
>> " <Label>s used in && <alert-name>s excepting <label>s used in
>> <provider-id>s && MUST comply with the syntax for Non Reserved
>> LDH-labels [RFC5890].  Labels used in &&<provider-id>s&& MUST
>> comply with the syntax for Non Reserved LDH-labels or for A-labels
>> [RFC5890]. " (I put the modified text  between  &&..&&.)
>>
>> We also could used different names for the two types of labels, e.g.
>> "label" and ""provider-id-label", but I am niot sure we want this.
>
> Ah, yes, I'm starting to remember that discussion.
>
> I examine this text (as you have edited it) in detail:
>
>> "The <alert-indication>s are hierarchical identifiers.  The set of
>> allowable characters is the same as that for domain names [RFC1123].
>
> I just looked at RFC 1123, and it doesn't seem to have any BNF.  So
> it's a background reference for domain names, but not really
> normative.  We may want to remove the reference, as the references to
> RFC 5890 below tell the real syntax.
>
>> <Label>s used in <alert-name>s excepting <label>s used in
>> <provider-id>s MUST comply with the syntax for Non Reserved
>> LDH-labels [RFC5890].  Labels used in <provider-id>s MUST
>> comply with the syntax for Non Reserved LDH-labels or for A-labels
>> [RFC5890].
>
> (I use RFC 5890 figure 1 on page 10 as a reference for terms like
> "A-label".)
>
> There are three sorts of strings that we may want to treat separately:
>
> One sort are domain names.  These are called <provider-id> in the
> current BNF.  As far as I can tell from RFC 5890, valid domain names
> (when represented on the wire) must be composed of:
>
> - NR-LDH labels (ordinary ASCII labels that meet certain validity
>   rules, especially not starting with "xn--", which indicates an
>   A-label), and
> - A-labels (non-ASCII labels encoded with Punycode).
>
> The second sort are "privately-defined labels", that is, the <label>
> part of a <private-name> and the <alert-indication>s that are <label>s
> that follow it before the next <private-name>.  These are the ones
> covered by:
>
>     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>.
>
> We probably want to allow these to be internationalized as well.  If
> so, we would define these as "NR-LDH / A-label".
>
> The third sort are the "standardized labels", the <labels> that aren't
> covered by the preceding two categories.  We probably want to
> restrict these to traditional ASCII labels, so their syntax is
> "NR-LDH".
>
> OK, now that I've thought that through, I can compare it with your
> text.  I make the following observations:
>
> - In my listing of rules 1, 2, 3, etc. in
>   http://www.ietf.org/mail-archive/web/salud/current/msg00341.html,
>   though I specify when a <label> *is* defined by a private entity, I
>   don't state when a <label> *is not*, that is, when its definition
>   must be standard.  That would be accomplished by:  "(5x) The meaning
>   of a <label> whose meaning is not defined by an entity according to
>   the rules (5c) and (5d) is defined by standardization."  (That
>   wording is not quite correct.)
>
> - It would make discussion easier if the <label>s within a
>   <provider-id> were a different nonterminal symbol.  Then we could
>   say (taking an example from your text above), "<Label>s MUST comply
>   with the syntax for Non Reserved LDH-labels [RFC5890]." rather than
>   "<Label>s used in <alert-name>s excepting <label>s used in
>   <provider-id>s MUST comply with the syntax for Non Reserved
>   LDH-labels [RFC5890]."
>
> - Your wording "<Label>s ... MUST comply with the syntax for Non
>   Reserved LDH-labels [RFC5890]" means that only "ASCII labels" can be
>   used for privately-defined alert-names.  Do we want this
>   restriction?  Or do we want to allow entities to define
>   "internationalized" alert-names?  To allow internationalization, we
>   would say, "<labels> MUST comply with the syntax for Non Reserved
>   LDH-labels or for A-labels [RFC5890]."
>
> - I'm sure we want to restrict the standardized <label>s to be NR-LDH
>   labels, i.e., ASCII.  We can state such a restriction in the RFC, or
>   we can just assume that we will never define non-ASCII standardized
>   labels.
>
>> Comparisons MUST follow the comparison rules for the
>> corresponding type of label.
>
> I'm taking the comparison rule for internationalized domain names from
> RFC 3490 section 2:
>
>    In IDNA, equivalence of labels is defined in terms of the ToASCII
>    operation, which constructs an ASCII form for a given label, whether
>    or not the label was already an ASCII label.  Labels are defined to
>    be equivalent if and only if their ASCII forms produced by ToASCII
>    match using a case-insensitive ASCII comparison.  ASCII labels
>    already have a notion of equivalence: upper case and lower case are
>    considered equivalent.  The IDNA notion of equivalence is an
>    extension of that older notion.  Equivalent labels in IDNA are
>    treated as alternate forms of the same label, just as "foo" and "Foo"
>    are treated as alternate forms of the same label.
>
> That seems to mean that internationalized labels are compared by first
> converting them into ASCII strings and then comparing the ASCII
> strings case-insensitively.  Since Alert-Info URN domain names are
> already in their ASCII form, this means that the URN domain names can
> just be compared case-insensitively.
>
> And the <label>s that are not part of domain names are also to be
> compared case-insensitively.
>
> So I think we can safely reduce all that to the statement that all
> comparisons are to be done case-insensitively.  It would certainly
> make life easier for implementers if we state that directly.  (I
> suppose we need a reference to RFC 3490 in regard to comparing
> internationalized domain names.)
>
>> 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."
>
> We probably want to make it clear what we are concerned about:
>
>     > Registered URNs MUST be transmitted with the case in which they are
>     > registered. A new name MUST NOT be registered if it is
>     > case-insensitively equal to an already registered name."
>
> (I see that I am using "standardized" where the draft uses
> "registered".)
>
> Dale
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud

From worley@shell01.TheWorld.com  Thu Feb 21 12:27:41 2013
Return-Path: <worley@shell01.TheWorld.com>
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 289EC21F898A for <salud@ietfa.amsl.com>; Thu, 21 Feb 2013 12:27:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 ZZD8ShUs3J59 for <salud@ietfa.amsl.com>; Thu, 21 Feb 2013 12:27:40 -0800 (PST)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3AE21F88E2 for <salud@ietf.org>; Thu, 21 Feb 2013 12:27:40 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1LKRV2i031516; Thu, 21 Feb 2013 15:27:33 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1LKRVmC2303047; Thu, 21 Feb 2013 15:27:31 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1LKRU4D2297154; Thu, 21 Feb 2013 15:27:30 -0500 (EST)
Date: Thu, 21 Feb 2013 15:27:30 -0500 (EST)
Message-Id: <201302212027.r1LKRU4D2297154@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: Laura Liess <laura.liess.dt@googlemail.com>
In-reply-to: <CACWXZj2P58HXJUAYQyB_mp9z_-qCCVwKD1jHhcJg6kGxJ5xVng@mail.gmail.com> (laura.liess.dt@googlemail.com)
References: <CACWXZj2WhAsmQ3Ku7bVpiNhbFxX7-vx9d9wWzzKgiVLSeKk__g@mail.gmail.com> <201302132105.r1DL5BM01801234@shell01.TheWorld.com> <CACWXZj0Qq=Q=7necdgCPLeFAMbr3gg-WmBb-8UzegseEd_b_Qw@mail.gmail.com> <201302181854.r1IIsNFG2067515@shell01.TheWorld.com> <CACWXZj2P58HXJUAYQyB_mp9z_-qCCVwKD1jHhcJg6kGxJ5xVng@mail.gmail.com>
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: Thu, 21 Feb 2013 20:27:41 -0000

(as an individual)

> From: Laura Liess <laura.liess.dt@googlemail.com>
> 
> 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:secure@example.com

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:secure@example.com:top-secret@army.mil

I want to express:

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

2) The additional meaning when "secure@example.com" is added to
"urn:alert:source:internal" is defined by example.com.

3) The additional meaning when "top-secret@army.mil" is added to
"urn:alert:source:internal:secure@example.com" 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,
"secure@example.com" and "top-secret@army.mil" have no meaning in
isolation.

Dale

From pkyzivat@alum.mit.edu  Thu Feb 21 14:23:06 2013
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 6BD8E21E8093 for <salud@ietfa.amsl.com>; Thu, 21 Feb 2013 14:23:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.362
X-Spam-Level: 
X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=0.075,  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 Bl6ZNo1j7UpG for <salud@ietfa.amsl.com>; Thu, 21 Feb 2013 14:23:04 -0800 (PST)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 6B30C21E8045 for <salud@ietf.org>; Thu, 21 Feb 2013 14:22:58 -0800 (PST)
Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta05.westchester.pa.mail.comcast.net with comcast id 31kP1l0030Fqzac55ANxTZ; Thu, 21 Feb 2013 22:22:57 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id 3ANx1l00v3ZTu2S3UANx4Q; Thu, 21 Feb 2013 22:22:57 +0000
Message-ID: <51269E41.1020109@alum.mit.edu>
Date: Thu, 21 Feb 2013 17:22:57 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: salud@ietf.org
References: <CACWXZj2WhAsmQ3Ku7bVpiNhbFxX7-vx9d9wWzzKgiVLSeKk__g@mail.gmail.com> <201302132105.r1DL5BM01801234@shell01.TheWorld.com> <CACWXZj0Qq=Q=7necdgCPLeFAMbr3gg-WmBb-8UzegseEd_b_Qw@mail.gmail.com> <201302181854.r1IIsNFG2067515@shell01.TheWorld.com> <CACWXZj2P58HXJUAYQyB_mp9z_-qCCVwKD1jHhcJg6kGxJ5xVng@mail.gmail.com> <201302212027.r1LKRU4D2297154@shell01.TheWorld.com>
In-Reply-To: <201302212027.r1LKRU4D2297154@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=1361485377; bh=IeXnVRdZJj62/HNFcMu79pbI81FvA6VLS+er+jCfHsk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BXJ5C+SL4DjNGP4ZeyYHAZhVpy8RiJlkjgVOEtwu9uoQ5pHpIqg10jPeLSu/EZaji pE/2jR8cU2Gl4PT15TxTRj7y0Nn6F1SosCAHbt5uWBOVPNbr5l6gP7tjVfp31MRRsR x6yBaRsu0QWEiMotr8ozQ3Nf+aMuOgoCDRi5Qw4w743CuoaBsiUN1hSLghDnArgD5e 2a4dtU3P7+p3jevIrcdRG4Uk2vermg5UL0hRmvtQ47oqZyxukTWGTsG+kFk/jlnFZ3 85w9cefbrsg2+O5n+sqmH46dRW1TAbOJ8IxoxhdRDswJoJo+8LezbpF8kS/3G4j7hn 2I6XYJ3M9FXAQ==
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: Thu, 21 Feb 2013 22:23:06 -0000

On 2/21/13 3:27 PM, Dale R. Worley wrote:
> (as an individual)
>
>> From: Laura Liess <laura.liess.dt@googlemail.com>
>>
>> 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:secure@example.com
>
> 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:secure@example.com:top-secret@army.mil
>
> I want to express:
>
> 1) The meaning of "urn:alert:source:internal" is defined by the standard.
>
> 2) The additional meaning when "secure@example.com" is added to
> "urn:alert:source:internal" is defined by example.com.
>
> 3) The additional meaning when "top-secret@army.mil" is added to
> "urn:alert:source:internal:secure@example.com" 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,
> "secure@example.com" and "top-secret@army.mil" have no meaning in
> isolation.
>
> Dale
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>


From laura.liess.dt@googlemail.com  Fri Feb 22 07:13:36 2013
Return-Path: <laura.liess.dt@googlemail.com>
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 EF3B221F8613 for <salud@ietfa.amsl.com>; Fri, 22 Feb 2013 07:13:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.616
X-Spam-Level: 
X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=0.363,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 kxggg4x02xUP for <salud@ietfa.amsl.com>; Fri, 22 Feb 2013 07:13:36 -0800 (PST)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFCC21F855F for <salud@ietf.org>; Fri, 22 Feb 2013 07:13:35 -0800 (PST)
Received: by mail-la0-f52.google.com with SMTP id fs12so708939lab.25 for <salud@ietf.org>; Fri, 22 Feb 2013 07:13:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jmKPdPOTAmXCiS4nMBXMqgGU9I5MWtMldevRvph/ZK4=; b=ARV7HQ5NY+olZWrubUDZMmAHjf4eDLfSkr4Z/TSgnkFjebHnhfitwhKBlrCiyx+TdJ 8SdCU4zxPXVmvK4b73WbHubFysCcPKNUrKaj4Go3D0QykCyP6ARRyRYNmu71MvOWvPVI t0D/v9VKF/tXnRfCguIcoKu/BP+h95a5yosKfU/L2ITyOGmN0xOqJypMTYNvtPPtI7ll ++uMX+IS+zBmPW5f/r32Vb6nJQj6HPjiFWiRLPuYbBclAvtJZdM0KRJpLOrDCVJw3oug I8vIE5NkPKh/hISK0e8ikLf3OPJbRNw+3tr0m7jWtmljtJwjwMKnH0MdWvii4k5du5j3 3zgA==
MIME-Version: 1.0
X-Received: by 10.152.104.80 with SMTP id gc16mr2031995lab.49.1361546014400; Fri, 22 Feb 2013 07:13:34 -0800 (PST)
Received: by 10.114.95.99 with HTTP; Fri, 22 Feb 2013 07:13:34 -0800 (PST)
In-Reply-To: <201302212027.r1LKRU4D2297154@shell01.TheWorld.com>
References: <CACWXZj2WhAsmQ3Ku7bVpiNhbFxX7-vx9d9wWzzKgiVLSeKk__g@mail.gmail.com> <201302132105.r1DL5BM01801234@shell01.TheWorld.com> <CACWXZj0Qq=Q=7necdgCPLeFAMbr3gg-WmBb-8UzegseEd_b_Qw@mail.gmail.com> <201302181854.r1IIsNFG2067515@shell01.TheWorld.com> <CACWXZj2P58HXJUAYQyB_mp9z_-qCCVwKD1jHhcJg6kGxJ5xVng@mail.gmail.com> <201302212027.r1LKRU4D2297154@shell01.TheWorld.com>
Date: Fri, 22 Feb 2013 16:13:34 +0100
Message-ID: <CACWXZj1txwpeCFqAJrJQpL845BNswyvm651WABGULr0DuEwF3A@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: "Dale R. Worley" <worley@ariadne.com>
Content-Type: text/plain; charset=ISO-8859-1
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: Fri, 22 Feb 2013 15:13:37 -0000

Dale,

2013/2/21 Dale R. Worley <worley@ariadne.com>:
> (as an individual)
>
>> From: Laura Liess <laura.liess.dt@googlemail.com>
>>
>> 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:secure@example.com
>
> 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:secure@example.com:top-secret@army.mil
>
> I want to express:
>
> 1) The meaning of "urn:alert:source:internal" is defined by the standard.
>
> 2) The additional meaning when "secure@example.com" is added to
> "urn:alert:source:internal" is defined by example.com.
>
> 3) The additional meaning when "top-secret@army.mil" is added to
> "urn:alert:source:internal:secure@example.com" 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,
> "secure@example.com" and "top-secret@army.mil" 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

From worley@shell01.TheWorld.com  Fri Feb 22 10:26:02 2013
Return-Path: <worley@shell01.TheWorld.com>
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 E606B21F86E8 for <salud@ietfa.amsl.com>; Fri, 22 Feb 2013 10:26:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.211
X-Spam-Level: 
X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=0.769,  BAYES_00=-2.599, GB_I_LETTER=-2, J_BACKHAIR_31=1, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 BORZDwHTdChr for <salud@ietfa.amsl.com>; Fri, 22 Feb 2013 10:26:02 -0800 (PST)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id C95E021F84E2 for <salud@ietf.org>; Fri, 22 Feb 2013 10:26:01 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r1MIOqH7017568; Fri, 22 Feb 2013 13:24:54 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r1MIOpHu2387764; Fri, 22 Feb 2013 13:24:51 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r1MIOpqh2386335; Fri, 22 Feb 2013 13:24:51 -0500 (EST)
Date: Fri, 22 Feb 2013 13:24:51 -0500 (EST)
Message-Id: <201302221824.r1MIOpqh2386335@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: Laura Liess <laura.liess.dt@googlemail.com>
In-reply-to: <CACWXZj1txwpeCFqAJrJQpL845BNswyvm651WABGULr0DuEwF3A@mail.gmail.com> (laura.liess.dt@googlemail.com)
References: <CACWXZj2WhAsmQ3Ku7bVpiNhbFxX7-vx9d9wWzzKgiVLSeKk__g@mail.gmail.com> <201302132105.r1DL5BM01801234@shell01.TheWorld.com> <CACWXZj0Qq=Q=7necdgCPLeFAMbr3gg-WmBb-8UzegseEd_b_Qw@mail.gmail.com> <201302181854.r1IIsNFG2067515@shell01.TheWorld.com> <CACWXZj2P58HXJUAYQyB_mp9z_-qCCVwKD1jHhcJg6kGxJ5xVng@mail.gmail.com> <201302212027.r1LKRU4D2297154@shell01.TheWorld.com> <CACWXZj1txwpeCFqAJrJQpL845BNswyvm651WABGULr0DuEwF3A@mail.gmail.com>
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: Fri, 22 Feb 2013 18:26:03 -0000

(as an individual)

> From: Laura Liess <laura.liess.dt@googlemail.com>
> 
> 2013/2/21 Dale R. Worley <worley@ariadne.com>:
> > 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.

I agree with you and Paul now.

Let me propose this:  We restrict private alert labels to be NR-LDH
labels (ordinary ASCII labels) at this time.  Later, we can amend the
standard to allow A-labels (internationalized labels).  Processing
software should not be confused if it sees an A-label as a private
alert label, because their syntax is very similar to NR-LDH labels.

Better, let us add a requirement that processing software MUST be able
to cope with internationalized <alert-label>s, even though we do not
now allow them:

After the text where we state the restrictions on the labels, such as:

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

Add:

    However, processes that interpret these URNs MUST correctly
    process URNs even if they contain arbitrary LDH labels as
    <alert-label>s.  (Of necessity, the process will not understand a
    URN containing an <alert-label> that is not a Non Reserved
    LDH-label, and so that <alert-label> and any following
    <alert-label>s will be ignored per the rules of Section 8.1.)

(Note:  An "LDH label" is what is normally called "an ordinary ASCII
label".  From RFC 5890:

   2.3.1.  LDH Label

   This is the classical label form used, albeit with some additional
   restrictions, in hostnames [RFC0952].  Its syntax is identical to
   that described as the "preferred name syntax" in Section 3.5 of RFC
   1034 [RFC1034] as modified by RFC 1123 [RFC1123].  Briefly, it is a
   string consisting of ASCII letters, digits, and the hyphen with the
   further restriction that the hyphen cannot appear at the beginning or
   end of the string.  Like all DNS labels, its total length must not
   exceed 63 octets.

)

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

Yes, I think that split would make describing the semantic
restrictions simpler.

We might want to replace <toplabel> with <domain-label>.  It is true
that the final label in a domain name is much more restricted, but we
do not need to define or enforce that restriction in our document.

> > I don't quite know how to express this, because, as you point out,
> > "secure@example.com" and "top-secret@army.mil" 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.

I am sure you are right that we have to be very accurate.

Let me try with this:

In section 4, the namespace registration template, there is this
paragraph:

      The<alert-indication>s are hierarchical identifiers.  The set of
      allowable characters is the same as that for domain names
      [RFC1123].  Labels used in <standard-name> MUST comply with the
      syntax for Non Reserved LDH-labels [RFC5890].  Labels used in
      <private-name> 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.

This is the only place where we mention the fact that alert-info URNs
are hierarchical -- and we do not explain exactly what "hierarchical"
means.

Let us separate the first sentence into a separate paragraph, and add
this text to describe what "hierarchical" means:

      The <alert-indication>s are hierarchical identifiers.  An
      <alert-URN> asserts some fact or feature of the offered SIP
      dialog, or some fact or feature of how it should be presented to
      a user, or of how it is being presented to a user.  Removing an
      <alert-identifier> from a URN creates shorter a URN with a less
      specific meaning; the set of dialogs to which the longer URN
      applies is necessarily a subset of the set of dialogs to which
      the shorter URN applies.  (If first URN contains only one
      <alert-indication>, then the larger set is considered to be the
      set of all dialogs.)

      The specific criteria defining the subset to which the longer
      URN applies, within the larger set of dialogs, is considered to
      be the meaning of the <alert-indication>.  This meaning is
      relative to and depends upon the preceding <alert-category> and
      <alert-indication>s (if any).  The meanings of two
      <alert-indication>s that are textually the same but are
      preceded by different <alert-category>s or <alert-indication>s
      have no necessary connection.  (An <alert-category> considered
      alone has no meaning.)

      The entity owning <provider> defines the meaning of a <private-name>
      that is used as an <alert-indication>.

      The entity owning the <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> that
      follows that <private-name> and that precedes the next
      <alert-indication> which is a <private-name> (if any).

      The meaning of all other <alert-indication>s is defined by
      standardization.

Dale
