[dispatch] Conceptual proposal for extensibility of Alert-Info URNs

["WORLEY, Dale R (Dale)" <[e-mail]>]

[As I am the chair-elect for this topic, I now have to identify that I
am proposing this as an individual contributor-elect.]

This is a conceptual proposal for for specifying Alert-Info URNs.  The
problem that I am attacking is extensibility -- because the practical
application of the Alert-Info URNs will be as successors of the
ring tone and ringback tone implementations of innumerable existing
telephone systems, we expect the uses of Alert-Info URNs to be subject
to much extension.  The primary problem is to provide a framework
which allows such extensions to be implemented without damaging
interoperability between systems whose Alert-Info usage has not been
coordinated a priori.  A secondary problem is to ensure that the
framework can be implemented efficiently in practical situations.

The basis of this proposal has been stolen from previous contributors
to the Alert-Info work.

Since this is a conceptual proposal, I am not particular about the
syntax to be used -- the syntax shown here is just to illustrate the
concepts.  What I am proposing is a system of semantics; many variant
syntaxes can be used to implement it with differing tradeoffs.

* Terminology

We say that a "specifier" sends an "indication" (a URN in an
Alert-Info header) to a "renderer" which then "renders" a "signal"
based on the indication to a human user.  A "category" is a
characteristic whose "values" can be used to classify indications.

* Requirements and non-requirements

