Subject: [salud] Interpreting a series of URNs

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 9 Aug 2011 15:32:32 -0400

[as individual]

Here is a draft of a description of how to interpret a series of URNs, even if
the series has multiple URNs for a single alert-category or contradicstory
URNs.

--------------------

The general idea of the following rules is that each alert-info URN is
obeyed as much as it can be, given the limitations given by the
previous alert-info URNs in the sequence.  So in a series of URNs,
they are in strict priority order:  the first one has absolute
control, and the last one is obeyed only to the degree that it is
compatible with all the preceding URNs.

If a process adds a URN to the beginning of a series of URNs, then
that URN will be obeyed, and the remaining URNs can only modify its
effect.  If a process adds a URN to the end of a series of URNs, then
that URN can only modify the effect of the preceding URNs.

A series of URNs in the namespace 'alert' is interpreted by a device
in the following way:

The device that interprets the series of URNs knows the set of
alerting signals that it can generate and which alert URNs each signal
is compatible with.

The device interprets each URN in order, starting with the first.

As the device progresses through the series of URNs, it maintains
(implicitly or explicitly) the subset of its alerting signals that are
compatible with the URNs as they have been interpreted so far.
Initially, this set is the entire set of alerting signals that the
device can generate.

To interpret an additional URN, the device examines the URN to
determine if it recognizes the alert-category and the
alert-indication.  If the device does not recognize the
alert-category, it skips the URN and continues with the next URN,
without changing the current set of alerting signals.  If the device
does not recognize the entire alert-indication, it successively
removes the final 'name' until it does recognize what remains of the
alert-indication, and then continues with interpreting the shorter
URN.  If the device does not recognize even the first 'name' of the
alert-indication, it skips the URN and continues with the next URN (as
what remains of the URN provides no information at all about the
alterting signal).

The device then eliminates from the current set of alerting signals
all signals which are not compatible with the (possibly shortened) URN
that is being interpreted.  If one or more signals remain in the set,
the device continues with the next URN, using the reduced set of
signals.

If no signals in the current set are compatible with the URN, the
device shortens the URN by removing the final 'name' from its
alert-indication.  The device then returns to restricting the previous
current set based on compatibility with the shorter URN.  If one or
more signals then remain in the set, the device continues with the
next URN.

If again no signals remain in the set, the device shortens the URN
again by removing another 'name' from the alert-indication, and
attempts the restriction of the set again.  This process continues
until either one or more signals remain after the restriction, or the
first alert-indication of the URN is removed, at which point this URN
has been reduced to having no meaning (and thus excludes no alerting
signals), and the device continues on to interpret the next URN.

At the end of interpreting the sequence, the current set will
necessarily contain one or more alerting signals.  The device choses
one signal from among these signals in any way it likes.

Dale

---

From: Laura Liess <[email-masked]>
Date: Thu, 11 Aug 2011 16:58:05 +0200

Dale,

Thank you very much for the elaborate description. I have one question
on the algorithm.

 Take the following example:
The device has a set of alerting signals consisting which are for
<urn:alert:source:external>, <urn:alert:source:internal>,
<urn:alert:priority:low>, <urn:alert:priority:high>. It receives
<urn:alert:source:external>.  The device eliminates
<urn:alert:source:internal> and keeps  <urn:alert:source:external>,
<urn:alert:priority:low>, <urn:alert:priority:high>.  Could it happen
that it chooses to render <urn:alert:priority:high> or did I miss
something in the algorithm description?

Thanks a lot
Laura

2011/8/9 Worle R (Dale) <[email-masked]>:
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 11 Aug 2011 15:08:36 -0400

[as individual]

> From: Laura Liess [[email-masked]]
> 
> Thank you very much for the elaborate description.

BTW, I am interested in any advice on how to make the description
clearer, or about anything that is unclear.  If we can't make this
clear enough to be widely understood, we'll have to give it up and do
something simpler.

> I have one question on the algorithm.
> 

I think it could.

Let me go through your example in more detail to make sure I
understand it.  I am going to call the signals "signal-external",
etc. to avoid confusing the signals with the URNs.  So there are 4
signals, each of which is compatible with the following URNs:

signal-external is compatible with:
    <urn:alert:source:external>
    <urn:alert:priority:low>
    <urn:alert:priority:high>

signal-internal is compatible with:
    <urn:alert:source:internal>
    <urn:alert:priority:low>
    <urn:alert:priority:high>

signal-low is compatible with:
    <urn:alert:source:external>
    <urn:alert:source:internal>
    <urn:alert:priority:low>

signal-high is compatible with:
    <urn:alert:source:external>
    <urn:alert:source:internal>
    <urn:alert:priority:high>

The device receives <urn:alert:source:external>, which eliminates one
signal, but leaves no criterion to choose from among the three
remaining signals.  The algorithm assumes that the device chooses one
of the remaining signals based on some unstated criterion.

I guess this example has this odd feature because the algorithm is
oriented toward ruling out signals that are incompatible with URNs,
rather than ranking which signals are most compatible with the URNs.

A similar example would be to have 3 signals, "signal-normal" used in
normal situations (internal, low priority), "signal-external" used for
external calls, and "signal-high" for his priority calls:

signal-normal is compatible with:
    <urn:alert:source:external>
    <urn:alert:source:internal>
    <urn:alert:priority:low>
    <urn:alert:priority:high>

signal-external is compatible with:
    <urn:alert:source:external>
    <urn:alert:priority:low>
    <urn:alert:priority:high>

signal-high is compatible with:
    <urn:alert:source:external>
    <urn:alert:source:internal>
    <urn:alert:priority:high>

Then if <urn:alert:source:internal> is received, signal-normal and
signal-high are both compatible.  So it seems that the device would
have to know to to choose signal-normal over signal-high.

