idnits 2.17.1 draft-worley-alert-info-fsm-07.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC7462]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 296 has weird spacing: '... source urn:a...' == Line 339 has weird spacing: '...riority urn:...' == Line 863 has weird spacing: '... source urn...' == Line 865 has weird spacing: '... source urn...' == Line 868 has weird spacing: '... source urn:...' == (1 more instance...) -- The document date (February 23, 2017) is 2618 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 7 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 February 23, 2017 5 Expires: August 27, 2017 7 A Simpler Method for Processing Alert-Info URNs 8 draft-worley-alert-info-fsm-07 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. Based on the URNs in the Alert-Info header field, the 17 user agent must select the best available signal to present to its 18 user to indicate the characteristics of the call. This document 19 describes a method by which a user agent's designer can, based on the 20 user agent's signals and their meanings, construct a finite state 21 machine (FSM) to process the URNs to select a signal in a way that 22 obeys the restrictions given in the definition of the "alert" URN 23 namespace. In many situations, the resulting FSM is simpler and 24 faster than the selection algorithm described in [RFC7462]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 27, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Selecting the Signals and Their Corresponding "alert" URNs . 6 59 3. General Considerations for Processing Alert-Info . . . . . . 8 60 4. Constructing the Finite State Machine for a Very Simple 61 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 4.1. Listing the Expressed URNs . . . . . . . . . . . . . . . 10 63 4.2. Constructing the Alphabet . . . . . . . . . . . . . . . . 10 64 4.3. Constructing the States and Transitions . . . . . . . . . 12 65 4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 4.5. Examples of Processing Alert-Info URNs . . . . . . . . . 17 67 5. Example with "source" and "priority" URNs . . . . . . . . . . 19 68 6. Example 1 of RFC 7462 . . . . . . . . . . . . . . . . . . . . 23 69 7. Examples 2, 3, and 4 of RFC 7462 . . . . . . . . . . . . . . 28 70 8. An Example that Subsets Internal Sources . . . . . . . . . . 31 71 9. An Example of "alert:service" URNs . . . . . . . . . . . . . 32 72 10. An Example Using Country Codes . . . . . . . . . . . . . . . 32 73 11. Prioritizing Signals . . . . . . . . . . . . . . . . . . . . 37 74 12. Dynamic Sets of Signals . . . . . . . . . . . . . . . . . . . 39 75 13. Revision History . . . . . . . . . . . . . . . . . . . . . . 40 76 13.1. Changes from draft-worley-alert-info-fsm-06 to draft- 77 worley-alert-info-fsm-07 . . . . . . . . . . . . . . . . 41 78 13.2. Changes from draft-worley-alert-info-fsm-05 to draft- 79 worley-alert-info-fsm-06 . . . . . . . . . . . . . . . . 41 80 13.3. Changes from draft-worley-alert-info-fsm-04 to draft- 81 worley-alert-info-fsm-05 . . . . . . . . . . . . . . . . 41 82 13.4. Changes from draft-worley-alert-info-fsm-03 to draft- 83 worley-alert-info-fsm-04 . . . . . . . . . . . . . . . . 41 84 13.5. Changes from draft-worley-alert-info-fsm-02 to draft- 85 worley-alert-info-fsm-03 . . . . . . . . . . . . . . . . 41 86 13.6. Changes from draft-worley-alert-info-fsm-01 to draft- 87 worley-alert-info-fsm-02 . . . . . . . . . . . . . . . . 41 88 13.7. Changes from draft-worley-alert-info-fsm-00 to draft- 89 worley-alert-info-fsm-01 . . . . . . . . . . . . . . . . 41 90 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 91 14.1. Normative References . . . . . . . . . . . . . . . . . . 42 92 14.2. Informative References . . . . . . . . . . . . . . . . . 42 93 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 42 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42 96 1. Introduction 98 When a SIP user agent server receives an incoming INVITE request, it 99 chooses an alerting signal (the ring tone) to present to its user 100 (the called user) by processing the Alert-Info header field(s) in the 101 incoming INVITE request [RFC3261]. Similarly, a SIP user agent 102 client determines an alerting signal (the ringback tone) to present 103 to its user (the calling user) by processing the Alert-Info header 104 field(s) in the incoming provisional response(s) to its outgoing 105 INVITE request. 107 [RFC3261] envisioned that the Alert-Info header field value would be 108 a URL that the user agent could use to retrieve a signal. This usage 109 has security problems and is inconvenient to implement in practice. 110 [RFC7462] introduced an alternative practice: The Alert-Info values 111 could be URNs in the "alert" URN namespace which specify features of 112 the call or of the signal that should be signaled to the user. 113 [RFC7462] defined a large set of "alert" URNs and procedures for 114 extending the set. 116 However, a user agent is unlikely to provide alerting signals that 117 can explicitly render more than a small subset of the possible 118 combinations of "alert" URNs, so the user agent is frequently 119 required to select an alerting signal which renders only a subset of 120 the information in the Alert-Info header field(s). The requirements 121 for the process of selecting an alerting signal based on "alert" URNs 122 are given in section 11.1 of [RFC7462] and can be described as 123 follows: 125 The "alert" URNs are processed from left to right. Each "alert" 126 URN has precedence over all URNs that follow it, and its 127 interpretation is subordinate to all URNs that precede it. 129 As each URN is processed, one of the UA's signals is chosen which 130 expresses that URN as far as can be done without reducing the 131 degree to which any of the preceding URNs were expressed by the 132 signal chosen for the preceding URN. Thus, as processing 133 proceeds, the chosen signals become increasingly specific and 134 contain more information, but all of the information about a 135 particular URN that is expressed by the signal chosen for that URN 136 is also expressed by the signals chosen for all following URNs. 138 If the entirety of the current URN cannot be expressed by any 139 allowed signal, then in turn, each of the trailing alert-ind-parts 140 (the sections separated by colons) is removed until the reduced 141 URN can be expressed by some signal which also expresses at least 142 the same reduced versions of the preceding URNs that were 143 expressed by the signal chosen for the preceding URN. This can be 144 described as "a signal that expresses as much of the current URN 145 as possible while still expressing as much of the previous URNs as 146 the preceding signal did." 148 So, for instance, consider processing 150 Alert-Info: urn:alert:category-a:part-a1:part-a2, 151 urn:alert:category-b:part-b1:part-b2 153 If the UA has no signal for urn:alert:category-a:part-a1:part-a2, it 154 removes part-a2 from the URN and checks whether it has a signal for 155 the less-specific URN urn:alert:category-a:part-a1. If it has no 156 signal for that URN, it gives up on the URN entirely (since 157 urn:alert:category-a doesn't exist, and can be considered to express 158 nothing about the call), and the chosen signal is the default signal 159 of the UA, the signal that is used when there is no Alert-Info. 161 But let us suppose the UA has a signal for urn:alert:category-a:part- 162 a1, and chooses that signal when processing the first URN. All 163 processing after this point will be restricted to signals that 164 express urn:alert:category-a:part-a1, or a more specific URN of the 165 category category-a. 167 The UA then goes on to examine the next URN, urn:alert:category- 168 b:part-b1:part-b2. If there is a signal that expresses both 169 urn:alert:category-a:part-a1 and urn:alert:category-b:part-b1:part- 170 b2, then the UA chooses that signal. If there is no such signal, the 171 second URN is reduced to urn:alert:category-b:part-b1, and the UA 172 checks for a signal that expresses that URN along with 173 urn:alert:category-a:part-a1. If there is no such signal that 174 matches that relaxed requirement, the second URN is reduced to 175 urn:alert:category-b, which is discarded, and the chosen signal for 176 the first URN is chosen for the second URN. In any case, all 177 processing after this point will be restricted to signals that 178 express urn:alert:category-a:part-a1 or a more specific URN of the 179 category category-a, and also express the chosen part of 180 urn:alert:category-b:part-b1:part-b2. 182 This process is continued until the last "alert" URN is processed; 183 the signal chosen for the last URN is the signal that the UA uses. 185 Section 12 of [RFC7462] gives one possible algorithm for selecting a 186 signal which satisfies the requirements of section 11.1. That 187 algorithm can be used regardless of the set of alerting signals that 188 the user agent provides and their specified meanings. This 189 demonstrates that the rules can always be satisfied. However, the 190 algorithm is complex and slow. 192 The purpose of this document is to describe an easier method for 193 selecting signals that conforms to section 11.1: Once the user agent 194 designer has chosen a set of signals and the URNs that they express, 195 a finite state machine is constructed that selects alerting signals 196 based on the URNs in the Alert-Info header field(s) in a SIP message. 198 o The designer selects the set of signals that the user agent 199 produces, matching each signal to the "alert" URN or the 200 combination of "alert" URNs which are the meaning carried by the 201 signal. 203 o Based on the user agent's signals and their meanings, the designer 204 constructs an "alphabet" containing a finite number of symbols; 205 each possible "alert" URN is mapped into one particular symbol. 207 o The designer constructs a finite state machine (FSM) whose input 208 is the alphabet of symbols and whose states describe information 209 extracted from the Alert-Info URNs. 211 o Each state of the FSM has an attached signal. Processing the 212 Alert-Info URNs will leave the FSM in some particular state; the 213 UA renders the signal that is attached to that final state. 215 To select a ring tone or ringback tone based on a SIP message, the 216 user agent processes the "alert" URNs in the Alert-Info header field 217 from left to right. Initially the FSM is in a designated initial 218 state. The user agent maps each successive URN into the 219 corresponding symbol, and then executes the state transition of the 220 FSM specified by the symbol. The state of the FSM after processing 221 the URNs determines which signal the user agent will render to the 222 user. 224 Note that the user agent generally has two FSMs, because a user agent 225 usually wants to signal different information in ring tones than it 226 signals in ringback tones. One FSM is used to select the ring tone 227 to render for an incoming INVITE request. The other FSM is used to 228 select the ringback tone to render based on an incoming provisional 229 response to an outgoing INVITE request. Both FSMs are constructed in 230 the same way, but the constructions are based on different lists of 231 signals and corresponding URNs. 233 All of the steps of the method after the designer has selected the 234 signals and their URNs are algorithmic, and the algorithm assures 235 that the operation of the FSM will satisfy the constraints of section 236 11.1 of [RFC7462]. An implementation of the algorithmic steps is 237 provided in [code]. 239 In simple situations, a suitable FSM or equivalent ad-hoc code can be 240 constructed by hand using ad-hoc analysis. Generally, this is only 241 practical in situations where a small number of alert categories and 242 alert indications are signaled and the categories interact in a 243 simple, uniform way. E.g., the examples in Section 5 and Section 6 244 could be constructed by ad-hoc analysis. But automatic processing is 245 valuable if the situation is too complicated to construct a correct 246 FSM by ad-hoc analysis, or if the set of signals will change too 247 frequently for human production to be economical. 249 2. Selecting the Signals and Their Corresponding "alert" URNs 251 The designer must select signals that the UA will generate and define 252 the meanings that the signals will have to the user. Based on this, 253 the designer determines for each signal the "alert" URN or 254 combination of "alert" URNs that indicate that meaning in SIP 255 messages, and consequently should elicit that signal from the UA. 257 For example, suppose the UA has a particular ring tone for calls from 258 an external source. A call from an exteral source is marked with the 259 URN urn:alert:source:external (specified in section 9 of [RFC7462]). 260 Thus, the table of signals includes: 262 Signal URN(s) 263 ---------------------------- ------------------------------- 264 external source urn:alert:source:external 266 Similarly, if the UA has a particular ring tone for calls from an 267 internal source, the table includes: 269 Signal URN(s) 270 ---------------------------- ------------------------------- 271 internal source urn:alert:source:internal 273 If the UA has ring tones for calls that are marked as having higher 274 or lower priority, then the table includes: 276 Signal URN(s) 277 ---------------------------- ------------------------------- 278 high priority urn:alert:priority:high 279 low priority urn:alert:priority:low 281 Note that the UA must be able to signal for a message that has no 282 "alert" URNs in the Alert-Info header field, which means that there 283 must always be a default signal which has zero corresponding URNs: 285 Signal URN(s) 286 ---------------------------- ------------------------------- 287 default (none) 289 A signal can be defined to indicate a combination of conditions. For 290 instance, a signal that is used only for high-priority, internal- 291 source calls expresses two URNs, and will only be used when both URNs 292 are present in Alert-Info: 294 Signal URN(s) 295 ------------------------------ ------------------------------- 296 high priority, internal source urn:alert:priority:high, 297 urn:alert:source:internal 299 A signal can be defined to cover a number of related conditions by 300 specifying a URN that is the common prefix of the URNs for the 301 various conditions. For instance, the URNs for "recall due to 302 callback", "recall due to call hold", and "recall due to transfer" 303 all start with urn:alert:service:recall, and so one signal can be 304 provided for all of them by: 306 Signal URN(s) 307 ---------------------------- ------------------------------- 308 recall urn:alert:service:recall 310 But if a specific signal is also provided for "recall due to 311 callback" by this entry: 313 Signal URN(s) 314 ---------------------------- ------------------------------- 315 recall generally urn:alert:service:recall 316 recall due to callback urn:alert:service:recall:callback 318 then if the message contains urn:alert:service:recall:callback, the 319 "recall due to callback" signal will be chosen instead of "recall 320 generally" because the UA chooses the signal that most completely 321 expresses the information in the Alert-Info header field. 323 The designer may wish to define extension URNs that provide more 324 specific information about a call than the standard "alert" URNs do. 325 One method is to add additional components to standard URNs. For 326 instance, an extra-high priority could be indicated by the URN 327 urn:alert:priority:high:extra-high@example. The final "extra- 328 high@example" is an "alert-ind-part" that is a private extension. 329 (See sections 7 and 10.2 of [RFC7462] for a discussion of private 330 extensions.) In any case, adding an alert-ind-part to a URN makes 331 its meaning more specific, in that any call to which the longer URN 332 can be applied can also have the shorter URN applied. In this case, 333 "extra-high-priority calls" are considered a subset of "high-priority 334 calls". 336 Signal URN(s) 337 --------------------- ------------------------------- 338 high priority urn:alert:priority:high 339 extra high priority urn:alert:priority:high:extra@example.com 341 Of course, for this extension to be useful, the senders of SIP 342 messages (e.g., other UAs) must generate the extension URN in 343 suitable circumstances. 345 In some circumstances, the designer may want to create an entirely 346 new category of "alert" URNs to indicate a type of information that 347 is not indicated by any standard category of URNs. In that case, the 348 designer uses a private extension as the alert-category (the third 349 component of the URN), combined with whatever alert-ind-part (fourth 350 component) values are desired. For example, a simplified version of 351 the U.S. military security designations could be: 353 Signal URN(s) 354 ----------------------- ------------------------------- 355 unclassified urn:alert:security@example:unclassified 356 confidential urn:alert:security@example:confidential 357 secret urn:alert:security@example:secret 358 top-secret urn:alert:security@example:top-secret 360 The designer should ensure that the new alert-category is orthogonal 361 to all defined standard alert-categories, in that any combination of 362 one of the new URNs with one of the standard URNs is meaningful in 363 that there could be a message carrying both URNs. 365 In addition, the set of alert-ind-parts for the new alert-category 366 should be comprehensive and disjoint, in that every message can be 367 described by exactly one of them. 369 3. General Considerations for Processing Alert-Info 371 In this section, we will discuss various considerations which arise 372 when processing Alert-Info. These have to be taken care of properly 373 in order to conform to the standards, as well as to endure a good 374 user experience. But since they are largely independent of the 375 generated finite state machine and its processing, they are gathered 376 here in a seperate section. 378 The UA may have a number of different finite state machines (FSMs) 379 for processing URNs. Generally, there will be different FSMs for 380 processing Alert-Info in incoming INVITE requests and for incoming 381 provisional responses to outgoing INVITE requests. But any situation 382 that changes the set of signals that the UA is willing to generate 383 specifies a different set of signals and corresponding URNs, and thus 384 generates a different FSM. For example, if a call is active on the 385 UA, all audible signals may become unavailable, or audible signals 386 may be available only if urn:alert:priority:high is specified. 388 Similarly, if the set of signals is customized by user action or 389 local policy, the generated FSM must be updated. This can be done by 390 regenerating it according to the method described here, or by 391 generating a "generic" FSM and instantiating it based on the 392 available signals. (See Section 12 for a discussion of this.) 394 Note that the values in an Alert-Info header field are allowed to be 395 URIs of any scheme, and within the "urn" scheme, are allowed to have 396 any namespace [RFC3261]. The processing of URIs that are not "alert" 397 URNs is not considered by this document, nor is that processing 398 specified by [RFC7462]. But the algorithm designer must consider 399 what to do with such URIs if they are encountered. The simplest 400 choice is to ignore them. Alternatively, the algorithm may examine 401 the URI to determine if it names an alerting signal or describes how 402 to retrieve an alerting signal, and if so, choose to render that 403 signal, rather than processing the "alert" URNs to select a signal. 404 In any case, the remainder of this document assumes that the signal 405 is to be chosen based on the "alert" URNs in Alert-Info, and that all 406 Alert-Info URIs that are not "alert" URNs have been removed. 408 The UA may also receive "alert" URNs that are semantically invalid in 409 various ways. E.g., the URN may have only three components, despite 410 that all valid "alert" URNs have at least one alert-ind-part, and 411 thus four components. The only useful strategy is to ignore such 412 URNs (and possibly log them for analysis). 414 The method described here is robust in its handling of categories and 415 alert-ind-parts which are unknown to the UA, and as a consequence, it 416 is also robust if they are not valid standardized URNs. Thus, these 417 error conditions need not be handled specially. 419 4. Constructing the Finite State Machine for a Very Simple Example 421 Constructing the FSM involves: 423 1. Listing the URNs which are expressed by the various signals of 424 the user agent. 426 2. From the expressed URNs, constructing the finite alphabet of 427 symbols into which input URNs are mapped and which drive the 428 state transitions of the FSM. 430 3. Constructing the states of the FSM and the transitions between 431 them. 433 4. Selecting a signal to be associated with each FSM state. 435 We will explain the process using a very simple example in which 436 there are two signals, one expressing "internal source" and one 437 expressing "external source", along with a default signal (for when 438 there is no source information to signal). The "internal source" 439 signal expresses urn:alert:source:internal, and the "external source" 440 signal expresses urn:alert:source:external. 442 4.1. Listing the Expressed URNs 444 The first step is to establish for each of the user agent's signals 445 what call characteristics it represents, which is to say, the set of 446 "alert" URNs which are its information content. 448 Signal URN(s) 449 ---------------------------- ------------------------------- 450 default (none) 451 internal source urn:alert:source:internal 452 external source urn:alert:source:external 454 From the totality of these expressed URNs, the designer can then 455 determine which sets of URNs must be distinguished from each other. 456 In our simple example, the expressed URNs are: 458 urn:alert:source:external 459 urn:alert:source:internal 461 4.2. Constructing the Alphabet 463 In order to reduce the infinite set of possible "alert" URNs to a 464 finite alphabet of input symbols which cause the FSM's transitions, 465 the designer must partition the "alert" URNs into a finite set of 466 categories. 468 Once we've listed all the expressed URNs, we can list all of the 469 alert-categories that are relevant to the user agent's signaling; 470 "alert" URNs in any other alert-category cannot affect the signaling 471 and can be ignored. (The easiest method to ignore the non-relevant 472 URNs is to skip over them during Alert-Info processing. A more 473 formal method is to map all of them into one "Other" symbol, and then 474 for each state of the FSM, have the Other symbol transition to that 475 same state.) 476 Within each relevant alert-category, we now define a distinct symbol 477 for every expressed URN and for all of their "ancestor" URNs (those 478 that can be created by removing one or more trailing alert-ind- 479 parts). In order to name the symbols in a way that distinguishes 480 them from the corresponding URNs, we remove the initial "urn:alert:" 481 and capitalize each alert-ind-part. Thus in our example, we get 482 these symbols: 484 Source 485 Source:External 486 Source:Internal 488 Note that there is a "Source" symbol even though there is no 489 corresponding URN. (urn:alert:source is not a valid URN -- see 490 [RFC7462] section 7 -- although the processing algorithm must be 491 prepared to screen out such a purported URN if it appears in the 492 Alert-Info header field.) However, its existance as a symbol will be 493 useful later when we construct the FSM. 495 For each of these symbols, we add a symbol that classifies URNs that 496 extend the symbol's corresponding URN with alert-ind-parts that 497 cannot be expressed by signals: 499 Source:Other 500 Source:External:Other 501 Source:Internal:Other 503 The latter two classify URNs like 504 urn:alert:source:external:foo@example, which extend URNs that we 505 already have symbols for. The first is for classifying URNs, such as 506 urn:alert:source:bar@example, which have first alert-ind-parts that 507 contradict all the "source" URNs that the user agent can signal. 509 These steps give us this set of symbols: 511 Source 512 Source:External 513 Source:External:Other 514 Source:Internal 515 Source:Internal:Other 516 Source:Other 518 We can then simplify the set of symbols by removing the ones like 519 Source:External:Other and Source:Internal:Other that consist of 520 adding "Other" to a symbol which corresponds to an expressed URN 521 which is not ancestral to any other expressed URNs. This works 522 because adding further alert-ind-parts to a URN which is a leaf in 523 regard to the set of signals has no additional effect. In this 524 example, urn:alert:source:external:foo@example has the same effect as 525 urn:alert:source:external, both for causing a signal to be chosen as 526 well as for suppressing the effect of later URNs. 528 This leaves the following symbols for the "source" category: 530 Source 531 Source:External 532 Source:Internal 533 Source:Other 535 These can be visually summarized by showing the infinite tree of 536 possible source "alert" URNs and how it is partitioned into subtrees 537 that map to each of these symbols. We also mark with "*" the 538 expressed URNs. 540 urn:alert 541 | 542 { | } 543 { source } --> 1 544 { | } 545 | 546 +--------------------+------------------+ 547 | | | 548 { | } { | } { | } 549 { external* } --> 2 { internal* } --> 3 { ... } --> 4 550 { | } { | } { } 551 { ... } { ... } 552 { } { } 554 1 = Source 555 2 = Source:External 556 3 = Source:Internal 557 4 = Source:Other 559 4.3. Constructing the States and Transitions 561 The user agent processes the Alert-Info URNs left-to-right using a 562 finite state machine (FSM), with each successive URN causing the FSM 563 to transition to a new state. Each state of the FSM records the 564 information which has so far been extracted from the URNs. The state 565 of the FSM after processing all the URNs determines which signal the 566 user agent will render to the user. 568 We label each state with a set of symbols, one from each relevant 569 category, which describe the information that's been extracted from 570 all of the URNs that have so far been processed. The initial state 571 is labeled with the "null" symbols that are just the category names, 572 because no information has yet been recorded. In our simple example, 573 the initial state is labeled "Source", since that's the only relevant 574 category. 576 State: Source (initial state) 578 Each state has a corresponding alerting signal, which is the signal 579 that the user agent will produce when URN processing leaves the FSM 580 in that state. The signal is the one that best expresses the 581 information that has been extracted from the URNs. Usually the 582 choice of signal is obvious to the designer, but there are certain 583 constraints that the choice must satisfy. The main constraint is 584 that the signal's expressed URNs must be semantic supersets of (i.e., 585 identical to or a prefix of) the URNs corresponding to the symbols in 586 the state's label. In particular, if the expressed URN of the signal 587 in a certain category is shorter than the state's label, we show that 588 in the state's name by putting parentheses around the trailing part 589 of the symbol that is not expressed by the signal. For instance, if 590 the symbol in the label is "Source:External" but the signal only 591 expresses "Source" (i.e., no "source" URN at all), then the symbol in 592 the label is modified to be "Source:(External)". 594 The reason for this unintuitive construction is that in some states, 595 the FSM has recorded information that the chosen signal cannot 596 express. 598 Note that the parentheses are part of the state name, so in some 599 circumstances there may be two or more distinct states labeled with 600 the same symbols, but with different placement of parentheses within 601 the symbols. These similar state names are relevant when the FSM can 602 record information from multiple "alert" URNs but cannot express all 603 of them -- depending on the order in which the URNs appear, the UA 604 may have to render different signals, so it needs states that record 605 the same information but render different subsets of that 606 information. 608 The initial state's label is the string of null symbols for the 609 relevant categories, so the only allowed signal is the default 610 signal, which expresses no URNs: 612 State: Source (initial state) 613 Signal: default 615 From each state, we must construct the transition for each possible 616 input symbol. For a particular state and symbol, we construct the 617 label of the destination state by combining the input symbol with the 618 symbol in the start state's label for the same category. If one of 619 the symbols is a prefix of the other, we select the longer one; if 620 not, we select the symbol in the start state's label. 622 Thus, in our simple example, the initial state has the following 623 transitions: 625 State: Source (initial state) 626 Signal: default 627 Transitions: 628 Source:External -> Source:External 629 Source:Internal -> Source:Internal 630 Source:Other -> Source:Other 632 In all of these transitions, the input symbol is compatible with the 633 matching label of the state, "Source", so the destination state's 634 label is the full input symbol. 636 However, there is a further constraint on the destination state: Its 637 signal must express URNs that at least contain the expressed URNs of 638 the signal of the start state. Within that constraint, and being 639 compatible with the destination state's label, for the category of 640 the input URN, the destination state's signal must express the 641 longest URN that can be expressed by any signal. 643 In our example, this means that the destination Source:External state 644 has the "external source" signal, which expresses 645 urn:alert:source:external. Since that signal expresses all of the 646 state's label, it is the chosen state. Similarly, the destination 647 Source:Internal state has the "internal source" signal. But for the 648 transition on input Source:Other, the "Source:Other" state must have 649 the default signal, as there is no signal that expresses 650 urn:alert:source:[some-unknown-alert-ind-part]. So the destination 651 state is "Source:(Other)", where the parentheses record that the 652 "Other" part of the label is not expressed by the state's signal. 654 Thus, the initial state and the states it can transition to are: 656 State: Source (initial state) 657 Signal: default 658 Transitions: 659 Source:External -> Source:External 660 Source:Internal -> Source:Internal 661 Source:Other -> Source:(Other) 663 State: Source:External 664 Signal: external source (urn:alert:source:external) 666 State: Source:Internal 667 Signal: internal source (urn:alert:source:internal) 669 State: Source:(Other) 670 Signal: default 672 Looking at the state Source:External, we see that it is incompatible 673 with all input symbols other than Source:External, and thus all of 674 its transitions are to itself: 676 State: Source:External 677 Signal: external source (urn:alert:source:external) 678 Transitions: 679 Source:External -> Source:External 680 Source:Internal -> Source:External 681 Source:Other -> Source:External 683 and similarly: 685 State: Source:Internal 686 Signal: internal source (urn:alert:source:internal) 687 Transitions: 688 Source:External -> Source:Internal 689 Source:Internal -> Source:Internal 690 Source:Other -> Source:Internal 692 State: Source:(Other) 693 Signal: default 694 Transitions: 695 Source:External -> Source:(Other) 696 Source:Internal -> Source:(Other) 697 Source:Other -> Source:(Other) 699 4.4. Summary 701 The FSM can be constructed by processing the file "very-simple.txt" 702 with the program "alert-info-fsm.py" in [code]. The program's output 703 shows the stages of the construction, which are: 705 1. The signals have the meanings: 707 Signal URN(s) 708 ---------------------------- ------------------------------- 709 default (none) 710 internal source urn:alert:source:internal 711 external source urn:alert:source:external. 713 2. The expressed URNs are 715 urn:alert:source:external 716 urn:alert:source:internal 718 3. The relevant categories of "alert" URNs are only: 720 source 722 4. Thus, the infinite universe of possible "alert" URNs can be 723 reduced to these symbols, which are the categories of URNs that 724 are different in ways that are significant to the resolution 725 process: 727 Source 728 Source:External 729 Source:Internal 730 Source:Other 732 5. The FSM is: 734 State: Source (initial state) 735 Signal: default 736 Transitions: 737 Source:External -> Source:External 738 Source:Internal -> Source:Internal 739 Source:Other -> Source:(Other) 741 State: Source:External 742 Signal: external source (urn:alert:source:external) 743 Transitions: 744 Source:External -> Source:External 745 Source:Internal -> Source:External 746 Source:Other -> Source:External 748 State: Source:Internal 749 Signal: internal source (urn:alert:source:internal) 750 Transitions: 751 Source:External -> Source:Internal 752 Source:Internal -> Source:Internal 753 Source:Other -> Source:Internal 755 State: Source:(Other) 756 Signal: default 757 Transitions: 758 Source:External -> Source:(Other) 759 Source:Internal -> Source:(Other) 760 Source:Other -> Source:(Other) 762 * Each state is labeled by a set of symbols which describe the 763 information which has been extracted from the URNs so far. 765 * Each state has a signal which is a semantic superset of the 766 state's label, i.e., the signal's expressed URNs match the 767 initial portion of the label symbols. If Alert-Info 768 processing finishes with the FSM in a state, the user agent 769 will render the state's signal to the user. 771 * The state's label is marked to show what subset of the symbols 772 are expressed by the state's signal. Two states can have the 773 same label but different signals. 775 * If a transition's input symbol is compatible with (is a 776 semantic subset) of the start state's label for that category, 777 the destination state's label is updated with the input 778 symbol. If not, the destination state is the start state. 779 This is how the state's label records what information has 780 been accumulated while processing the Alert-Info URNs. 782 * A transition's destination state has a signal which 783 semantically subsets the start state's signal as much as 784 possible in the category of the input symbol. (In most cases, 785 the choice of signal is unique. In rare cases there may be 786 more than one signal that meets this criterion, so the 787 designer may have some flexibility.) 789 4.5. Examples of Processing Alert-Info URNs 791 In the trivial case where the user agent receives no Alert-Info URNs, 792 then processing begins and ends with the FSM in the initial state and 793 selects the default signal. 795 If the user agent receives 796 Alert-Info: 798 then processing progresses: 800 State: Source 801 Process: Source:Internal (urn:alert:source:internal) 802 State: Source:Internal 803 Signal: internal source 805 If the user agent receives 807 Alert-Info: , 808 810 then processing progresses: 812 State: Source 813 Process: Source:External (urn:alert:source:external) 814 State: Source:External 815 Process: Source:Internal (urn:alert:source:internal) 816 State: Source:External 817 Signal: external source 819 If the user agent receives 821 Alert-Info: , 822 824 then processing progresses: 826 State: Source 827 Process: Source:Other (urn:alert:source:unclassified) 828 State: Source:(Other) 829 Process: Source:Internal (urn:alert:source:internal) 830 State: Source:(Other) 831 Signal: default 833 If the user agent receives 835 Alert-Info: , 836 838 then processing progresses: 840 State: Source 841 Ignore: urn:alert:priority:high 842 State: Source 843 Process: Source:Internal (urn:alert:source:internal) 844 State: Source:Internal 845 Signal: internal source 847 5. Example with "source" and "priority" URNs 849 Now consider an example where the user agent can signal "external 850 source", "internal source", "low priority", and "high priority" 851 individually or in any combination of source and priority, along with 852 a default signal. This example is essentially the cartesian product 853 of two copies of the example in Section 4, one dealing with the 854 call's source and one dealing with the call's priority. So there is 855 a total of 9 signals: 857 Signal URN(s) 858 ---------------------------- ------------------------------- 859 default (none) 860 external source urn:alert:source:external 861 internal source urn:alert:source:internal 862 low priority urn:alert:priority:low 863 low priority/external source urn:alert:priority:low, 864 urn:alert:source:external 865 low priority/internal source urn:alert:priority:low, 866 urn:alert:source:internal 867 high priority urn:alert:priority:high 868 high priority/external source urn:alert:priority:high, 869 urn:alert:source:external 870 high priority/internal source urn:alert:priority:high, 871 urn:alert:source:internal 873 The expressed URNs are: 875 urn:alert:source:external 876 urn:alert:source:internal 877 urn:alert:priority:low 878 urn:alert:priority:high 880 The relevant categories of "alert" URNs are only: 882 source 883 priority 885 The alphabet of symbols is: 887 Source 888 Source:External 889 Source:Internal 890 Source:Other 891 Priority 892 Priority:Low 893 Priority:High 894 Priority:Other 896 The 16 states are as follows, where 10 states have a simple structure 897 because from them, no further information can be recorded. 899 State: Priority/Source 900 Signal: default 901 Transitions: 902 Priority:Other -> Priority:(Other)/Source 903 Priority:High -> Priority:High/Source 904 Priority:Low -> Priority:Low/Source 905 Source:Other -> Priority/Source:(Other) 906 Source:External -> Priority/Source:External 907 Source:Internal -> Priority/Source:Internal 909 State: Priority:(Other)/Source 910 Signal: default 911 Transitions: 912 Priority:Other -> Priority:(Other)/Source 913 Priority:High -> Priority:(Other)/Source 914 Priority:Low -> Priority:(Other)/Source 915 Source:Other -> Priority:(Other)/Source:(Other) 916 Source:External -> Priority:(Other)/Source:External 917 Source:Internal -> Priority:(Other)/Source:Internal 919 State: Priority:(Other)/Source:(Other) 920 Signal: default 921 Transitions: 922 any -> Priority:(Other)/Source:(Other) 924 State: Priority:(Other)/Source:External 925 Signal: external source 926 Transitions: 927 any -> Priority:(Other)/Source:External 929 State: Priority:(Other)/Source:Internal 930 Signal: internal source 931 Transitions: 932 any -> Priority:(Other)/Source:Internal 934 State: Priority:High/Source 935 Signal: high priority 936 Transitions: 937 Priority:Other -> Priority:High/Source 938 Priority:High -> Priority:High/Source 939 Priority:Low -> Priority:High/Source 940 Source:Other -> Priority:High/Source:(Other) 941 Source:External -> Priority:High/Source:External 942 Source:Internal -> Priority:High/Source:Internal 944 State: Priority:High/Source:(Other) 945 Signal: high priority 946 Transitions: 947 any -> Priority:High/Source:(Other) 949 State: Priority:High/Source:External 950 Signal: high priority/external source 951 Transitions: 952 any -> Priority:High/Source:External 954 State: Priority:High/Source:Internal 955 Signal: high priority/internal source 956 Transitions: 957 any -> Priority:High/Source:Internal 959 State: Priority:Low/Source 960 Signal: low priority 961 Transitions: 962 Priority:Other -> Priority:Low/Source 963 Priority:High -> Priority:Low/Source 964 Priority:Low -> Priority:Low/Source 965 Source:Other -> Priority:Low/Source:(Other) 966 Source:External -> Priority:Low/Source:External 967 Source:Internal -> Priority:Low/Source:Internal 969 State: Priority:Low/Source:(Other) 970 Signal: low priority 971 Transitions: 972 any -> Priority:Low/Source:(Other) 974 State: Priority:Low/Source:External 975 Signal: low priority/external source 976 Transitions: 977 any -> Priority:Low/Source:External 979 State: Priority:Low/Source:Internal 980 Signal: low priority/internal source 981 Transitions: 982 any -> Priority:Low/Source:Internal 984 State: Priority/Source:(Other) 985 Signal: default 986 Transitions: 987 Priority:Other -> Priority:(Other)/Source:(Other) 988 Priority:High -> Priority:High/Source:(Other) 989 Priority:Low -> Priority:Low/Source:(Other) 990 Source:Other -> Priority/Source:(Other) 991 Source:External -> Priority/Source:(Other) 992 Source:Internal -> Priority/Source:(Other) 994 State: Priority/Source:External 995 Signal: external source 996 Transitions: 997 Priority:Other -> Priority:(Other)/Source:External 998 Priority:High -> Priority:High/Source:External 999 Priority:Low -> Priority:Low/Source:External 1000 Source:Other -> Priority/Source:External 1001 Source:External -> Priority/Source:External 1002 Source:Internal -> Priority/Source:External 1004 State: Priority/Source:Internal 1005 Signal: internal source 1006 Transitions: 1007 Priority:Other -> Priority:(Other)/Source:Internal 1008 Priority:High -> Priority:High/Source:Internal 1009 Priority:Low -> Priority:Low/Source:Internal 1010 Source:Other -> Priority/Source:Internal 1011 Source:External -> Priority/Source:Internal 1012 Source:Internal -> Priority/Source:Internal 1014 An example of processing that involves multiple "source" URNs and one 1015 "priority" URN: 1017 Alert-Info: , 1018 , 1019 1021 State: Source/Priority 1022 Process: Source:Internal (urn:alert:source:internal) 1023 State: Source:Internal/Priority 1024 Process: Source:(Other) (urn:alert:source:unclassified) 1025 State: Source:Internal/Priority 1026 Process: Priority:High (urn:alert:priority:high) 1027 State: Source:Internal/Priority:High 1028 Signal: internal source/high priority 1030 6. Example 1 of RFC 7462 1032 A more complicated example is in section 12.2.1 of [RFC7462]. It is 1033 like the example in Section 5 of this document, except that the user 1034 agent can only signal "external source", "internal source", "low 1035 priority", and "high priority" individually but not in combination, 1036 as well as a default signal: 1038 Signal URN(s) 1039 ---------------------------- ------------------------------- 1040 default (none) 1041 internal source urn:alert:source:external 1042 external source urn:alert:source:internal 1043 high low urn:alert:priority:low 1044 high priority urn:alert:priority:high 1046 The signals can express the following URNs: 1048 urn:alert:source:external 1049 urn:alert:source:internal 1050 urn:alert:priority:low 1051 urn:alert:priority:high 1053 The relevant categories of "alert" URNs are: 1055 source 1056 priority 1058 The alphabet of symbols is: 1060 Source 1061 Source:External 1062 Source:Internal 1063 Source:Other 1064 Priority 1065 Priority:Low 1066 Priority:High 1067 Priority:Other 1069 In this example, the FSM has 20 states because both "source" and 1070 "priority" URNs are recorded, but the order in which the two appear 1071 affects the signal: 1073 State: Priority/Source 1074 Signal: default 1075 Transitions: 1076 Priority:Other -> Priority:(Other)/Source 1077 Priority:High -> Priority:High/Source 1078 Priority:Low -> Priority:Low/Source 1079 Source:Other -> Priority/Source:(Other) 1080 Source:External -> Priority/Source:External 1081 Source:Internal -> Priority/Source:Internal 1083 State Priority:(Other)/Source can transition to states that can 1084 signal source, because the recorded priority can't be signaled and 1085 thus does not block the signalling of the source: 1087 State: Priority:(Other)/Source 1088 Signal: default 1089 Transitions: 1090 Priority:Other -> Priority:(Other)/Source 1091 Priority:High -> Priority:(Other)/Source 1092 Priority:Low -> Priority:(Other)/Source 1093 Source:Other -> Priority:(Other)/Source:(Other) 1094 Source:External -> Priority:(Other)/Source:External 1095 Source:Internal -> Priority:(Other)/Source:Internal 1097 State: Priority:(Other)/Source:(Other) 1098 Signal: default 1099 Transitions: 1100 any -> Priority:(Other)/Source:(Other) 1102 State: Priority:(Other)/Source:External 1103 Signal: external source 1104 Transitions: 1105 any -> Priority:(Other)/Source:External 1107 State: Priority:(Other)/Source:Internal 1108 Signal: internal source 1109 Transitions: 1110 any -> Priority:(Other)/Source:Internal 1112 Because there are no signals for combinations of "source" and 1113 "priority" URNs, processing a "source" URN from the state 1114 Priority:High/Source leads to a state that records the priority 1115 information, but does not signal it: 1117 State: Priority:High/Source 1118 Signal: high priority 1119 Transitions: 1120 Priority:Other -> Priority:High/Source 1121 Priority:High -> Priority:High/Source 1122 Priority:Low -> Priority:High/Source 1123 Source:Other -> Priority:High/Source:(Other) 1124 Source:External -> Priority:High/Source:(External) 1125 Source:Internal -> Priority:High/Source:(Internal) 1127 State: Priority:High/Source:(Other) 1128 Signal: high priority 1129 Transitions: 1130 any -> Priority:High/Source:(Other) 1132 From the state Priority:High/Source, "source" URNs transition to 1133 states that record both source and priority but signal only priority, 1134 one of which is Priority:High/Source:(External). But from Priority/ 1135 Source:External, the symbol Priority:High transitions to the state 1136 Priority:(High)/Source:External, which records the same information 1137 but signals the source, not the priority. -- One state is reached by 1138 processing a "priority" URN and then a "source" URN, whereas the 1139 other is reached by processing a "source" URN and then a "priority" 1140 URN. 1142 State: Priority:High/Source:(External) 1143 Signal: high priority 1144 Transitions: 1145 any -> Priority:High/Source:(External) 1147 State: Priority:High/Source:(Internal) 1148 Signal: high priority 1149 Transitions: 1150 any -> Priority:High/Source:(Internal) 1152 And similarly for Priority:Low/Source: 1154 State: Priority:Low/Source 1155 Signal: low priority 1156 Transitions: 1157 Priority:Other -> Priority:Low/Source 1158 Priority:High -> Priority:Low/Source 1159 Priority:Low -> Priority:Low/Source 1160 Source:Other -> Priority:Low/Source:(Other) 1161 Source:External -> Priority:Low/Source:(External) 1162 Source:Internal -> Priority:Low/Source:(Internal) 1164 State: Priority:Low/Source:(Other) 1165 Signal: low priority 1166 Transitions: 1167 any -> Priority:Low/Source:(Other) 1169 State: Priority:Low/Source:(External) 1170 Signal: low priority 1171 Transitions: 1172 any -> Priority:Low/Source:(External) 1174 State: Priority:Low/Source:(Internal) 1175 Signal: low priority 1176 Transitions: 1177 any -> Priority:Low/Source:(Internal) 1179 State: Priority/Source:(Other) 1180 Signal: default 1181 Transitions: 1182 Priority:Other -> Priority:(Other)/Source:(Other) 1183 Priority:High -> Priority:High/Source:(Other) 1184 Priority:Low -> Priority:Low/Source:(Other) 1185 Source:Other -> Priority/Source:(Other) 1186 Source:External -> Priority/Source:(Other) 1187 Source:Internal -> Priority/Source:(Other) 1189 State: Priority/Source:External 1190 Signal: external source 1191 Transitions: 1192 Priority:Other -> Priority:(Other)/Source:External 1193 Priority:High -> Priority:(High)/Source:External 1194 Priority:Low -> Priority:(Low)/Source:External 1195 Source:Other -> Priority/Source:External 1196 Source:External -> Priority/Source:External 1197 Source:Internal -> Priority/Source:External 1199 State: Priority:(High)/Source:External 1200 Signal: external source 1201 Transitions: 1202 any -> Priority:(High)/Source:External 1204 State: Priority:(Low)/Source:External 1205 Signal: external source 1206 Transitions: 1207 any -> Priority:(Low)/Source:External 1209 State: Priority/Source:Internal 1210 Signal: internal source 1211 Transitions: 1212 Priority:Other -> Priority:(Other)/Source:Internal 1213 Priority:High -> Priority:(High)/Source:Internal 1214 Priority:Low -> Priority:(Low)/Source:Internal 1215 Source:Other -> Priority/Source:Internal 1216 Source:External -> Priority/Source:Internal 1217 Source:Internal -> Priority/Source:Internal 1219 State: Priority:(High)/Source:Internal 1220 Signal: internal source 1221 Transitions: 1222 any -> Priority:(High)/Source:Internal 1224 State: Priority:(Low)/Source:Internal 1225 Signal: internal source 1226 Transitions: 1227 any -> Priority:(Low)/Source:Internal 1229 As an example of processing, if the user agent receives 1231 Alert-Info: 1233 then processing progresses: 1235 State: Priority/Source 1236 Process: Source:Internal (urn:alert:source:internal) 1237 State: Priority/Source:Internal 1238 Signal: internal source 1240 A more complicated example involves multiple "source" URNs which do 1241 not select a non-default signal and one "priority" URN which can be 1242 signaled: 1244 Alert-Info: , 1245 , 1246 1248 State: Priority/Source 1249 Process: Source:Other (urn:alert:source:unclassified) 1250 State: Priority/Source:(Other) 1251 Process: Source:Internal (urn:alert:source:internal) 1252 State: Priority/Source:(Other) 1253 Process: Priority:High (urn:alert:priority:high) 1254 State: Priority:High/Source:(Other) 1255 Signal: high priority 1257 Since the only characteristic of a state that affects the output of 1258 the FSM is the state's signal, several groups of states in this FSM 1259 can be merged using standard FSM optimization algorithms: 1261 states with signal "high priority": 1262 Priority:High/Source 1263 Priority:High/Source:(Other) 1264 Priority:High/Source:(External) 1265 Priority:High/Source:(Internal) 1267 states with signal "low priority": 1268 Priority:Low/Source 1269 Priority:Low/Source:(Other) 1270 Priority:Low/Source:(External) 1271 Priority:Low/Source:(Internal) 1273 states with signal "external source": 1274 Priority/Source:External 1275 Priority:(High)/Source:External 1276 Priority:(Low)/Source:External 1277 Priority:(Other)/Source:External 1279 states with signal "internal source": 1280 Priority/Source:Internal 1281 Priority:(High)/Source:Internal 1282 Priority:(Low)/Source:Internal 1283 Priority:(Other)/Source:Internal 1285 This reduces the FSM to 7 states. 1287 7. Examples 2, 3, and 4 of RFC 7462 1289 Examples 2, 3, and 4 of [RFC7462] are similar to the example in 1290 Section 5, but they do not include a signal for the combination 1291 "internal source, low priority" to make resolution examples work 1292 asymmetrically. 1294 The FSM for this example has the same alphabet as the FSM of 1295 Section 5. Most of the states of this FSM are the same as the states 1296 of the FSM of Section 5, but the state Source:Internal/Priority:Low 1297 is missing because there is no signal for that combination. It is 1298 replaced by two states: One state is Source:Internal/Priority:(Low); 1299 it records that Source:Internal was specified first (and is to be 1300 signaled) and that Priority:Low was specified later (and can not be 1301 signaled -- but it still prevents any further "priority" URN from 1302 having an effect). The other state is 1303 Source:(Internal)/Priority:Low; it records the reverse sequence of 1304 events. 1306 The changes in the FSM are: 1308 State: Priority:Low/Source 1309 Signal: low priority 1310 Transitions: 1311 Source:Internal -> Priority:Low/Source:(Internal) 1312 (other transitions unchanged) 1314 State: Priority:Low/Source:(Internal) 1315 Signal: low priority 1316 Transitions: 1317 any -> Priority:Low/Source:(Internal) 1319 State: Priority/Source:Internal 1320 Signal: internal source 1321 Transitions: 1322 Priority:Low -> Priority:(Low)/Source:Internal 1323 (other transitions unchanged) 1325 State: Priority:(Low)/Source:Internal 1326 Signal: internal source 1327 Transitions: 1328 any -> Priority:(Low)/Source:Internal 1330 An example of processing that involves multiple "source" URNs and one 1331 "priority" URN: 1333 Alert-Info: , 1334 , 1335 1337 State: Priority/Source 1338 Process: Source:Internal (urn:alert:source:internal) 1339 State: Priority/Source:Internal 1340 Process: Source:Other (urn:alert:source:unclassified) 1341 State: Priority/Source:Internal 1342 Process: Priority:High (urn:alert:priority:high) 1343 State: Priority:High/Source:Internal 1344 Signal: internal source/high priority 1346 If the user agent receives 1348 Alert-Info: 1350 State: Priority/Source 1351 Process: Source:Internal (urn:alert:source:internal) 1352 State: Priority/Source:Internal 1353 Signal: internal source 1355 If the user agent receives 1357 Alert-Info: , 1358 1360 State: Priority/Source 1361 Process: Source:External (urn:alert:source:external) 1362 State: Priority/Source:External 1363 Process: Priority:Low (urn:alert:priority:low) 1364 State: Priority:Low/Source:External 1365 Signal: external source/low priority 1367 Suppose the same user agent receives 1369 Alert-Info: , 1370 1372 Note that there is no signal that corresponds to this combination. 1373 In that case, the processing is: 1375 State: Priority/Source 1376 Process: Source:Internal (urn:alert:source:internal) 1377 State: Priority/Source:Internal 1378 Process: Priority:Low (urn:alert:priority:low) 1379 State: Priority:(Low)/Source:Internal 1380 Signal: internal source 1382 If the order of the URNs is reversed, what is signaled is the meaning 1383 of now-different first URN: 1385 Alert-Info: , 1386 1388 State: Priority/Source 1389 Process: Priority:Low (urn:alert:priority:low) 1390 State: Priority:Low/Source 1391 Process: Source:Internal (urn:alert:source:internal) 1392 State: Priority:Low/Source:(Internal) 1393 Signal: low priority 1395 Notice that the existence of the new states prevents later URNs of a 1396 category from overriding earlier URNs of that category, even if the 1397 earlier one was not itself signalable and the later one would be 1398 signalable in the absence of the earlier one: 1400 Alert-Info: , 1401 , 1402 1404 State: Priority/Source 1405 Process: Priority:Low (urn:alert:priority:low) 1406 State: Priority:Low/Source 1407 Process: Source:Internal (urn:alert:source:internal) 1408 State: Priority:Low/Source:(Internal) 1409 Process: Source:External (urn:alert:source:external) 1410 State: Priority:Low/Source:(Internal) 1411 Signal: low priority 1413 This situation shows the necessity of states whose labels contain 1414 parentheses. If the second transition had been to the state 1415 Priority:Low/Source (on the basis that there is no proper state 1416 Priority:Low/Source:Internal), then the third transition would have 1417 been to the state Priority:Low/Source:External, and the signal would 1418 have been "external source/low priority". 1420 8. An Example that Subsets Internal Sources 1422 In the example of Section 4, there are signals for "external source" 1423 and "internal source". Let us add to that example a signal for 1424 "source internal from a VIP". That last signal expresses the private 1425 extension URN urn:alert:source:internal:vip@example, which is a 1426 subset of urn:alert:source:internal, which is expressed by the 1427 "source internal" signal. There is a total of 3 expressed URNs, one 1428 of which is a subset of another: 1430 urn:alert:source:internal 1431 urn:alert:source:internal:vip@example 1432 urn:alert:source:external 1434 This generates the following alphabet of symbols, which includes two 1435 Other symbols for the category source: 1437 Source 1438 Source:Internal 1439 Source:Internal:Vip@example 1440 Source:Internal:Other 1441 Source:Other 1443 9. An Example of "alert:service" URNs 1445 In this example there are signals for "service forward" (the call has 1446 been forwarded) and "source recall callback" (a recall due to a 1447 callback). This gives 2 expressed URNs: 1449 urn:alert:service:forward 1450 urn:alert:service:recall:callback 1452 This generates the following alphabet of symbols. Note that there 1453 are two "Other" symbols, because the "alert:service" URNs have an 1454 additional level of qualification. 1456 Service 1457 Service:Forward 1458 Service:Recall 1459 Service:Recall:Callback 1460 Service:Recall:Other 1461 Service:Other 1463 10. An Example Using Country Codes 1465 In this example, we consider how a UA generates ringback signals when 1466 the UA wishes to reproduce the traditional behavior that the caller 1467 hears the ringback signals defined by the telephone service in the 1468 callee's country, rather than the ringback singals defined by the 1469 service in the caller's country. In the Alert-Info header field of 1470 the 180 provisional response, we assume that the called UA provides 1471 an "alert:country" URN containing the ISO 3166-1 alpha-2 country 1472 code. 1474 The UA has a default signal and a "non-country" signal for 1475 urn:alert:service:call-waiting. For the example country with code 1476 "XA", the UA has a default signal and signals for 1477 urn:alert:service:call-waiting and urn:alert:service:forward. For 1478 the example country with code "XB", the UA has a default signal and a 1479 signal for urn:alert:service:forward. These inconsistencies between 1480 the non-country signals and the country signals are chosen to 1481 demonstrate the flexibility of the construction method, showing that 1482 three systems of signals can be combined correctly even when the 1483 systems were established without coordination between them. 1485 The signals are: 1487 Signal URN(s) 1488 ---------------------------- ------------------------------- 1489 default (none) 1490 call-waiting urn:alert:service:call-waiting 1492 XA default urn:alert:country:xa 1493 XA call-waiting urn:alert:country:xa, 1494 urn:alert:service:call-waiting 1495 XA forward urn:alert:country:xa, 1496 urn:alert:service:forward 1498 XB default urn:alert:country:xb 1499 XB forward urn:alert:country:xb, 1500 urn:alert:service:forward 1502 The expressed URNs are: 1504 urn:alert:country:xa 1505 urn:alert:country:xb 1506 urn:alert:service:call-waiting 1507 urn:alert:service:forward 1509 The relevant categories of "alert" URNs are only: 1511 country 1512 service 1514 The alphabet of symbols is: 1516 Country 1517 Country:[other] 1518 Country:Xa 1519 Country:Xb 1520 Service 1521 Service:[other] 1522 Service:Call-waiting 1523 Service:Forward 1525 The 15 states are as follows: 1527 State: 0 Country/Service 1528 Signal: default 1529 Transitions: 1530 Country:[other] -> 1 Country:([other])/Service 1531 Country:Xa -> 5 Country:Xa/Service 1532 Country:Xb -> 9 Country:Xb/Service 1533 Service:[other] -> 13 Country/Service:([other]) 1534 Service:Call-waiting -> 14 Country/Service:Call-waiting 1535 Service:Forward -> 16 Country/Service:(Forward) 1537 State: 1 Country:([other])/Service 1538 Signal: default 1539 Transitions: 1540 Country:[other] -> 1 Country:([other])/Service 1541 Country:Xa -> 1 Country:([other])/Service 1542 Country:Xb -> 1 Country:([other])/Service 1543 Service:[other] -> 2 Country:([other])/Service:([other]) 1544 Service:Call-waiting -> 3 Country:([other])/Service:Call-waiting 1545 Service:Forward -> 4 Country:([other])/Service:(Forward) 1547 State: 2 Country:([other])/Service:([other]) 1548 Signal: default 1549 Transitions: 1550 any -> 2 Country:([other])/Service:([other]) 1552 State: 3 Country:([other])/Service:Call-waiting 1553 Signal: call-waiting 1554 Transitions: 1555 any -> 3 Country:([other])/Service:Call-waiting 1557 State: 4 Country:([other])/Service:(Forward) 1558 Signal: default 1559 Transitions: 1560 any -> 4 Country:([other])/Service:(Forward) 1562 State: 5 Country:Xa/Service 1563 Signal: XA default 1564 Transitions: 1565 Country:[other] -> 5 Country:Xa/Service 1566 Country:Xa -> 5 Country:Xa/Service 1567 Country:Xb -> 5 Country:Xa/Service 1568 Service:[other] -> 6 Country:Xa/Service:([other]) 1569 Service:Call-waiting -> 7 Country:Xa/Service:Call-waiting 1570 Service:Forward -> 8 Country:Xa/Service:Forward 1572 State: 6 Country:Xa/Service:([other]) 1573 Signal: XA default 1574 Transitions: 1575 any -> 6 Country:Xa/Service:([other]) 1577 State: 7 Country:Xa/Service:Call-waiting 1578 Signal: XA call-waiting 1579 Transitions: 1580 any -> 7 Country:Xa/Service:Call-waiting 1582 State: 8 Country:Xa/Service:Forward 1583 Signal: XA forward 1584 Transitions: 1585 any -> 8 Country:Xa/Service:Forward 1587 State: 9 Country:Xb/Service 1588 Signal: XB default 1589 Transitions: 1590 Country:[other] -> 9 Country:Xb/Service 1591 Country:Xa -> 9 Country:Xb/Service 1592 Country:Xb -> 9 Country:Xb/Service 1593 Service:[other] -> 10 Country:Xb/Service:([other]) 1594 Service:Call-waiting -> 11 Country:Xb/Service:(Call-waiting) 1595 Service:Forward -> 12 Country:Xb/Service:Forward 1597 State: 10 Country:Xb/Service:([other]) 1598 Signal: XB default 1599 Transitions: 1600 any -> 10 Country:Xb/Service:([other]) 1602 State: 11 Country:Xb/Service:(Call-waiting) 1603 Signal: XB default 1604 Transitions: 1605 any -> 11 Country:Xb/Service:(Call-waiting) 1607 State: 12 Country:Xb/Service:Forward 1608 Signal: XB forward 1609 Transitions: 1610 any -> 12 Country:Xb/Service:Forward 1612 State: 13 Country/Service:([other]) 1613 Signal: default 1614 Transitions: 1615 Country:[other] -> 2 Country:([other])/Service:([other]) 1616 Country:Xa -> 6 Country:Xa/Service:([other]) 1617 Country:Xb -> 10 Country:Xb/Service:([other]) 1618 Service:[other] -> 13 Country/Service:([other]) 1619 Service:Call-waiting -> 13 Country/Service:([other]) 1620 Service:Forward -> 13 Country/Service:([other]) 1622 State: 14 Country/Service:Call-waiting 1623 Signal: call-waiting 1624 Transitions: 1625 Country:[other] -> 3 Country:([other])/Service:Call-waiting 1626 Country:Xa -> 7 Country:Xa/Service:Call-waiting 1627 Country:Xb -> 15 Country:(Xb)/Service:Call-waiting 1628 Service:[other] -> 14 Country/Service:Call-waiting 1629 Service:Call-waiting -> 14 Country/Service:Call-waiting 1630 Service:Forward -> 14 Country/Service:Call-waiting 1632 State: 15 Country:(Xb)/Service:Call-waiting 1633 Signal: call-waiting 1634 Transitions: 1635 any -> 15 Country:(Xb)/Service:Call-waiting 1637 State: 16 Country/Service:(Forward) 1638 Signal: default 1639 Transitions: 1640 Country:[other] -> 4 Country:([other])/Service:(Forward) 1641 Country:Xa -> 8 Country:Xa/Service:Forward 1642 Country:Xb -> 12 Country:Xb/Service:Forward 1643 Service:[other] -> 16 Country/Service:(Forward) 1644 Service:Call-waiting -> 16 Country/Service:(Forward) 1645 Service:Forward -> 16 Country/Service:(Forward) 1647 Call-waiting can be signaled in conjunction with country XA but in 1648 conjunction with country XB. Thus the ordering of 1649 urn:alert:service:call-waiting with urn:alert:country:xa does not 1650 matter, but if urn:alert:country:xb appears before 1651 urn:alert:service:call-waiting, call-waiting cannot be signaled. On 1652 the other hand, if urn:alert:service:call-waiting appears before 1653 urn:alert:country:xb, then call-waiting is signaled, but using the 1654 non-country sgnal. 1656 Alert-Info: urn:alert:country:xa, 1657 urn:alert:service:call-waiting 1659 State: 0 Country/Service 1660 Process: Country:Xa (urn:alert:country:xa) 1661 State: 5 Country:Xa/Service 1662 Process: Service:Call-waiting (urn:alert:service:call-waiting) 1663 State: 7 Country:Xa/Service:Call-waiting 1664 Signal: XA call-waiting 1666 Alert-Info: urn:alert:service:call-waiting, 1667 urn:alert:country:xa 1669 State: 0 Country/Service 1670 Process: Service:Call-waiting (urn:alert:service:call-waiting) 1671 State: 14 Country/Service:Call-waiting 1672 Process: Country:Xa (urn:alert:country:xa) 1673 State: 7 Country:Xa/Service:Call-waiting 1674 Signal: XA call-waiting 1676 Alert-Info: urn:alert:country:xb, 1677 urn:alert:service:call-waiting 1679 State: 0 Country/Service 1680 Process: Country:Xb (urn:alert:country:xb) 1681 State: 9 Country:Xb/Service 1682 Process: Service:Call-waiting (urn:alert:service:call-waiting) 1683 State: 11 Country:Xb/Service:(Call-waiting) 1684 Signal: XB default 1686 Alert-Info: urn:alert:service:call-waiting, 1687 urn:alert:country:xb 1689 State: 0 Country/Service 1690 Process: Service:Call-waiting (urn:alert:service:call-waiting) 1691 State: 14 Country/Service:Call-waiting 1692 Process: Country:Xb (urn:alert:country:xb) 1693 State: 15 Country:(Xb)/Service:Call-waiting 1694 Signal: call-waiting 1696 11. Prioritizing Signals 1698 The specifications in [RFC7462] are oriented toward giving the sender 1699 of Alert-Info control over which of the "alert" URNs are most 1700 important. But in some situations, the user agent may prefer to 1701 prioritize expressing one URN category over another regardless of the 1702 order their URNs appear in Alert-Info. This section describes how 1703 that can be accommodated within the framework of [RFC7462], and 1704 presents an example FSM resulting from that approach. 1706 This example uses the signals of Section 6, viz., "external source", 1707 "internal source", "low priority" and "high priority", but this time, 1708 we want to signal "high priority" in preference to any other signal 1709 that might be applicable. 1711 We accommodate this within the framework of [RFC7462] by assigning 1712 the signal "high priority" for each of these combinations of URNs: 1714 urn:alert:priority:high 1715 urn:alert:priority:high, urn:alert:source:internal 1716 urn:alert:priority:high, urn:alert:source:external 1718 The result is that the "high priority" signal is the "best" signal 1719 for any combination of urn:alert:priority:high with "source" URNs. 1721 The intermediate steps of the method produce the same results as 1722 before. The signals can express the following URNs: 1724 urn:alert:source:external 1725 urn:alert:source:internal 1726 urn:alert:priority:low 1727 urn:alert:priority:high 1729 The relevant categories of "alert" URNs are: 1731 source 1732 priority 1734 The alphabet of symbols is: 1736 Source 1737 Source:External 1738 Source:Internal 1739 Source:Other 1740 Priority 1741 Priority:Low 1742 Priority:High 1743 Priority:Other 1745 When the FSM is constructed, it is the same as the FSM for Section 6, 1746 except that certain states are effectively renamed and merged, 1747 because any "source" is defined to be expressed if high priority is 1748 expressed: 1750 Priority:(High)/Source:External and 1751 Priority:High/Source:(External) become: 1752 State: Priority:High/Source:External 1753 Signal: high priority 1755 Priority:(High)/Source:Internal and 1756 Priority:High/Source:(Internal) become: 1757 State: Priority:High/Source:Internal 1758 Signal: high priority 1760 This reduces the FSM to 18 states. In addition, these two new 1761 states, along with a number of other states, can be merged by FSM 1762 optimization, since all of them have the signal "high priority" and 1763 from them, there are no transitions to states outside this set. The 1764 final FSM has 10 states. 1766 12. Dynamic Sets of Signals 1768 This section discusses how to construct FSMs for a user agent that 1769 allows variable sets of signals, for example, if the user can 1770 configure the use of ringtones. Several approaches can be used: 1772 o Whenever the set of ringtones is changed, re-execute the processes 1773 of Section 4. 1775 o Whenever the set of ringtones is changed, rebuild the list of 1776 expressed URNs (Section 4.1) and reconstruct the alphabet of 1777 symbols (Section 4.2). Then use an algorithm for dynamically 1778 constructing states of the FSM as they are needed during Alert- 1779 Info processing. 1781 o If the sets of possible URNs expressed by the ringtones is 1782 sufficiently limited, the steps of Section 4 can be carried out 1783 "generically", and the generic FSM can be specialized for the 1784 current ringtone configuration. 1786 The remainder of this section gives an example of the third approach. 1788 For the example, we will use a set of ringtones that express the 1789 identify of the caller. To signal this information, a private 1790 extension "alert" URN category is used, "caller@example": 1792 urn:alert:caller@example:alice@example.com 1793 urn:alert:caller@example:bob@example.com 1794 etc. 1796 which we can express by the generic pattern 1797 urn:alert:caller@example:IDENTITY 1799 where "IDENTITY" is replaced in succession by the set of caller 1800 identities that have their own ringtones to generate the set of 1801 expressed URNs. 1803 The alphabet is then: 1805 Caller@example 1806 Caller@example:IDENTITY 1807 Caller@example:Other 1809 where "IDENTITY" is replaced in succession by the set of caller 1810 identities. The "Caller@example:Other" symbol includes all URNs of 1811 the category "caller@example" that are not included in any of the 1812 other symbols. 1814 The states and transitions of the FSM are: 1816 State: Caller@example (initial state) 1817 Signal: default 1818 Transitions: 1819 Caller@example:IDENTITY -> Caller@example:IDENTITY 1820 Caller@example:Other -> Caller@example:(Other) 1822 State: Caller@example:IDENTITY 1823 Signal: signal for caller IDENTITY 1824 Transitions: 1825 any -> Caller@example:IDENTITY 1827 State: Caller@example:(Other) 1828 Signal: default 1829 Transitions: 1830 any -> Caller@example:(Other) 1832 where again, the second state is replicated once for each caller 1833 identity that has a ringtone, with "IDENTITY" replaced with the 1834 caller identity. 1836 13. Revision History 1838 [Note to RFC Editor: Please remove this entire section upon 1839 publication as an RFC.] 1841 13.1. Changes from draft-worley-alert-info-fsm-06 to draft-worley- 1842 alert-info-fsm-07 1844 Editorial improvements from independent submission reviewer. 1846 13.2. Changes from draft-worley-alert-info-fsm-05 to draft-worley- 1847 alert-info-fsm-06 1849 Editorial improvements from independent submission reviewer. 1851 Add note at end of introduction that you can do this by hand in 1852 simple cases. 1854 Add the country-code example. 1856 13.3. Changes from draft-worley-alert-info-fsm-04 to draft-worley- 1857 alert-info-fsm-05 1859 Editorial improvements. 1861 13.4. Changes from draft-worley-alert-info-fsm-03 to draft-worley- 1862 alert-info-fsm-04 1864 Editorial improvements. 1866 13.5. Changes from draft-worley-alert-info-fsm-02 to draft-worley- 1867 alert-info-fsm-03 1869 Correct indenting of some lines. 1871 13.6. Changes from draft-worley-alert-info-fsm-01 to draft-worley- 1872 alert-info-fsm-02 1874 Recast exposition to feature the implementation of the construction 1875 algorithm. 1877 13.7. Changes from draft-worley-alert-info-fsm-00 to draft-worley- 1878 alert-info-fsm-01 1880 Reorganized the text, including describing how the FSM states are 1881 constructed. 1883 14. References 1884 14.1. Normative References 1886 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1887 A., Peterson, J., Sparks, R., Handley, M., and E. 1888 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1889 DOI 10.17487/RFC3261, June 2002, 1890 . 1892 [RFC7462] Liess, L., Ed., Jesske, R., Johnston, A., Worley, D., and 1893 P. Kyzivat, "URNs for the Alert-Info Header Field of the 1894 Session Initiation Protocol (SIP)", RFC 7462, 1895 DOI 10.17487/RFC7462, March 2015, 1896 . 1898 14.2. Informative References 1900 [code] Worley, D., "draft-worley-alert-info-fsm.aux", February 1901 2017, . 1904 Acknowledgments 1906 Thanks to Paul Kyzivat, whose relentless identification of the 1907 weaknesses of earlier versions made the final document much, much 1908 better than it would have been, by changing it from the exposition of 1909 a concept into a practical tool. Thanks to Rifaat Shekh-Yusef for 1910 his thorough review. 1912 Author's Address 1914 Dale R. Worley 1915 Ariadne Internet Services 1916 738 Main St. 1917 Waltham, MA 02451 1918 US 1920 Email: worley@ariadne.com