Subject: [salud] Updates to section 6

From: [email-masked] (Dale R. Worley)
Date: Wed, 27 Mar 2013 20:39:40 -0400 (EDT)

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Mar 2013 23:40:00 +0800

Hi Dale,

Comments inline.

> I have a number of questions and comments at the beginning of this

I don't know. I see no reason to keep it.

> +listed in the registry".

OK.

> +the standard <alert-category>s.  And I do not remember what we decided

Note I commented on a related issue re "local" 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.)

> +by the extension rules of section 7.

OK

[snip]

> + <alert-category> or           Reference  Description

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?

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Thu, 28 Mar 2013 20:51:24 +0100

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

Thank you
Laura

2013/3/28 Dale R. Worley <[email-masked]>

> I have a number of questions and comments at the beginning of this

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.

+

+
> +the standard <alert-category>s.

 And I do not remember what we decided

> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: Laura Liess <[email-masked]>
Date: Thu, 28 Mar 2013 21:10:46 +0100

The  "locale:country:<ISO 3166-1 country code> " seems to be some kind of
different and difficult.

Now that we have the "private-name " stuff working fine, why not use it for
country specific tones? Instead of "urn:alert:locale:country:de:foo:bar"
    we would have "urn:alert:foo@de:bar".   Or is something wrong with it?

Laura

2013/3/28 Paul Kyzivat <[email-masked]>

>> ------------------------------**------------------------------**
>> ----------
> "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.
>
> 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.)
>
>
>>    ------------------------------**-----------------------------
>> ------------------------------**------------------------------**
>> ----------
>>
>
> 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?
>
> the IANA table, but rather are implicitly included by reference. How do we
> say that?
>
>         Thanks,
>         Paul
>
>
> ______________________________**_________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/salud<https://www.ietf.org/mailman/listinfo/salud>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Mar 2013 04:33:17 +0800

On 3/29/13 4:10 AM, Laura Liess wrote:
> The  "locale:country:<ISO 3166-1 country code> " seems to be some kind
> of different and difficult.
>
> Now that we have the "private-name " stuff working fine, why not use it
> for country specific tones? Instead of
> "urn:alert:locale:country:de:foo:bar"     we would have
> "urn:alert:foo@de:bar".   Or is something wrong with it?

I presume you mean urn:alert:locale:[email-masked]"?

I see several problems with that:

- there is no .bar TLD. :-)
   perhaps you meant: [email-masked] ??
   The existence of country-specific TLDs could be exploited.

- but then each country-specific private name would require an owner.
   We aren't in a position to become the owner for all of those,
   and I don't know how we could recruit anyone to do it.

- then they would all be private names. Where would they be
   specified?

I think we just need to fiddle with the words to deal with this.

	Thanks,
	Paul

> Laura
>
>
> 2013/3/28 Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>>
>
>     Hi Dale,
>
>     Comments inline.
>
>
>         ------------------------------__------------------------------__----------
>     Note I commented on a related issue re "local" 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.
>
>     subordinate to any of the <alert-category>s defined in *this*
>     document is Standards Action.
>
>             ------------------------------__-----------------------------
>         ------------------------------__------------------------------__----------
>
>
>     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?
>
>              Thanks,
>              Paul
>
>
>     _________________________________________________
>     salud mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/salud
>     <https://www.ietf.org/mailman/listinfo/salud>
>
>
>
>

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 28 Mar 2013 16:53:01 -0400 (EDT)

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 <[email-masked]>
> 
> Note I commented on a related issue re ["locale"] below. *That* category 
----------------------------------------------------------------------
--- 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 @@
 
-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.

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

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

   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>

   <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

   <alert-category> or           Reference  Description
   <alert-identifier>
   source                        RFC XXXX  Classification of the other
                                           party 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

   <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

   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

   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.

 <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

---

From: Laura Liess <[email-masked]>
Date: Fri, 29 Mar 2013 12:29:02 +0100

Paul,

> I presume you mean urn:alert:locale:[email-masked]"?

  I didn't meant "bar" being part of the <provider-id>, I just meant  foo
and bar being the <alert-label>s  of a German country-specific tone and
using the country code top level domain "de" as a <provider-id>, but it's
true, I don't know who could be the owner.

However, in this specification we don't define or register any particular
national tone, we expect national companies or organisations and national
standardization bodies to do it. We could require anybody who defines
national tones to be owner of a subdomain of the respective country code
top level domain which he must use as <provider-id> for the tone. In many
cases, national tones are defined by big phone companies anyway.

But I don't know, maybe this doesn't work at all and it was just a bad
idea.  Then let's forget it.

Thank you
Laura

>> <mailto:[email-masked]>**>
>>
>>
>>     Hi Dale,
>>
>>     Comments inline.
>>
>>
>>         ------------------------------**__----------------------------**
>> --__----------
>>
>>             ------------------------------**
>> __----------------------------**-
>>
>>         ------------------------------**__----------------------------**
>> --__----------
>>
>>
>>
>>     ______________________________**___________________
>>     salud mailing list
>>     https://www.ietf.org/mailman/_**_listinfo/salud<https://www.ietf.org/mailman/__listinfo/salud>
>>     <https://www.ietf.org/mailman/**listinfo/salud<https://www.ietf.org/mailman/listinfo/salud>
>> >
>>
>>
>>
>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Mar 2013 21:52:05 +0800

Dale,

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

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 29 Mar 2013 14:01:28 -0400 (EDT)

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

Here is the complete text of what I call "update 2" for section 6.

]]

6.  IANA Considerations

6.1.  Registry

Best regards,

Dale