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

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Tue, 15 Jun 2010 13:27:59 -0400

[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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Jun 2010 14:15:45 -0400

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:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Laura Liess <[email-masked]>
Date: Wed, 16 Jun 2010 15:12:05 +0200

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 <[email-masked]>:
> 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
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Jun 2010 09:39:05 -0400

> back in April ?  I think they could fit together, or do you see any

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

---

From: Laura Liess <[email-masked]>
Date: Thu, 17 Jun 2010 13:15:17 +0200

Dale,
Please see comments inline.

2010/6/16 WORLEY, Dale R (Dale) <[email-masked]>:
>> From: Paul Kyzivat
> I would very much like to avoid having different URNs within the
> Alert-Info header interact; that seems to me to be against the concept
> of each URN being a distinct name.  (Which is why I am assuming that
> the syntax allows one URN to contain multiple "values".)

We had URN to contain multiple "values" in the initial proposal, see
http://tools.ietf.org/id/draft-alexeitsev-bliss-alert-info-urns-02.txt,
but only to some degree. We had there duration and priority in one
URN, but for combining call-waiting and duration we still needed two
URNs because they were different categories. For this version, we got
following comment from Adam:
http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html . For
the next version of the draft,  Alan and I agreed to change to
combinations of discrete tokens.
So upto now we discussed two alternatives:
1) Return to URNs which contain multiple values, maybe with a modified
syntax to avoid multiple URNs. Problem: We have to find a way to avoid
the problem Adam pointed out to.
 2) Or we can stay with the current model of different interacting
URNs within the Alert-Info header. Problem: We need to define proper
combination and rendering rules.

I think both could work fine if we can solve the corresponding problem.

> Well, strictly speaking, the renderer doesn't have to follow the
> algorithm -- the normative part of the RFC will spell out what the
> intention of the URN is and what the constraints on renderers are, and
> we will put the algorithm in a non-normative appendix to prove that
> conforming renderers can be implemented straightforwardly.
>
>> From: Laura Liess
>
>> the problem I have with this is that we have
>> urn:alert:service:call-waiting already implemented and already
>> specified in 3GPP.
>
> If that is the *only* such URN defined and implemented in 3GPP, I
> expect that we can adjust the new syntax to give that one URN the
> intended interpretation while still implementing the semantics we
> agree upon within the whole namespace.
>
> Even if the syntax we decide upon is completely incompatible with this
> one URN, we can explicitly define it as a special case.  In the most
> extreme case, the RFC would define a *different* URN namespace, and we
> would specify that urn:alert:service:call-waiting maps to a specific
> URN in the new namespace.

I would prefer this to fit in the general scheme we are going to define.
>
> The harder situation is if the specifier wants to indicate some
> particular variant of the call-waiting signal.  What URN does it
> provide that include the variant information while still appearing to
> be "urn:alert:service:call-waiting" to 3GPP-only renderers?

I hope understand your question correctly.
Within 3GPP, there are no variants of the call-waiting signal. I am
not aware of any being used or needed by the DT.
This is probably a issue for PBXes, e.g. a short and  delayed
call-waiting signal. (Is this what you mean by "particular variant of
the call-waiting signal"?)  With both syntax alternatives we have up
to now, we would need at least two URNs. What you look for is getting
this all in only one URN, right?  Then we probably need a completely
new syntax. Maybe it's possible. We just have to be carefull to get
the problem Adam pointed out to solved.

Laura

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Jun 2010 09:44:14 -0400

Hmm. For some reason I have not received Dale's reply that Laura is 
replying to below. So I'm responding here.

	Thanks,
	Paul

>> the syntax allows one URN to contain multiple "values".)

I don't see a problem there. In the general case, if there are multiple 
URIs then the recipient has to decide how to rationalize them into 
something to be done. So what is wrong with giving some guidance in that 
regard?

Requiring all the categories to be specified in one URN has the downside 
that all category values need to be standardized as part of a single URN 
spec. Conversely, consolidating multiple URNs gives the potential to 
define a new category via an entirely new URN scheme. (I guess we should 
discuss if that is a good thing or a bad thing.)

>> conforming renderers can be implemented straightforwardly.

OK. You have convinced me this isn't a problem. Good!

---

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Thu, 17 Jun 2010 15:32:22 -0400

From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]

> something to be done. So what is wrong with giving some guidance in that

We could do that, but it seems to me to be opening a can of worms, in
that the guidance would be (in the general case) how to rationalize an
arbitrary set of URIs.  If we limit the rationalization process to the
elements of a single URN of a particular namespace, the problem
becomes simpler.

> spec.

Strictly speaking, you don't have to define the entire set of standard
categories in one RFC.  You do need some sort of registry for them and
their standardized values, but you can extend the registry with new
RFCs.  Of course, the vendor-specific extensions aren't cataloged
anywhere.

> Conversely, consolidating multiple URNs gives the potential to
> define a new category via an entirely new URN scheme. (I guess we
> should discuss if that is a good thing or a bad thing.)

I'd vote for considering that to be a bad thing.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Jun 2010 16:13:17 -0400

I don't feel especially strongly one way or the other regarding the 
multiple URNs vs. single URN issue.

	Thanks,
	Paul

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 17 Jun 2010 20:29:16 -0600

On 6/17/10 7:44 AM, Paul Kyzivat wrote:

> define a new category via an entirely new URN scheme. 

To clarify, there is no such thing as a "URN scheme". Upon approval,
draft-liess-dispatch-alert-info-urns will register a URN namespace
identifier (NID) in accordance with RFC 3406, not a "URN scheme".

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Jun 2010 09:15:37 -0400

Peter,

Ok - I couldn't remember the precise term and used something convenient.

	Thanks,
	Paul

Peter Saint-Andre wrote:
> ------------------------------------------------------------------------
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 18 Jun 2010 08:07:04 -0600

Understood. The term "branch of the URN tree" might be an informal way
of describing a URN namespace identifier. But the charter proposal says
"URN scheme", too, so I just wanted to nip that error in the bud. :)