From laura.liess.dt@googlemail.com Tue Apr 2 07:28:49 2013 Return-Path: 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 E3A5D21F8B19 for ; Tue, 2 Apr 2013 07:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Z1A6v8wJfK-g for ; Tue, 2 Apr 2013 07:28:49 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9292621F8B15 for ; Tue, 2 Apr 2013 07:28:48 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id u10so542209lbi.3 for ; Tue, 02 Apr 2013 07:28:47 -0700 (PDT) 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=fYf4ZuMebbDIsuP8npky7rLECdThGL2+x81QNleKHaM=; b=GatKxgUR+/Juust4O+cWHEFneb8eroijv+/Quk9MaFKuQE96F3Yd2PMfUZybEZzS2X yrkn313xXSEYqJY/ML3rg1ML0O//kuFhyCPR0z5lIn1tUVPOwJsu//RQ1j7CP2rl+r0i 9Fkm7zPGmyvb78bo5bu/e7Z9JOJbvatdyiR33EAWfMNWt6wsBeqImxIsWUEdt4nDTHf/ vAdsfbq6NTSJcW0ggI0P3hypIJLm3HMlRX6Lt9CWhVUR4ae6RBN9lR71PTmI0NLQALEk HpnAoXks16P+nvEviRbjTFQ5k9w+ugFC5kvAhE5UOZpcuN7iUopZIOaQxd5zBkWHA5/7 EWPA== MIME-Version: 1.0 X-Received: by 10.112.84.228 with SMTP id c4mr7703653lbz.113.1364912927184; Tue, 02 Apr 2013 07:28:47 -0700 (PDT) Received: by 10.114.95.99 with HTTP; Tue, 2 Apr 2013 07:28:47 -0700 (PDT) In-Reply-To: <201303291939.r2TJdAr81421114@shell01.TheWorld.com> References: <201303291939.r2TJdAr81421114@shell01.TheWorld.com> Date: Tue, 2 Apr 2013 16:28:47 +0200 Message-ID: From: Laura Liess To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=f46d04016b3b2ca2e804d9618e9e Cc: "salud@ietf.org" Subject: Re: [salud] (no subject) X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 14:28:50 -0000 --f46d04016b3b2ca2e804d9618e9e Content-Type: text/plain; charset=ISO-8859-1 2013/3/29 Dale R. Worley > > > > The "locale:country: " seems to be some kind of > > different and difficult. > > > > Now that we have the "private-name " stuff working fine, why not use it > for > > country specific tones? Instead of "urn:alert:locale:country:de:foo:bar" > > we would have "urn:alert:foo@de:bar". Or is something wrong with > it? > > E.g., > > That is an interesting idea. But we have a lot of apparatus regarding > s, so we would either need to make an exception for > domains that contained only one label, or to designate some > organization that is responsible for each country-TLD. > This was the initial idea, but we we don't have and can not designate organizations responsible for country-TLDs. We could require that country-specific alert URNs must be defined by some organization or working group in this country (this is the case anyway) and this national organisation or working group or an organisation designated by the working group must define the country-specific alert URN using the "private-name" mechanism and to be the owner of the used. But if we can get the format "locale:country:" to work properly we should stay with this format and avoid new changes. Maybe it is just a wording problem. > > > From: Laura Liess > > > > However, in this specification we don't define or register any particular > > national tone, we expect national companies or organisations and national > > standardization bodies to do it. We could require anybody who defines > > national tones to be owner of a subdomain of the respective country code > > top level domain which he must use as for the tone. In many > > cases, national tones are defined by big phone companies anyway. > > Fortunately, the "locale" URNs don't describe sensory aspects of > signals but semantic ones. So while indicates > that the signal should be rendered using German conventions, each > device interprets those conventions separately. > > In practice, I don't think the "locale" URNs will get a great deal of > use, because in many cases one UA will not know if another UA > implements any particular "locale" URN. > I am not sure. The requirement for defining a lot of US-specific tones came from Adam Roach. We didn't want to define all these tones in this specification because we didn't have the necessary expertise but instead we defined the urn:alert:locale:country: mechanism. Thank you Laura > > Dale > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > --f46d04016b3b2ca2e804d9618e9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



