[salud] Updates to section 6
worley@ariadne.com (Dale R. Worley) Thu, 28 March 2013 00:40 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 E8E9621F8B0C for <salud@ietfa.amsl.com>; Wed, 27 Mar 2013 17:40:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.679
X-Spam-Level:
X-Spam-Status: No, score=-0.679 tagged_above=-999 required=5 tests=[AWL=-1.299, 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, 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 eAxfjdKaCBwl for <salud@ietfa.amsl.com>; Wed, 27 Mar 2013 17:40:04 -0700 (PDT)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id CB74321F85C9 for <salud@ietf.org>; Wed, 27 Mar 2013 17:40:03 -0700 (PDT)
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 r2S0dhgt031440 for <salud@ietf.org>; Wed, 27 Mar 2013 20:39:45 -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 r2S0df671300307 for <salud@ietf.org>; Wed, 27 Mar 2013 19:39:43 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2S0deO01302294; Wed, 27 Mar 2013 20:39:40 -0400 (EDT)
Date: Wed, 27 Mar 2013 20:39:40 -0400
Message-Id: <201303280039.r2S0deO01302294@shell01.TheWorld.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: salud@ietf.org
Subject: [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 00:40:05 -0000
I suggest the following edits to section 6 to clarify the registration process and to align the syntax terminology with the new ABNF. The changes are marked in the left margin with "-" and "+". I have a number of questions and comments at the beginning of this text. Comments? Dale ---------------------------------------------------------------------- --- 07-section-6 2013-03-27 20:09:39.713133697 -0400 +++ 07-updated-section-6 2013-03-27 20:35:12.872213564 -0400 @@ -1,224 +1,250 @@ +[[ Where did this rule come from? + Each <alert-category> or <alert-indication> label MUST NOT exceed 27 + characters. + Can/should we maintain this rule given that we allow punycode labels + in FQDNs? + (I have a memory that there is a restriction on host name labels to + be no longer than 27 characters, but I could not find that stated + in any RFC.) + +I've removed "and the rules to combine them [i.e., <alert-label>s]" +from the description at the beginning of section 6.1 because for +registered URNs, the only rule needed is "use only the combinations +listed in the registry". + +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. + +I've removed the entries like this: + + service:<private-name> RFC XXXX Reserved for private + extensions + +because they are not enabled by the registration process, but rather +by the extension rules of section 7. + +]] + 6. IANA Considerations - This section registers a new URN namespace identifier (NID) in + 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. New alert identifiers - Alert URN identifiers are identified by <label>s managed by IANA, - according to the processes outlined in [RFC5226] in a new registry - called "Alert URN Labels". Thus, creating a new Alert-Info URN - identifier requires IANA action. The policy for adding a new alert - category is 'Standards Action'. (This document defines the alert - categories 'service', 'source', 'priority', 'duration', 'delay' and - 'locale'. ) The policy for assigning <label>s to <alert-indication>s - and the rules to combine them may differ for each <alert-category> - and MUST be defined by the document describing the corresponding - alert category. The entries in the registration table have the - following format: + Standard "alert" URN identifiers 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. 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: - <alert-category>/ Reference Description - <alert-identifier>; + <alert-category> or Reference Description + <alert-identifier> --------------------------------------------------------------- foo RFCxyz Description of the 'foo' - <alert-category>; + <alert-category> foo:bar RFCabc Description of the 'foo:bar' <alert-identifier> Each <alert-category> or <alert-indication> label MUST NOT exceed 27 characters. Liess, et al. Expires April 5, 2013 [Page 18] Internet-Draft Alert-Info URNs October 2012 6.2. Initial IANA Registration 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>/ Reference Description + <alert-category> or Reference Description <alert-identifier> ----------------------------------------------------------- service RFC XXXX <alert-category> for "service" <alert-identifier>s 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>/ Reference Description + <alert-category> or Reference Description <alert-identifier> ----------------------------------------------------------- source RFC XXXX <alert-category> for "source" <alert-identifier>s 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 - source:<private-name> RFC XXXX Reserved for private - extensions 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>/ Reference Description + <alert-category> or Reference Description <alert-identifier> ----------------------------------------------------------- priority RFC XXXX <alert-category> for "priority" <alert-identifier>s priority:normal RFC XXXX Normal ring /rinback rendering (default value) priority:low RFC XXXX Low priority call. priority:high RFC XXXX High priority call - priority:<private-name> RFC XXXX Reserved for private - extensions 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>/ Reference Description + <alert-category> or Reference Description <alert-identifier> ----------------------------------------------------------- duration RFC XXXX <alert-category> for "duration" <alert-identifier>s duration:normal RFC XXXX Normal ring /rinback rendering (default value) duration:short RFC XXXX Shorter than normal duration:long RFC XXXX Longer than normal - duration:<private-name> RFC XXXX Reserved for private - extensions. 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 the delay of the alerting - signals. + indicator provides information about whether the presentation of the + alerting signal should be delayed compared to the default + presentation process. - <alert-category>/ Reference Description + <alert-category> or Reference Description <alert-identifier> ----------------------------------------------------------- delay RFC XXXX <alert-category> for "delay" <alert-identifier> delay:none RFC XXXX Immediate alerting (default value) delay:yes RFC XXXX Delayed alerting - delay:<private-name> RFC XXXX Reserved for private - extensions 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. Liess, et al. Expires April 5, 2013 [Page 21] Internet-Draft Alert-Info URNs October 2012 - <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 ----------------------------------------------------------------------
- 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