Re: [salud] Updates to section 6
worley@ariadne.com (Dale R. Worley) Thu, 28 March 2013 20:54 UTC
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 5375621F89C3 for <salud@ietfa.amsl.com>; Thu, 28 Mar 2013 13:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.585
X-Spam-Level:
X-Spam-Status: No, score=0.585 tagged_above=-999 required=5 tests=[AWL=-2.335, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, MANGLED_LIST=2.3, 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 R7jyy+kfe4xh for <salud@ietfa.amsl.com>; Thu, 28 Mar 2013 13:54:02 -0700 (PDT)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 745D721F893B for <salud@ietf.org>; Thu, 28 Mar 2013 13:54:02 -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 r2SKr2eP021259; Thu, 28 Mar 2013 16:53:04 -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 r2SKr2fP1348851; Thu, 28 Mar 2013 15:53:02 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2SKr1ah1360213; Thu, 28 Mar 2013 16:53:01 -0400 (EDT)
Date: Thu, 28 Mar 2013 16:53:01 -0400
Message-Id: <201303282053.r2SKr1ah1360213@shell01.TheWorld.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
In-reply-to: <51546450.5010306@alum.mit.edu> (pkyzivat@alum.mit.edu)
References: <201303280039.r2S0deO01302294@shell01.TheWorld.com> <51546450.5010306@alum.mit.edu>
Cc: salud@ietf.org
Subject: Re: [salud] Updates 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 <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, 28 Mar 2013 20:54:04 -0000
Yes, this is more complicated than I thought. I think we need to update the text to take care of these issues. Following is (1) Paul's comments that I am addressing, (2) a diff showing my suggested additional updates, and (3) the resulting version of section 6. Best regards, Dale ---------------------------------------------------------------------- > From: Paul Kyzivat <pkyzivat@alum.mit.edu> > > > +We say "The policy for adding <alert-indication>s may differ for each > > +<alert-category> and MUST be defined by the document describing the > > +corresponding <alert-category>." But we do not state the policy for > > +the standard <alert-category>s. And I do not remember what we decided > > +that policy should be. > > Note I commented on a related issue re ["locale"] below. *That* category > needs a different rule from all the others, in that subordinates to > "local:country" may not be registered via the iana process. But I > suppose alternatives to default and country may be added as in any other. > > Otherwise I suggest we just specify that adding <alert-indication>s > subordinate to any of the <alert-category>s defined in *this* document > is Standards Action. > > Or we could take the easy way out and simply say that its Standards > Action for everything. (Except for private ones of course.) > > > 6.2.6. The "locale" alert-category and alert-identifiers > > > > The following table contains the initial IANA registration for the > > "locale" <alert-category> and <alert-identifier>s. The value of this > > - indicator provides information about the location of the user at the > > - other side of the call. > > + indicator provides information suggests that alerting signals > > + characteristic of the specified location should be used. > > > > - <alert-category>/ Reference Description > > + <alert-category> or Reference Description > > <alert-identifier> > > ----------------------------------------------------------- > > locale RFC XXXX <alert-category> > > for "locale" <alert-identifier> > > locale:default RFC XXXX Alerting not location > > specific > > (default value) > > locale:country:<ISO 3166-1 country code> > > RFC XXXX Country-specific alerting > > - locale:<private-name> RFC XXXX Reserved for private > > - extensions > > ---------------------------------------------------------------------- > > I'm wondering about the registration for country codes. I don't know if > it is clear here what IANA should do. Does this mean: > > - IANA should go out and get a copy of the ISO 3166-1 list and populate > it into their own table? > > - Specific country codes must be registered by some specification, but > must conform to 3166-1? > > Clearly we *intend* that individual country codes will not be listed in > the IANA table, but rather are implicitly included by reference. How do > we say that? ---------------------------------------------------------------------- --- 07-updated-section-6 2013-03-27 20:35:12.000000000 -0400 +++ 07-updated2-section-6 2013-03-28 14:55:15.979625380 -0400 @@ -1,30 +1,21 @@ +[[ +These differences are from the previous updated section 7. +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 <alert-identifier>. I've revised the +text to allow registration of *patterns* of <alert-identifier>. + +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 <alert-category>s. However, I don't know what policy we +want for new entries for our <alert-category>s. + +I've removed the rule about labels being <= 27 characters. + +In the registration entries for the <alert-category>s, I've changed +the descriptions to provide a brief description of what the category +means. ]] @@ -34,48 +25,53 @@ accordance with RFC 3406 with the registration template provided in Section 4. -6.1. New alert identifiers +6.1. Registry - Standard "alert" URN identifiers are identified by + Standard "alert" URNs are identified by <alert-identifier>s managed by IANA, according to the processes - outlined in [RFC5226] in a new registry called "Alert URN + outlined in [RFC5226], in a new registry called "Alert URN Identifiers". Thus, creating a new standard "alert" URN requires + IANA action. - IANA action. Each registered <alert-identifier> is composed of an - <alert-category> followed by an <alert-indication> composed of one - or more <alert-label>s, as described in Section 4. - - The policy for adding a new <alert-category> is 'Standards Action'. - (This document defines the <alert-category>s 'service', 'source', - 'priority', 'duration', 'delay' and 'locale'. ) The policy for - adding <alert-indication>s (sequences of <alert-label>s for use - with a particular <alert-category>) may differ for each - <alert-category> and MUST be defined by the document defining the - corresponding <alert-category>. The entries in the registration - table have the following format: + The registry contains: (1) <alert-category> values, (2) + <alert-identifier> values, composed of an <alert-category> followed + by an <alert-indication>, in turn composed of one or more + <alert-label>s, and (3) patterns for <alert-identifier> values + (e.g., for the "locale" <alert-category> in Section 6.2.6). + The policy for adding a new <alert-category> is 'Standards Action'. + The policy for adding <alert-identifier>s or patterns of + <alert-identifier>s within a particular <alert-category> may + differ for each <alert-category> and MUST be defined by the + document defining the corresponding <alert-category>. - <alert-category> or Reference Description - <alert-identifier> - --------------------------------------------------------------- - foo RFCxyz Description of the 'foo' - <alert-category> - foo:bar RFCabc Description of the 'foo:bar' - <alert-identifier> - - Each <alert-category> or <alert-indication> label MUST NOT exceed 27 - characters. 6.2. Initial IANA Registration + This document defines the <alert-category>s 'service', 'source', + 'priority', 'duration', 'delay' and 'locale'. The policy for + adding an <alert-identifier> for any of these <alert-category>s is + 'xxx'. +*** Should this policy be "Standards Action", "RFC Required", or + "Specification Required"? + The entries to be added to the registration table have the + following format: + <alert-category> or Reference Description + <alert-identifier> + --------------------------------------------------------------- + foo RFCxyz Description of the 'foo' + <alert-category> + foo:bar RFCabc Description of the 'foo:bar' + <alert-identifier> 6.2.1. The "service" alert-category and alert-identifiers @@ -88,10 +84,9 @@ <alert-category> or Reference Description <alert-identifier> ----------------------------------------------------------- - service RFC XXXX <alert-category> - for "service" - <alert-identifier>s - service:normal RFC XXXX Normal ring /rinback + service RFC XXXX Specific telephony + service used in this call + service:normal RFC XXXX Normal ring/rinback rendering (default value) service:call-waiting RFC XXXX Call waiting was initiated at the other side @@ -134,9 +129,8 @@ <alert-category> or Reference Description <alert-identifier> ----------------------------------------------------------- - source RFC XXXX <alert-category> - for "source" - <alert-identifier>s + source RFC XXXX Classification of the other + party to the call source:unclassified RFC XXXX Unclassified ring /rinback rendering (default value) source:internal RFC XXXX User at the other side of @@ -160,8 +154,7 @@ <alert-category> or Reference Description <alert-identifier> ----------------------------------------------------------- - priority RFC XXXX <alert-category> for - "priority" <alert-identifier>s + priority RFC XXXX Priority of the call priority:normal RFC XXXX Normal ring /rinback rendering (default value) priority:low RFC XXXX Low priority call. @@ -186,9 +179,7 @@ <alert-category> or Reference Description <alert-identifier> ----------------------------------------------------------- - duration RFC XXXX <alert-category> - for "duration" - <alert-identifier>s + duration RFC XXXX Duration of alerting signal duration:normal RFC XXXX Normal ring /rinback rendering (default value) duration:short RFC XXXX Shorter than normal @@ -205,8 +196,8 @@ <alert-category> or Reference Description <alert-identifier> ----------------------------------------------------------- - delay RFC XXXX <alert-category> for "delay" - <alert-identifier> + delay RFC XXXX Delay of rendering of alerting + signal delay:none RFC XXXX Immediate alerting (default value) delay:yes RFC XXXX Delayed alerting @@ -239,12 +230,14 @@ <alert-category> or Reference Description <alert-identifier> ----------------------------------------------------------- - locale RFC XXXX <alert-category> - for "locale" <alert-identifier> + locale RFC XXXX Location-specific alerting + signals locale:default RFC XXXX Alerting not location specific (default value) locale:country:<ISO 3166-1 country code> - RFC XXXX Country-specific alerting + RFC XXXX Alerting according to the + conventions of the specified + country ---------------------------------------------------------------------- [[ 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 <alert-identifier>. I've revised the text to allow registration of *patterns* of <alert-identifier>. 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 <alert-category>s. However, I don't know what policy we want for new entries for our <alert-category>s. I've removed the rule about labels being <= 27 characters. In the registration entries for the <alert-category>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 <alert-identifier>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) <alert-category> values, (2) <alert-identifier> values, composed of an <alert-category> followed by an <alert-indication>, in turn composed of one or more <alert-label>s, and (3) patterns for <alert-identifier> values (e.g., for the "locale" <alert-category> in Section 6.2.6). The policy for adding a new <alert-category> is 'Standards Action'. The policy for adding <alert-identifiers>s or patterns of <alert-identifiers>s within a particular <alert-category> may differ for each <alert-category> and MUST be defined by the document defining the corresponding <alert-category>. 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 <alert-category>s 'service', 'source', 'priority', 'duration', 'delay' and 'locale'. The policy for adding an <alert-identifier> for any of these <alert-category>s is 'xxx'. *** Should this policy be "Standards Action", "RFC Required", or "Specification Required"? The entries to be added to the registration table have the following format: <alert-category> or Reference Description <alert-identifier> --------------------------------------------------------------- foo RFCxyz Description of the 'foo' <alert-category> foo:bar RFCabc Description of the 'foo:bar' <alert-identifier> 6.2.1. The "service" alert-category and alert-identifiers The following table contains the initial IANA registration for the "service" <alert-category> and <alert-identifier>s. The value of this indicator is set to a value different from "normal" if the caller or callee is informed that a specific telephony service has been initiated. <alert-category> or Reference Description <alert-identifier> ----------------------------------------------------------- service RFC XXXX Specific telephony service used in this call service:normal RFC XXXX Normal ring/rinback rendering (default value) service:call-waiting RFC XXXX Call waiting was initiated at the other side of the call service:forward RFC XXXX Call has been forwarded service:recall:calback RFC XXXX Recall due to callback service:recall:hold RFC XXXX Recall due to call hold service:recall:transfer RFC XXXX Recall due to callback service:<private-name> RFC XXXX Reserved for private extensions 6.2.2. The "source" alert-category and alert-identifiers The following table contains the initial IANA registration for the "source" <alert-category> and <alert-identifier>. The value of this indicator provides information about the user at the other side of the call. Liess, et al. Expires April 5, 2013 [Page 19] Internet-Draft Alert-Info URNs October 2012 <alert-category> or Reference Description <alert-identifier> ----------------------------------------------------------- source RFC XXXX Classification of the other party to the call source:unclassified RFC XXXX Unclassified ring /rinback rendering (default value) source:internal RFC XXXX User at the other side of the call is internal to the enterprise or PBX system source:external RFC XXXX User at the other side of the call is internal to the enterprise or PBX system source:friend RFC XXXX User at the other side of the call is a friend source:family RFC XXXX User at the other side of the call is a family member 6.2.3. The "priority" alert-category and alert-identifiers The following table contains the initial IANA registration for the "priority" <alert-category> and <alert-identifier>s. The value of this indicator provides information about the priority the alerted user should give to the call. <alert-category> or Reference Description <alert-identifier> ----------------------------------------------------------- priority RFC XXXX Priority of the call priority:normal RFC XXXX Normal ring /rinback rendering (default value) priority:low RFC XXXX Low priority call. priority:high RFC XXXX High priority call 6.2.4. The "duration" alert-category and alert-identifiers The following table contains the initial IANA registration for the "duration" <alert-category> and <alert-identifier>s. The value of this indicator provides information about the duration of the alerting signals compared to the default alerting signals. Liess, et al. Expires April 5, 2013 [Page 20] Internet-Draft Alert-Info URNs October 2012 <alert-category> or Reference Description <alert-identifier> ----------------------------------------------------------- duration RFC XXXX Duration of alerting signal duration:normal RFC XXXX Normal ring /rinback rendering (default value) duration:short RFC XXXX Shorter than normal duration:long RFC XXXX Longer than normal 6.2.5. The "delay" alert-category and alert-identifiers The following table contains the initial IANA registration for the "delay" <alert-category> and <alert-identifier>s. The value of this indicator provides information about whether the presentation of the alerting signal should be delayed compared to the default presentation process. <alert-category> or Reference Description <alert-identifier> ----------------------------------------------------------- delay RFC XXXX Delay of rendering of alerting signal delay:none RFC XXXX Immediate alerting (default value) delay:yes RFC XXXX Delayed alerting 6.2.6. The "locale" alert-category and alert-identifiers The following table contains the initial IANA registration for the "locale" <alert-category> and <alert-identifier>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 <alert-category> or Reference Description <alert-identifier> ----------------------------------------------------------- locale RFC XXXX Location-specific alerting signals locale:default RFC XXXX Alerting not location specific (default value) locale:country:<ISO 3166-1 country code> RFC XXXX Alerting according to the conventions of the specified country ----------------------------------------------------------------------
- Re: [salud] Updates to section 6 Laura Liess
- [salud] Updates to section 6 Dale R. Worley
- Re: [salud] Updates to section 6 Paul Kyzivat
- Re: [salud] Updates to section 6 Laura Liess
- Re: [salud] Updates to section 6 Laura Liess
- Re: [salud] Updates to section 6 Paul Kyzivat
- Re: [salud] Updates to section 6 Dale R. Worley
- Re: [salud] Updates to section 6 Paul Kyzivat
- Re: [salud] Update 2 to section 6 Dale R. Worley
- Re: [salud] Update 2 to section 6 Paul Kyzivat