Subject: [salud] Default alert-indications for each alert-category

From: [email-masked] (Dale R. Worley)
Date: Thu, 14 Feb 2013 16:04:10 -0500 (EST)

(as an individual)

There are a number of URNs that we have defined which specify the
ordinary or default alternative of an alert-category.  The examples I
find are:

    urn:alert:service:normal
    urn:alert:source:unclassified
    urn:alert:priority:normal
    urn:alert:priority:normal
    urn:alert:duration:normal
    urn:alert:delay:none
    urn:alert:locale:default

For example, for urn:alert:service, there are these choices:

   - normal
   - call-waiting
   - forward
   - recall:callback
   - recall:hold
   - recall:transfer

(I do not list <private-name>, because all categories include private
names, and we have specified how <private-name>s are to be handled in
various situations.)

I expect that the effect of <urn:alert:service:normal> is the same as
having no urn:alert:service:* URN.

The question I am discussing here is whether this is somehow an
"incorrect" way to organize the URNs, whether we should remove the
definition of these "ordinary" URNs, because they do not specify any
particular information about the call, so if the user does not want to
specify a "service" classification, they should omit any such URN.

One argument in favor of keeping these URNs is that they correspond
well to how people think about choices like this; people tend to think
of any choice as having a specific choice which is also a default, and
that specifying no choice is the same as specifying the default.

The big question:  How does having a default alternative interact with
the rules and algorithms for rendering signals?

In regard to the rules of section 8.1, I do not see any difficulty, as
the UA is given great freedom to determine which signals are indicated
by which combinations of URNs.

In regard to the non-normative algorithm of section 9, I believe that
the proper handling is this:

Let us assume that there is one signal for the default service:
NORMAL.  There are also signals for all the non-default services:
CALL-WAITING, FORWARD, RECALL-CALLBACK, RECALL-HOLD, and
RECALL-TRANSFER.

There is a tree for the category "service", and we place each signal
in the proper place to show its meaning and correspondence with URNs:

    service----+----normal
    NORMAL     |
               |
               +----call-waiting
               |    CALL-WAITING
               |
               +----forward
               |    FORWARD
               |
               +----recall----+----callback
	                      |    RECALL-CALLBACK
	                      |
	                      +----hold
	                      |    RECALL-HOLD
	                      |
	                      +----transfer
                                   RECALL-TRANSFER

The reason that NORMAL is placed at the root of the "service" tree is
that NORMAL isn't specific, you can render NORMAL even when there is
no urn:alert:service:* URN.  All of the other signals are selected
only when there is a URN specifically for their category.

The result of this assignment is if no service URN is present, NORMAL
is selected in preference to the other signals because it is "less
specific" than the others.  However, if one of the other service URNs
is present, then its signal is sorted before NORMAL, and it will be
selected in preference to NORMAL.

OK, now that I look for it, the example in section 9.2.5 shows exactly
this construction.

This discussion convinces me that there is no difficulty with the
rules and algorithms if we define the "default" URNs.  (Using the
algorithm in section 9 requires properly setting up the signals, but
we have given the users an example of that.)  And I believe that it is
psychologically nicer to provide a way of specifying the default
condition.

Do other people agree?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Feb 2013 17:56:27 -0500

What you say here seems reasonable to me.

But a new issue is introduced by allowing private-names as categories.
Is there some similar sort of defaulting in that case? If so, now is it 
specified?

	Thanks,
	Paul

On 2/14/13 4:04 PM, Dale R. Worley wrote:
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 15 Feb 2013 16:27:30 -0500 (EST)

(as an individual)

> From: Paul Kyzivat <[email-masked]>
> 

As we have described things now, there is no guaranteed default for
alert-categories that are private-names.  No default default, as it
were.

But whoever defines such a category can define a label to be the
alert-indication that is the default value.  Of course, to obtain the
correct effect, the UA interpreting the URNs has to understand the
structure of the alert-category, and in particular, the meaning of
that alert-indication.

Hmmm...  I suppose one can always construct a URN whose
alert-indication is guaranteed to not be defined by the definer of the
private-name by using one's own private-name!  Example:  Assume that
example.com defines an alert-category [email-masked], defining URNs
of this form:

    urn:alert:[email-masked]:...

I, the owner of example.net, can create this URN:

    urn:alert:[email-masked]:[email-masked]

An interpreting UA will process that much like it will process
urn:alert:locale:country, because example.com never defined the
alert-indication [email-masked] for the alert-category
[email-masked].

I'm not sure there is any practical use for such a URN.  I suppose you
could add it to the beginning of the Alert-Info values to prevent any
later urn:alert:[email-masked]:* URNs from having any effect.  But it
would be simpler to remove any such URNs from the list of values.

Dale