Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt

Adam Roach <adam@nostrum.com> Fri, 06 November 2009 14:15 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 785923A6AA1 for <dispatch@core3.amsl.com>; Fri, 6 Nov 2009 06:15:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.608
X-Spam-Level:
X-Spam-Status: No, score=-1.608 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, SPF_PASS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuxJ1mUcVHG1 for <dispatch@core3.amsl.com>; Fri, 6 Nov 2009 06:15:22 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 40FCF3A69FD for <dispatch@ietf.org>; Fri, 6 Nov 2009 06:15:22 -0800 (PST)
Received: from host-144-65.meeting.ietf.org (host-144-65.meeting.ietf.org [133.93.144.65]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nA6EFev6091062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <dispatch@ietf.org>; Fri, 6 Nov 2009 08:15:43 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <4AF36AA9.20409@nostrum.com>
Date: Fri, 06 Nov 2009 09:15:37 +0900
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4
MIME-Version: 1.0
To: dispatch@ietf.org
References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4ADCCF93.2070208@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A003885F8F@S4DE9JSAANI.ost.t-com.de> <4ADFB028.3010604@cisco.com> <40FB0FFB97588246A1BEFB05759DC8A0038FD976@S4DE9JSAANI.ost.t-com.de>
In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A0038FD976@S4DE9JSAANI.ost.t-com.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 133.93.144.65 is authenticated by a trusted mechanism)
Subject: Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Nov 2009 14:15:23 -0000

On 10/28/09 6:22 PM, L.Liess@telekom.de wrote:
> I will take this as an open issue for the dispatch meeting slides. I
> hope Adam will be there because it was his proposal to use combinations
> of discrete items rather than hierarchy.

Sorry for not following this more closely.

At this point, I think we have two different things to tease apart: (1) 
The semantics for combining different dimensions of ringback, and (2) 
the syntax for combining these dimensions.

We really need to understand the first one before we start quibbling 
over the second one. So, while I do have some thoughts about the syntax, 
I'm not going to go into them -- even a little bit -- until we have a 
better grip on the semantic problem.

Here's an important point that Paul raises:
> It seems that what you propose is a multidimensional space, where 
> every point in that space is potentially rendered uniquely. But in 
> practice values will often be supplied for some but not all of the 
> dimensions. In that case we end up specifying some "slice" of the 
> array. I guess in this case you could look to see what you would 
> render for each point in the slice. If those are all identical, then 
> you are in good shape. But if they are not, then what? Do you pick one 
> of the points? That amounts to choosing a default value for each 
> unspecified dimension. Is that the right answer? 

I agree. We're effectively defining an n-dimensional space, and assuming 
that a point can be selected with fewer than n ordinals. And, yes, I 
think the correct answer is simply defining a default value for every 
new dimension defined -- preferably within the specification of the 
dimension itself (although some things, like country indication, would 
probably be better handled as local policy). Then, you can specify a 
value for as few as zero of the dimensions, and still have the answer be 
a point.

The other side of that coin is that clients receiving this information 
will not necessarily understand (or care to support) all of the 
dimensions being presented. I believe that this is handled on the 
recipient's part by ignoring any dimensions it does not understand.

However, I think that Paul's characterization of the difference between 
the previous approach and the current approach isn't correct:
> It seems like what you must be doing is replacing a hierarchy with an 
> N-dimensional matrix which is sparsely populated. That seems harder to 
> deal with. 

I don't agree that it is sparsely populated. Many of the points might 
result in the same answer, but that doesn't mean it's sparsely 
populated. I think you could take the current draft and (modulo the 
issues with 7.3.3) pick any value from each of the three dimensions at 
random, and have a semantically sensible ringtone. Here; I'll roll the 
dice a couple of times: Internal short Brazilian ringback. External 
priority Pakistani ringback. You can play along at home -- find me an 
empty space in the matrix, and I'll concede the point.

So, quite to the contrary, I think the two approaches are *semantically* 
identical, and the only difference between what was proposed before and 
what is proposed now is a *superficial* and *syntactic* difference. If 
you need proof, I'll write a quick perl script that converts between the 
two syntactic representations. :)

/a