GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8433

Independent Submission D. Worley Request for Comments: 8433 Ariadne Category: Informational August 2018 ISSN: 2070-1721

           A Simpler Method for Resolving Alert-Info URNs

Abstract

 The "alert" namespace of Uniform Resource Names (URNs) can be used in
 the Alert-Info header field of Session Initiation Protocol (SIP)
 requests and responses to inform a voice over IP (VoIP) telephone
 (user agent) of the characteristics of the call that the user agent
 has originated or terminated.  The user agent must resolve the URNs
 into a signal; that is, it must select the best available signal to
 present to its user to indicate the characteristics of the call.
 RFC 7462 describes a non-normative algorithm for signal selection.
 This document describes a more efficient alternative algorithm: a
 user agent's designer can, based on the user agent's signals and
 their meanings, construct a finite state machine (FSM) to process the
 URNs to select a signal in a way that obeys the restrictions given in
 the definition of the "alert" URN namespace.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This is a contribution to the RFC Series, independently of any other
 RFC stream.  The RFC Editor has chosen to publish this document at
 its discretion and makes no statement about its value for
 implementation or deployment.  Documents approved for publication by
 the RFC Editor are not candidates for any level of Internet Standard;
 see Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 https://www.rfc-editor.org/info/rfc8433.

Worley Informational [Page 1] RFC 8433 Resolving Alert-Info URNs August 2018