What would make life easier in this situation is if we had 4 signals,
one for each combination of source and priority.

The benefit of the algorithm is that it knows when to remove the final
"name" from a URN, which is when the URN is compatible with none of
the remaining signals.  That allows people to extend URNs into even
more specialized URNs without causing devices to malfunction --
devices that do not understand the extension "name" will remove it.

But it seems that in a lot of common cases, we want to say that some
URNs are "more compatible" with certain signals than other signals.
I'll have to think about the ramifications of that...

Dale

---

From: Laura Liess <[email-masked]>
Date: Fri, 12 Aug 2011 16:17:28 +0200

Dale,

Please see inline.

> clear enough to be widely understood, we'll have to give it up and do

[LL] I like your idea and I am not sure at all it is easy to find
something simpler.

> rather than ranking which signals are most compatible with the URNs.

Exactly. This is the reason why I choosed this example.
> devices that do not understand the extension "name" will remove it.

[LL] I see another advantage, from the point of view of the network:
Proxies will want to overwrite Alert-Info URNs in certain situations.
E.g. carriers don't want
their customers to be bothered by SPIT INVITEs with <urn:alert:priority:high>,
so they need a mean to tell the end device not to play the signal. If
only one urn per category is allowed, the only thing the proxy can do
is to find out if <urn:alert:priority:high> or a child of it is
present and delete or overwrite it.
However, if the call is a call between two units of the same
enterprise with the VoIP traffic traversing the carrier network, the
caller and the callee may not want  <urn:alert:priority:high> to be
overwritten by the carrier. This is not possible with the rules
described above without a lot of provisioning at the carrier, which is
probably not posible at all in practice.
With your algorithm principle, the carrier only needs to add
<urn:alert:priority:normal > at the beginning of the urn-chain. The
end device will have both URNs,  <urn:alert:priority:normal > and
<urn:alert:priority:high >, in that order. Most end devices would
eliminate devices
<urn:alert:priority:high >. Enterprise devices, which will recognise
the sender as beeing from the own enterprise, could keep and render
it. The algoritm is great and gives us a lot of flexibility.

It's just that we probably need to make some small modifications for
the algorithm to work in all cases. I think this is possible if we add
some non-critical restrictions and some actions.

1) We require the sets of the Alert-Info URNs to consist of a number
of disjunct trees. The roots of the trees are the alert-categories.
"private" branches can be added everywhere in a tree. There are no
"private" trees.

2) Every URN received by the end device is then on some branch of one
of the trees. Let's select these tree branches.

3) Every device has a basic set of supported signals,  which
correspond to Alert-Info URNs. (Additionaly it may have a set of
additional supported signals which are combinations of two or more
basic signals from different trees.) Let's select the tree branches
which contain at least one signal from the basic signal set.

4) Put the tree branches selected at 2) and the tree branches selected
at 3) on top of each other.

5) Eliminate all  received URNs which are not equal to a suppoted
signal or do not have at least a supported signal as a parent.
(Eliminate all received URNs for which we don't have a rendering.)

6) Eliminate all suported signals that are not equal to a received URN
or do not have at least a a received URN as a child, but keep at least
the default signal for each category. ( Eliminate all signals for
which I didn't received any indication to render them.)or take Take
the I didn't received any indication to render this signal, so I take
the default. )

7) We have now trees with one or more branches left. The leafs are
allways a received URN, "oldest" node is allways a basic signal which
the device can render.

8) At this point the device has a set of received URNs which have all
al least one parent which is a signal (this means we know how to
render it). If there is only one received URN left in a category, then
the device keeps its youngest signal parent.

9) If we have more than one received URN left in a tree we need
priority rules. The URN order in the Alert-Info-header is used if the
device has no other rules. In this case the device keeps the youngest
signal parent of the first URN in this category from the
Alert-Info-header.

10) The device can have special rules. Back again to the "priority"
example, the enterprise device which knows that the message is from
within the enterprise via a carrier which inserts the URNs at the
beginning of the Alert-Info-header, could have a rule saying that not
the first, but the last URN has to be be rendered.

My intention was that the algorithm is in principle the same with what
you proposed, just that it eliminates the signals for which no
indication was received.  I am not sure if it works.

Thanks a lot
Laura

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 19 Aug 2011 16:18:01 -0400

[as individual]

I am just now getting back to this work, and I haven't had time to fully
digest your response.

However, as an addendum to my previous message, the following may be
a useful approach:

- Normatively, state a few requirements that the process of interpreting URNs
  must follow.  I believe that we can keep these principles to a small number,
  probably five or fewer.

- Non-normatively, provide an algorithm whose results satisfy the requirements.
  This algorithm would be similar to the one I stated previously, with additions
  to handle situations like the one you proposed.  An example algorithm (1) proves
  that the normative requirements can be met, and (2) provides an initial implementation
  for manufacturers.

What could these requirements be?  I think we want to have the following two
requirements, but there may be more.

- Each alert-info URN has precedence over all URNs that follow it, and
  its interpretation is subordinate to all URNs that precede it.

- If the UA cannot implement the effect of a URN (because it does not
  recognize the URN or the URN's effect is precluded by
  higher-precedence, preceding URNs), the UA must remove the final
  "name" of the URN repeatedly until either (1) the resulting URN is
  recognized and can be given effect, or (2) the resulting URN is
  reduced to having no "names".  In case (2), the entire URN cannot be
  given effect, so it is ignored.

Dale

---

From: Laura Liess <[email-masked]>
Date: Tue, 23 Aug 2011 05:36:49 +0200

Dale,

We  we have to specify the algorithm anyway. I think we can derive the
normative rules from it.

(I will be away on vacation during the next 3 weeks. I don't know if I
will have internet access.)

Thanks
Laura