Subject: [salud] -05: Resolution rules

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 9 Feb 2012 16:41:55 -0500

I think these are some improvements we could make to the "resolution
rules" in section 7, and related parts of the text.

   4.  Namespace Registration Template

        alert-URN       = "URN:alert:" alert-identifier
        alert-identifier= alert-category ":" alert-indication
        alert-category  = name
        alert-indication= name *(":" name)
        name = let-dig [ *let-dig-hyp let-dig ]
        let-dig-hyp     = let-dig / "-"
        let-dig         = ALPHA / DIGIT
        ALPHA           = %x41-5A / %x61-7A   ; A-Z / a-z
        DIGIT           = %x30-39 ; 0-9

It turns out that this syntax doesn't allow for private-names at all!
So I think we need to add/modify:

        name = standard-name / private-name
        standard-name = label
        private-name = label "." label *[ "." label ]
        label = let-dig [ *let-dig-hyp let-dig ]

(I think that "label" is the term used in DNS for
sequence-of-letters-digits-and-hyphens.)

Here I require private-name to contain at least one ".", so
private-names are never the same as standard-names.

Because we don't now define "<private-name>", add:

   Throughout this document, "<private-name>" is used as a syntactic
   variable for any string conformant to the "private-name" ABNF
   above.

Some changes to section 7, where I have made notes:

   7.  Combinations of Alert-Info URNs and 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-
   message are not defined in this specification.

   In many cases, more than one URNs 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>.

   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
   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
   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 removes the final name of the URN
      repeatedly until either (1) the resulting URN is recognized and
      can be given effect by some signal (without reducing the degree of
      expression of any preceding URN), or (2) the resulting URN is
      reduced to having no names.  In case (2), that URN in the series
      cannot be given effect, so it is ignored.

I think it was Paul who mentioned that we may want to remove from a
URN not the final name, but the final label from a private-name.
That is, changing the final private-name from a subdomain to its
super-domain.  That makes paragraph b a bit more complex.  I've
reformatted it to use indentation to clarify the situation:

  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 labels,
	  the final label,
  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.

      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, any particular signal is preferred over all
      signals that are more specific (in regard to the defined meaning
      of the signal to the user) than that particular signal.  (E.g., if
      each signal expresses a set of alert-indications (values) for a
      set of alert-categories (per the BNF), then a first signal is more
      specific than a second signal if the second signal's alert-
      indications are (partial or complete) initial portions of the
      first signal's corresponding alert-indications.)

I've always disliked the latter part of paragraph c.  (I can say that
because I wrote it.)  I think this is an improvement:

   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-indications of certain alert-categories, one
   signal is less-specific than a second signal if the first signal's
   alert-indications are a subset or are prefixes of the second signal's
   alert-indications.)

And I want to allow the UA to use information from elsewhere in the
message, as long as it doesn't contradict the Alert-Info:

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

And after the rules, let us add remind the reader that the set of
signals may depend on the status of UA, as well as user preferences
and local policy:

   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
   urn:alert-info:priority:high is specified.

I'd like to turn this paragraph into its own section:

   There are cases when the device can render audio and visual (e.g.
   video or text) at the same time.  This kind of rendering can be
   considered as one signal which has a set of sensory components
   instead of a set of different signals.  E. g., if the device
   generates audio signals and visual signals at the same time, each
   "signal" is a combination of one audio and one visual component.
   There is some benefit to treating separately audio and visual
   signals, since the total number that need to be defined can be a lot
   less.  It is an implementation choice to use one option or another.

like this:

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

Dale