[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
----------------------------------------------------------------------