Copyright Notice

 Copyright (c) 2018 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (https://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.

Table of Contents

 1. Introduction ....................................................3
    1.1. Requirements Governing Resolution Algorithms ...............4
    1.2. Summary of the New Resolution Algorithm ....................5
    1.3. Conventions Used in This Document ..........................7
 2. Selecting the Signals and Their Corresponding "alert" URNs ......7
 3. General Considerations for Processing Alert-Info ................9
 4. Constructing the Finite State Machine for a Very Simple
    Example ........................................................10
    4.1. Listing the Expressed URNs ................................11
    4.2. Constructing the Alphabet of Symbols ......................11
    4.3. Constructing the States and Transitions ...................13
    4.4. Summary ...................................................17
    4.5. Examples of Processing Alert-Info URNs ....................19
 5. Further Examples ...............................................20
    5.1. Example with "source" and "priority" URNs .................20
    5.2. Example 1 of RFC 7462 .....................................24
    5.3. Examples 2, 3, and 4 of RFC 7462 ..........................30
    5.4. An Example That Subsets Internal Sources ..................33
    5.5. An Example of "alert:service" URNs ........................34
    5.6. An Example Using Country Codes ............................34
 6. Prioritizing Signals ...........................................40
 7. Dynamic Sets of Signals ........................................41
 8. Security Considerations ........................................43
 9. IANA Considerations ............................................43
 10. References ....................................................44
    10.1. Normative References .....................................44
    10.2. Informative References ...................................44
 Acknowledgments ...................................................45
 Author's Address ..................................................45

Worley Informational [Page 2] RFC 8433 Resolving Alert-Info URNs August 2018

1. Introduction

 When a SIP user agent (UA) server receives an incoming INVITE
 request, it chooses an alerting signal (the ring tone) to present to
 its user (the called user) by processing the Alert-Info header
 field(s) in the incoming INVITE request [RFC3261].  Similarly, a SIP
 UA client determines an alerting signal (the ringback tone) to
 present to its user (the calling user) by processing the Alert-Info
 header field(s) in the incoming provisional response(s) to its
 outgoing INVITE request.
 [RFC3261] envisioned that the Alert-Info header field value would be
 a URL that the UA could use to retrieve the encoded media of the
 signal.  This usage has security problems and is inconvenient to
 implement in practice.
 [RFC7462] introduced an alternative practice: the Alert-Info values
 can be URNs in the "alert" URN namespace that specify features of the
 call or of the signal that should be signaled to the user.  [RFC7462]
 defined a large set of "alert" URNs and procedures for extending
 the set.
 A UA is unlikely to provide more than a small set of alerting
 signals, and there are an infinite number of possible combinations of
 "alert" URNs.  Thus, a UA is often required to select an alerting
 signal that renders only a subset of the information in the
 Alert-Info header field(s) -- which is the resolution process for
 "alert" URNs.  The requirements for resolving "alert" URNs are given
 in Section 11.1 of [RFC7462].
 Section 12 of [RFC7462] gives a (non-normative) resolution algorithm
 for selecting a signal that satisfies the requirements of
 Section 11.1 of that document.  That algorithm can be used regardless
 of the set of alerting signals that the UA provides and their
 specified meanings.  The existence of the algorithm defined in
 [RFC7462] demonstrates that the resolution requirements can always be
 satisfied.  However, the algorithm is complex and slow.
 The purpose of this document is to describe an improved
 implementation -- a more efficient resolution algorithm for selecting
 signals that conforms to the requirements of Section 11.1 of
 [RFC7462].  (Of course, like any such algorithm, it is non-normative,
 and the implementation is free to use any algorithm that conforms to
 the requirements of Section 11.1 of [RFC7462].)
 In the algorithm defined in this document, once the UA designer has
 chosen the set of signals that the UA produces and the "alert" URNs
 that they express, a finite state machine (FSM) is constructed that

Worley Informational [Page 3] RFC 8433 Resolving Alert-Info URNs August 2018

 selects alerting signals based on the URNs in the Alert-Info header
 field(s) in a SIP message.  The incoming "alert" URNs are
 preprocessed in a straightforward manner into a sequence of "symbols"
 drawn from a fixed finite set; these symbols are then used as input
 to the FSM.  After processing the input, the state of the FSM selects
 the correct alerting signal to present to the user.
 Both the preprocessor and the FSM are determined only by the selected
 set of signals and the set of "alert" URNs expressed by the signals,
 so the processing machinery can be fixed at the time of designing
 the UA.

1.1. Requirements Governing Resolution Algorithms

 The requirements for the resolution of "alert" URNs are given in
 Section 11.1 of [RFC7462] and can be described as follows:
 o  The "alert" URNs are processed from left to right.  Each "alert"
    URN has precedence over all URNs that follow it, and its
    interpretation is subordinate to all URNs that precede it.
 o  As each URN is processed, one of the UA's signals is chosen that
    expresses that URN as far as can be done without reducing the
    degree to which any of the preceding URNs were expressed by the
    signal chosen for the preceding URN.  Thus, as processing
    proceeds, the chosen signals become increasingly specific and
    contain more information, but all of the information about a
    particular URN that is expressed by the signal chosen for that URN
    is also expressed by the signals chosen for all following URNs.
 o  If the entirety of the current URN cannot be expressed by any
    allowed signal, then each of the trailing alert-ind-parts (the
    sections separated by colons) is in turn removed until the reduced
    URN can be expressed by some signal that also expresses at least
    the same reduced versions of the preceding URNs that were
    expressed by the signal chosen for the preceding URN.  This can be
    described as "a signal that expresses as much of the current URN
    as possible while still expressing as much of the previous URNs as
    the preceding signal did."
 So, for instance, consider processing
     Alert-Info: urn:alert:category-a:part-a1:part-a2,
                 urn:alert:category-b:part-b1:part-b2
 If the UA has no signal for urn:alert:category-a:part-a1:part-a2, it
 removes part-a2 from the URN and checks whether it has a signal for
 the less-specific URN urn:alert:category-a:part-a1.  If it has no

Worley Informational [Page 4] RFC 8433 Resolving Alert-Info URNs August 2018

 signal for that URN, it gives up on the URN entirely (since
 urn:alert:category-a doesn't exist and can be considered to express
 nothing about the call), and the chosen signal is the default signal
 of the UA, i.e., the signal that is used when there is no Alert-Info.
 But let us suppose the UA has a signal for
 urn:alert:category-a:part-a1 and chooses that signal when processing
 the first URN.  All processing after this point will be restricted to
 signals that express urn:alert:category-a:part-a1 or a more specific
 URN of the category "category-a".
 The UA then goes on to examine the next URN,
 urn:alert:category-b:part-b1:part-b2.  If there is a signal that
 expresses both urn:alert:category-a:part-a1 and
 urn:alert:category-b:part-b1:part-b2, then the UA chooses that
 signal.  If there is no such signal, the second URN is reduced to
 urn:alert:category-b:part-b1, and the UA checks for a signal that
 expresses that URN along with urn:alert:category-a:part-a1.  If there
 is no such signal that matches that relaxed requirement, the second
 URN is reduced to urn:alert:category-b, which is discarded, and the
 chosen signal for the first URN is chosen for the second URN.  In any
 case, all processing after this point will be restricted to signals
 that express urn:alert:category-a:part-a1 or a more specific URN of
 the category "category-a" and that also express the chosen part of
 urn:alert:category-b:part-b1:part-b2.
 This process is continued until the last "alert" URN is processed;
 the signal chosen for the last URN is the signal that the UA uses.

1.2. Summary of the New Resolution Algorithm

 The purpose of this document is to describe a resolution algorithm
 that conforms to Section 11.1 of [RFC7462] but is simpler than the
 algorithm described in Section 12 of [RFC7462]: once the UA designer
 has chosen a set of signals and the URNs that they express, an FSM is
 constructed that selects alerting signals based on the URNs in the
 Alert-Info header field(s) in a SIP message.
 o  The designer selects the set of signals that the UA produces,
    matching each signal to a set of "alert" URNs that together
    specify the meaning that is carried by the signal.  (If the signal
    is a "default" signal that has no specific meaning, the set is
    empty.  If the signal carries the meaning of one "alert" URN, the
    set contains that URN.  If the signal carries a meaning that is
    the logical AND of two or more "alert" URNs, the set contains
    those URNs.)

Worley Informational [Page 5] RFC 8433 Resolving Alert-Info URNs August 2018

 o  Based on the UA's signals and their meanings, the designer
    constructs an "alphabet" containing a finite number of symbols;
    each possible "alert" URN is mapped into one particular symbol.
 o  The designer constructs an FSM whose input is the alphabet of
    symbols and whose states describe the information extracted from
    the Alert-Info URNs.
 o  Each state of the FSM has an associated signal.  Processing the
    Alert-Info URNs will leave the FSM in some particular state; the
    UA renders the signal that is attached to that final state.
 To select a ring tone or ringback tone based on a SIP message, the UA
 processes the "alert" URNs in the Alert-Info header field from left
 to right.  Initially, the FSM is in a designated initial state.  The
 UA maps each successive URN into the corresponding symbol and then
 executes the state transition of the FSM specified by the symbol.
 The state of the FSM after processing the URNs determines which
 signal the UA will render to the user.
 Note that the UA generally has two FSMs, because a UA usually wants
 to signal different information in ring tones than it signals in
 ringback tones.  One FSM is used to select the ring tone to render
 for an incoming INVITE request.  The other FSM is used to select the
 ringback tone to render based on an incoming provisional response to
 an outgoing INVITE request.  Both FSMs are constructed in the same
 way, but the constructions are based on different lists of signals
 and corresponding URNs.
 All of the steps of the method after the designer has selected the
 signals and their URNs are algorithmic, and the algorithm of those
 steps ensures that the operation of the FSM will satisfy the
 constraints of Section 11.1 of [RFC7462].  A Python implementation of
 the algorithmic steps is provided in [code].
 In simple situations, a suitable FSM or equivalent ad hoc code can be
 constructed by hand using ad hoc analysis.  Generally, this is only
 practical in situations where a small number of alert-categories and
 alert-indications are signaled and the categories interact in a
 simple, uniform way.  For example, the examples in Sections 5.1 and
 5.2 could be constructed by ad hoc analysis.  But automatic
 processing is valuable if the situation is too complicated to
 construct a correct FSM by ad hoc analysis, or if the set of signals
 will change too frequently for human production to be economical.

Worley Informational [Page 6] RFC 8433 Resolving Alert-Info URNs August 2018

1.3. Conventions Used in This Document

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
 "OPTIONAL" in this document are to be interpreted as described in
 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
 capitals, as shown here.

2. Selecting the Signals and Their Corresponding "alert" URNs

 The designer must select signals that the UA will generate and define
 the meanings that the signals will have to the user.  Based on this,
 the designer determines for each signal the "alert" URN or
 combination of "alert" URNs that (1) indicate that signal's meaning
 in SIP messages and (2) consequently should elicit that signal from
 the UA.
 For example, suppose the UA has a particular ring tone for calls from
 an external source.  A call from an external source is marked with
 the URN urn:alert:source:external (specified in Section 9 of
 [RFC7462]).  Thus, the table of signals includes:
     Signal                          URN(s)
     ----------------------------    -------------------------------
     external source                 urn:alert:source:external
 Similarly, if the UA has a particular ring tone for calls from an
 internal source, the table includes:
     Signal                          URN(s)
     ----------------------------    -------------------------------
     internal source                 urn:alert:source:internal
 If the UA has ring tones for calls that are marked as having higher
 or lower priority, then the table includes:
     Signal                          URN(s)
     ----------------------------    -------------------------------
     high priority                   urn:alert:priority:high
     low priority                    urn:alert:priority:low
 Note that the UA must be able to signal for a message that has no
 "alert" URNs in the Alert-Info header field, which means that there
 must always be a default signal that has zero corresponding URNs:
     Signal                          URN(s)
     ----------------------------    -------------------------------
     default                         (none)

Worley Informational [Page 7] RFC 8433 Resolving Alert-Info URNs August 2018

 A signal can be defined to indicate a combination of conditions.  For
 instance, a signal that is used only for high-priority, internal-
 source calls expresses two URNs and will only be used when both URNs
 are present in Alert-Info:
     Signal                          URN(s)
     ------------------------------  -------------------------------
     high priority, internal source  urn:alert:priority:high,
                                         urn:alert:source:internal
 A signal can be defined to cover a number of related conditions by
 specifying a URN that is the common prefix of the URNs for the
 various conditions.  For instance, the URNs for "recall due to
 callback", "recall due to call hold", and "recall due to transfer"
 all start with urn:alert:service:recall, and so one signal can be
 provided for all of them by:
     Signal                          URN(s)
     ----------------------------    -------------------------------
     recall                          urn:alert:service:recall
 But if a specific signal is also provided for "recall due to
 callback" by this entry:
     Signal                          URN(s)
     ----------------------------    ---------------------------------
     recall generally                urn:alert:service:recall
     recall due to callback          urn:alert:service:recall:callback
 then if the message contains urn:alert:service:recall:callback, the
 "recall due to callback" signal will be chosen instead of "recall
 generally" because the UA chooses the signal that most completely
 expresses the information in the Alert-Info header field.
 The designer may wish to define extension URNs that provide more
 specific information about a call than the standard "alert" URNs do.
 One method is to add additional components to standard URNs.  For
 instance, an extra-high priority could be indicated by the URN
 urn:alert:priority:high:extra@example.  The final "extra@example" is
 an "alert-ind-part" that is a private extension.  (See Sections 7 and
 10.2 of [RFC7462] for a discussion of private extensions.)  In any
 case, adding an alert-ind-part to a URN makes its meaning more
 specific, in that any call to which the longer URN can be applied can
 also have the shorter URN applied.  In this case, "extra-high-
 priority calls" are considered a subset of "high-priority calls".

Worley Informational [Page 8] RFC 8433 Resolving Alert-Info URNs August 2018

     Signal                URN(s)
     --------------------- -----------------------------------------
     high priority         urn:alert:priority:high
     extra-high priority   urn:alert:priority:high:extra@example.com
 Of course, for this extension to be useful, the senders of SIP
 messages (e.g., other UAs) must generate the extension URN in
 suitable circumstances.
 In some circumstances, the designer may want to create an entirely
 new category of "alert" URNs to indicate a type of information that
 is not indicated by any standard category of URNs.  In that case, the
 designer uses a private extension as the alert-category (the third
 component of the URN), combined with whatever alert-ind-part (fourth
 component) values are desired.  For example, a simplified version of
 the U.S. military security designations could be:
     Signal                    URN(s)
     -----------------------   ---------------------------------------
     unclassified              urn:alert:security@example:unclassified
     confidential              urn:alert:security@example:confidential
     secret                    urn:alert:security@example:secret
     top secret                urn:alert:security@example:top-secret
 The designer should ensure that the new alert-category is orthogonal
 to all defined standard alert-categories, in that any combination of
 one of the new URNs with one of the standard URNs is meaningful in
 that there could be a message carrying both URNs.
 In addition, the set of alert-ind-parts for the new alert-category
 should be comprehensive and disjoint, in that every message can be
 described by exactly one of them.

3. General Considerations for Processing Alert-Info

 In this section, we will discuss various considerations that arise
 when processing Alert-Info.  These have to be taken care of properly
 in order to conform to the standards, as well as to ensure a good
 user experience.  But since they are largely independent of the
 generated FSM and its processing, they are gathered here in a
 separate section.
 The UA may have a number of different FSMs for processing URNs.
 Generally, there will be different FSMs for processing Alert-Info in
 incoming INVITE requests and for incoming provisional responses to
 outgoing INVITE requests.  But any situation that changes the set of
 signals that the UA is willing to generate specifies a different set
 of signals and corresponding URNs and thus generates a different FSM.

Worley Informational [Page 9] RFC 8433 Resolving Alert-Info URNs August 2018

 For example, if a call is active on the UA, all audible signals may
 become unavailable, or audible signals may be available only if
 urn:alert:priority:high is specified.
 Similarly, if the set of signals is customized by user action or
 local policy, the generated FSM must be updated.  This can be done by
 (1) regenerating it according to the method described here or
 (2) generating a "generic" FSM and instantiating it based on the
 available signals.  (See Section 7 for a discussion of this.)
 Note that the values in an Alert-Info header field are allowed to be
 URIs of any scheme and, within the "urn" scheme, are allowed to have
 any namespace [RFC3261].  The processing of URIs that are not "alert"
 URNs is not considered by this document, nor is that processing
 specified by [RFC7462].  But the algorithm designer must consider
 what to do with such URIs if they are encountered.  The simplest
 choice is to ignore them.  Alternatively, the algorithm may examine
 the URI to determine if it names an alerting signal or describes how
 to retrieve an alerting signal, and, if so, choose to render that
 signal rather than process the "alert" URNs to select a signal.  In
 any case, the remainder of this document assumes that (1) the signal
 is to be chosen based on the "alert" URNs in Alert-Info and (2) all
 Alert-Info URIs that are not "alert" URNs have been removed.
 The UA may also receive "alert" URNs that are semantically invalid in
 various ways.  For example, the URN may have only three components,
 despite the fact that all valid "alert" URNs have at least one
 alert-ind-part and thus four components.  The only useful strategy is
 to ignore such URNs (and possibly log them for analysis).
 The method described here is robust in its handling of categories and
 alert-ind-parts that are unknown to the UA; as a consequence, it is
 also robust if they are not valid standardized URNs.  Thus, these
 error conditions need not be handled specially.

4. Constructing the Finite State Machine for a Very Simple Example

 Constructing the FSM involves:
 1.  Listing the URNs that are expressed by the various signals of
     the UA.
 2.  From the expressed URNs, constructing the finite alphabet of
     symbols into which input URNs are mapped and that drive the state
     transitions of the FSM.

Worley Informational [Page 10] RFC 8433 Resolving Alert-Info URNs August 2018

 3.  Constructing the states of the FSM and the transitions between
     them.
 4.  Selecting a signal to be associated with each FSM state.
 We will explain the process using a very simple example in which
 there are two signals -- one expressing "internal source" and one
 expressing "external source" -- along with a default signal (for when
 there is no source information to signal).  The "internal source"
 signal expresses urn:alert:source:internal, and the "external source"
 signal expresses urn:alert:source:external.

4.1. Listing the Expressed URNs

 The first step is to establish for each of the UA's signals what call
 characteristics it represents, which is to say, the set of "alert"
 URNs that are its information content.
     Signal                          URN(s)
     ----------------------------    -------------------------------
     default                         (none)
     internal source                 urn:alert:source:internal
     external source                 urn:alert:source:external
 From the totality of these expressed URNs, the designer can then
 determine which sets of URNs must be distinguished from each other.
 In our simple example, the expressed URNs are:
     urn:alert:source:external
     urn:alert:source:internal

4.2. Constructing the Alphabet of Symbols

 In order to reduce the infinite set of possible "alert" URNs to a
 finite alphabet of input symbols that cause the FSM's transitions,
 the designer must partition the "alert" URNs into a finite set of
 categories.
 Once we've listed all the expressed URNs, we can list all of the
 alert-categories that are relevant to the UA's signaling; "alert"
 URNs in any other alert-category cannot affect the signaling and can
 be ignored.  (The easiest way to ignore the non-relevant URNs is to
 skip over them during Alert-Info processing.  A more formal method is
 to map all of them into one "Other" symbol and then, for each state
 of the FSM, have the "Other" symbol transition to that same state.)

Worley Informational [Page 11] RFC 8433 Resolving Alert-Info URNs August 2018

 Within each relevant alert-category, we now define a distinct
 symbol for every expressed URN and for all of their "ancestor" URNs
 (those that can be created by removing one or more trailing
 alert-ind-parts).  In order to name the symbols in a way that
 distinguishes them from the corresponding URNs, we remove the initial
 "urn:alert:" and capitalize each alert-ind-part.  Thus, in our
 example, we get these symbols:
     Source
     Source:External
     Source:Internal
 Note that there is a "Source" symbol even though there is no
 corresponding URN.  (urn:alert:source is not a valid URN -- see
 Section 7 of [RFC7462] -- although the processing algorithm must be
 prepared to screen out such a purported URN if it appears in the
 Alert-Info header field.)  However, its existence as a symbol will be
 useful later when we construct the FSM.
 For each of these symbols, we add a symbol that classifies URNs that
 extend the symbol's corresponding URN with alert-ind-parts that
 cannot be expressed by signals:
     Source:Other
     Source:External:Other
     Source:Internal:Other
 The latter two classify URNs, such as
 urn:alert:source:external:foo@example, that extend URNs that we
 already have symbols for.  The first is for classifying URNs, such as
 urn:alert:source:bar@example, that have first alert-ind-parts that
 contradict all the "source" URNs that the UA can signal.
 These steps give us this set of symbols:
     Source
     Source:External
     Source:External:Other
     Source:Internal
     Source:Internal:Other
     Source:Other
 We can then simplify the set of symbols by removing the ones like
 Source:External:Other and Source:Internal:Other that consist of
 adding "Other" to a symbol that corresponds to an expressed URN that
 is not ancestral to any other expressed URNs.  This works because
 adding further alert-ind-parts to a URN that is a leaf in regard to

Worley Informational [Page 12] RFC 8433 Resolving Alert-Info URNs August 2018

 the set of signals has no additional effect.  In this example,
 urn:alert:source:external:foo@example has the same effect as
 urn:alert:source:external for both (1) causing a signal to be chosen
 and (2) suppressing the effect of later URNs.
 This leaves the following symbols for the "source" category:
     Source
     Source:External
     Source:Internal
     Source:Other
 These can be visually summarized by showing the infinite tree of
 possible source "alert" URNs and how it is partitioned into subtrees
 that map to each of these symbols.  We also mark with "*" the
 expressed URNs.
                              urn:alert
                                  |
                              {   |    }
                              { source } --> 1
                              {   |    }
                                  |
             +--------------------+------------------+
             |                    |                  |
        {    |      }        {    |      }        {  |  }
        { external* } --> 2  { internal* } --> 3  { ... } --> 4
        {    |      }        {    |      }        {     }
        {   ...     }        {   ...     }
        {           }        {           }
     1 = Source
     2 = Source:External
     3 = Source:Internal
     4 = Source:Other

4.3. Constructing the States and Transitions

 The UA processes the Alert-Info URNs from left to right using an FSM,
 with each successive URN causing the FSM to transition to a new
 state.  Each state of the FSM records the information that has so far
 been extracted from the URNs.  The state of the FSM after processing
 all the URNs determines which signal the UA will render to the user.
 We label each state with a set of symbols, one from each relevant
 category, that describe the information that's been extracted from
 all of the URNs that have so far been processed.  The initial state
 is labeled with the "null" symbols that are just the category names,

Worley Informational [Page 13] RFC 8433 Resolving Alert-Info URNs August 2018

 because no information has yet been recorded.  In our simple example,
 the initial state is labeled "Source", since that's the only relevant
 category.
     State: Source (initial state)
 Each state has a corresponding alerting signal, which is the signal
 that the UA will produce when URN processing leaves the FSM in that
 state.  The signal is the one that best expresses the information
 that has been extracted from the URNs.  Usually, the choice of signal
 is obvious to the designer, but there are certain constraints that
 the choice must satisfy.  The main constraint is that the signal's
 expressed URNs must be semantic supersets of (i.e., identical to or a
 prefix of) the URNs corresponding to the symbols in the state's
 label.  In particular, if the expressed URN of the signal in a
 certain category is shorter than the state's label, we show that in
 the state's name by putting parentheses around the trailing part of
 the symbol that is not expressed by the signal.  For instance, if the
 symbol in the label is "Source:External" but the signal only
 expresses "Source" (i.e., no "source" URN at all), then the symbol in
 the label is modified to be "Source:(External)".
 The reason for this nonintuitive construction is that in some states,
 the FSM has recorded information that the chosen signal cannot
 express.
 Note that the parentheses are part of the state name, so in some
 circumstances there may be two or more distinct states labeled with
 the same symbols but with different placement of parentheses within
 the symbols.  These similar state names are relevant when the FSM can
 record information from multiple "alert" URNs but cannot express all
 of them -- depending on the order in which the URNs appear, the UA
 may have to render different signals, so it needs states that record
 the same information but render different subsets of that
 information.
 The initial state's label is the string of null symbols for the
 relevant categories, so the only allowed signal is the default
 signal, which expresses no URNs:
     State: Source (initial state)
     Signal: default

Worley Informational [Page 14] RFC 8433 Resolving Alert-Info URNs August 2018

 From each state, we must construct the transition for each possible
 input symbol.  For a particular current state and symbol, we
 construct the label of the next state by combining the input symbol
 with the symbol in the current state's label for the same category.
 If one of the symbols is a prefix of the other, we select the longer
 one; if not, we select the symbol in the current state's label.
 Thus, in our simple example, the initial state has the following
 transitions:
     State: Source (initial state)
     Signal: default
     Transitions:
         Source:External -> Source:External
         Source:Internal -> Source:Internal
         Source:Other -> Source:Other
 In all of these transitions, the input symbol is compatible with the
 matching label of the current state, "Source", so the next state's
 label is the full input symbol.
 However, there is a further constraint on the next state: its signal
 must express URNs that at least contain the expressed URNs of the
 signal of the current state.  Within that constraint, and being
 compatible with the next state's label, for the category of the input
 URN, the next state's signal must express the longest URN that can be
 expressed by any signal.
 In our example, this means that the next Source:External state has
 the "external source" signal, which expresses
 urn:alert:source:external.  Since that signal expresses all of the
 state's label, it is the chosen state.  Similarly, the next
 Source:Internal state has the "internal source" signal.  But for the
 transition on input Source:Other, the "Source:Other" state must have
 the default signal, as there is no signal that expresses
 urn:alert:source:[some-unknown-alert-ind-part].  So the next state is
 "Source:(Other)", where the parentheses record that the "Other" part
 of the label is not expressed by the state's signal.

Worley Informational [Page 15] RFC 8433 Resolving Alert-Info URNs August 2018

 Thus, the current state and the next states that it can transition
 to are:
     State: Source (initial state)
     Signal: default
     Transitions:
         Source:External -> Source:External
         Source:Internal -> Source:Internal
         Source:Other -> Source:(Other)
     State: Source:External
     Signal: external source (urn:alert:source:external)
     State: Source:Internal
     Signal: internal source (urn:alert:source:internal)
     State: Source:(Other)
     Signal: default
 Looking at the state Source:External, we see that it is incompatible
 with all input symbols other than Source:External, and thus all of
 its transitions are to itself:
     State: Source:External
     Signal: external source (urn:alert:source:external)
     Transitions:
         Source:External -> Source:External
         Source:Internal -> Source:External
         Source:Other -> Source:External
 and similarly:
     State: Source:Internal
     Signal: internal source (urn:alert:source:internal)
     Transitions:
         Source:External -> Source:Internal
         Source:Internal -> Source:Internal
         Source:Other -> Source:Internal
     State: Source:(Other)
     Signal: default
     Transitions:
         Source:External -> Source:(Other)
         Source:Internal -> Source:(Other)
         Source:Other -> Source:(Other)

Worley Informational [Page 16] RFC 8433 Resolving Alert-Info URNs August 2018

4.4. Summary

 The FSM can be constructed by processing the file "very-simple.txt"
 with the program "alert-info-fsm.py" in [code].  The program's output
 shows the stages of the construction, which are as follows:
 1.  The signals have the meanings:
     Signal                          URN(s)
     ----------------------------    -------------------------------
     default                         (none)
     internal source                 urn:alert:source:internal
     external source                 urn:alert:source:external
 2.  The expressed URNs are:
     urn:alert:source:external
     urn:alert:source:internal
 3.  The relevant categories of "alert" URNs are only:
     source
 4.  Thus, the infinite universe of possible "alert" URNs can be
     reduced to these symbols, which are the categories of URNs that
     are different in ways that are significant to the resolution
     process:
     Source
     Source:External
     Source:Internal
     Source:Other
 5.  The FSM is:
     State: Source (initial state)
     Signal: default
     Transitions:
         Source:External -> Source:External
         Source:Internal -> Source:Internal
         Source:Other -> Source:(Other)
     State: Source:External
     Signal: external source (urn:alert:source:external)
     Transitions:
         Source:External -> Source:External
         Source:Internal -> Source:External
         Source:Other -> Source:External

Worley Informational [Page 17] RFC 8433 Resolving Alert-Info URNs August 2018

     State: Source:Internal
     Signal: internal source (urn:alert:source:internal)
     Transitions:
         Source:External -> Source:Internal
         Source:Internal -> Source:Internal
         Source:Other -> Source:Internal
     State: Source:(Other)
     Signal: default
     Transitions:
         Source:External -> Source:(Other)
         Source:Internal -> Source:(Other)
         Source:Other -> Source:(Other)
  • Each state is labeled by a set of symbols that describe the

information that has been extracted from the URNs so far.

  • Each state has a signal that is a semantic superset of the

state's label, i.e., the signal's expressed URNs match the

        initial portion of the label symbols.  If Alert-Info
        processing finishes with the FSM in a state, the UA will
        render the state's signal to the user.
  • The state's label is marked to show what subset of the symbols

are expressed by the state's signal. Two states can have the

        same label but different signals.
  • If a transition's input symbol is compatible with (is a

semantic subset of) the current state's label for that

        category, the next state's label is updated with the input
        symbol.  If not, the next state is the current state.  This is
        how the state's label records what information has been
        accumulated while processing the Alert-Info URNs.
  • A transition's next state has a signal that semantically