2013/3/29 Dale R. Worley <worley@ariadne.com>
>
> The =A0"locale:country:<ISO 3166-1 country code> " see= ms to be some kind of
> different and difficult.
>
> Now that we have the "private-name " stuff working fine, why= not use it for
> country specific tones? Instead of "urn:alert:locale:country:de:f= oo:bar"
> =A0 =A0 we would have "urn:alert:foo@de:bar". =A0 Or is some= thing wrong with it?

E.g., <urn:alert:service:call-waiting@de>

That is an interesting idea. =A0But we have a lot of apparatus regarding <private-name>s, so we would either need to make an exception for
domains that contained only one label, or to designate some
organization that is responsible for each country-TLD.

This was the initial idea, but we we don't have and can not design= ate organizations responsible for country-TLDs.
We could require that c= ountry-specific alert URNs must be defined by some organization or working = group in this country (this is the case anyway) and this national organisat= ion or working group or an organisation designated by the working group mus= t define the country-specific alert URN using the "private-name" = mechanism and to be the owner of the <provider-id> used.

=A0But if we can get the format "locale:country:<ISO= 3166-1 country code>" to work properly we should stay with this fo= rmat and avoid new changes. Maybe it is just a wording problem.

=A0=

> From: Laura Liess <laura.liess.dt@googlemail.com>
>
> However, in this specification we don't define or register any par= ticular
> national tone, we expect national companies or organisations and natio= nal
> standardization bodies to do it. We could require anybody who defines<= br> > national tones to be owner of a subdomain of the respective country co= de
> top level domain which he must use as <provider-id> for the tone= . In many
> cases, national tones are defined by big phone companies anyway.

Fortunately, the "locale" URNs don't describe sensory aspects= of
signals but semantic ones. =A0So while <urn:locale:country:de> indica= tes
that the signal should be rendered using German conventions, each
device interprets those conventions separately.

In practice, I don't think the "locale" URNs will get a great= deal of
use, because in many cases one UA will not know if another UA
implements any particular "locale" URN.
=A0<= /div>
I am not sure. The requirement for defining a lot of US-specific = tones came from Adam Roach. We didn't want to define all these tones in= this specification because we didn't have the necessary expertise but = instead we defined the urn:alert:locale:country:<ISO 3166-1 country code= > mechanism.

Thank you
Laura
=A0

Dale
_______________________________________________
salud mailing list
salud@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/salud

