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

[Laura Liess <[e-mail]>]

Dale, Paul,

what about trying to combine Dale's conceptual framework (which also
seems to me to solve the semantic-non semantic discussion) and the
syntax Paul and John and I agreed upon
http://www.ietf.org/mail-archive/web/dispatch/current/msg01618.html
back in April ?  I think they could fit together, or do you see any
issues where they don't?

Laura

2010/6/15 Paul Kyzivat <[e-mail]>:
> Very interesting!
>
> Without getting into syntax specifics, I think I like this - it provides a
> much cleaner conceptual framework. The idea of the specifier providing a
> priority seems to resolve some loose ends.
>
>        Thanks,
>        Paul
>
> WORLEY, Dale R (Dale) wrote:
>>
>> [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
>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>