subsets the current state's signal as much as possible in the

        category of the input symbol.  (In most cases, the choice of
        signal is unique.  In rare cases, there may be more than one
        signal that meets this criterion, so the designer may have
        some flexibility.)

Worley Informational [Page 18] RFC 8433 Resolving Alert-Info URNs August 2018

4.5. Examples of Processing Alert-Info URNs

 In the trivial case where the UA receives no Alert-Info URNs,
 processing begins and ends with the FSM in the initial state, and the
 default signal is selected.
 If the UA receives
     Alert-Info: <urn:alert:source:internal>
 then processing progresses:
     State: Source
         Process: Source:Internal (urn:alert:source:internal)
     State: Source:Internal
     Signal: internal source
 If the UA receives
     Alert-Info: <urn:alert:source:external>,
         <urn:alert:source:internal>
 then processing progresses:
     State: Source
         Process: Source:External (urn:alert:source:external)
     State: Source:External
         Process: Source:Internal (urn:alert:source:internal)
     State: Source:External
     Signal: external source
 If the UA receives
     Alert-Info: <urn:alert:source:unclassified>,
         <urn:alert:source:internal>
 then processing progresses:
     State: Source
         Process: Source:Other (urn:alert:source:unclassified)
     State: Source:(Other)
         Process: Source:Internal (urn:alert:source:internal)
     State: Source:(Other)
     Signal: default