--f46d04016b3b2ca2e804d9618e9e-- From pkyzivat@alum.mit.edu Tue Apr 2 08:19:41 2013 Return-Path: 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 2123821F88E3 for ; Tue, 2 Apr 2013 08:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.163 X-Spam-Level: X-Spam-Status: No, score=0.163 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.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 a2jjuqPBTC0P for ; Tue, 2 Apr 2013 08:19:40 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 4931021F86A6 for ; Tue, 2 Apr 2013 08:19:40 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta01.westchester.pa.mail.comcast.net with comcast id K1oy1l00417dt5G513KfSF; Tue, 02 Apr 2013 15:19:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id K3Kf1l00F3ZTu2S3Z3KfUC; Tue, 02 Apr 2013 15:19:39 +0000 Message-ID: <515AF70A.4060603@alum.mit.edu> Date: Tue, 02 Apr 2013 23:19:38 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Dale R. Worley" References: <201303280039.r2S0deO01302294@shell01.TheWorld.com> <51546450.5010306@alum.mit.edu> <201303282053.r2SKr1ah1360213@shell01.TheWorld.com> <51559C85.5090908@alum.mit.edu> <201303291801.r2TI1STv1417761@shell01.TheWorld.com> In-Reply-To: <201303291801.r2TI1STv1417761@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=1364915979; bh=3T3SlEo67RbJqhmPFsLR/9ilu8/N2jbIlz8+qRD+Qvw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qDYOlr26tI4MOhGGLQBiCcmrZadnGxjWdyLiTfJX34JW4htwrslEFjvtYeloDKkTJ v/YZqXLBMP5jTxOAu11tCMEGylxf5WEale+VaDhzsACvIpHH3AmObTZYS3nF8CYqIO dZm0KhFkSpdvIBaRr650xIyyQjM7HNWLLjUP3tpW/dTf+otdp0VB6OqKYGt9vJUILq U3QEWh4xImLAAIqn3LoeSmgiO7M/gC9aiyEhQL+Ux5f+ctkhIT/IHK9qMHdB4PA72g 1C39XWXTVGNBPaqQFrMGPd3DQFfaZ4b96eicFmZhzGrsF91fnZSJ14b56C+bPcesYi PmONfS6Y4OB0Q== Cc: salud@ietf.org Subject: Re: [salud] Update 2 to section 6 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 15:19:41 -0000 On 3/30/13 2:01 AM, Dale R. Worley wrote: >> From: Paul Kyzivat >> >> I'm now lost in all the diffs. Can you send a complete version? > > Here is the complete text of what I call "update 2" for section 6. Thx. > ---------------------------------------------------------------------- > [[ > Here are revisions to the registrations to fix the problem Paul > identified, which is that the registration for locale:country:XX is > really a pattern, not a specific . I've revised the > text to allow registration of *patterns* of . > > I've moved the words regarding the registration policies -- in 6.1 is > the generic policy information, and in 6.2 is the policy information > about our 6 s. However, I don't know what policy we > want for new entries for our s. > > I've removed the rule about labels being <= 27 characters. > > In the registration entries for the s, I've changed > the descriptions to provide a brief description of what the category > means. > > ]] > > 6. IANA Considerations > > This section registers a new URN namespace identifier (NID), "alert", in > accordance with RFC 3406 with the registration template provided in > Section 4. > > 6.1. Registry > > Standard "alert" URNs are identified by > s managed by IANA, according to the processes > outlined in [RFC5226], in a new registry called "Alert URN > Identifiers". Thus, creating a new standard "alert" URN requires > IANA action. > > The registry contains: (1) values, (2) > values, composed of an followed > by an , in turn composed of one or more > s, and (3) patterns for values > (e.g., for the "locale" in Section 6.2.6). > > The policy for adding a new is 'Standards Action'. > The policy for adding s or patterns of > s within a particular may > differ for each and MUST be defined by the > document defining the corresponding . > > > Liess, et al. Expires April 5, 2013 [Page 18] > > Internet-Draft Alert-Info URNs October 2012 > > > 6.2. Initial IANA Registration > > This document defines the s 'service', 'source', > 'priority', 'duration', 'delay' and 'locale'. The policy for > adding an for any of these s is > 'xxx'. > > *** Should this policy be "Standards Action", "RFC Required", or > "Specification Required"? I am inclined to say "Standards Action" because RFC Required is a little loose, and Specification Required needs an expert, and then we would need to write some guidelines for the expert. While Standards Action may be overly restrictive I think it is better to start out that way and change it later if there is need. > The entries to be added to the registration table have the > following format: > > > or Reference Description > > --------------------------------------------------------------- > foo RFCxyz Description of the 'foo' > > foo:bar RFCabc Description of the 'foo:bar' > I think we need a bit more in support of patterns. E.g. foo:bar: RFCabc Description of a pattern, detailed in the referenced document, that matches multiple values. (I'm not in love with that description.) [snip] > 6.2.6. The "locale" alert-category and alert-identifiers > > The following table contains the initial IANA registration for the > "locale" and s. The value of this > indicator provides information suggests that alerting signals > characteristic of the specified location should be used. > > > > > > > > > > > > > > > Liess, et al. Expires April 5, 2013 [Page 21] > > Internet-Draft Alert-Info URNs October 2012 > > > or Reference Description > > ----------------------------------------------------------- > locale RFC XXXX Location-specific alerting > signals > locale:default RFC XXXX Alerting not location > specific > (default value) > locale:country: > RFC XXXX Alerting according to the > conventions of the specified > country > > > ---------------------------------------------------------------------- Thanks, Paul From pkyzivat@alum.mit.edu Tue Apr 2 08:20:55 2013 Return-Path: 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 1492B21F8935 for ; Tue, 2 Apr 2013 08:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 1rx6b2+6eAjb for ; Tue, 2 Apr 2013 08:20:54 -0700 (PDT) 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 569F521F86A6 for ; Tue, 2 Apr 2013 08:20:54 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta03.westchester.pa.mail.comcast.net with comcast id Jz651l00H0ldTLk533Ltbj; Tue, 02 Apr 2013 15:20:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id K3Lt1l00B3ZTu2S3Q3Ltgn; Tue, 02 Apr 2013 15:20:53 +0000 Message-ID: <515AF755.5000301@alum.mit.edu> Date: Tue, 02 Apr 2013 23:20:53 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: salud@ietf.org References: <201303291936.r2TJafcx1420955@shell01.TheWorld.com> In-Reply-To: <201303291936.r2TJafcx1420955@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=1364916053; bh=KFWR7/EA5eEGX33w0iqm8uLOB0F/cfrnGOYB/fQ9vX4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=buBoUetnUL++7eRqgD1s2m/6X+jXJriyIOmRIF+NSHNJshb8OsMbU7bXsJai5lMPe I5/dHbC8qtgIk05BkvIPvIyxk6ZWyPTQNspf6aA7PaY/6W1TNsvGxcOGFxonZPRKCG 14GsSv6c1P/tukMZbPTPyYvXhU0GWn5nRM0CVydJgGnEfvw4Anhv7KjlrbWFtp+85h S6IAs4co99VfD8yisCUkfrAal3Vyf+JqkrY0M53VuwOVWqFKT5YCq5+3iKx08FT5qo wRW+/LD5N4gyMpy4vu1PQAE1HgHq6QjhM4Rg7VltIS/ZvHHdkOw1KKc9Ee8vzXs10W /embTXKEETpLw== Subject: Re: [salud] defaulting in comparisons X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 15:20:55 -0000 On 3/30/13 3:36 AM, Dale R. Worley wrote: > [as an individual] > > If I remember correctly, we agreed that using date defaults in > s would not make the URNs "not equal". That is, we want > > urn:alert:service:call-waiting:abc@somecompany.example.com > > urn:alert:service:call-waiting:abc@somecompany.example.com(2013-01-01) > > to compare equal. That was my understanding. Thanks, Paul > If this is true, we have to adjust the wording in the namespace > registration template. > > Dale > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > From laura.liess.dt@googlemail.com Wed Apr 3 04:53:20 2013 Return-Path: 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 CB7FB21F850C for ; Wed, 3 Apr 2013 04:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 JhWcIvkzBD8b for ; Wed, 3 Apr 2013 04:53:19 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5723421F84CC for ; Wed, 3 Apr 2013 04:53:19 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id u10so1496077lbi.17 for ; Wed, 03 Apr 2013 04:53:12 -0700 (PDT) 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=I6WI5vI8m5V7fbi5Wp0vS0iGKISmFOtC9duXMKyABvk=; b=k3pKHXIHZnSRe77SfZrrLjvFg8qu+hnuuANMBWMrZtVtIBdQVzSDxDgTfrMBQ88+Oo LbJ8A66NMkOtVTlTorJVxUpalC5uUElHR6/lOarOBVSiwK/ct8Bsv83qN0pV/jUgsqlr Pq0/YnCAb1EfukNdcsV+dvKF+PiuuIM1MuoYv8q1pNTyf90t6AXCuev0YnracpXvY7kM 6cJiMdeHe1t8ycuCeVUhn7lzaKnpgsvkkJ3LYFkJdxdPGsLQ7U5RA1FjNeCm/nNXONYm 8MXJx45EoOeV4TzvtZ7A/8eXOHseekofCfCTLGKXL43ZGPo8CSYm4Ul/ToU8uCrK8prk NiPw== MIME-Version: 1.0 X-Received: by 10.112.146.34 with SMTP id sz2mr949523lbb.4.1364989992353; Wed, 03 Apr 2013 04:53:12 -0700 (PDT) Received: by 10.114.95.99 with HTTP; Wed, 3 Apr 2013 04:53:12 -0700 (PDT) In-Reply-To: <201303291937.r2TJb2bq1421580@shell01.TheWorld.com> References: <201303291937.r2TJb2bq1421580@shell01.TheWorld.com> Date: Wed, 3 Apr 2013 13:53:12 +0200 Message-ID: From: Laura Liess To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=047d7b3a85c89dc94d04d9737ff5 Cc: salud@ietf.org Subject: Re: [salud] Section 7 update X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 11:53:20 -0000 --047d7b3a85c89dc94d04d9737ff5 Content-Type: text/plain; charset=ISO-8859-1 Dale, I read the text and I am OK with it. 2013/3/29 Dale R. Worley ..................................... > > > Within a URN, all components that follow a > but are before any following s are > additional private extensions whose meaning is defined by the > organization defining the . > > A URN that contains a private extension can be further subdivided > by the private extension of a different organization: the second > organization adds a component containing a > that is valid for the second organiztiion. > > *** In the next paragraph, I use , but we really need a > syntax term for "an that is an . > We need to look into that. > The note applies to the penultimate paragraph, doesn't it? In this case, I think it is quite clear from the text what is meant. Thank you Laura --047d7b3a85c89dc94d04d9737ff5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dale,
I read the text and I am OK with it.=A0

