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

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
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 