Worley Informational [Page 19] RFC 8433 Resolving Alert-Info URNs August 2018

 If the UA receives
     Alert-Info: <urn:alert:priority:high>,
         <urn:alert:source:internal>
 then processing progresses:
     State: Source
         Ignore: urn:alert:priority:high
     State: Source
         Process: Source:Internal (urn:alert:source:internal)
     State: Source:Internal
     Signal: internal source

5. Further Examples

5.1. Example with "source" and "priority" URNs

 Now consider an example where the UA can signal "external source",
 "internal source", "low priority", and "high priority" individually
 or in any combination of source and priority, along with a default
 signal.  This example is essentially the Cartesian product of two
 copies of the example in Section 4: one dealing with the call's
 source and one dealing with the call's priority.  So there are a
 total of 9 signals:
     Signal                          URN(s)
     ----------------------------    -------------------------------
     default                         (none)
     external source                 urn:alert:source:external
     internal source                 urn:alert:source:internal
     low priority                    urn:alert:priority:low
     low priority/external source    urn:alert:priority:low,
                                         urn:alert:source:external
     low priority/internal source    urn:alert:priority:low,
                                         urn:alert:source:internal
     high priority                   urn:alert:priority:high
     high priority/external source   urn:alert:priority:high,
                                         urn:alert:source:external
     high priority/internal source   urn:alert:priority:high,
                                         urn:alert:source:internal
 The expressed URNs are:
     urn:alert:source:external
     urn:alert:source:internal
     urn:alert:priority:low
     urn:alert:priority:high

Worley Informational [Page 20] RFC 8433 Resolving Alert-Info URNs August 2018

 The relevant categories of "alert" URNs are only:
     source
     priority
 The alphabet of symbols is:
     Source
     Source:External
     Source:Internal
     Source:Other
     Priority
     Priority:Low
     Priority:High
     Priority:Other
 The 16 states are as follows, where 9 states are "sink" states from
 which no further information can be recorded, as all transitions from
 the state lead to itself.
     State: Priority/Source
     Signal: default
     Transitions:
         Priority:Other -> Priority:(Other)/Source
         Priority:High -> Priority:High/Source
         Priority:Low -> Priority:Low/Source
         Source:Other -> Priority/Source:(Other)
         Source:External -> Priority/Source:External
         Source:Internal -> Priority/Source:Internal
     State: Priority:(Other)/Source
     Signal: default
     Transitions:
         Priority:Other -> Priority:(Other)/Source
         Priority:High -> Priority:(Other)/Source
         Priority:Low -> Priority:(Other)/Source
         Source:Other -> Priority:(Other)/Source:(Other)
         Source:External -> Priority:(Other)/Source:External
         Source:Internal -> Priority:(Other)/Source:Internal
     State: Priority:(Other)/Source:(Other)
     Signal: default
     Transitions:
         any -> Priority:(Other)/Source:(Other)