2013/3/29 Dale R. Worley <worley@ariadne.com>
=
.....................................


=A0 =A0Within a URN, all <alert-label> components that follow a
=A0 =A0<private-name> but are before any following <private-name&g= t;s are
=A0 =A0additional private extensions whose meaning is defined by the
=A0 =A0organization defining the <private-name>.

=A0 =A0A URN that contains a private extension can be further subdivided =A0 =A0by the private extension of a different organization: =A0the second<= br> =A0 =A0organization adds a <private-name> component containing a
=A0 =A0<provider> that is valid for the second organiztiion.

*** In the next paragraph, I use <alert-label>, but we really need a<= br> =A0 =A0 syntax term for "an <alert-ind-part> that is an <aler= t-label>.
=A0 =A0 We need to look into that.
=A0

T= he note applies to the penultimate paragraph, doesn't it? In this case,= I think it is quite clear from the text what is meant.

Thank you Laura

=A0

--047d7b3a85c89dc94d04d9737ff5-- From R.Jesske@telekom.de Wed Apr 3 05:01:06 2013 Return-Path: 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 5624821F8B11 for ; Wed, 3 Apr 2013 05:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 xxQJ7xrMA-zQ for ; Wed, 3 Apr 2013 05:01:05 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id A42C521F8B0C for ; Wed, 3 Apr 2013 05:01:03 -0700 (PDT) Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 03 Apr 2013 14:01:01 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 3 Apr 2013 14:00:49 +0200 From: To: , Date: Wed, 3 Apr 2013 14:00:49 +0200 Thread-Topic: [salud] Section 7 update Thread-Index: Ac4wYdiw39JkPuT8TM6/LE202bhjlwAAPQAA Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D16E6424732@HE111648.emea1.cds.t-internal.com> References: <201303291937.r2TJb2bq1421580@shell01.TheWorld.com> In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_580BEA5E3B99744AB1F5BFF5E9A3C67D16E6424732HE111648emea1_" MIME-Version: 1.0 Cc: salud@ietf.org Subject: Re: [salud] Section 7 update X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 12:01:06 -0000 --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D16E6424732HE111648emea1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dale, from my side +1. -Roland ________________________________ Von: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] Im Auftrag von = Laura Liess Gesendet: Mittwoch, 3. April 2013 13:53 An: Dale R. Worley Cc: salud@ietf.org Betreff: Re: [salud] Section 7 update Dale, I read the text and I am OK with it. 2013/3/29 Dale R. Worley > ..................................... Within a URN, all components that follow a but are before any following s are additional private extensions whose meaning is defined by the organization defining the . A URN that contains a private extension can be further subdivided by the private extension of a different organization: the second organization adds a component containing a that is valid for the second organiztiion. *** In the next paragraph, I use , but we really need a syntax term for "an that is an . We need to look into that. The note applies to the penultimate paragraph, doesn't it? In this case, I = think it is quite clear from the text what is meant. Thank you Laura --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D16E6424732HE111648emea1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Dale,
from my side +1.
 
