Re: [salud] Updates to section 6

[Laura Liess <[e-mail]>]

Dale,
One comment inline. Otherwise  I like your changes.

Thank you
Laura

2013/3/28 Dale R. Worley <[e-mail]>

> 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.)


The very first version of the draft in bliss was intended, as far as I
know, to be very similar  to RFC 5031. RFC 5031 Section 4.1. contains this
restriction. "To allow use within the constraints of S-NAPTR [RFC3958], all
top-level service names MUST NOT exceed 27 characters." But the alert URNs
don't have anything to do with S_NAPTR, so I think we can remove the
restriction.




+
> +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
> ----------------------------------------------------------------------
> _______________________________________________
> salud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/salud
>