Worley Informational [Page 21] RFC 8433 Resolving Alert-Info URNs August 2018

     State: Priority:(Other)/Source:External
     Signal: external source
     Transitions:
         any -> Priority:(Other)/Source:External
     State: Priority:(Other)/Source:Internal
     Signal: internal source
     Transitions:
         any -> Priority:(Other)/Source:Internal
     State: Priority:High/Source
     Signal: high priority
     Transitions:
         Priority:Other -> Priority:High/Source
         Priority:High -> Priority:High/Source
         Priority:Low -> Priority:High/Source
         Source:Other -> Priority:High/Source:(Other)
         Source:External -> Priority:High/Source:External
         Source:Internal -> Priority:High/Source:Internal
     State: Priority:High/Source:(Other)
     Signal: high priority
     Transitions:
         any -> Priority:High/Source:(Other)
     State: Priority:High/Source:External
     Signal: high priority/external source
     Transitions:
         any -> Priority:High/Source:External
     State: Priority:High/Source:Internal
     Signal: high priority/internal source
     Transitions:
         any -> Priority:High/Source:Internal
     State: Priority:Low/Source
     Signal: low priority
     Transitions:
         Priority:Other -> Priority:Low/Source
         Priority:High -> Priority:Low/Source
         Priority:Low -> Priority:Low/Source
         Source:Other -> Priority:Low/Source:(Other)
         Source:External -> Priority:Low/Source:External
         Source:Internal -> Priority:Low/Source:Internal

Worley Informational [Page 22] RFC 8433 Resolving Alert-Info URNs August 2018

     State: Priority:Low/Source:(Other)
     Signal: low priority
     Transitions:
         any -> Priority:Low/Source:(Other)
     State: Priority:Low/Source:External
     Signal: low priority/external source
     Transitions:
         any -> Priority:Low/Source:External
     State: Priority:Low/Source:Internal
     Signal: low priority/internal source
     Transitions:
         any -> Priority:Low/Source:Internal
     State: Priority/Source:(Other)
     Signal: default
     Transitions:
         Priority:Other -> Priority:(Other)/Source:(Other)
         Priority:High -> Priority:High/Source:(Other)
         Priority:Low -> Priority:Low/Source:(Other)
         Source:Other -> Priority/Source:(Other)
         Source:External -> Priority/Source:(Other)
         Source:Internal -> Priority/Source:(Other)
     State: Priority/Source:External
     Signal: external source
     Transitions:
         Priority:Other -> Priority:(Other)/Source:External
         Priority:High -> Priority:High/Source:External
         Priority:Low -> Priority:Low/Source:External
         Source:Other -> Priority/Source:External
         Source:External -> Priority/Source:External
         Source:Internal -> Priority/Source:External
     State: Priority/Source:Internal
     Signal: internal source
     Transitions:
         Priority:Other -> Priority:(Other)/Source:Internal
         Priority:High -> Priority:High/Source:Internal
         Priority:Low -> Priority:Low/Source:Internal
         Source:Other -> Priority/Source:Internal
         Source:External -> Priority/Source:Internal
         Source:Internal -> Priority/Source:Internal

Worley Informational [Page 23] RFC 8433 Resolving Alert-Info URNs August 2018

 An example of processing that involves multiple "source" URNs and one
 "priority" URN:
     Alert-Info: <urn:alert:source:internal>,
         <urn:alert:source:unclassified>,
         <urn:alert:priority:high>
 in which case processing progresses:
     State: Source/Priority
         Process: Source:Internal (urn:alert:source:internal)
     State: Source:Internal/Priority
         Process: Source:(Other) (urn:alert:source:unclassified)
     State: Source:Internal/Priority
         Process: Priority:High (urn:alert:priority:high)
     State: Source:Internal/Priority:High
     Signal: internal source/high priority

5.2. Example 1 of RFC 7462

 A more complicated example is provided in Section 12.2.1 of
 [RFC7462].  It is like the example in Section 5.1 of this document,
 except that the UA can only signal "external source", "internal
 source", "low priority", and "high priority" individually but not in
 combination, as well as a default signal:
     Signal                          URN(s)
     ----------------------------    -------------------------------
     default                         (none)
     internal source                 urn:alert:source:external
     external source                 urn:alert:source:internal
     low priority                    urn:alert:priority:low
     high priority                   urn:alert:priority:high
 The signals can express the following URNs:
     urn:alert:source:external
     urn:alert:source:internal
     urn:alert:priority:low
     urn:alert:priority:high
 The relevant categories of "alert" URNs are:
     source
     priority

Worley Informational [Page 24] RFC 8433 Resolving Alert-Info URNs August 2018

 The alphabet of symbols is:
     Source
     Source:External
     Source:Internal
     Source:Other
     Priority
     Priority:Low
     Priority:High
     Priority:Other
 In this example, the FSM has 20 states because both "source" and
 "priority" URNs are recorded, but the order in which the two appear
 affects the signal:
     State: Priority/Source
     Signal: default
     Transitions:
         Priority:Other -> Priority:(Other)/Source
         Priority:High -> Priority:High/Source
         Priority:Low -> Priority:Low/Source
         Source:Other -> Priority/Source:(Other)
         Source:External -> Priority/Source:External
         Source:Internal -> Priority/Source:Internal
 State Priority:(Other)/Source can transition to states that can
 signal the source, because the recorded priority can't be signaled
 and thus does not block the signaling of the source:
     State: Priority:(Other)/Source
     Signal: default
     Transitions:
         Priority:Other -> Priority:(Other)/Source
         Priority:High -> Priority:(Other)/Source
         Priority:Low -> Priority:(Other)/Source
         Source:Other -> Priority:(Other)/Source:(Other)
         Source:External -> Priority:(Other)/Source:External
         Source:Internal -> Priority:(Other)/Source:Internal
     State: Priority:(Other)/Source:(Other)
     Signal: default
     Transitions:
         any -> Priority:(Other)/Source:(Other)
     State: Priority:(Other)/Source:External
     Signal: external source
     Transitions:
         any -> Priority:(Other)/Source:External

Worley Informational [Page 25] RFC 8433 Resolving Alert-Info URNs August 2018

     State: Priority:(Other)/Source:Internal
     Signal: internal source
     Transitions:
         any -> Priority:(Other)/Source:Internal
 Because there are no signals for combinations of "source" and
 "priority" URNs, processing a "source" URN from the state
 Priority:High/Source leads to a state that records the priority
 information but does not signal it:
     State: Priority:High/Source
     Signal: high priority
     Transitions:
         Priority:Other -> Priority:High/Source
         Priority:High -> Priority:High/Source
         Priority:Low -> Priority:High/Source
         Source:Other -> Priority:High/Source:(Other)
         Source:External -> Priority:High/Source:(External)
         Source:Internal -> Priority:High/Source:(Internal)
     State: Priority:High/Source:(Other)
     Signal: high priority
     Transitions:
         any -> Priority:High/Source:(Other)
 From the state Priority:High/Source, "source" URNs transition to
 states that record both source and priority but signal only priority,
 one of which is Priority:High/Source:(External).  But from
 Priority/Source:External, the symbol Priority:High transitions to the
 state Priority:(High)/Source:External, which records the same
 information but signals the source, not the priority.  One state is
 reached by processing a "priority" URN and then a "source" URN,
 whereas the other is reached by processing a "source" URN and then a
 "priority" URN.
     State: Priority:High/Source:(External)
     Signal: high priority
     Transitions:
         any -> Priority:High/Source:(External)
     State: Priority:High/Source:(Internal)
     Signal: high priority
     Transitions:
         any -> Priority:High/Source:(Internal)

Worley Informational [Page 26] RFC 8433 Resolving Alert-Info URNs August 2018

 and similarly for Priority:Low/Source:
     State: Priority:Low/Source
     Signal: low priority
     Transitions:
         Priority:Other -> Priority:Low/Source
         Priority:High -> Priority:Low/Source
         Priority:Low -> Priority:Low/Source
         Source:Other -> Priority:Low/Source:(Other)
         Source:External -> Priority:Low/Source:(External)
         Source:Internal -> Priority:Low/Source:(Internal)
     State: Priority:Low/Source:(Other)
     Signal: low priority
     Transitions:
         any -> Priority:Low/Source:(Other)
     State: Priority:Low/Source:(External)
     Signal: low priority
     Transitions:
         any -> Priority:Low/Source:(External)
     State: Priority:Low/Source:(Internal)
     Signal: low priority
     Transitions:
         any -> Priority:Low/Source:(Internal)
     State: Priority/Source:(Other)
     Signal: default
     Transitions:
         Priority:Other -> Priority:(Other)/Source:(Other)
         Priority:High -> Priority:High/Source:(Other)
         Priority:Low -> Priority:Low/Source:(Other)
         Source:Other -> Priority/Source:(Other)
         Source:External -> Priority/Source:(Other)
         Source:Internal -> Priority/Source:(Other)
     State: Priority/Source:External
     Signal: external source
     Transitions:
         Priority:Other -> Priority:(Other)/Source:External
         Priority:High -> Priority:(High)/Source:External
         Priority:Low -> Priority:(Low)/Source:External
         Source:Other -> Priority/Source:External
         Source:External -> Priority/Source:External
         Source:Internal -> Priority/Source:External