-Roland

Von: salud-bounces@ietf.org=20 [mailto:salud-bounces@ietf.org] Im Auftrag von Laura=20 Liess
Gesendet: Mittwoch, 3. April 2013 13:53
An: Dal= e R.=20 Worley
Cc: salud@ietf.org
Betreff: Re: [salud] Sectio= n 7=20 update

Dale,
I read the text and I am OK with it. 

2013/3/29 Dale R. Worley <worley@ariadne.com>

................= .....................


   Within a URN, all <alert-labe= l>=20 components that follow a
   <private-name> but are b= efore=20 any following <private-name>s are
   additional priv= ate=20 extensions whose meaning is defined by the
   organization= =20 defining the <private-name>.

   A URN that conta= ins a=20 private extension can be further subdivided
   by the priv= ate=20 extension of a different organization:  the second
 =20  organization adds a <private-name> component containing=20 a
   <provider> that is valid for the second=20 organiztiion.

*** In the next paragraph, I use <alert-label&g= t;,=20 but we really need a
    syntax term for "an=20 <alert-ind-part> that is an <alert-label>.
   = We=20 need to look into that.
 

The note applies to the penultimate paragraph, doesn't it? In th= is=20 case, I think it is quite clear from the text what is meant.

Than= k=20 you
Laura


 