Requirement A:  Indications must be able to represent a wide variety
of signals, which have many largely-orthogonal characteristics.  (See
draft-liess-dispatch-alert-info-urns-00 section section 2 for a
partial list, and Paul Kyzivat's message for another partial list.)

Requirement B:  Indications include subsets which have distinctly
different semantics, that is, they form disjoint "value spaces".  For
example, some indications should describe the semantics of the
signaling situation whereas others should describe the audio
characteristics of the signal.  This implies that there is no single
set of categories that can be used as independent coordinates of the
value-space of indications.

Requirement C:  The set of indications must be able to support
extensibility by a wide variety of organizations that are not
coordinated with each other.  Extensions must be able to:

- add further values to any existing category

- add further categories that are orthogonal to existing categories

- semantically subdivide the meaning provided by any existing
  indication

- add further "value spaces" of indications whose semantics are not
  related to existing indications, and thus, whose categories differ
  from and do not interact with existing categories

Requirement D:  An indication is transmitted from a specifier to a
renderer, which must base its rendering decision only on the
indication.  In particular, there is no multi-message negotiation
process or carrying of context from one indication to the next.

Requirement E:  The renderer may be customized in ways that limit the
set of signals that it can render, or it may be provided with a set of
signals that have uncommon semantics.  (The canonical example is a UA
for the hearing-impaired.)  (By Requirement D, the renderer has no way
of transmitting this fact to the specifier.)

Requirement F:  If the specifier and the renderer have designs that
are properly coordinated, the indications must be able to reliably
carry all extensions that are supported in the coordinated designs.

Requirement G:  In any situation, the renderer must be able to perform
close to the best possible rendering that it could do even the
specifier had specific knowledge of the renderer's capabilities.

Non-Requirement H:  In any situation other than that of Requirement F,
we do not require the render to perform the best possible rendering.

* Categories, values, and indicators

There are a theoretically infinite number of categories.  Each
category is named by a word, such as:

    reason
    priority
    source
    duration

The values of each category conceptually form a tree.  The root of the
tree is the universal, or most general, value.  It is denoted by the
the category name, and represents the universe of all possibilities.
Each further subdivision of a value is specified by adding a hyphen
and another word.  Thus, within the category "state" we have values:

    state
    state-unknown
    state-waiting
    state-on.call
    state-away

(Here we pretend '.' is a letter.)

The first of these values specifies no specific information.  The
following values specify subdivisions of the semantic space.  The
value "state-waiting" can be further subdivided based on the
importance of the call being waited upon:

    state-waiting-standard
    state-waiting-vip

An indication is assembled by providing a sequence of values (which
implicitly specify their categories), separated by colons, in order of
importance.  That is, the first value is the one that should be
rendered as accurately as possible; within that constraint, the second
value should be rendered as accurately as possible; etc.

For example, we can assemble the following indications:

    an internal, priority call
        source-internal:priority-high

    priority call waiting
        reason-call.waiting:priority-high

    short Albanian auto-callback
        reason-auto.callback:duration-short:locale-al

(The specific examples are taken from
draft-liess-dispatch-alert-info-urns-00 section 4.5, the specific
categories and values are adapted from Paul Kyzivat's message.)

All of these indications are easily extensible.  For instance, if
Albania has two service providers with different signal tones, we
could specialize the last indication into:

    short Albanian auto-callback, service provider A
        reason-auto.callback:duration-short:locale-al-sp.A

    short Albanian auto-callback, service provider B
        reason-auto.callback:duration-short:locale-al-sp.B

Due to the rule that the earlier values in an indicator have more
influence than latter values, there is a subtle difference between:

    source-internal:priority-high
    priority-high:source-internal

in regard to which aspect of the indication it is more important to
render.

* Selecting the signal based on an indication

Having defined a universe of indications with infinite extensibility,
we now need to show that a practical device can interpret indications
to select from a limited set of signals.  To do this, I will describe
a very general algorithm for doing this selection in all possible
situations.  Note that in practical cases (where all the signals that
can be rendered can be described by a small number of values of a
small number of categories) the algorithm will operate in a reasonably
rapid and simple way.

To start with, we assume that the renderer possesses a set of
available signals.  This set will naturally be partially determined by
the renderer itself, but the set may also be affected by the
configuration of the renderer (e.g., hearing-impaired mode vs. hearing
mode) and the context of the indication (e.g., ring tone vs. ringback
tone situations).  The set may be finite or infinite.  Of course, if
the set is infinite, it can't be represented literally, but the
renderer necessarily has a method of representing the set and its
possible subsets.  A finite set of available signals can be enumerated
directly, or represented in some other way.

Each available signal is described by the values of a set of
categories.  We assume that the renderer only knows the values for a
finite set of categories; for all other categories, all available
signals implicitly have the "universal", root value.

Informally, the algorithm proceeds as follows:

    Load a set of "acceptable signals" with all available signals.

    Process the words in the values in the indication from left to right.
    As each additional word is considered, consider the portion of the
    value that has been examined, and remove from the acceptable set all
    signals which are inconsistent with that value, in that their value
    for that category is not equal to or below the indication's value (as
    processed so far).

        If after processing a word, one or more signals remain in the
        acceptable set, continue processing the next word.

        If after processing a word, no signals remain in the
        acceptable set, restore the previous state of the acceptable
        set and continue with the next value in the indication.

    At the end of processing, the acceptable set will contain one or more
    signals.  Choose from among them according to some sort of priority
    system.

More formally, an indication is processed by:

      initialize the acceptable set of signals with all available signals

      for each value in the indication (going left to right):

          for each word in the value (going left to right, which is down
          the tree of values):

              if there are acceptable signals which have a value of the
              category which is equal to or below the indication value as
              seen so far:

                  delete all acceptable signals which do not have such a
                  value, and continue processing this value

              else

                  cease processing this value and continue with the next
                  value

      the acceptable set will contain at least one signal.  Choose from
      among the acceptable signals via some priority scheme.

Let me work through an example.

Let us suppose that the renderer implements three categories:

    reason
        reason-normal
        reason-call.waiting
        reason-forward
        reason-auto.callback
        reason-recall.hold
        reason-recall.transfer

    duration
        duration-normal
        duration-short
        duration-long

    locale
        locale-fm
        locale-al
            locale-al-sp.A
            locale-al-sp.B

Let us suppose that the renderer has signals for all combinations of
the leaf values of these categories, except that for historical
reasons if "reason" has a non-universal value, "default" must be
universal, and vice-versa; the signals (copied from the PSTN service
providers) do not allow signaling a non-standard reason with a
non-standard duration.  So the allowed combinations of these two
values are:

    reason-normal & duration
    reason-call.waiting & duration
    reason-forward & duration
    reason-auto.callback & duration
    reason-recall.hold & duration
    reason-recall.transfer & duration
    reason & duration-normal
    reason & duration-short
    reason & duration-long

There are signals that combine each of these with "locale-fm",
"locale-al-sp.A", and "locale-al-sp.B".

To process the indication
"reason-auto.callback:duration-short:locale-al-sp.A", the renderer
first loads the acceptable signal set with all 27 of its signals, and
then examines the indication word by word:

- "reason"

Removes no signals from the set.

- "reason-auto.callback"

Reduces the set to

    reason-auto.callback & duration & locale-fm
    reason-auto.callback & duration & locale-al-sp.A
    reason-auto.callback & duration & locale-al-sp.B

- "duration"

Removes no signals from the set.

- "duration-short"

Since no signals in the set have a value at or under this value, no
change is made and the processing of this value ends.

- "locale"

Removes no signals from the set.

- "locale-al"

Reduces the set to

    reason-auto.callback & duration & locale-al-sp.A
    reason-auto.callback & duration & locale-al-sp.B

- "locale-al-sp.A"

Reduces the set to

    reason-auto.callback & duration & locale-al-sp.A

The end of the indication is reached, and since only one signal remains
in the set, it is rendered.

Now, if the indication was less specific,
"reason-auto.callback:duration-short:locale-al", at the end the
acceptable set would be

    reason-auto.callback & duration & locale-al-sp.A
    reason-auto.callback & duration & locale-al-sp.B

and the renderer would have to choose between these two signals in
some way.

Let us suppose that the renderer implemented a further category:

    mode
        mode-visual
        mode-audio

and applied the value "mode-audio" to all of the above signals, but
only added the following signals with "mode-visual":

    reason & duration-normal & locale & mode-visual
    reason & duration-short & locale & mode-visual
    reason & duration-long & locale & mode-visual

That is, the only variation provided is in "duration".

Then the indication "reason-auto.callback:duration-short:locale-al"
would generate the same acceptable set as above, that is, there would
be no "mode-visual" signals.  The indication
"mode-visual:reason-auto.callback:duration-short:locale-al" would
generate the acceptable set:

    reason & duration-short & locale & mode-visual

This is because the indication implies that matching "mode" is more
important than matching "reason" and "duration".  Once the selection
for "mode-visual" has been done, no further selection can be done on
"reason", but "duration-short" can be acted upon.

In practice, for use with a hearing-impaired user, the initial set of
signals would be restricted to those with "mode-visual".  In this
example, we have assumed that the user considers "mode-visual" and
"mode-audio" to be equally acceptable.

If we configured the renderer to only use "mode-visual" signals, then
the indication "reason-auto.callback:duration-short:locale-al" would
select only the signal

    reason & duration-short & locale & mode-visual

In this configuration, the indication
"mode-audio:reason-auto.callback:duration-short:locale-al" would also
select that signal, because the value "mode-audio" cannot be acted
upon within that set of available signals.  It is effectively ignored.

* Extensibility

Let us now see how this scheme supports the various types of
extensibility listed in Requirement C.

- add further values to any existing category

We could define an additional value such as

    reason-avaya.special

If the renderer had any signals that had this value, they would be
selected by an indicator containing "reason-avaya.special".  If the
renderer has no such signals, then in an indicator this value acts the
same as "reason", that is, it has no effect.

- add further categories that are orthogonal to existing categories

We could define an additional category with values:

    avaya
        avaya-a
        avaya-b
        avaya-c

If a renderer does not know of this category, all of its signals
implicitly have the value "avaya".  Because of this, when such a
renderer processes a value of this category in an indicator, it never
changes the available set.

- semantically subdivide the meaning provided by any existing
  indication

We could define subvalues of existing values, such as:

    state
        state-waiting
            state-waiting-avaya.standard
            state-waiting-avaya.vip

If the renderer has two signals that differ only in the values
"state-waiting-avaya.standard" and "state-waiting-avaya.vip", any
indicator that does not know of this subdivision will never separate
the two signals; they will both remain in the acceptable set or both
be excluded from it.  So the renderer needs a policy for choosing one
over the other -- In this case, clearly "state-waiting-avaya.standard"
is to be preferred.

However, if the indicator gives one of the two subvalues, the renderer
will select the appropriate signal.

If the indicator gives one of the two subvalues but the renderer only
knows of "state-waiting", the "avaya.standard" or "avaya.vip" part of
the value will never affect the acceptable set (since to select based
on it would make the acceptable set empty).  Processing of
"state-waiting-avaya.standard" would have the same effect as
"state-waiting".

- add further "value spaces" of indications whose semantics are not
  related to existing indications, and thus, whose categories differ
  from and do not interact with existing categories

We can define completely independent spaces of signals by defining new
categories to describe the new space, giving signals in one space the
universal value for categories describing the other space.

For example, we can define

    auto
        auto-make
            auto-make-volvo
            auto-make-toyota
    color
        color-red
        color-green

If we have signals with the values

    auto-make-volvo & color-red
    auto-make-volvo & color-green
    auto-make-toyota & color-red
    auto-make-toyota & color-green

and add them to the set of "mode-visual" signals given above, we get:

    reason & duration-normal & locale & mode-visual & auto & color
    reason & duration-short & locale & mode-visual & auto & color
    reason & duration-long & locale & mode-visual & auto & color
    reason & duration & locale & mode & auto-make-volvo & color-red
    reason & duration & locale & mode & auto-make-volvo & color-green
    reason & duration & locale & mode & auto-make-toyota & color-red
    reason & duration & locale & mode & auto-make-toyota & color-green

This set is a combination of chalk and cheese.  But the first
non-universal value in the indicator will select signals of one type
or the other.  For instance, "auto-make" will select

    reason & duration & locale & mode & auto-make-volvo & color-red
    reason & duration & locale & mode & auto-make-volvo & color-green
    reason & duration & locale & mode & auto-make-toyota & color-red
    reason & duration & locale & mode & auto-make-toyota & color-green

and "duration-normal" will select

    reason & duration-normal & locale & mode-visual & auto & color

Dale