Worley Informational [Page 27] RFC 8433 Resolving Alert-Info URNs August 2018

     State: Priority:(High)/Source:External
     Signal: external source
     Transitions:
         any -> Priority:(High)/Source:External
     State: Priority:(Low)/Source:External
     Signal: external source
     Transitions:
         any -> Priority:(Low)/Source:External
     State: Priority/Source:Internal
     Signal: internal source
     Transitions:
         Priority:Other -> Priority:(Other)/Source:Internal
         Priority:High -> Priority:(High)/Source:Internal
         Priority:Low -> Priority:(Low)/Source:Internal
         Source:Other -> Priority/Source:Internal
         Source:External -> Priority/Source:Internal
         Source:Internal -> Priority/Source:Internal
     State: Priority:(High)/Source:Internal
     Signal: internal source
     Transitions:
         any -> Priority:(High)/Source:Internal
     State: Priority:(Low)/Source:Internal
     Signal: internal source
     Transitions:
         any -> Priority:(Low)/Source:Internal
 As an example of processing, if the UA receives
     Alert-Info: <urn:alert:source:internal>
 then processing progresses:
     State: Priority/Source
         Process: Source:Internal (urn:alert:source:internal)
     State: Priority/Source:Internal
     Signal: internal source

Worley Informational [Page 28] RFC 8433 Resolving Alert-Info URNs August 2018

 A more complicated example involves multiple "source" URNs that do
 not select a non-default signal and one "priority" URN that can be
 signaled:
     Alert-Info: <urn:alert:source:unclassified>,
         <urn:alert:source:internal>,
         <urn:alert:priority:high>
 in which case processing progresses:
     State: Priority/Source
         Process: Source:Other (urn:alert:source:unclassified)
     State: Priority/Source:(Other)
         Process: Source:Internal (urn:alert:source:internal)
     State: Priority/Source:(Other)
         Process: Priority:High (urn:alert:priority:high)
     State: Priority:High/Source:(Other)
     Signal: high priority
 The only output of the FSM is the state's signal.  Based on this,
 several groups of states in this FSM can be merged using standard FSM
 optimization algorithms:
     states with signal "high priority":
         Priority:High/Source
         Priority:High/Source:(Other)
         Priority:High/Source:(External)
         Priority:High/Source:(Internal)
     states with signal "low priority":
         Priority:Low/Source
         Priority:Low/Source:(Other)
         Priority:Low/Source:(External)
         Priority:Low/Source:(Internal)
     states with signal "external source":
         Priority/Source:External
         Priority:(High)/Source:External
         Priority:(Low)/Source:External
         Priority:(Other)/Source:External
     states with signal "internal source":
         Priority/Source:Internal
         Priority:(High)/Source:Internal
         Priority:(Low)/Source:Internal
         Priority:(Other)/Source:Internal

Worley Informational [Page 29] RFC 8433 Resolving Alert-Info URNs August 2018

 This reduces the FSM to eight states:
     Priority/Source
     Priority:(Other)/Source
     Priority:(Other)/Source:(Other)
     Priority:High/Source  [aggregated]
     Priority:Low/Source  [aggregated]
     Priority/Source:(Other)
     Priority/Source:External  [aggregated]
     Priority/Source:Internal  [aggregated]

5.3. Examples 2, 3, and 4 of RFC 7462

 Examples 2, 3, and 4 of [RFC7462] are similar to the example in
 Section 5.1 of this document, but they do not include a signal for
 the combination "internal source, low priority" to make resolution
 examples work asymmetrically.
 The FSM for this example has the same alphabet as the FSM of
 Section 5.1.  Most of the states of this FSM are the same as the
 states of the FSM of Section 5.1, but the state
 Source:Internal/Priority:Low is missing because there is no signal
 for that combination.  It is replaced by two states:
 1.  One state is Source:Internal/Priority:(Low); it records that
     Source:Internal was specified first (and is to be signaled) and
     that Priority:Low was specified later (and cannot be signaled --
     but it still prevents any further "priority" URNs from having an
     effect).
 2.  The other state is Source:(Internal)/Priority:Low; it records the
     reverse sequence of events.
 The changes in the FSM are:
     State: Priority:Low/Source
     Signal: low priority
     Transitions:
         Source:Internal -> Priority:Low/Source:(Internal)
         (other transitions unchanged)
     State: Priority:Low/Source:(Internal)
     Signal: low priority
     Transitions:
         any -> Priority:Low/Source:(Internal)

Worley Informational [Page 30] RFC 8433 Resolving Alert-Info URNs August 2018

     State: Priority/Source:Internal
     Signal: internal source
     Transitions:
         Priority:Low -> Priority:(Low)/Source:Internal
         (other transitions unchanged)
     State: Priority:(Low)/Source:Internal
     Signal: internal source
     Transitions:
         any -> Priority:(Low)/Source:Internal
 An example of processing that involves multiple "source" URNs and one
 "priority" URN:
     Alert-Info: <urn:alert:source:internal>,
         <urn:alert:source:unclassified>,
         <urn:alert:priority:high>
 then processing progresses:
     State: Priority/Source
         Process: Source:Internal (urn:alert:source:internal)
     State: Priority/Source:Internal
         Process: Source:Other (urn:alert:source:unclassified)
     State: Priority/Source:Internal
         Process: Priority:High (urn:alert:priority:high)
     State: Priority:High/Source:Internal
     Signal: internal source/high priority
 If the UA receives
     Alert-Info: <urn:alert:source:internal>
 then processing progresses:
     State: Priority/Source
         Process: Source:Internal (urn:alert:source:internal)
     State: Priority/Source:Internal
     Signal: internal source

Worley Informational [Page 31] RFC 8433 Resolving Alert-Info URNs August 2018

 If the UA receives
     Alert-Info: <urn:alert:source:external>,
         <urn:alert:priority:low>
 then processing progresses:
     State: Priority/Source
         Process: Source:External (urn:alert:source:external)
     State: Priority/Source:External
         Process: Priority:Low (urn:alert:priority:low)
     State: Priority:Low/Source:External
     Signal: external source/low priority
 Suppose the same UA receives
     Alert-Info: <urn:alert:source:internal>,
         <urn:alert:priority:low>
 Note that there is no signal that corresponds to this combination.
 In that case, the processing is:
     State: Priority/Source
         Process: Source:Internal (urn:alert:source:internal)
     State: Priority/Source:Internal
         Process: Priority:Low (urn:alert:priority:low)
     State: Priority:(Low)/Source:Internal
     Signal: internal source
 If the order of the URNs is reversed, what is signaled is the meaning
 of the now-different first URN:
     Alert-Info: <urn:alert:priority:low>,
         <urn:alert:source:internal>
     State: Priority/Source
         Process: Priority:Low (urn:alert:priority:low)
     State: Priority:Low/Source
         Process: Source:Internal (urn:alert:source:internal)
     State: Priority:Low/Source:(Internal)
     Signal: low priority

Worley Informational [Page 32] RFC 8433 Resolving Alert-Info URNs August 2018

 Notice that the existence of the new states prevents later URNs of a
 category from overriding earlier URNs of that category, even if the
 earlier one was not itself signalable and the later one would be
 signalable in the absence of the earlier one:
     Alert-Info: <urn:alert:priority:low>,
         <urn:alert:source:internal>,
         <urn:alert:source:external>
     State: Priority/Source
         Process: Priority:Low (urn:alert:priority:low)
     State: Priority:Low/Source
         Process: Source:Internal (urn:alert:source:internal)
     State: Priority:Low/Source:(Internal)
         Process: Source:External (urn:alert:source:external)
     State: Priority:Low/Source:(Internal)
     Signal: low priority
 This situation shows the necessity of states whose labels contain
 parentheses.  If the second transition had been to the state
 Priority:Low/Source (on the basis that there is no proper state
 Priority:Low/Source:Internal), then the third transition would have
 been to the state Priority:Low/Source:External, and the signal would
 have been "external source/low priority".

5.4. An Example That Subsets Internal Sources

 In the example of Section 4, there are signals for "external source"
 and "internal source".  Let us add to that example a signal for
 "source internal from a VIP (Very Important Person)".  That last
 signal expresses the private extension URN
 urn:alert:source:internal:vip@example, which is a subset of
 urn:alert:source:internal, which is expressed by the "source
 internal" signal.  There are a total of three expressed URNs, one of
 which is a subset of another:
     urn:alert:source:internal
     urn:alert:source:internal:vip@example
     urn:alert:source:external
 This generates the following alphabet of symbols, which includes two
 "Other" symbols for the "source" category:
     Source
     Source:Internal
     Source:Internal:Vip@example
     Source:Internal:Other
     Source:Other

Worley Informational [Page 33] RFC 8433 Resolving Alert-Info URNs August 2018

5.5. An Example of "alert:service" URNs

 In this example, there are signals for "service forward" (the call
 has been forwarded) and "source recall callback" (a recall due to a
 callback).  This gives two expressed URNs:
     urn:alert:service:forward
     urn:alert:service:recall:callback
 This generates the following alphabet of symbols.  Note that there
 are two "Other" symbols, because the "alert:service" URNs have an
 additional level of qualification.
     Service
     Service:Forward
     Service:Recall
     Service:Recall:Callback
     Service:Recall:Other
     Service:Other