--_000_580BEA5E3B99744AB1F5BFF5E9A3C67D16E6424732HE111648emea1_-- From worley@shell01.TheWorld.com Wed Apr 17 19:36:06 2013 Return-Path: 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 CE94A21E80EE for ; Wed, 17 Apr 2013 19:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 Axi5pHbukl+n for ; Wed, 17 Apr 2013 19:36:05 -0700 (PDT) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 112CE21E80ED for ; Wed, 17 Apr 2013 19:36:04 -0700 (PDT) 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 r3I2ZGYe015210 for ; Wed, 17 Apr 2013 22:35:18 -0400 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 r3I2ZGIF2909589 for ; Wed, 17 Apr 2013 22:35:16 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3I2ZFYk2907972; Wed, 17 Apr 2013 22:35:15 -0400 (EDT) Date: Wed, 17 Apr 2013 22:35:15 -0400 (EDT) Message-Id: <201304180235.r3I2ZFYk2907972@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: salud@ietf.org Subject: [salud] Section 8, updated X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 02:36:07 -0000 My apologies, I've been neglecting the draft recently. Here is an update of section 8. There are a few changes to clarify the wording (in my opinion), and some to make the terminology and algorithm match the new ABNF and the technical changes. Note that the algorithmic part is simplified significantly! 8. Combinations of Alert-Info URNs 8.1. Priority Rules This section describes combination rules for the case when all the - Alert-Info header fields only contain Alert-Info URNs. Combinations - of URNs and URIs in the Alert-Info header fields of the same SIP- + Alert-Info header fields only contain Alert-Info URNs. Other combinations + of URIs in the Alert-Info header fields of the same SIP message are not defined in this specification. - In many cases, more than one URNs will be needed to fully define a + In many cases, more than one URN will be needed to fully define a particular tone. This is done by including multiple Alert-Info URNs, in one or more Alert-Info header fields in a request or a response. - For example, an internal, priority call could be indicated by Alert- - Info: , . A - priority call waiting tone could be indicated by Alert-Info: - , . + For example, an internal, priority call could be indicated by + + Alert-Info: , + + A priority call waiting tone could be indicated by + + Alert-Info: , The sender of the Alert-Info header may include an arbitrary list of Alert-Info URNs, even if they are redundant or contradictory. An earlier URN has priority over any later contradictory URN. This allows any element to modify a list of URNs to require a feature value (by adding a URN at the beginning of the list) or to suggest a feature value (by adding a URN at the end of the list). - The receiving UA attempts to match the received Alert-Info URNs + The receiving UA matches the received Alert-Info URN combination with the signal(s) it is able to render. - The implementation is free to ignore any or all parts of the received - Alert-Info URNs. The exact way in which a UA renders a received + The implementation is free to ignore an Alert-Info URN if it does + not recognize the URN, or if it is incapable of rendering its + effect in the context. Similarly, it can remove a final series of + one or more s of an Alert-Info URN to create a + "more generic" URN which it recognizes and whose meaning it can + render in the context. + + The exact way in which a UA renders a received combination of Alert-Info URNs is left as an implementation issue. However, the implementation MUST comply to following rules: a. Each alert-info URN has precedence over all URNs that follow it, and its interpretation is subordinate to all URNs that precede it. b. If the UA cannot implement the effect of a URN (because it does not recognize the URN or the URN's effect is precluded by - preceding URNs), the UA repeatedly removes either - - (1) the final of the URN, or - - (2) if the final is a with three or more -