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

[Paul Kyzivat <[e-mail]>]

Laura Liess wrote:
> 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?

I was trying to avoid syntax issues for the moment, in order to focus on 
the essence of Dale's proposal. But if we generally like where that is 
going then eventually it will come back to syntax.

IIUC, in what Dale has proposed the "indication" includes a prioritized 
list of capability-values. If we followed the syntax of the current 
draft, then the prioritization would probably come by considering the 
order of URNs in the Alert-Info header to be significant.

I think that could work. It might even be possible to generalize the 
rule to the treatment of all sorts of URIs in the Alert-Info header, not 
just this particular class of URNs. The rule would be something like:

- process URIs from the A-I header in order. For each:
   - if it is understood, and is acceptable according to local policy:
     - if it can be used in conjunction with already accepted URIs:
       - then accept this one as well
       - else discard it
- once that is complete, if nothing has been accepted,
   or if some aspect of alerting as not been addressed by
   what has been accepted, then fill in suitable defaults.
- use the accepted URIs, plus defaults, to do the alerting.

The above is a higher level "meta-policy" for alerting, within which the 
selection and combination rules that Dale spells out can be applied.

One thing that *isn't* covered by Dale, or the above, is what to do if 
the "renderer" disagrees with the "specifier" about the priorities. I 
don't (yet) have an opinion if that is a problem that needs solving.

	Thanks,
	Paul

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