5.6. An Example Using Country Codes

 In this example, we consider how a UA generates ringback signals when
 the UA wishes to reproduce the traditional behavior where the caller
 hears the ringback signals defined by the telephone service in the
 callee's country rather than the ringback signals defined by the
 service in the caller's country.  In the Alert-Info header field of
 the 180 (Ringing) provisional response, we assume that the called UA
 provides an "alert:country" URN [RFC7462] containing the ISO 3166-1
 [ISO-3166-1] alpha-2 country code of the callee's country.
 The UA has a default signal and a "non-country" signal for
 urn:alert:service:call-waiting.  For the example country with code
 "XA", the UA has a default signal and signals for
 urn:alert:service:call-waiting and urn:alert:service:forward.  For
 the example country with code "XB", the UA has a default signal and a
 signal for urn:alert:service:forward.  These inconsistencies between
 the non-country signals and the country signals are chosen to
 demonstrate the flexibility of the construction method, showing that
 three systems of signals can be combined correctly even when the
 systems were established without coordination between them.

Worley Informational [Page 34] RFC 8433 Resolving Alert-Info URNs August 2018

 The signals are:
     Signal                        URN(s)
     --------------------------    ----------------------------------
     default                       (none)
     call-waiting                  urn:alert:service:call-waiting
     XA default                    urn:alert:country:xa
     XA call-waiting               urn:alert:country:xa,
                                       urn:alert:service:call-waiting
     XA forward                    urn:alert:country:xa,
                                       urn:alert:service:forward
     XB default                    urn:alert:country:xb
     XB forward                    urn:alert:country:xb,
                                      urn:alert:service:forward
 The expressed URNs are:
     urn:alert:country:xa
     urn:alert:country:xb
     urn:alert:service:call-waiting
     urn:alert:service:forward
 The relevant categories of "alert" URNs are only:
     country
     service
 The alphabet of symbols is:
     Country
     Country:[other]
     Country:Xa
     Country:Xb
     Service
     Service:[other]
     Service:Call-waiting
     Service:Forward

Worley Informational [Page 35] RFC 8433 Resolving Alert-Info URNs August 2018

 The 17 states are as follows:
     State: 0 Country/Service
     Signal: default
     Transitions:
         Country:[other] -> 1 Country:([other])/Service
         Country:Xa -> 5 Country:Xa/Service
         Country:Xb -> 9 Country:Xb/Service
         Service:[other] -> 13 Country/Service:([other])
         Service:Call-waiting -> 14 Country/Service:Call-waiting
         Service:Forward -> 16 Country/Service:(Forward)
  State: 1 Country:([other])/Service
  Signal: default
  Transitions:
      Country:[other] -> 1 Country:([other])/Service
      Country:Xa -> 1 Country:([other])/Service
      Country:Xb -> 1 Country:([other])/Service
      Service:[other] -> 2 Country:([other])/Service:([other])
      Service:Call-waiting -> 3 Country:([other])/Service:Call-waiting
      Service:Forward -> 4 Country:([other])/Service:(Forward)
     State: 2 Country:([other])/Service:([other])
     Signal: default
     Transitions:
         any -> 2 Country:([other])/Service:([other])
     State: 3 Country:([other])/Service:Call-waiting
     Signal: call-waiting
     Transitions:
         any -> 3 Country:([other])/Service:Call-waiting
     State: 4 Country:([other])/Service:(Forward)
     Signal: default
     Transitions:
         any -> 4 Country:([other])/Service:(Forward)
     State: 5 Country:Xa/Service
     Signal: XA default
     Transitions:
         Country:[other] -> 5 Country:Xa/Service
         Country:Xa -> 5 Country:Xa/Service
         Country:Xb -> 5 Country:Xa/Service
         Service:[other] -> 6 Country:Xa/Service:([other])
         Service:Call-waiting -> 7 Country:Xa/Service:Call-waiting
         Service:Forward -> 8 Country:Xa/Service:Forward

Worley Informational [Page 36] RFC 8433 Resolving Alert-Info URNs August 2018

     State: 6 Country:Xa/Service:([other])
     Signal: XA default
     Transitions:
         any -> 6 Country:Xa/Service:([other])
     State: 7 Country:Xa/Service:Call-waiting
     Signal: XA call-waiting
     Transitions:
         any -> 7 Country:Xa/Service:Call-waiting
     State: 8 Country:Xa/Service:Forward
     Signal: XA forward
     Transitions:
         any -> 8 Country:Xa/Service:Forward
     State: 9 Country:Xb/Service
     Signal: XB default
     Transitions:
         Country:[other] -> 9 Country:Xb/Service
         Country:Xa -> 9 Country:Xb/Service
         Country:Xb -> 9 Country:Xb/Service
         Service:[other] -> 10 Country:Xb/Service:([other])
         Service:Call-waiting -> 11 Country:Xb/Service:(Call-waiting)
         Service:Forward -> 12 Country:Xb/Service:Forward
     State: 10 Country:Xb/Service:([other])
     Signal: XB default
     Transitions:
         any -> 10 Country:Xb/Service:([other])
     State: 11 Country:Xb/Service:(Call-waiting)
     Signal: XB default
     Transitions:
         any -> 11 Country:Xb/Service:(Call-waiting)
     State: 12 Country:Xb/Service:Forward
     Signal: XB forward
     Transitions:
         any -> 12 Country:Xb/Service:Forward

Worley Informational [Page 37] RFC 8433 Resolving Alert-Info URNs August 2018

     State: 13 Country/Service:([other])
     Signal: default
     Transitions:
         Country:[other] -> 2 Country:([other])/Service:([other])
         Country:Xa -> 6 Country:Xa/Service:([other])
         Country:Xb -> 10 Country:Xb/Service:([other])
         Service:[other] -> 13 Country/Service:([other])
         Service:Call-waiting -> 13 Country/Service:([other])
         Service:Forward -> 13 Country/Service:([other])
     State: 14 Country/Service:Call-waiting
     Signal: call-waiting
     Transitions:
         Country:[other] -> 3 Country:([other])/Service:Call-waiting
         Country:Xa -> 7 Country:Xa/Service:Call-waiting
         Country:Xb -> 15 Country:(Xb)/Service:Call-waiting
         Service:[other] -> 14 Country/Service:Call-waiting
         Service:Call-waiting -> 14 Country/Service:Call-waiting
         Service:Forward -> 14 Country/Service:Call-waiting
     State: 15 Country:(Xb)/Service:Call-waiting
     Signal: call-waiting
     Transitions:
         any -> 15 Country:(Xb)/Service:Call-waiting
     State: 16 Country/Service:(Forward)
     Signal: default
     Transitions:
         Country:[other] -> 4 Country:([other])/Service:(Forward)
         Country:Xa -> 8 Country:Xa/Service:Forward
         Country:Xb -> 12 Country:Xb/Service:Forward
         Service:[other] -> 16 Country/Service:(Forward)
         Service:Call-waiting -> 16 Country/Service:(Forward)
         Service:Forward -> 16 Country/Service:(Forward)
 Call-waiting can be signaled in conjunction with country XA but not
 in conjunction with country XB, as the UA does not have a signal to
 present call-waiting alerts for country XB.  Thus, the ordering of
 urn:alert:service:call-waiting with urn:alert:country:xa does not
 matter, but if urn:alert:country:xb appears before
 urn:alert:service:call-waiting, call-waiting cannot be signaled.

Worley Informational [Page 38] RFC 8433 Resolving Alert-Info URNs August 2018

 On the other hand, if urn:alert:service:call-waiting appears before
 urn:alert:country:xb, then call-waiting is signaled, but using the
 non-country signal.
    Alert-Info: urn:alert:country:xa,
            urn:alert:service:call-waiting
    State: 0 Country/Service
        Process: Country:Xa (urn:alert:country:xa)
    State: 5 Country:Xa/Service
        Process: Service:Call-waiting (urn:alert:service:call-waiting)
    State: 7 Country:Xa/Service:Call-waiting
    Signal: XA call-waiting
    Alert-Info: urn:alert:service:call-waiting,
            urn:alert:country:xa
    State: 0 Country/Service
        Process: Service:Call-waiting (urn:alert:service:call-waiting)
    State: 14 Country/Service:Call-waiting
        Process: Country:Xa (urn:alert:country:xa)
    State: 7 Country:Xa/Service:Call-waiting
    Signal: XA call-waiting
    Alert-Info: urn:alert:country:xb,
            urn:alert:service:call-waiting
    State: 0 Country/Service
        Process: Country:Xb (urn:alert:country:xb)
    State: 9 Country:Xb/Service
        Process: Service:Call-waiting (urn:alert:service:call-waiting)
    State: 11 Country:Xb/Service:(Call-waiting)
    Signal: XB default
    Alert-Info: urn:alert:service:call-waiting,
            urn:alert:country:xb
    State: 0 Country/Service
        Process: Service:Call-waiting (urn:alert:service:call-waiting)
    State: 14 Country/Service:Call-waiting
        Process: Country:Xb (urn:alert:country:xb)
    State: 15 Country:(Xb)/Service:Call-waiting
    Signal: call-waiting

