idnits 2.17.1 draft-worley-alert-info-fsm-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 340 has weird spacing: '... source urn:a...' == Line 383 has weird spacing: '...riority urn:...' == Line 911 has weird spacing: '... source urn...' == Line 913 has weird spacing: '... source urn...' == Line 916 has weird spacing: '... source urn:...' == (1 more instance...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 20, 2018) is 2191 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SALUD D. Worley 3 Internet-Draft Ariadne 4 Intended status: Informational April 20, 2018 5 Expires: October 22, 2018 7 A Simpler Method for Resolving Alert-Info URNs 8 draft-worley-alert-info-fsm-10 10 Abstract 12 The "alert" namespace of uniform resource names (URNs) can be used in 13 the Alert-Info header field of Session Initiation Protocol (SIP) 14 requests and responses to inform a VoIP telephone (user agent) of the 15 characteristics of the call that the user agent has originated or 16 terminated. The user agent must resolve the URNs into a signal, that 17 is, it must select the best available signal to present to its user 18 to indicate the characteristics of the call. 20 RFC 7462 describes a non-normative algorithm for signal selection. 21 This document describes a more efficient alternative algorithm: A 22 user agent's designer can, based on the user agent's signals and 23 their meanings, construct a finite state machine (FSM) to process the 24 URNs to select a signal in a way that obeys the restrictions given in 25 the definition of the "alert" URN namespace. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 22, 2018. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Governing Resolution Algorithms . . . . . . 4 60 1.2. Summary of the New Resolution Algorithm . . . . . . . . . 5 61 2. Selecting the Signals and Their Corresponding "alert" URNs . 7 62 3. General Considerations for Processing Alert-Info . . . . . . 9 63 4. Constructing the Finite State Machine for a Very Simple 64 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.1. Listing the Expressed URNs . . . . . . . . . . . . . . . 11 66 4.2. Constructing the Alphabet . . . . . . . . . . . . . . . . 11 67 4.3. Constructing the States and Transitions . . . . . . . . . 13 68 4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 4.5. Examples of Processing Alert-Info URNs . . . . . . . . . 18 70 5. Further Examples . . . . . . . . . . . . . . . . . . . . . . 19 71 5.1. Example with "source" and "priority" URNs . . . . . . . . 19 72 5.2. Example 1 of RFC 7462 . . . . . . . . . . . . . . . . . . 24 73 5.3. Examples 2, 3, and 4 of RFC 7462 . . . . . . . . . . . . 29 74 5.4. An Example that Subsets Internal Sources . . . . . . . . 32 75 5.5. An Example of "alert:service" URNs . . . . . . . . . . . 32 76 5.6. An Example Using Country Codes . . . . . . . . . . . . . 33 77 6. Prioritizing Signals . . . . . . . . . . . . . . . . . . . . 38 78 7. Dynamic Sets of Signals . . . . . . . . . . . . . . . . . . . 40 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 81 10. Revision History . . . . . . . . . . . . . . . . . . . . . . 42 82 10.1. Changes from draft-worley-alert-info-fsm-09 to draft- 83 worley-alert-info-fsm-10 . . . . . . . . . . . . . . . . 43 84 10.2. Changes from draft-worley-alert-info-fsm-08 to draft- 85 worley-alert-info-fsm-09 . . . . . . . . . . . . . . . . 43 86 10.3. Changes from draft-worley-alert-info-fsm-07 to draft- 87 worley-alert-info-fsm-08 . . . . . . . . . . . . . . . . 43 88 10.4. Changes from draft-worley-alert-info-fsm-06 to draft- 89 worley-alert-info-fsm-07 . . . . . . . . . . . . . . . . 43 90 10.5. Changes from draft-worley-alert-info-fsm-05 to draft- 91 worley-alert-info-fsm-06 . . . . . . . . . . . . . . . . 43 92 10.6. Changes from draft-worley-alert-info-fsm-04 to draft- 93 worley-alert-info-fsm-05 . . . . . . . . . . . . . . . . 43 94 10.7. Changes from draft-worley-alert-info-fsm-03 to draft- 95 worley-alert-info-fsm-04 . . . . . . . . . . . . . . . . 44 96 10.8. Changes from draft-worley-alert-info-fsm-02 to draft- 97 worley-alert-info-fsm-03 . . . . . . . . . . . . . . . . 44 98 10.9. Changes from draft-worley-alert-info-fsm-01 to draft- 99 worley-alert-info-fsm-02 . . . . . . . . . . . . . . . . 44 100 10.10. Changes from draft-worley-alert-info-fsm-00 to draft- 101 worley-alert-info-fsm-01 . . . . . . . . . . . . . . . . 44 102 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 103 11.1. Normative References . . . . . . . . . . . . . . . . . . 44 104 11.2. Informative References . . . . . . . . . . . . . . . . . 44 105 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 45 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 45 108 1. Introduction 110 When a SIP user agent server receives an incoming INVITE request, it 111 chooses an alerting signal (the ring tone) to present to its user 112 (the called user) by processing the Alert-Info header field(s) in the 113 incoming INVITE request [RFC3261]. Similarly, a SIP user agent 114 client determines an alerting signal (the ringback tone) to present 115 to its user (the calling user) by processing the Alert-Info header 116 field(s) in the incoming provisional response(s) to its outgoing 117 INVITE request. 119 [RFC3261] envisioned that the Alert-Info header field value would be 120 a URL that the user agent could use to retrieve the encoded media of 121 the signal. This usage has security problems and is inconvenient to 122 implement in practice. 124 [RFC7462] introduced an alternative practice: The Alert-Info values 125 can be URNs in the "alert" URN namespace which specify features of 126 the call or of the signal that should be signaled to the user. 127 [RFC7462] defined a large set of "alert" URNs and procedures for 128 extending the set. 130 A user agent is unlikely to provide more than a small set of alerting 131 signals and there are an infinite number of possible combinations of 132 "alert" URNs. Thus, a user agent is often required to select an 133 alerting signal which renders only a subset of the information in the 134 Alert-Info header field(s) -- which is the resolution process for 135 "alert" URNs. The requirements for resolving "alert" URNs are given 136 in section 11.1 of [RFC7462]. 138 Section 12 of [RFC7462] gives a (non-normative) resolution algorithm 139 for selecting a signal which satisfies the requirements of section 140 11.1. That algorithm can be used regardless of the set of alerting 141 signals that the user agent provides and their specified meanings. 142 The existence of this algorithm demonstrates that the resolution 143 requirements can always be satisfied. However, the algorithm is 144 complex and slow. 146 The purpose of this document is to describe an improved 147 implementation, a more efficient resolution algorithm for selecting 148 signals that conforms to the requirements of section 11.1. (Of 149 course, like any such algorithm, it is non-normative, and the 150 implementation is free to use any algorithm that conforms to the 151 requirements of section 11.1 of [RFC7462].) 153 In this algorithm, once the user agent designer has chosen the set of 154 signals that the user agent produces and the "alert" URNs that they 155 express, a finite state machine is constructed that selects alerting 156 signals based on the URNs in the Alert-Info header field(s) in a SIP 157 message. The incoming "alert" URNs are preprocessed in a 158 straightforward manner into a sequence of "symbols" drawn from a 159 fixed finite set, which are then used as input to the finite state 160 machine. After processing the input, the state of the finite state 161 machine selects the correct alerting signal to present to the user. 163 Both the preprocessor and the finite state machine are determined 164 only by the selected set of signals and the set of "alert" URNs 165 expressed by the signals, so the processing machinery can be fixed at 166 the time of designing the user agent. 168 1.1. Requirements Governing Resolution Algorithms 170 The requirements for the resolution of "alert" URNs are given in 171 section 11.1 of [RFC7462] and can be described as follows: 173 The "alert" URNs are processed from left to right. Each "alert" 174 URN has precedence over all URNs that follow it, and its 175 interpretation is subordinate to all URNs that precede it. 177 As each URN is processed, one of the UA's signals is chosen which 178 expresses that URN as far as can be done without reducing the 179 degree to which any of the preceding URNs were expressed by the 180 signal chosen for the preceding URN. Thus, as processing 181 proceeds, the chosen signals become increasingly specific and 182 contain more information, but all of the information about a 183 particular URN that is expressed by the signal chosen for that URN 184 is also expressed by the signals chosen for all following URNs. 186 If the entirety of the current URN cannot be expressed by any 187 allowed signal, then in turn, each of the trailing alert-ind-parts 188 (the sections separated by colons) is removed until the reduced 189 URN can be expressed by some signal which also expresses at least 190 the same reduced versions of the preceding URNs that were 191 expressed by the signal chosen for the preceding URN. This can be 192 described as "a signal that expresses as much of the current URN 193 as possible while still expressing as much of the previous URNs as 194 the preceding signal did". 196 So, for instance, consider processing 198 Alert-Info: urn:alert:category-a:part-a1:part-a2, 199 urn:alert:category-b:part-b1:part-b2 201 If the UA has no signal for urn:alert:category-a:part-a1:part-a2, it 202 removes part-a2 from the URN and checks whether it has a signal for 203 the less-specific URN urn:alert:category-a:part-a1. If it has no 204 signal for that URN, it gives up on the URN entirely (since 205 urn:alert:category-a doesn't exist, and can be considered to express 206 nothing about the call), and the chosen signal is the default signal 207 of the UA, the signal that is used when there is no Alert-Info. 209 But let us suppose the UA has a signal for urn:alert:category-a:part- 210 a1, and chooses that signal when processing the first URN. All 211 processing after this point will be restricted to signals that 212 express urn:alert:category-a:part-a1, or a more specific URN of the 213 category category-a. 215 The UA then goes on to examine the next URN, urn:alert:category- 216 b:part-b1:part-b2. If there is a signal that expresses both 217 urn:alert:category-a:part-a1 and urn:alert:category-b:part-b1:part- 218 b2, then the UA chooses that signal. If there is no such signal, the 219 second URN is reduced to urn:alert:category-b:part-b1, and the UA 220 checks for a signal that expresses that URN along with 221 urn:alert:category-a:part-a1. If there is no such signal that 222 matches that relaxed requirement, the second URN is reduced to 223 urn:alert:category-b, which is discarded, and the chosen signal for 224 the first URN is chosen for the second URN. In any case, all 225 processing after this point will be restricted to signals that 226 express urn:alert:category-a:part-a1 or a more specific URN of the 227 category category-a, and also express the chosen part of 228 urn:alert:category-b:part-b1:part-b2. 230 This process is continued until the last "alert" URN is processed; 231 the signal chosen for the last URN is the signal that the UA uses. 233 1.2. Summary of the New Resolution Algorithm 235 The purpose of this document is to describe a resolution algorithm 236 that conforms to section 11.1 of [RFC7462] but is simpler than the 237 algorithm described in section 12 of [RFC7462]: Once the user agent 238 designer has chosen a set of signals and the URNs that they express, 239 a finite state machine is constructed that selects alerting signals 240 based on the URNs in the Alert-Info header field(s) in a SIP message. 242 o The designer selects the set of signals that the user agent 243 produces, matching each signal to the "alert" URN or the 244 combination of "alert" URNs which are the meaning carried by the 245 signal. 247 o Based on the user agent's signals and their meanings, the designer 248 constructs an "alphabet" containing a finite number of symbols; 249 each possible "alert" URN is mapped into one particular symbol. 251 o The designer constructs a finite state machine (FSM) whose input 252 is the alphabet of symbols and whose states describe the 253 information extracted from the Alert-Info URNs. 255 o Each state of the FSM has an associated signal. Processing the 256 Alert-Info URNs will leave the FSM in some particular state; the 257 UA renders the signal that is attached to that final state. 259 To select a ring tone or ringback tone based on a SIP message, the 260 user agent processes the "alert" URNs in the Alert-Info header field 261 from left to right. Initially the FSM is in a designated initial 262 state. The user agent maps each successive URN into the 263 corresponding symbol, and then executes the state transition of the 264 FSM specified by the symbol. The state of the FSM after processing 265 the URNs determines which signal the user agent will render to the 266 user. 268 Note that the user agent generally has two FSMs, because a user agent 269 usually wants to signal different information in ring tones than it 270 signals in ringback tones. One FSM is used to select the ring tone 271 to render for an incoming INVITE request. The other FSM is used to 272 select the ringback tone to render based on an incoming provisional 273 response to an outgoing INVITE request. Both FSMs are constructed in 274 the same way, but the constructions are based on different lists of 275 signals and corresponding URNs. 277 All of the steps of the method after the designer has selected the 278 signals and their URNs are algorithmic, and the algorithm of those 279 steps assures that the operation of the FSM will satisfy the 280 constraints of section 11.1 of [RFC7462]. A Python implementation of 281 the algorithmic steps is provided in [code]. 283 In simple situations, a suitable FSM or equivalent ad-hoc code can be 284 constructed by hand using ad-hoc analysis. Generally, this is only 285 practical in situations where a small number of alert categories and 286 alert indications are signaled and the categories interact in a 287 simple, uniform way. E.g., the examples in Section 5.1 and 288 Section 5.2 could be constructed by ad-hoc analysis. But automatic 289 processing is valuable if the situation is too complicated to 290 construct a correct FSM by ad-hoc analysis, or if the set of signals 291 will change too frequently for human production to be economical. 293 2. Selecting the Signals and Their Corresponding "alert" URNs 295 The designer must select signals that the UA will generate and define 296 the meanings that the signals will have to the user. Based on this, 297 the designer determines for each signal the "alert" URN or 298 combination of "alert" URNs that indicate that meaning in SIP 299 messages, and consequently should elicit that signal from the UA. 301 For example, suppose the UA has a particular ring tone for calls from 302 an external source. A call from an external source is marked with 303 the URN urn:alert:source:external (specified in section 9 of 304 [RFC7462]). Thus, the table of signals includes: 306 Signal URN(s) 307 ---------------------------- ------------------------------- 308 external source urn:alert:source:external 310 Similarly, if the UA has a particular ring tone for calls from an 311 internal source, the table includes: 313 Signal URN(s) 314 ---------------------------- ------------------------------- 315 internal source urn:alert:source:internal 317 If the UA has ring tones for calls that are marked as having higher 318 or lower priority, then the table includes: 320 Signal URN(s) 321 ---------------------------- ------------------------------- 322 high priority urn:alert:priority:high 323 low priority urn:alert:priority:low 325 Note that the UA must be able to signal for a message that has no 326 "alert" URNs in the Alert-Info header field, which means that there 327 must always be a default signal which has zero corresponding URNs: 329 Signal URN(s) 330 ---------------------------- ------------------------------- 331 default (none) 333 A signal can be defined to indicate a combination of conditions. For 334 instance, a signal that is used only for high-priority, internal- 335 source calls expresses two URNs, and will only be used when both URNs 336 are present in Alert-Info: 338 Signal URN(s) 339 ------------------------------ ------------------------------- 340 high priority, internal source urn:alert:priority:high, 341 urn:alert:source:internal 343 A signal can be defined to cover a number of related conditions by 344 specifying a URN that is the common prefix of the URNs for the 345 various conditions. For instance, the URNs for "recall due to 346 callback", "recall due to call hold", and "recall due to transfer" 347 all start with urn:alert:service:recall, and so one signal can be 348 provided for all of them by: 350 Signal URN(s) 351 ---------------------------- ------------------------------- 352 recall urn:alert:service:recall 354 But if a specific signal is also provided for "recall due to 355 callback" by this entry: 357 Signal URN(s) 358 ---------------------------- ------------------------------- 359 recall generally urn:alert:service:recall 360 recall due to callback urn:alert:service:recall:callback 362 then if the message contains urn:alert:service:recall:callback, the 363 "recall due to callback" signal will be chosen instead of "recall 364 generally" because the UA chooses the signal that most completely 365 expresses the information in the Alert-Info header field. 367 The designer may wish to define extension URNs that provide more 368 specific information about a call than the standard "alert" URNs do. 369 One method is to add additional components to standard URNs. For 370 instance, an extra-high priority could be indicated by the URN 371 urn:alert:priority:high:extra-high@example. The final "extra- 372 high@example" is an "alert-ind-part" that is a private extension. 373 (See sections 7 and 10.2 of [RFC7462] for a discussion of private 374 extensions.) In any case, adding an alert-ind-part to a URN makes 375 its meaning more specific, in that any call to which the longer URN 376 can be applied can also have the shorter URN applied. In this case, 377 "extra-high-priority calls" are considered a subset of "high-priority 378 calls". 380 Signal URN(s) 381 --------------------- ------------------------------- 382 high priority urn:alert:priority:high 383 extra high priority urn:alert:priority:high:extra@example.com 385 Of course, for this extension to be useful, the senders of SIP 386 messages (e.g., other UAs) must generate the extension URN in 387 suitable circumstances. 389 In some circumstances, the designer may want to create an entirely 390 new category of "alert" URNs to indicate a type of information that 391 is not indicated by any standard category of URNs. In that case, the 392 designer uses a private extension as the alert-category (the third 393 component of the URN), combined with whatever alert-ind-part (fourth 394 component) values are desired. For example, a simplified version of 395 the U.S. military security designations could be: 397 Signal URN(s) 398 ----------------------- ------------------------------- 399 unclassified urn:alert:security@example:unclassified 400 confidential urn:alert:security@example:confidential 401 secret urn:alert:security@example:secret 402 top-secret urn:alert:security@example:top-secret 404 The designer should ensure that the new alert-category is orthogonal 405 to all defined standard alert-categories, in that any combination of 406 one of the new URNs with one of the standard URNs is meaningful in 407 that there could be a message carrying both URNs. 409 In addition, the set of alert-ind-parts for the new alert-category 410 should be comprehensive and disjoint, in that every message can be 411 described by exactly one of them. 413 3. General Considerations for Processing Alert-Info 415 In this section, we will discuss various considerations which arise 416 when processing Alert-Info. These have to be taken care of properly 417 in order to conform to the standards, as well as to endure a good 418 user experience. But since they are largely independent of the 419 generated finite state machine and its processing, they are gathered 420 here in a separate section. 422 The UA may have a number of different finite state machines (FSMs) 423 for processing URNs. Generally, there will be different FSMs for 424 processing Alert-Info in incoming INVITE requests and for incoming 425 provisional responses to outgoing INVITE requests. But any situation 426 that changes the set of signals that the UA is willing to generate 427 specifies a different set of signals and corresponding URNs, and thus 428 generates a different FSM. For example, if a call is active on the 429 UA, all audible signals may become unavailable, or audible signals 430 may be available only if urn:alert:priority:high is specified. 432 Similarly, if the set of signals is customized by user action or 433 local policy, the generated FSM must be updated. This can be done by 434 regenerating it according to the method described here, or by 435 generating a "generic" FSM and instantiating it based on the 436 available signals. (See Section 7 for a discussion of this.) 438 Note that the values in an Alert-Info header field are allowed to be 439 URIs of any scheme, and within the "urn" scheme, are allowed to have 440 any namespace [RFC3261]. The processing of URIs that are not "alert" 441 URNs is not considered by this document, nor is that processing 442 specified by [RFC7462]. But the algorithm designer must consider 443 what to do with such URIs if they are encountered. The simplest 444 choice is to ignore them. Alternatively, the algorithm may examine 445 the URI to determine if it names an alerting signal or describes how 446 to retrieve an alerting signal, and if so, choose to render that 447 signal, rather than processing the "alert" URNs to select a signal. 448 In any case, the remainder of this document assumes that the signal 449 is to be chosen based on the "alert" URNs in Alert-Info, and that all 450 Alert-Info URIs that are not "alert" URNs have been removed. 452 The UA may also receive "alert" URNs that are semantically invalid in 453 various ways. E.g., the URN may have only three components, despite 454 that all valid "alert" URNs have at least one alert-ind-part, and 455 thus four components. The only useful strategy is to ignore such 456 URNs (and possibly log them for analysis). 458 The method described here is robust in its handling of categories and 459 alert-ind-parts which are unknown to the UA, and as a consequence, it 460 is also robust if they are not valid standardized URNs. Thus, these 461 error conditions need not be handled specially. 463 4. Constructing the Finite State Machine for a Very Simple Example 465 Constructing the FSM involves: 467 1. Listing the URNs which are expressed by the various signals of 468 the user agent. 470 2. From the expressed URNs, constructing the finite alphabet of 471 symbols into which input URNs are mapped and which drive the 472 state transitions of the FSM. 474 3. Constructing the states of the FSM and the transitions between 475 them. 477 4. Selecting a signal to be associated with each FSM state. 479 We will explain the process using a very simple example in which 480 there are two signals, one expressing "internal source" and one 481 expressing "external source", along with a default signal (for when 482 there is no source information to signal). The "internal source" 483 signal expresses urn:alert:source:internal, and the "external source" 484 signal expresses urn:alert:source:external. 486 4.1. Listing the Expressed URNs 488 The first step is to establish for each of the user agent's signals 489 what call characteristics it represents, which is to say, the set of 490 "alert" URNs which are its information content. 492 Signal URN(s) 493 ---------------------------- ------------------------------- 494 default (none) 495 internal source urn:alert:source:internal 496 external source urn:alert:source:external 498 From the totality of these expressed URNs, the designer can then 499 determine which sets of URNs must be distinguished from each other. 500 In our simple example, the expressed URNs are: 502 urn:alert:source:external 503 urn:alert:source:internal 505 4.2. Constructing the Alphabet 507 In order to reduce the infinite set of possible "alert" URNs to a 508 finite alphabet of input symbols which cause the FSM's transitions, 509 the designer must partition the "alert" URNs into a finite set of 510 categories. 512 Once we've listed all the expressed URNs, we can list all of the 513 alert-categories that are relevant to the user agent's signaling; 514 "alert" URNs in any other alert-category cannot affect the signaling 515 and can be ignored. (The easiest method to ignore the non-relevant 516 URNs is to skip over them during Alert-Info processing. A more 517 formal method is to map all of them into one "Other" symbol, and then 518 for each state of the FSM, have the Other symbol transition to that 519 same state.) 521 Within each relevant alert-category, we now define a distinct symbol 522 for every expressed URN and for all of their "ancestor" URNs (those 523 that can be created by removing one or more trailing alert-ind- 524 parts). In order to name the symbols in a way that distinguishes 525 them from the corresponding URNs, we remove the initial "urn:alert:" 526 and capitalize each alert-ind-part. Thus in our example, we get 527 these symbols: 529 Source 530 Source:External 531 Source:Internal 533 Note that there is a "Source" symbol even though there is no 534 corresponding URN. (urn:alert:source is not a valid URN -- see 535 [RFC7462] section 7 -- although the processing algorithm must be 536 prepared to screen out such a purported URN if it appears in the 537 Alert-Info header field.) However, its existence as a symbol will be 538 useful later when we construct the FSM. 540 For each of these symbols, we add a symbol that classifies URNs that 541 extend the symbol's corresponding URN with alert-ind-parts that 542 cannot be expressed by signals: 544 Source:Other 545 Source:External:Other 546 Source:Internal:Other 548 The latter two classify URNs like 549 urn:alert:source:external:foo@example, which extend URNs that we 550 already have symbols for. The first is for classifying URNs, such as 551 urn:alert:source:bar@example, which have first alert-ind-parts that 552 contradict all the "source" URNs that the user agent can signal. 554 These steps give us this set of symbols: 556 Source 557 Source:External 558 Source:External:Other 559 Source:Internal 560 Source:Internal:Other 561 Source:Other 563 We can then simplify the set of symbols by removing the ones like 564 Source:External:Other and Source:Internal:Other that consist of 565 adding "Other" to a symbol which corresponds to an expressed URN 566 which is not ancestral to any other expressed URNs. This works 567 because adding further alert-ind-parts to a URN which is a leaf in 568 regard to the set of signals has no additional effect. In this 569 example, urn:alert:source:external:foo@example has the same effect as 570 urn:alert:source:external, both for causing a signal to be chosen as 571 well as for suppressing the effect of later URNs. 573 This leaves the following symbols for the "source" category: 575 Source 576 Source:External 577 Source:Internal 578 Source:Other 580 These can be visually summarized by showing the infinite tree of 581 possible source "alert" URNs and how it is partitioned into subtrees 582 that map to each of these symbols. We also mark with "*" the 583 expressed URNs. 585 urn:alert 586 | 587 { | } 588 { source } --> 1 589 { | } 590 | 591 +--------------------+------------------+ 592 | | | 593 { | } { | } { | } 594 { external* } --> 2 { internal* } --> 3 { ... } --> 4 595 { | } { | } { } 596 { ... } { ... } 597 { } { } 599 1 = Source 600 2 = Source:External 601 3 = Source:Internal 602 4 = Source:Other 604 4.3. Constructing the States and Transitions 606 The user agent processes the Alert-Info URNs left-to-right using a 607 finite state machine (FSM), with each successive URN causing the FSM 608 to transition to a new state. Each state of the FSM records the 609 information which has so far been extracted from the URNs. The state 610 of the FSM after processing all the URNs determines which signal the 611 user agent will render to the user. 613 We label each state with a set of symbols, one from each relevant 614 category, which describe the information that's been extracted from 615 all of the URNs that have so far been processed. The initial state 616 is labeled with the "null" symbols that are just the category names, 617 because no information has yet been recorded. In our simple example, 618 the initial state is labeled "Source", since that's the only relevant 619 category. 621 State: Source (initial state) 623 Each state has a corresponding alerting signal, which is the signal 624 that the user agent will produce when URN processing leaves the FSM 625 in that state. The signal is the one that best expresses the 626 information that has been extracted from the URNs. Usually the 627 choice of signal is obvious to the designer, but there are certain 628 constraints that the choice must satisfy. The main constraint is 629 that the signal's expressed URNs must be semantic supersets of (i.e., 630 identical to or a prefix of) the URNs corresponding to the symbols in 631 the state's label. In particular, if the expressed URN of the signal 632 in a certain category is shorter than the state's label, we show that 633 in the state's name by putting parentheses around the trailing part 634 of the symbol that is not expressed by the signal. For instance, if 635 the symbol in the label is "Source:External" but the signal only 636 expresses "Source" (i.e., no "source" URN at all), then the symbol in 637 the label is modified to be "Source:(External)". 639 The reason for this unintuitive construction is that in some states, 640 the FSM has recorded information that the chosen signal cannot 641 express. 643 Note that the parentheses are part of the state name, so in some 644 circumstances there may be two or more distinct states labeled with 645 the same symbols, but with different placement of parentheses within 646 the symbols. These similar state names are relevant when the FSM can 647 record information from multiple "alert" URNs but cannot express all 648 of them -- depending on the order in which the URNs appear, the UA 649 may have to render different signals, so it needs states that record 650 the same information but render different subsets of that 651 information. 653 The initial state's label is the string of null symbols for the 654 relevant categories, so the only allowed signal is the default 655 signal, which expresses no URNs: 657 State: Source (initial state) 658 Signal: default 660 From each state, we must construct the transition for each possible 661 input symbol. For a particular state and symbol, we construct the 662 label of the destination state by combining the input symbol with the 663 symbol in the start state's label for the same category. If one of 664 the symbols is a prefix of the other, we select the longer one; if 665 not, we select the symbol in the start state's label. 667 Thus, in our simple example, the initial state has the following 668 transitions: 670 State: Source (initial state) 671 Signal: default 672 Transitions: 673 Source:External -> Source:External 674 Source:Internal -> Source:Internal 675 Source:Other -> Source:Other 677 In all of these transitions, the input symbol is compatible with the 678 matching label of the state, "Source", so the destination state's 679 label is the full input symbol. 681 However, there is a further constraint on the destination state: Its 682 signal must express URNs that at least contain the expressed URNs of 683 the signal of the start state. Within that constraint, and being 684 compatible with the destination state's label, for the category of 685 the input URN, the destination state's signal must express the 686 longest URN that can be expressed by any signal. 688 In our example, this means that the destination Source:External state 689 has the "external source" signal, which expresses 690 urn:alert:source:external. Since that signal expresses all of the 691 state's label, it is the chosen state. Similarly, the destination 692 Source:Internal state has the "internal source" signal. But for the 693 transition on input Source:Other, the "Source:Other" state must have 694 the default signal, as there is no signal that expresses 695 urn:alert:source:[some-unknown-alert-ind-part]. So the destination 696 state is "Source:(Other)", where the parentheses record that the 697 "Other" part of the label is not expressed by the state's signal. 699 Thus, the initial state and the states it can transition to are: 701 State: Source (initial state) 702 Signal: default 703 Transitions: 704 Source:External -> Source:External 705 Source:Internal -> Source:Internal 706 Source:Other -> Source:(Other) 708 State: Source:External 709 Signal: external source (urn:alert:source:external) 711 State: Source:Internal 712 Signal: internal source (urn:alert:source:internal) 714 State: Source:(Other) 715 Signal: default 717 Looking at the state Source:External, we see that it is incompatible 718 with all input symbols other than Source:External, and thus all of 719 its transitions are to itself: 721 State: Source:External 722 Signal: external source (urn:alert:source:external) 723 Transitions: 724 Source:External -> Source:External 725 Source:Internal -> Source:External 726 Source:Other -> Source:External 728 and similarly: 730 State: Source:Internal 731 Signal: internal source (urn:alert:source:internal) 732 Transitions: 733 Source:External -> Source:Internal 734 Source:Internal -> Source:Internal 735 Source:Other -> Source:Internal 737 State: Source:(Other) 738 Signal: default 739 Transitions: 740 Source:External -> Source:(Other) 741 Source:Internal -> Source:(Other) 742 Source:Other -> Source:(Other) 744 4.4. Summary 746 The FSM can be constructed by processing the file "very-simple.txt" 747 with the program "alert-info-fsm.py" in [code]. The program's output 748 shows the stages of the construction, which are: 750 1. The signals have the meanings: 752 Signal URN(s) 753 ---------------------------- ------------------------------- 754 default (none) 755 internal source urn:alert:source:internal 756 external source urn:alert:source:external. 758 2. The expressed URNs are 760 urn:alert:source:external 761 urn:alert:source:internal 763 3. The relevant categories of "alert" URNs are only: 765 source 767 4. Thus, the infinite universe of possible "alert" URNs can be 768 reduced to these symbols, which are the categories of URNs that 769 are different in ways that are significant to the resolution 770 process: 772 Source 773 Source:External 774 Source:Internal 775 Source:Other 777 5. The FSM is: 779 State: Source (initial state) 780 Signal: default 781 Transitions: 782 Source:External -> Source:External 783 Source:Internal -> Source:Internal 784 Source:Other -> Source:(Other) 786 State: Source:External 787 Signal: external source (urn:alert:source:external) 788 Transitions: 789 Source:External -> Source:External 790 Source:Internal -> Source:External 791 Source:Other -> Source:External 793 State: Source:Internal 794 Signal: internal source (urn:alert:source:internal) 795 Transitions: 796 Source:External -> Source:Internal 797 Source:Internal -> Source:Internal 798 Source:Other -> Source:Internal 800 State: Source:(Other) 801 Signal: default 802 Transitions: 803 Source:External -> Source:(Other) 804 Source:Internal -> Source:(Other) 805 Source:Other -> Source:(Other) 807 * Each state is labeled by a set of symbols which describe the 808 information which has been extracted from the URNs so far. 810 * Each state has a signal which is a semantic superset of the 811 state's label, i.e., the signal's expressed URNs match the 812 initial portion of the label symbols. If Alert-Info 813 processing finishes with the FSM in a state, the user agent 814 will render the state's signal to the user. 816 * The state's label is marked to show what subset of the symbols 817 are expressed by the state's signal. Two states can have the 818 same label but different signals. 820 * If a transition's input symbol is compatible with (is a 821 semantic subset) of the start state's label for that category, 822 the destination state's label is updated with the input 823 symbol. If not, the destination state is the start state. 824 This is how the state's label records what information has 825 been accumulated while processing the Alert-Info URNs. 827 * A transition's destination state has a signal which 828 semantically subsets the start state's signal as much as 829 possible in the category of the input symbol. (In most cases, 830 the choice of signal is unique. In rare cases there may be 831 more than one signal that meets this criterion, so the 832 designer may have some flexibility.) 834 4.5. Examples of Processing Alert-Info URNs 836 In the trivial case where the user agent receives no Alert-Info URNs, 837 then processing begins and ends with the FSM in the initial state and 838 selects the default signal. 840 If the user agent receives 842 Alert-Info: 844 then processing progresses: 846 State: Source 847 Process: Source:Internal (urn:alert:source:internal) 848 State: Source:Internal 849 Signal: internal source 851 If the user agent receives 853 Alert-Info: , 854 856 then processing progresses: 858 State: Source 859 Process: Source:External (urn:alert:source:external) 860 State: Source:External 861 Process: Source:Internal (urn:alert:source:internal) 862 State: Source:External 863 Signal: external source 865 If the user agent receives 867 Alert-Info: , 868 870 then processing progresses: 872 State: Source 873 Process: Source:Other (urn:alert:source:unclassified) 874 State: Source:(Other) 875 Process: Source:Internal (urn:alert:source:internal) 876 State: Source:(Other) 877 Signal: default 879 If the user agent receives 881 Alert-Info: , 882 884 then processing progresses: 886 State: Source 887 Ignore: urn:alert:priority:high 888 State: Source 889 Process: Source:Internal (urn:alert:source:internal) 890 State: Source:Internal 891 Signal: internal source 893 5. Further Examples 895 5.1. Example with "source" and "priority" URNs 897 Now consider an example where the user agent can signal "external 898 source", "internal source", "low priority", and "high priority" 899 individually or in any combination of source and priority, along with 900 a default signal. This example is essentially the cartesian product 901 of two copies of the example in Section 4, one dealing with the 902 call's source and one dealing with the call's priority. So there is 903 a total of 9 signals: 905 Signal URN(s) 906 ---------------------------- ------------------------------- 907 default (none) 908 external source urn:alert:source:external 909 internal source urn:alert:source:internal 910 low priority urn:alert:priority:low 911 low priority/external source urn:alert:priority:low, 912 urn:alert:source:external 913 low priority/internal source urn:alert:priority:low, 914 urn:alert:source:internal 915 high priority urn:alert:priority:high 916 high priority/external source urn:alert:priority:high, 917 urn:alert:source:external 918 high priority/internal source urn:alert:priority:high, 919 urn:alert:source:internal 921 The expressed URNs are: 923 urn:alert:source:external 924 urn:alert:source:internal 925 urn:alert:priority:low 926 urn:alert:priority:high 928 The relevant categories of "alert" URNs are only: 930 source 931 priority 933 The alphabet of symbols is: 935 Source 936 Source:External 937 Source:Internal 938 Source:Other 939 Priority 940 Priority:Low 941 Priority:High 942 Priority:Other 944 The 16 states are as follows, where 10 states have a simple structure 945 because from them, no further information can be recorded. 947 State: Priority/Source 948 Signal: default 949 Transitions: 950 Priority:Other -> Priority:(Other)/Source 951 Priority:High -> Priority:High/Source 952 Priority:Low -> Priority:Low/Source 953 Source:Other -> Priority/Source:(Other) 954 Source:External -> Priority/Source:External 955 Source:Internal -> Priority/Source:Internal 957 State: Priority:(Other)/Source 958 Signal: default 959 Transitions: 960 Priority:Other -> Priority:(Other)/Source 961 Priority:High -> Priority:(Other)/Source 962 Priority:Low -> Priority:(Other)/Source 963 Source:Other -> Priority:(Other)/Source:(Other) 964 Source:External -> Priority:(Other)/Source:External 965 Source:Internal -> Priority:(Other)/Source:Internal 967 State: Priority:(Other)/Source:(Other) 968 Signal: default 969 Transitions: 970 any -> Priority:(Other)/Source:(Other) 972 State: Priority:(Other)/Source:External 973 Signal: external source 974 Transitions: 975 any -> Priority:(Other)/Source:External 977 State: Priority:(Other)/Source:Internal 978 Signal: internal source 979 Transitions: 980 any -> Priority:(Other)/Source:Internal 982 State: Priority:High/Source 983 Signal: high priority 984 Transitions: 985 Priority:Other -> Priority:High/Source 986 Priority:High -> Priority:High/Source 987 Priority:Low -> Priority:High/Source 988 Source:Other -> Priority:High/Source:(Other) 989 Source:External -> Priority:High/Source:External 990 Source:Internal -> Priority:High/Source:Internal 992 State: Priority:High/Source:(Other) 993 Signal: high priority 994 Transitions: 995 any -> Priority:High/Source:(Other) 997 State: Priority:High/Source:External 998 Signal: high priority/external source 999 Transitions: 1000 any -> Priority:High/Source:External 1002 State: Priority:High/Source:Internal 1003 Signal: high priority/internal source 1004 Transitions: 1005 any -> Priority:High/Source:Internal 1007 State: Priority:Low/Source 1008 Signal: low priority 1009 Transitions: 1010 Priority:Other -> Priority:Low/Source 1011 Priority:High -> Priority:Low/Source 1012 Priority:Low -> Priority:Low/Source 1013 Source:Other -> Priority:Low/Source:(Other) 1014 Source:External -> Priority:Low/Source:External 1015 Source:Internal -> Priority:Low/Source:Internal 1017 State: Priority:Low/Source:(Other) 1018 Signal: low priority 1019 Transitions: 1020 any -> Priority:Low/Source:(Other) 1022 State: Priority:Low/Source:External 1023 Signal: low priority/external source 1024 Transitions: 1025 any -> Priority:Low/Source:External 1027 State: Priority:Low/Source:Internal 1028 Signal: low priority/internal source 1029 Transitions: 1030 any -> Priority:Low/Source:Internal 1032 State: Priority/Source:(Other) 1033 Signal: default 1034 Transitions: 1035 Priority:Other -> Priority:(Other)/Source:(Other) 1036 Priority:High -> Priority:High/Source:(Other) 1037 Priority:Low -> Priority:Low/Source:(Other) 1038 Source:Other -> Priority/Source:(Other) 1039 Source:External -> Priority/Source:(Other) 1040 Source:Internal -> Priority/Source:(Other) 1042 State: Priority/Source:External 1043 Signal: external source 1044 Transitions: 1045 Priority:Other -> Priority:(Other)/Source:External 1046 Priority:High -> Priority:High/Source:External 1047 Priority:Low -> Priority:Low/Source:External 1048 Source:Other -> Priority/Source:External 1049 Source:External -> Priority/Source:External 1050 Source:Internal -> Priority/Source:External 1052 State: Priority/Source:Internal 1053 Signal: internal source 1054 Transitions: 1055 Priority:Other -> Priority:(Other)/Source:Internal 1056 Priority:High -> Priority:High/Source:Internal 1057 Priority:Low -> Priority:Low/Source:Internal 1058 Source:Other -> Priority/Source:Internal 1059 Source:External -> Priority/Source:Internal 1060 Source:Internal -> Priority/Source:Internal 1062 An example of processing that involves multiple "source" URNs and one 1063 "priority" URN: 1065 Alert-Info: , 1066 , 1067 1069 State: Source/Priority 1070 Process: Source:Internal (urn:alert:source:internal) 1071 State: Source:Internal/Priority 1072 Process: Source:(Other) (urn:alert:source:unclassified) 1073 State: Source:Internal/Priority 1074 Process: Priority:High (urn:alert:priority:high) 1075 State: Source:Internal/Priority:High 1076 Signal: internal source/high priority 1078 5.2. Example 1 of RFC 7462 1080 A more complicated example is in section 12.2.1 of [RFC7462]. It is 1081 like the example in Section 5.1 of this document, except that the 1082 user agent can only signal "external source", "internal source", "low 1083 priority", and "high priority" individually but not in combination, 1084 as well as a default signal: 1086 Signal URN(s) 1087 ---------------------------- ------------------------------- 1088 default (none) 1089 internal source urn:alert:source:external 1090 external source urn:alert:source:internal 1091 high low urn:alert:priority:low 1092 high priority urn:alert:priority:high 1094 The signals can express the following URNs: 1096 urn:alert:source:external 1097 urn:alert:source:internal 1098 urn:alert:priority:low 1099 urn:alert:priority:high 1101 The relevant categories of "alert" URNs are: 1103 source 1104 priority 1106 The alphabet of symbols is: 1108 Source 1109 Source:External 1110 Source:Internal 1111 Source:Other 1112 Priority 1113 Priority:Low 1114 Priority:High 1115 Priority:Other 1117 In this example, the FSM has 20 states because both "source" and 1118 "priority" URNs are recorded, but the order in which the two appear 1119 affects the signal: 1121 State: Priority/Source 1122 Signal: default 1123 Transitions: 1124 Priority:Other -> Priority:(Other)/Source 1125 Priority:High -> Priority:High/Source 1126 Priority:Low -> Priority:Low/Source 1127 Source:Other -> Priority/Source:(Other) 1128 Source:External -> Priority/Source:External 1129 Source:Internal -> Priority/Source:Internal 1131 State Priority:(Other)/Source can transition to states that can 1132 signal source, because the recorded priority can't be signaled and 1133 thus does not block the signaling of the source: 1135 State: Priority:(Other)/Source 1136 Signal: default 1137 Transitions: 1138 Priority:Other -> Priority:(Other)/Source 1139 Priority:High -> Priority:(Other)/Source 1140 Priority:Low -> Priority:(Other)/Source 1141 Source:Other -> Priority:(Other)/Source:(Other) 1142 Source:External -> Priority:(Other)/Source:External 1143 Source:Internal -> Priority:(Other)/Source:Internal 1145 State: Priority:(Other)/Source:(Other) 1146 Signal: default 1147 Transitions: 1148 any -> Priority:(Other)/Source:(Other) 1150 State: Priority:(Other)/Source:External 1151 Signal: external source 1152 Transitions: 1153 any -> Priority:(Other)/Source:External 1155 State: Priority:(Other)/Source:Internal 1156 Signal: internal source 1157 Transitions: 1158 any -> Priority:(Other)/Source:Internal 1160 Because there are no signals for combinations of "source" and 1161 "priority" URNs, processing a "source" URN from the state 1162 Priority:High/Source leads to a state that records the priority 1163 information, but does not signal it: 1165 State: Priority:High/Source 1166 Signal: high priority 1167 Transitions: 1168 Priority:Other -> Priority:High/Source 1169 Priority:High -> Priority:High/Source 1170 Priority:Low -> Priority:High/Source 1171 Source:Other -> Priority:High/Source:(Other) 1172 Source:External -> Priority:High/Source:(External) 1173 Source:Internal -> Priority:High/Source:(Internal) 1175 State: Priority:High/Source:(Other) 1176 Signal: high priority 1177 Transitions: 1178 any -> Priority:High/Source:(Other) 1180 From the state Priority:High/Source, "source" URNs transition to 1181 states that record both source and priority but signal only priority, 1182 one of which is Priority:High/Source:(External). But from Priority/ 1183 Source:External, the symbol Priority:High transitions to the state 1184 Priority:(High)/Source:External, which records the same information 1185 but signals the source, not the priority. -- One state is reached by 1186 processing a "priority" URN and then a "source" URN, whereas the 1187 other is reached by processing a "source" URN and then a "priority" 1188 URN. 1190 State: Priority:High/Source:(External) 1191 Signal: high priority 1192 Transitions: 1193 any -> Priority:High/Source:(External) 1195 State: Priority:High/Source:(Internal) 1196 Signal: high priority 1197 Transitions: 1198 any -> Priority:High/Source:(Internal) 1200 And similarly for Priority:Low/Source: 1202 State: Priority:Low/Source 1203 Signal: low priority 1204 Transitions: 1205 Priority:Other -> Priority:Low/Source 1206 Priority:High -> Priority:Low/Source 1207 Priority:Low -> Priority:Low/Source 1208 Source:Other -> Priority:Low/Source:(Other) 1209 Source:External -> Priority:Low/Source:(External) 1210 Source:Internal -> Priority:Low/Source:(Internal) 1212 State: Priority:Low/Source:(Other) 1213 Signal: low priority 1214 Transitions: 1215 any -> Priority:Low/Source:(Other) 1217 State: Priority:Low/Source:(External) 1218 Signal: low priority 1219 Transitions: 1220 any -> Priority:Low/Source:(External) 1222 State: Priority:Low/Source:(Internal) 1223 Signal: low priority 1224 Transitions: 1225 any -> Priority:Low/Source:(Internal) 1227 State: Priority/Source:(Other) 1228 Signal: default 1229 Transitions: 1230 Priority:Other -> Priority:(Other)/Source:(Other) 1231 Priority:High -> Priority:High/Source:(Other) 1232 Priority:Low -> Priority:Low/Source:(Other) 1233 Source:Other -> Priority/Source:(Other) 1234 Source:External -> Priority/Source:(Other) 1235 Source:Internal -> Priority/Source:(Other) 1237 State: Priority/Source:External 1238 Signal: external source 1239 Transitions: 1240 Priority:Other -> Priority:(Other)/Source:External 1241 Priority:High -> Priority:(High)/Source:External 1242 Priority:Low -> Priority:(Low)/Source:External 1243 Source:Other -> Priority/Source:External 1244 Source:External -> Priority/Source:External 1245 Source:Internal -> Priority/Source:External 1247 State: Priority:(High)/Source:External 1248 Signal: external source 1249 Transitions: 1250 any -> Priority:(High)/Source:External 1252 State: Priority:(Low)/Source:External 1253 Signal: external source 1254 Transitions: 1255 any -> Priority:(Low)/Source:External 1257 State: Priority/Source:Internal 1258 Signal: internal source 1259 Transitions: 1260 Priority:Other -> Priority:(Other)/Source:Internal 1261 Priority:High -> Priority:(High)/Source:Internal 1262 Priority:Low -> Priority:(Low)/Source:Internal 1263 Source:Other -> Priority/Source:Internal 1264 Source:External -> Priority/Source:Internal 1265 Source:Internal -> Priority/Source:Internal 1267 State: Priority:(High)/Source:Internal 1268 Signal: internal source 1269 Transitions: 1270 any -> Priority:(High)/Source:Internal 1272 State: Priority:(Low)/Source:Internal 1273 Signal: internal source 1274 Transitions: 1275 any -> Priority:(Low)/Source:Internal 1277 As an example of processing, if the user agent receives 1279 Alert-Info: 1281 then processing progresses: 1283 State: Priority/Source 1284 Process: Source:Internal (urn:alert:source:internal) 1285 State: Priority/Source:Internal 1286 Signal: internal source 1288 A more complicated example involves multiple "source" URNs which do 1289 not select a non-default signal and one "priority" URN which can be 1290 signaled: 1292 Alert-Info: , 1293 , 1294 1296 State: Priority/Source 1297 Process: Source:Other (urn:alert:source:unclassified) 1298 State: Priority/Source:(Other) 1299 Process: Source:Internal (urn:alert:source:internal) 1300 State: Priority/Source:(Other) 1301 Process: Priority:High (urn:alert:priority:high) 1302 State: Priority:High/Source:(Other) 1303 Signal: high priority 1305 Since the only characteristic of a state that affects the output of 1306 the FSM is the state's signal, several groups of states in this FSM 1307 can be merged using standard FSM optimization algorithms: 1309 states with signal "high priority": 1310 Priority:High/Source 1311 Priority:High/Source:(Other) 1312 Priority:High/Source:(External) 1313 Priority:High/Source:(Internal) 1315 states with signal "low priority": 1316 Priority:Low/Source 1317 Priority:Low/Source:(Other) 1318 Priority:Low/Source:(External) 1319 Priority:Low/Source:(Internal) 1321 states with signal "external source": 1322 Priority/Source:External 1323 Priority:(High)/Source:External 1324 Priority:(Low)/Source:External 1325 Priority:(Other)/Source:External 1327 states with signal "internal source": 1328 Priority/Source:Internal 1329 Priority:(High)/Source:Internal 1330 Priority:(Low)/Source:Internal 1331 Priority:(Other)/Source:Internal 1333 This reduces the FSM to 7 states. 1335 5.3. Examples 2, 3, and 4 of RFC 7462 1337 Examples 2, 3, and 4 of [RFC7462] are similar to the example in 1338 Section 5.1, but they do not include a signal for the combination 1339 "internal source, low priority" to make resolution examples work 1340 asymmetrically. 1342 The FSM for this example has the same alphabet as the FSM of 1343 Section 5.1. Most of the states of this FSM are the same as the 1344 states of the FSM of Section 5.1, but the state Source:Internal/ 1345 Priority:Low is missing because there is no signal for that 1346 combination. It is replaced by two states: One state is 1347 Source:Internal/Priority:(Low); it records that Source:Internal was 1348 specified first (and is to be signaled) and that Priority:Low was 1349 specified later (and can not be signaled -- but it still prevents any 1350 further "priority" URN from having an effect). The other state is 1351 Source:(Internal)/Priority:Low; it records the reverse sequence of 1352 events. 1354 The changes in the FSM are: 1356 State: Priority:Low/Source 1357 Signal: low priority 1358 Transitions: 1359 Source:Internal -> Priority:Low/Source:(Internal) 1360 (other transitions unchanged) 1362 State: Priority:Low/Source:(Internal) 1363 Signal: low priority 1364 Transitions: 1365 any -> Priority:Low/Source:(Internal) 1367 State: Priority/Source:Internal 1368 Signal: internal source 1369 Transitions: 1370 Priority:Low -> Priority:(Low)/Source:Internal 1371 (other transitions unchanged) 1373 State: Priority:(Low)/Source:Internal 1374 Signal: internal source 1375 Transitions: 1376 any -> Priority:(Low)/Source:Internal 1378 An example of processing that involves multiple "source" URNs and one 1379 "priority" URN: 1381 Alert-Info: , 1382 , 1383 1385 State: Priority/Source 1386 Process: Source:Internal (urn:alert:source:internal) 1387 State: Priority/Source:Internal 1388 Process: Source:Other (urn:alert:source:unclassified) 1389 State: Priority/Source:Internal 1390 Process: Priority:High (urn:alert:priority:high) 1391 State: Priority:High/Source:Internal 1392 Signal: internal source/high priority 1394 If the user agent receives 1396 Alert-Info: 1398 State: Priority/Source 1399 Process: Source:Internal (urn:alert:source:internal) 1400 State: Priority/Source:Internal 1401 Signal: internal source 1403 If the user agent receives 1405 Alert-Info: , 1406 1408 State: Priority/Source 1409 Process: Source:External (urn:alert:source:external) 1410 State: Priority/Source:External 1411 Process: Priority:Low (urn:alert:priority:low) 1412 State: Priority:Low/Source:External 1413 Signal: external source/low priority 1415 Suppose the same user agent receives 1417 Alert-Info: , 1418 1420 Note that there is no signal that corresponds to this combination. 1421 In that case, the processing is: 1423 State: Priority/Source 1424 Process: Source:Internal (urn:alert:source:internal) 1425 State: Priority/Source:Internal 1426 Process: Priority:Low (urn:alert:priority:low) 1427 State: Priority:(Low)/Source:Internal 1428 Signal: internal source 1430 If the order of the URNs is reversed, what is signaled is the meaning 1431 of now-different first URN: 1433 Alert-Info: , 1434 1436 State: Priority/Source 1437 Process: Priority:Low (urn:alert:priority:low) 1438 State: Priority:Low/Source 1439 Process: Source:Internal (urn:alert:source:internal) 1440 State: Priority:Low/Source:(Internal) 1441 Signal: low priority 1443 Notice that the existence of the new states prevents later URNs of a 1444 category from overriding earlier URNs of that category, even if the 1445 earlier one was not itself signalable and the later one would be 1446 signalable in the absence of the earlier one: 1448 Alert-Info: , 1449 , 1450 1452 State: Priority/Source 1453 Process: Priority:Low (urn:alert:priority:low) 1454 State: Priority:Low/Source 1455 Process: Source:Internal (urn:alert:source:internal) 1456 State: Priority:Low/Source:(Internal) 1457 Process: Source:External (urn:alert:source:external) 1458 State: Priority:Low/Source:(Internal) 1459 Signal: low priority 1461 This situation shows the necessity of states whose labels contain 1462 parentheses. If the second transition had been to the state 1463 Priority:Low/Source (on the basis that there is no proper state 1464 Priority:Low/Source:Internal), then the third transition would have 1465 been to the state Priority:Low/Source:External, and the signal would 1466 have been "external source/low priority". 1468 5.4. An Example that Subsets Internal Sources 1470 In the example of Section 4, there are signals for "external source" 1471 and "internal source". Let us add to that example a signal for 1472 "source internal from a VIP". That last signal expresses the private 1473 extension URN urn:alert:source:internal:vip@example, which is a 1474 subset of urn:alert:source:internal, which is expressed by the 1475 "source internal" signal. There is a total of 3 expressed URNs, one 1476 of which is a subset of another: 1478 urn:alert:source:internal 1479 urn:alert:source:internal:vip@example 1480 urn:alert:source:external 1482 This generates the following alphabet of symbols, which includes two 1483 Other symbols for the category source: 1485 Source 1486 Source:Internal 1487 Source:Internal:Vip@example 1488 Source:Internal:Other 1489 Source:Other 1491 5.5. An Example of "alert:service" URNs 1493 In this example there are signals for "service forward" (the call has 1494 been forwarded) and "source recall callback" (a recall due to a 1495 callback). This gives 2 expressed URNs: 1497 urn:alert:service:forward 1498 urn:alert:service:recall:callback 1500 This generates the following alphabet of symbols. Note that there 1501 are two "Other" symbols, because the "alert:service" URNs have an 1502 additional level of qualification. 1504 Service 1505 Service:Forward 1506 Service:Recall 1507 Service:Recall:Callback 1508 Service:Recall:Other 1509 Service:Other 1511 5.6. An Example Using Country Codes 1513 In this example, we consider how a UA generates ringback signals when 1514 the UA wishes to reproduce the traditional behavior that the caller 1515 hears the ringback signals defined by the telephone service in the 1516 callee's country, rather than the ringback signals defined by the 1517 service in the caller's country. In the Alert-Info header field of 1518 the 180 Ringing provisional response, we assume that the called UA 1519 provides an "alert:country" URN containing the ISO 3166-1 alpha-2 1520 country code of the callee's country. 1522 The UA has a default signal and a "non-country" signal for 1523 urn:alert:service:call-waiting. For the example country with code 1524 "XA", the UA has a default signal and signals for 1525 urn:alert:service:call-waiting and urn:alert:service:forward. For 1526 the example country with code "XB", the UA has a default signal and a 1527 signal for urn:alert:service:forward. These inconsistencies between 1528 the non-country signals and the country signals are chosen to 1529 demonstrate the flexibility of the construction method, showing that 1530 three systems of signals can be combined correctly even when the 1531 systems were established without coordination between them. 1533 The signals are: 1535 Signal URN(s) 1536 ---------------------------- ------------------------------- 1537 default (none) 1538 call-waiting urn:alert:service:call-waiting 1540 XA default urn:alert:country:xa 1541 XA call-waiting urn:alert:country:xa, 1542 urn:alert:service:call-waiting 1543 XA forward urn:alert:country:xa, 1544 urn:alert:service:forward 1546 XB default urn:alert:country:xb 1547 XB forward urn:alert:country:xb, 1548 urn:alert:service:forward 1550 The expressed URNs are: 1552 urn:alert:country:xa 1553 urn:alert:country:xb 1554 urn:alert:service:call-waiting 1555 urn:alert:service:forward 1557 The relevant categories of "alert" URNs are only: 1559 country 1560 service 1562 The alphabet of symbols is: 1564 Country 1565 Country:[other] 1566 Country:Xa 1567 Country:Xb 1568 Service 1569 Service:[other] 1570 Service:Call-waiting 1571 Service:Forward 1573 The 15 states are as follows: 1575 State: 0 Country/Service 1576 Signal: default 1577 Transitions: 1578 Country:[other] -> 1 Country:([other])/Service 1579 Country:Xa -> 5 Country:Xa/Service 1580 Country:Xb -> 9 Country:Xb/Service 1581 Service:[other] -> 13 Country/Service:([other]) 1582 Service:Call-waiting -> 14 Country/Service:Call-waiting 1583 Service:Forward -> 16 Country/Service:(Forward) 1585 State: 1 Country:([other])/Service 1586 Signal: default 1587 Transitions: 1588 Country:[other] -> 1 Country:([other])/Service 1589 Country:Xa -> 1 Country:([other])/Service 1590 Country:Xb -> 1 Country:([other])/Service 1591 Service:[other] -> 2 Country:([other])/Service:([other]) 1592 Service:Call-waiting -> 3 Country:([other])/Service:Call-waiting 1593 Service:Forward -> 4 Country:([other])/Service:(Forward) 1595 State: 2 Country:([other])/Service:([other]) 1596 Signal: default 1597 Transitions: 1598 any -> 2 Country:([other])/Service:([other]) 1600 State: 3 Country:([other])/Service:Call-waiting 1601 Signal: call-waiting 1602 Transitions: 1603 any -> 3 Country:([other])/Service:Call-waiting 1605 State: 4 Country:([other])/Service:(Forward) 1606 Signal: default 1607 Transitions: 1608 any -> 4 Country:([other])/Service:(Forward) 1610 State: 5 Country:Xa/Service 1611 Signal: XA default 1612 Transitions: 1613 Country:[other] -> 5 Country:Xa/Service 1614 Country:Xa -> 5 Country:Xa/Service 1615 Country:Xb -> 5 Country:Xa/Service 1616 Service:[other] -> 6 Country:Xa/Service:([other]) 1617 Service:Call-waiting -> 7 Country:Xa/Service:Call-waiting 1618 Service:Forward -> 8 Country:Xa/Service:Forward 1620 State: 6 Country:Xa/Service:([other]) 1621 Signal: XA default 1622 Transitions: 1623 any -> 6 Country:Xa/Service:([other]) 1625 State: 7 Country:Xa/Service:Call-waiting 1626 Signal: XA call-waiting 1627 Transitions: 1628 any -> 7 Country:Xa/Service:Call-waiting 1630 State: 8 Country:Xa/Service:Forward 1631 Signal: XA forward 1632 Transitions: 1633 any -> 8 Country:Xa/Service:Forward 1635 State: 9 Country:Xb/Service 1636 Signal: XB default 1637 Transitions: 1638 Country:[other] -> 9 Country:Xb/Service 1639 Country:Xa -> 9 Country:Xb/Service 1640 Country:Xb -> 9 Country:Xb/Service 1641 Service:[other] -> 10 Country:Xb/Service:([other]) 1642 Service:Call-waiting -> 11 Country:Xb/Service:(Call-waiting) 1643 Service:Forward -> 12 Country:Xb/Service:Forward 1645 State: 10 Country:Xb/Service:([other]) 1646 Signal: XB default 1647 Transitions: 1648 any -> 10 Country:Xb/Service:([other]) 1650 State: 11 Country:Xb/Service:(Call-waiting) 1651 Signal: XB default 1652 Transitions: 1653 any -> 11 Country:Xb/Service:(Call-waiting) 1655 State: 12 Country:Xb/Service:Forward 1656 Signal: XB forward 1657 Transitions: 1658 any -> 12 Country:Xb/Service:Forward 1660 State: 13 Country/Service:([other]) 1661 Signal: default 1662 Transitions: 1663 Country:[other] -> 2 Country:([other])/Service:([other]) 1664 Country:Xa -> 6 Country:Xa/Service:([other]) 1665 Country:Xb -> 10 Country:Xb/Service:([other]) 1666 Service:[other] -> 13 Country/Service:([other]) 1667 Service:Call-waiting -> 13 Country/Service:([other]) 1668 Service:Forward -> 13 Country/Service:([other]) 1670 State: 14 Country/Service:Call-waiting 1671 Signal: call-waiting 1672 Transitions: 1673 Country:[other] -> 3 Country:([other])/Service:Call-waiting 1674 Country:Xa -> 7 Country:Xa/Service:Call-waiting 1675 Country:Xb -> 15 Country:(Xb)/Service:Call-waiting 1676 Service:[other] -> 14 Country/Service:Call-waiting 1677 Service:Call-waiting -> 14 Country/Service:Call-waiting 1678 Service:Forward -> 14 Country/Service:Call-waiting 1680 State: 15 Country:(Xb)/Service:Call-waiting 1681 Signal: call-waiting 1682 Transitions: 1683 any -> 15 Country:(Xb)/Service:Call-waiting 1685 State: 16 Country/Service:(Forward) 1686 Signal: default 1687 Transitions: 1688 Country:[other] -> 4 Country:([other])/Service:(Forward) 1689 Country:Xa -> 8 Country:Xa/Service:Forward 1690 Country:Xb -> 12 Country:Xb/Service:Forward 1691 Service:[other] -> 16 Country/Service:(Forward) 1692 Service:Call-waiting -> 16 Country/Service:(Forward) 1693 Service:Forward -> 16 Country/Service:(Forward) 1695 Call-waiting can be signaled in conjunction with country XA, but not 1696 in conjunction with country XB as the UA does not have a signal to 1697 present call waiting alerts for country XB. Thus the ordering of 1698 urn:alert:service:call-waiting with urn:alert:country:xa does not 1699 matter, but if urn:alert:country:xb appears before 1700 urn:alert:service:call-waiting, call-waiting cannot be signaled. On 1701 the other hand, if urn:alert:service:call-waiting appears before 1702 urn:alert:country:xb, then call-waiting is signaled, but using the 1703 non-country signal. 1705 Alert-Info: urn:alert:country:xa, 1706 urn:alert:service:call-waiting 1708 State: 0 Country/Service 1709 Process: Country:Xa (urn:alert:country:xa) 1710 State: 5 Country:Xa/Service 1711 Process: Service:Call-waiting (urn:alert:service:call-waiting) 1712 State: 7 Country:Xa/Service:Call-waiting 1713 Signal: XA call-waiting 1715 Alert-Info: urn:alert:service:call-waiting, 1716 urn:alert:country:xa 1718 State: 0 Country/Service 1719 Process: Service:Call-waiting (urn:alert:service:call-waiting) 1720 State: 14 Country/Service:Call-waiting 1721 Process: Country:Xa (urn:alert:country:xa) 1722 State: 7 Country:Xa/Service:Call-waiting 1723 Signal: XA call-waiting 1725 Alert-Info: urn:alert:country:xb, 1726 urn:alert:service:call-waiting 1728 State: 0 Country/Service 1729 Process: Country:Xb (urn:alert:country:xb) 1730 State: 9 Country:Xb/Service 1731 Process: Service:Call-waiting (urn:alert:service:call-waiting) 1732 State: 11 Country:Xb/Service:(Call-waiting) 1733 Signal: XB default 1735 Alert-Info: urn:alert:service:call-waiting, 1736 urn:alert:country:xb 1738 State: 0 Country/Service 1739 Process: Service:Call-waiting (urn:alert:service:call-waiting) 1740 State: 14 Country/Service:Call-waiting 1741 Process: Country:Xb (urn:alert:country:xb) 1742 State: 15 Country:(Xb)/Service:Call-waiting 1743 Signal: call-waiting 1745 6. Prioritizing Signals 1747 The specifications in [RFC7462] are oriented toward giving the sender 1748 of Alert-Info control over which of the "alert" URNs are most 1749 important. But in some situations, the user agent may prefer to 1750 prioritize expressing one URN category over another regardless of the 1751 order their URNs appear in Alert-Info. This section describes how 1752 that can be accommodated within the framework of [RFC7462], and 1753 presents an example FSM resulting from that approach. 1755 This example uses the signals of Section 5.2, viz., "external 1756 source", "internal source", "low priority" and "high priority", but 1757 this time, we want to signal "high priority" in preference to any 1758 other signal that might be applicable. 1760 We accommodate this within the framework of [RFC7462] by assigning 1761 the signal "high priority" for each of these combinations of URNs: 1763 urn:alert:priority:high 1764 urn:alert:priority:high, urn:alert:source:internal 1765 urn:alert:priority:high, urn:alert:source:external 1767 The result is that the "high priority" signal is the "best" signal 1768 for any combination of urn:alert:priority:high with "source" URNs. 1770 The intermediate steps of the method produce the same results as 1771 before. The signals can express the following URNs: 1773 urn:alert:source:external 1774 urn:alert:source:internal 1775 urn:alert:priority:low 1776 urn:alert:priority:high 1778 The relevant categories of "alert" URNs are: 1780 source 1781 priority 1783 The alphabet of symbols is: 1785 Source 1786 Source:External 1787 Source:Internal 1788 Source:Other 1789 Priority 1790 Priority:Low 1791 Priority:High 1792 Priority:Other 1794 When the FSM is constructed, it is the same as the FSM for 1795 Section 5.2, except that certain states are effectively renamed and 1796 merged, because any "source" is defined to be expressed if high 1797 priority is expressed: 1799 Priority:(High)/Source:External and 1800 Priority:High/Source:(External) become: 1801 State: Priority:High/Source:External 1802 Signal: high priority 1804 Priority:(High)/Source:Internal and 1805 Priority:High/Source:(Internal) become: 1806 State: Priority:High/Source:Internal 1807 Signal: high priority 1809 This reduces the FSM to 18 states. In addition, these two new 1810 states, along with a number of other states, can be merged by FSM 1811 optimization, since all of them have the signal "high priority" and 1812 from them, there are no transitions to states outside this set. The 1813 final FSM has 10 states. 1815 7. Dynamic Sets of Signals 1817 This section discusses how to construct FSMs for a user agent that 1818 allows variable sets of signals, for example, if the user can 1819 configure the use of ringtones. Several approaches can be used: 1821 o Whenever the set of ringtones is changed, re-execute the processes 1822 of Section 4. 1824 o Whenever the set of ringtones is changed, rebuild the list of 1825 expressed URNs (Section 4.1) and reconstruct the alphabet of 1826 symbols (Section 4.2). Then use an algorithm for dynamically 1827 constructing states of the FSM as they are needed during Alert- 1828 Info processing. 1830 o If the sets of possible URNs expressed by the ringtones is 1831 sufficiently limited, the steps of Section 4 can be carried out 1832 "generically", and the generic FSM can be specialized for the 1833 current ringtone configuration. 1835 The remainder of this section gives an example of the third approach. 1837 For the example, we will use a set of ringtones that express the 1838 identify of the caller. To signal this information, a private 1839 extension "alert" URN category is used, "caller@example": 1841 urn:alert:caller@example:alice@example.com 1842 urn:alert:caller@example:bob@example.com 1843 etc. 1845 which we can express by the generic pattern 1846 urn:alert:caller@example:IDENTITY 1848 where "IDENTITY" is replaced in succession by the set of caller 1849 identities that have their own ringtones to generate the set of 1850 expressed URNs. 1852 The alphabet is then: 1854 Caller@example 1855 Caller@example:IDENTITY 1856 Caller@example:Other 1858 where "IDENTITY" is replaced in succession by the set of caller 1859 identities. The "Caller@example:Other" symbol includes all URNs of 1860 the category "caller@example" that are not included in any of the 1861 other symbols. 1863 The states and transitions of the FSM are: 1865 State: Caller@example (initial state) 1866 Signal: default 1867 Transitions: 1868 Caller@example:IDENTITY -> Caller@example:IDENTITY 1869 Caller@example:Other -> Caller@example:(Other) 1871 State: Caller@example:IDENTITY 1872 Signal: signal for caller IDENTITY 1873 Transitions: 1874 any -> Caller@example:IDENTITY 1876 State: Caller@example:(Other) 1877 Signal: default 1878 Transitions: 1879 any -> Caller@example:(Other) 1881 where again, the second state is replicated once for each caller 1882 identity that has a ringtone, with "IDENTITY" replaced with the 1883 caller identity. 1885 8. Security Considerations 1887 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1888 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 1889 "OPTIONAL" in this section are to be interpreted as described in BCP 1890 14 [RFC8174] when, and only when, they appear in all capitals, as 1891 shown here. 1893 The security considerations regarding the use and processing of 1894 "alert" URNs that are discussed in [RFC7462] MUST be followed when 1895 the algorithm described in this document is used. 1897 Like any implementation of [RFC7462], implementations of this 1898 algorithm MUST take into account that the value of a received Alert- 1899 Info header field may contain URIs of any scheme, may contain 1900 syntactically invalid values, and may be syntactically invalid 1901 overall. The handling of syntactically invalid values is specified 1902 by [RFC3261]. The handling of URIs other than "alert" URIs is 1903 outside the scope of this document (and outside the scope of 1904 [RFC7462]), and MAY be subject to local policy. 1906 Like the algorithm described in [RFC7462] section 12, this 1907 algorithm's output is limited to a choice among the signals that it 1908 has been configured for, limiting the security issues regarding the 1909 processing of its output. This algorithm will use at most linear 1910 time and constant space to process a sequence of "alert" URNs, which 1911 is significantly more efficient than the algorithm of [RFC7462], and 1912 minimizes the security vulnerabilities of this processing step that 1913 are due to resource consumption. 1915 However, this process for constructing an FSM can use more than 1916 linear time and space, probably exponential time and space in the 1917 worst case. This SHOULD taken into consideration whenever an FSM is 1918 constructed using this algorithm, and MUST be when it is done 1919 dynamically by a user agent. Whenever an FSM is constructed by a 1920 process that is not under the direct supervision of a human user, 1921 procedures MUST be used to ensure that the processing and memory 1922 consumption are limited to acceptable amounts, and that if the FSM 1923 construction is aborted due to excessive consumption, the designated 1924 consumers of the FSM MUST have appropriate fallback procedures. 1926 9. IANA Considerations 1928 [Note to the RFC Editor: Per the instructions in BCP 26 section 9.1, 1929 please leave this section in the document (but remove this note).] 1931 This document has no IANA actions. 1933 10. Revision History 1935 [Note to RFC Editor: Please remove this entire section upon 1936 publication as an RFC.] 1938 10.1. Changes from draft-worley-alert-info-fsm-09 to draft-worley- 1939 alert-info-fsm-10 1941 Group the examples after the "very simple example" as subsections of 1942 a section. 1944 Add IANA considerations Section 9 and security considerations 1945 Section 8. 1947 10.2. Changes from draft-worley-alert-info-fsm-08 to draft-worley- 1948 alert-info-fsm-09 1950 Clarify that this algorithm is non-normative, as is the one in 1951 section 12 of RFC 7462, and implementations are free to choose any 1952 algorithm. 1954 10.3. Changes from draft-worley-alert-info-fsm-07 to draft-worley- 1955 alert-info-fsm-08 1957 Correct the discussion in the example of Section 5.6. 1959 Revamp the introduction. 1961 Use the term "resolve" for processing "alert" URNs to select a 1962 signal. 1964 10.4. Changes from draft-worley-alert-info-fsm-06 to draft-worley- 1965 alert-info-fsm-07 1967 Editorial improvements from independent submission reviewer. 1969 10.5. Changes from draft-worley-alert-info-fsm-05 to draft-worley- 1970 alert-info-fsm-06 1972 Editorial improvements from independent submission reviewer. 1974 Add note at end of introduction that you can do this by hand in 1975 simple cases. 1977 Add the country-code example. 1979 10.6. Changes from draft-worley-alert-info-fsm-04 to draft-worley- 1980 alert-info-fsm-05 1982 Editorial improvements. 1984 10.7. Changes from draft-worley-alert-info-fsm-03 to draft-worley- 1985 alert-info-fsm-04 1987 Editorial improvements. 1989 10.8. Changes from draft-worley-alert-info-fsm-02 to draft-worley- 1990 alert-info-fsm-03 1992 Correct indenting of some lines. 1994 10.9. Changes from draft-worley-alert-info-fsm-01 to draft-worley- 1995 alert-info-fsm-02 1997 Recast exposition to feature the implementation of the construction 1998 algorithm. 2000 10.10. Changes from draft-worley-alert-info-fsm-00 to draft-worley- 2001 alert-info-fsm-01 2003 Reorganized the text, including describing how the FSM states are 2004 constructed. 2006 11. References 2008 11.1. Normative References 2010 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2011 A., Peterson, J., Sparks, R., Handley, M., and E. 2012 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2013 DOI 10.17487/RFC3261, June 2002, 2014 . 2016 [RFC7462] Liess, L., Ed., Jesske, R., Johnston, A., Worley, D., and 2017 P. Kyzivat, "URNs for the Alert-Info Header Field of the 2018 Session Initiation Protocol (SIP)", RFC 7462, 2019 DOI 10.17487/RFC7462, March 2015, 2020 . 2022 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2023 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2024 May 2017, . 2026 11.2. Informative References 2028 [code] Worley, D., "draft-worley-alert-info-fsm.aux", February 2029 2017, . 2032 Acknowledgments 2034 Thanks to Paul Kyzivat, whose relentless identification of the 2035 weaknesses of earlier versions made the final document much, much 2036 better than it would have been, by changing it from the exposition of 2037 a concept into a practical tool. Thanks to Rifaat Shekh-Yusef, Eric 2038 Burger, and Gonzalo Camarillo for their thorough reviews. Thanks to 2039 the earlier Independent Submissions Editor, Nevil Brownlee, for his 2040 work obtaining reviewers, and the later Independent Submissions 2041 Editor, Adrian Farrel, for prompting me to write the Security 2042 Considerations section (which I had expected to be trivial, but was 2043 not). 2045 Author's Address 2047 Dale R. Worley 2048 Ariadne Internet Services 2049 738 Main St. 2050 Waltham, MA 02451 2051 US 2053 Email: worley@ariadne.com