Re: [salud] Updates to section 6

[Paul Kyzivat <[e-mail]>]

Dale,

I'm now lost in all the diffs. Can you send a complete version?

	Thanks,
	Paul

On 3/29/13 4:53 AM, Dale R. Worley wrote:
> 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 <[e-mail]>
>>
>>> +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
>
>
> ----------------------------------------------------------------------
>