Subject: [salud] The status of the work

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 4 Nov 2011 15:21:36 -0400

[as chair]

The current next step is that Laura is working on the -03 version to
incorporate all the decisions that we have made to this point.

My understanding of issues on which we have made progress and open
issues is as follows.  (The messages in the archive that I refer to
are only approximate, and are biased toward messages I have written
(because I can remember them more easily); in all cases, related
messages in the threads are equally important.)

(See http://www.ietf.org/mail-archive/web/salud/current/msg00131.html
for a list of the "major" technical issues we have identified.)

Each Alert-Info URN will give one characteristic of the desired
signal, and the entire "indication" that one end sends to the other is
the ordered set of urn:alert URNs in the Alert-Info header.

(msg00157) The "components" of a URN will be separated by ":", rather
than "." as was used in earlier versions.  ("." is used to subdivide
some components.)

URNs will in principle allow infinite subdivision of characteristic
values, although most of the standard URNs give only one level of
subdivision of the characteristic, and a few give two levels of
subdivision.

(msg00147) The sender of the Alert-Info header may include an
arbitrary list of urn:alert 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).

(msg00154) A relatively wide range of extensibility will be allowed.
An extension "at the top level" creates an entirely new
characteristic, an extension "at the second level" creates an entirely
new value for a characteristic, an extension "at the third level"
creates a subdivision of a standard value, etc.  Extensions at lower
levels are preferred over those at upper levels, and we may have
stricter requirements for extensions at upper levels (perhaps even
forbidding them).  Exactly how much freedom we want to allow for
non-standard values is not clear yet.

Proprietary extensions will be indicated by a URN component which is a
reversed FQDN of the entity that defines the extension (possibly
followed by further components).  Standard URNs will never contain
components containing ".", so proprietary extensions need no further
marker.

The "legacy" URN <urn:alert:service:normal> conforms to the envisioned
URN structure, and so needs no exceptional definition.

(msg00152) Regarding the specification of how an element must
interpret a series of URNs:

- (msg00171) There will be a normative list of requirements on how the
  element must do this.  This list is short (3 rules) but should
  suffice for interoperation.

- (msg00171) Non-normatively, there will be a fully-specified example
  algorithm, both to prove that the requirements can be satisfied and
  as a guide to implementers.

- (msg00174) Some notes on the non-normative algorithm that point out
  how a direct implementation of the algorithm can be made more
  efficient.  (The specification of the algorithm being organized for
  clarity rather than efficiency.)

- (This I have just thought of as a possibility:)  (msg00167,
  msg00168, msg00150) Some worked-out examples of how the example
  algorithm works, showing that it satisfies the requirements in
  difficult situations, and also to warn implementers of potential
  problem situations any algorithm must handle.

- (msg00174) Notes on how to handle "combined" signals.  E.g., a UA
  that can produce both a visual and an audible signal at the same
  time.  From a theoretical point of view, no new logic is needed, but
  the resulting operation is confusing to the intuition and
  inefficient in implementation.  It turns out that each of the two
  signals can be selected independently by examining the URNs once in
  regard to each signal compoent; the results will still satisfy the
  requirements and (if the individual selections are via the example
  algorithm) the result will be as if the example algorithm selected
  from the theoretical set of signal-pairs.

(msg00163) Consideration of how to suppress undesired indications from
untrusted callers while allowing them from trusted callers.

Various minor adjustments of the set of standard URNs.  Possibly
changing the "priority" values to be the same as the values of the
"Priority" header.  (However, we aren't sure how important the
Priority header is, since it doesn't match anything in the PSTN;
interoperation may not be important.)

Terminology in the draft is not used consistently, and there may be
useless glossary entries from an overly-elaborate glossary I wrote
near the beginning of the process.  This will be cleaned up after we
settle the technical issues.

Dale