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
- [dispatch] New version for the Alert-Info URNs dr… L.Liess
- Re: [dispatch] New version for the Alert-Info URN… Paul Kyzivat
- Re: [dispatch] [BLISS] New version for the Alert-… Elwell, John
- Re: [dispatch] New version for the Alert-Info URN… L.Liess
- Re: [dispatch] New version for the Alert-Info URN… Paul Kyzivat
- Re: [dispatch] [BLISS] New version for the Alert-… L.Liess
- Re: [dispatch] [BLISS] New version for the Alert-… Elwell, John
- Re: [dispatch] New version for the Alert-Info URN… L.Liess
- Re: [dispatch] New version for the Alert-Info URN… Paul Kyzivat
- Re: [dispatch] New version for the Alert-Info URN… Dean Willis
- Re: [dispatch] New version for the Alert-Info URN… Paul Kyzivat
- Re: [dispatch] New version for the Alert-Info URN… Dean Willis
- Re: [dispatch] New version for the Alert-Info URN… Paul Kyzivat
- Re: [dispatch] New version for the Alert-Info URN… Alan Johnston
- Re: [dispatch] New version for the Alert-Info URN… Alan Johnston
- Re: [dispatch] New version for the Alert-Info URN… Francois AUDET
- Re: [dispatch] New version for the Alert-Info URN… Paul Kyzivat
- Re: [dispatch] New version for the Alert-Info URN… L.Liess
- Re: [dispatch] New version for the Alert-Info URN… Paul Kyzivat
- Re: [dispatch] New version for the Alert-Info URN… Adam Roach
- Re: [dispatch] New version for the Alert-Info URN… Adam Roach
- Re: [dispatch] New version for the Alert-Info URN… Paul Kyzivat
- Re: [dispatch] New version for the Alert-Info URN… L.Liess
- Re: [dispatch] New version for the Alert-InfoURNs… Spencer Dawkins