Worley Informational [Page 39] RFC 8433 Resolving Alert-Info URNs August 2018

6. Prioritizing Signals

 The specifications provided in [RFC7462] are oriented toward giving
 the sender of Alert-Info control over which of the "alert" URNs are
 most important.  But in some situations, the UA may prefer to
 prioritize expressing one URN category over another regardless of the
 order in which their URNs appear in Alert-Info.  This section
 describes how that can be accommodated within the framework of
 [RFC7462] and presents an example FSM resulting from that approach.
 This example uses the signals of Section 5.2, viz., "external
 source", "internal source", "low priority", and "high priority", but
 this time, we want to signal "high priority" in preference to any
 other signal that might be applicable.
 We accommodate this within the framework of [RFC7462] by assigning
 the signal "high priority" for each of these combinations of URNs:
     urn:alert:priority:high
     urn:alert:priority:high, urn:alert:source:internal
     urn:alert:priority:high, urn:alert:source:external
 The result is that the signal "high priority" is the "best" signal
 for any combination of urn:alert:priority:high with "source" URNs.
 Constructing the symbols produces the same results as before.  The
 signals can express the following URNs:
     urn:alert:source:external
     urn:alert:source:internal
     urn:alert:priority:low
     urn:alert:priority:high
 The relevant categories of "alert" URNs are:
     source
     priority
 The alphabet of symbols is:
     Source
     Source:External
     Source:Internal
     Source:Other
     Priority
     Priority:Low
     Priority:High
     Priority:Other

Worley Informational [Page 40] RFC 8433 Resolving Alert-Info URNs August 2018

 When the FSM is constructed, it is the same as the FSM of
 Section 5.2, except that certain states are effectively renamed and
 merged, because any "source" is defined to be expressed if high
 priority is expressed:
     Priority:(High)/Source:External and
     Priority:High/Source:(External) become:
         State: Priority:High/Source:External
         Signal: high priority
     Priority:(High)/Source:Internal and
     Priority:High/Source:(Internal) become:
         State: Priority:High/Source:Internal
         Signal: high priority
 This reduces the FSM to 18 states.  In addition, these two new
 states, along with a number of other states, can be merged by FSM
 optimization, since all of them have the signal "high priority" and
 from them, there are no transitions to states outside this set.  The
 optimized FSM has 10 states.

7. Dynamic Sets of Signals

 This section discusses how to construct FSMs for a UA that allows
 variable sets of signals -- for example, if the user can configure
 the use of ring tones.  Several approaches can be used:
 o  Whenever the set of ring tones is changed, re-execute the
    processes of Section 4.
 o  Whenever the set of ring tones is changed, rebuild the list of
    expressed URNs (Section 4.1) and reconstruct the alphabet of
    symbols (Section 4.2).  Then, use an algorithm for dynamically
    constructing the states of the FSM as needed during Alert-Info
    processing.
 o  If the sets of possible URNs expressed by the ring tones are
    sufficiently limited, the steps of Section 4 can be carried out
    "generically", and the generic FSM can be specialized for the
    current ring tone configuration.
 The remainder of this section gives an example of the third approach.

Worley Informational [Page 41] RFC 8433 Resolving Alert-Info URNs August 2018

 For the example, we will use a set of ring tones that express the
 identity of the caller.  To signal this information, a private
 extension "alert" URN category, "caller@example", is used:
     urn:alert:caller@example:alice@example.com
     urn:alert:caller@example:bob@example.com
     etc.
 which we can express by the generic pattern
     urn:alert:caller@example:IDENTITY
 where "IDENTITY" is replaced in succession by the set of caller
 identities that have their own ring tones to generate the set of
 expressed URNs.
 The alphabet is then:
     Caller@example
     Caller@example:IDENTITY
     Caller@example:Other
 where "IDENTITY" is replaced in succession by the set of caller
 identities.  The "Caller@example:Other" symbol includes all URNs of
 the category "caller@example" that are not included in any of the
 "Caller@example:IDENTITY" symbols, i.e, where the second
 alert-ind-part is not one of the known caller identities.
 The states and transitions of the FSM are:
     State: Caller@example (initial state)
     Signal: default
     Transitions:
         Caller@example:IDENTITY -> Caller@example:IDENTITY
         Caller@example:Other -> Caller@example:(Other)
     State: Caller@example:IDENTITY
     Signal: signal for caller IDENTITY
     Transitions:
         any -> Caller@example:IDENTITY
     State: Caller@example:(Other)
     Signal: default
     Transitions:
         any -> Caller@example:(Other)

Worley Informational [Page 42] RFC 8433 Resolving Alert-Info URNs August 2018

 where again, the second state is replicated once for each caller
 identity that has a ring tone, with "IDENTITY" replaced with the
 caller identity.

8. Security Considerations

 The security considerations discussed in Section 16 of [RFC7462]
 regarding the use and processing of "alert" URNs MUST be followed
 when the algorithm described in this document is used.
 Like any implementation of [RFC7462], implementations of the
 algorithm defined in this document MUST take into account that the
 value of a received Alert-Info header field may contain URIs of any
 scheme, may contain syntactically invalid values, and may be
 syntactically invalid overall.  The handling of syntactically invalid
 values is specified by [RFC3261].  The handling of URIs other than
 "alert" URIs is outside the scope of this document (and outside the
 scope of [RFC7462]) and MAY be subject to local policy.
 Like the algorithm described in Section 12 of [RFC7462], the output
 of the algorithm defined in this document is limited to a choice
 among the signals that it has been configured for, limiting the
 security issues regarding the processing of its output.  This
 algorithm will use at most linear time and constant space to process
 a sequence of "alert" URNs.  This is significantly more efficient
 than the algorithm of [RFC7462] and minimizes the security
 vulnerabilities of this processing step that are due to resource
 consumption.
 However, the process defined in this document for constructing an FSM
 can use more than linear time and constant space -- probably
 exponential time and space in the worst case.  This SHOULD be taken
 into consideration whenever an FSM is constructed using this
 algorithm and MUST be taken into consideration when it is done
 dynamically by a UA.  Whenever an FSM is constructed by a process
 that is not under the direct supervision of a human user, procedures
 MUST be used to ensure that (1) the processing and memory consumption
 are limited to acceptable amounts and (2) if the FSM construction is
 aborted due to excessive consumption, the designated consumers of the
 FSM MUST have appropriate fallback procedures.

9. IANA Considerations

 This document has no IANA actions.

Worley Informational [Page 43] RFC 8433 Resolving Alert-Info URNs August 2018

10. References

10.1. Normative References

 [ISO-3166-1]
            International Organization for Standardization, "Codes for
            the representation of names of countries and their
            subdivisions -- Part 1: Country codes", ISO
            Standard 3166-1:2013, November 2013,
            <https://www.iso.org/iso-3166-country-codes.html>.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <https://www.rfc-editor.org/info/rfc2119>.
 [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
            A., Peterson, J., Sparks, R., Handley, M., and E.
            Schooler, "SIP: Session Initiation Protocol", RFC 3261,
            DOI 10.17487/RFC3261, June 2002,
            <https://www.rfc-editor.org/info/rfc3261>.
 [RFC7462]  Liess, L., Ed., Jesske, R., Johnston, A., Worley, D., and
            P. Kyzivat, "URNs for the Alert-Info Header Field of the
            Session Initiation Protocol (SIP)", RFC 7462,
            DOI 10.17487/RFC7462, March 2015,
            <https://www.rfc-editor.org/info/rfc7462>.
 [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
            RFC 2119 Key Words", BCP 14, RFC 8174,
            DOI 10.17487/RFC8174, May 2017,
            <https://www.rfc-editor.org/info/rfc8174>.

10.2. Informative References

 [code]     Worley, D., "draft-worley-alert-info-fsm.aux",
            February 2017, <http://svn.resiprocate.org/rep/
            ietf-drafts/worley/draft-worley-alert-info-fsm.aux>.

Worley Informational [Page 44] RFC 8433 Resolving Alert-Info URNs August 2018

Acknowledgments

 Thanks to Paul Kyzivat, whose relentless identification of the
 weaknesses of earlier versions made the final document much, much
 better than it would have been, by changing it from the exposition of
 a concept into a practical tool.  Thanks to Rifaat Shekh-Yusef, Eric
 Burger, and Gonzalo Camarillo for their thorough reviews.  Thanks to
 the earlier Independent Submissions Editor, Nevil Brownlee, for his
 work obtaining reviewers, and the later Independent Submissions
 Editor, Adrian Farrel, for prompting me to write the Security
 Considerations section (which I had expected to be trivial but
 was not).

Author's Address

 Dale R. Worley
 Ariadne Internet Services
 738 Main St.
 Waltham, MA  02451
 United States of America
 Email: worley@ariadne.com

Worley Informational [Page 45]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8433.txt · Last modified: 2018/08/27 19:11 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki