[salud] Section 8, updated

[[e-mail] (Dale R. Worley)]

My apologies, I've been neglecting the draft recently.  Here is an
update of section 8.  There are a few changes to clarify the wording
(in my opinion), and some to make the terminology and algorithm match
the new ABNF and the technical changes.

Note that the algorithmic part is simplified significantly!

 8.  Combinations of Alert-Info URNs
 
 8.1.  Priority Rules
 
    This section describes combination rules for the case when all the
-   Alert-Info header fields only contain Alert-Info URNs.  Combinations
-   of URNs and URIs in the Alert-Info header fields of the same SIP-
+   Alert-Info header fields only contain Alert-Info URNs.  Other combinations
+   of URIs in the Alert-Info header fields of the same SIP
    message are not defined in this specification.
 
-   In many cases, more than one URNs will be needed to fully define a
+   In many cases, more than one URN will be needed to fully define a
    particular tone.  This is done by including multiple Alert-Info URNs,
    in one or more Alert-Info header fields in a request or a response.
-   For example, an internal, priority call could be indicated by Alert-
-   Info: <urn:alert:source:internal>, <urn:alert:priority:high>.  A
-   priority call waiting tone could be indicated by Alert-Info:
-   <urn:alert:service:call-waiting>, <urn:alert:priority:high>.
+   For example, an internal, priority call could be indicated by
+
+      Alert-Info: <urn:alert:source:internal>, <urn:alert:priority:high>
+
+   A priority call waiting tone could be indicated by
+
+      Alert-Info: <urn:alert:service:call-waiting>, <urn:alert:priority:high>
 
    The sender of the Alert-Info header may include an arbitrary list of
    Alert-Info URNs, even if they are redundant or contradictory.  An
    earlier URN has priority over any later contradictory URN.  This
    allows any element to modify a list of URNs to require a feature
    value (by adding a URN at the beginning of the list) or to suggest a
    feature value (by adding a URN at the end of the list).
 
-   The receiving UA attempts to match the received Alert-Info URNs
+   The receiving UA matches the received Alert-Info URN
    combination with the signal(s) it is able to render.
 
-   The implementation is free to ignore any or all parts of the received
-   Alert-Info URNs.  The exact way in which a UA renders a received
+   The implementation is free to ignore an Alert-Info URN if it does
+   not recognize the URN, or if it is incapable of rendering its
+   effect in the context.  Similarly, it can remove a final series of
+   one or more <alert-ind-part>s of an Alert-Info URN to create a
+   "more generic" URN which it recognizes and whose meaning it can
+   render in the context.
+
+   The exact way in which a UA renders a received
    combination of Alert-Info URNs is left as an implementation issue.
    However, the implementation MUST comply to following rules:
 
       a.  Each alert-info URN has precedence over all URNs that follow
       it, and its interpretation is subordinate to all URNs that precede
       it.
 
       b.  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
-      preceding URNs), the UA repeatedly removes either
-
-         (1) the final <name> of the URN, or
-
-         (2) if the final <name> is a <private-name> with three or more
-         <label>s, the final <label>
-
-      until either
+      preceding URNs), the UA repeatedly removes the final
+      <alert-ind-part> of the URN until either
 
          (i) the resulting URN is recognized and can be given effect by
          some signal (without reducing the degree of expression of any
          preceding URN), or
 
-         (ii) the resulting URN is reduced to having no <alert-
-         indication>.
-
-         In case (ii), that URN in the series cannot be given effect, so
-         it is ignored.
+         (ii) the resulting URN is reduced to having no <alert-ind-part>,
+         in which case, that URN in the series cannot be given effect, and
+         so is ignored.
 
       c.  In case that after processing all the received URNs, the UA
       can generate more than one signal that are equally effective at
       expressing the URNs (under the preceding rules), one of those
       signals is selected.  When selecting from the set of equally
       effective signals, no signal should be chosen if a less-specific
       signal is also in the set.  (Specificity is to be judged based on
       the defined meanings of the signals to the user.)  (E.g., if each
       signal is considered to express certain <alert-indication>s of
       certain <alert-categories>, one signal is less-specific than a
       second signal if the first signal's <alert-indication>s are a
       subset or are prefixes of the second signal's <alert-
       indication>s.)  However, a more-specific signal may be chosen if
       the choice is based on information derived from the containing SIP
       message.  E.g., a signal implying urn:alert-info:priority:high may
       be chosen if the SIP message contains the header "Priority:
       urgent".
 
    In all situations, the set of signals that can be rendered and their
    significances may change based on user preferences and local policy.
 
-   In adidition, they may change based on the status of the UA.  E.g.,
-   if a call is active on the UA, all audible signals may become
-   unavailable, or audible signals may be available only if
+   In adidition, the chosen signal may change based on the status of
+   the UA.  E.g., if a call is active on the UA, all audible signals
+   may become unavailable, or audible signals may be available only if
    urn:alert-info:priority:high is specified.
 
 8.2.  Multi-mode signals
 
    There are cases when the device can render two signal modes (e.g.,
    audio and visual, or video or text) at the same time.
 
    Formally, the device must be considered as making its choice from the
-   set of all combined signals that it can render, and that choice must
+   set of all combined signals that it can render (pairs of one signal
+   from the first mode and one signal from the second mode), and that choice must
    conform to the above rules.  However, it can be proven that if the
    device makes its rendering choice for each of the two modes
    independently, with each choice separately conforming to the above
    rules, its combined choice conforms to the above rules, when it is
    regarded as a choice from among all possible combinations.
 
    In such a situation, it may simplify implementation to make each
    choice separately.  It is an implementation decision whether to chose
    from among combined signals, or to combine choices made from each
    signal mode.

Comments?

Dale