idnits 2.17.1 draft-worley-alert-info-fsm-08.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 327 has weird spacing: '... source urn:a...' == Line 370 has weird spacing: '...riority urn:...' == Line 896 has weird spacing: '... source urn...' == Line 898 has weird spacing: '... source urn...' == Line 901 has weird spacing: '... source urn:...' == (1 more instance...) -- The document date (May 26, 2017) is 2526 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 May 26, 2017 5 Expires: November 27, 2017 7 A Simpler Method for Resolving Alert-Info URNs 8 draft-worley-alert-info-fsm-08 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. This document describes 19 a method by which a user agent's designer can, based on the user 20 agent's signals and their meanings, construct a finite state machine 21 (FSM) to process the URNs to select a signal in a way that obeys the 22 restrictions given in the definition of the "alert" URN namespace. 23 In many situations, the resulting FSM is simpler to implement 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 November 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 1.1. Requirements Governing Resolution Algorithms . . . . . . 4 59 1.2. Summary of the New Resolution Algorithm . . . . . . . . . 5 60 2. Selecting the Signals and Their Corresponding "alert" URNs . 6 61 3. General Considerations for Processing Alert-Info . . . . . . 9 62 4. Constructing the Finite State Machine for a Very Simple 63 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 4.1. Listing the Expressed URNs . . . . . . . . . . . . . . . 11 65 4.2. Constructing the Alphabet . . . . . . . . . . . . . . . . 11 66 4.3. Constructing the States and Transitions . . . . . . . . . 13 67 4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 68 4.5. Examples of Processing Alert-Info URNs . . . . . . . . . 18 69 5. Example with "source" and "priority" URNs . . . . . . . . . . 19 70 6. Example 1 of RFC 7462 . . . . . . . . . . . . . . . . . . . . 24 71 7. Examples 2, 3, and 4 of RFC 7462 . . . . . . . . . . . . . . 29 72 8. An Example that Subsets Internal Sources . . . . . . . . . . 32 73 9. An Example of "alert:service" URNs . . . . . . . . . . . . . 32 74 10. An Example Using Country Codes . . . . . . . . . . . . . . . 33 75 11. Prioritizing Signals . . . . . . . . . . . . . . . . . . . . 38 76 12. Dynamic Sets of Signals . . . . . . . . . . . . . . . . . . . 40 77 13. Revision History . . . . . . . . . . . . . . . . . . . . . . 41 78 13.1. Changes from draft-worley-alert-info-fsm-07 to draft- 79 worley-alert-info-fsm-08 . . . . . . . . . . . . . . . . 42 80 13.2. Changes from draft-worley-alert-info-fsm-06 to draft- 81 worley-alert-info-fsm-07 . . . . . . . . . . . . . . . . 42 82 13.3. Changes from draft-worley-alert-info-fsm-05 to draft- 83 worley-alert-info-fsm-06 . . . . . . . . . . . . . . . . 42 84 13.4. Changes from draft-worley-alert-info-fsm-04 to draft- 85 worley-alert-info-fsm-05 . . . . . . . . . . . . . . . . 42 86 13.5. Changes from draft-worley-alert-info-fsm-03 to draft- 87 worley-alert-info-fsm-04 . . . . . . . . . . . . . . . . 42 88 13.6. Changes from draft-worley-alert-info-fsm-02 to draft- 89 worley-alert-info-fsm-03 . . . . . . . . . . . . . . . . 42 90 13.7. Changes from draft-worley-alert-info-fsm-01 to draft- 91 worley-alert-info-fsm-02 . . . . . . . . . . . . . . . . 42 92 13.8. Changes from draft-worley-alert-info-fsm-00 to draft- 93 worley-alert-info-fsm-01 . . . . . . . . . . . . . . . . 43 94 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 95 14.1. Normative References . . . . . . . . . . . . . . . . . . 43 96 14.2. Informative References . . . . . . . . . . . . . . . . . 43 97 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 43 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 43 100 1. Introduction 102 When a SIP user agent server receives an incoming INVITE request, it 103 chooses an alerting signal (the ring tone) to present to its user 104 (the called user) by processing the Alert-Info header field(s) in the 105 incoming INVITE request [RFC3261]. Similarly, a SIP user agent 106 client determines an alerting signal (the ringback tone) to present 107 to its user (the calling user) by processing the Alert-Info header 108 field(s) in the incoming provisional response(s) to its outgoing 109 INVITE request. 111 [RFC3261] envisioned that the Alert-Info header field value would be 112 a URL that the user agent could use to retrieve the encoded media of 113 the signal. This usage has security problems and is inconvenient to 114 implement in practice. 116 [RFC7462] introduced an alternative practice: The Alert-Info values 117 can be URNs in the "alert" URN namespace which specify features of 118 the call or of the signal that should be signaled to the user. 119 [RFC7462] defined a large set of "alert" URNs and procedures for 120 extending the set. 122 A user agent is unlikely to provide more than a small set of alerting 123 signals and there are an infinite number of possible combinations of 124 "alert" URNs. Thus, a user agent is often required to select an 125 alerting signal which renders only a subset of the information in the 126 Alert-Info header field(s) -- which is the resolution process for 127 "alert" URNs. The requirements for resolving "alert" URNs are given 128 in section 11.1 of [RFC7462]. 130 Section 12 of [RFC7462] gives a resolution algorithm for selecting a 131 signal which satisfies the requirements of section 11.1. That 132 algorithm can be used regardless of the set of alerting signals that 133 the user agent provides and their specified meanings. The existence 134 of this algorithm demonstrates that the resolution requirements can 135 always be satisfied. However, the algorithm is complex and slow. 137 The purpose of this document is to describe an improved 138 implementation, a more efficient resolution algorithm for selecting 139 signals that conforms to the requirements of section 11.1: Once the 140 user agent designer has chosen the set of signals that the user agent 141 produces and the "alert" URNs that they express, a finite state 142 machine is constructed that selects alerting signals based on the 143 URNs in the Alert-Info header field(s) in a SIP message. The 144 incoming "alert" URNs are preprocessed in a straightforward manner 145 into a sequence of "symbols" drawn from a fixed finite set, which are 146 then used as input to the finite state machine. After processing the 147 input, the state of the finite state machine selects the correct 148 alerting signal to present to the user. 150 Both the preprocessor and the finite state machine are determined 151 only by the selected set of signals and the set of "alert" URNs 152 expressed by the signals, so the processing machinery can be fixed at 153 the time of designing the user agent. 155 1.1. Requirements Governing Resolution Algorithms 157 The requirements for the resolution of "alert" URNs are given in 158 section 11.1 of [RFC7462] and can be described as follows: 160 The "alert" URNs are processed from left to right. Each "alert" 161 URN has precedence over all URNs that follow it, and its 162 interpretation is subordinate to all URNs that precede it. 164 As each URN is processed, one of the UA's signals is chosen which 165 expresses that URN as far as can be done without reducing the 166 degree to which any of the preceding URNs were expressed by the 167 signal chosen for the preceding URN. Thus, as processing 168 proceeds, the chosen signals become increasingly specific and 169 contain more information, but all of the information about a 170 particular URN that is expressed by the signal chosen for that URN 171 is also expressed by the signals chosen for all following URNs. 173 If the entirety of the current URN cannot be expressed by any 174 allowed signal, then in turn, each of the trailing alert-ind-parts 175 (the sections separated by colons) is removed until the reduced 176 URN can be expressed by some signal which also expresses at least 177 the same reduced versions of the preceding URNs that were 178 expressed by the signal chosen for the preceding URN. This can be 179 described as "a signal that expresses as much of the current URN 180 as possible while still expressing as much of the previous URNs as 181 the preceding signal did". 183 So, for instance, consider processing 185 Alert-Info: urn:alert:category-a:part-a1:part-a2, 186 urn:alert:category-b:part-b1:part-b2 188 If the UA has no signal for urn:alert:category-a:part-a1:part-a2, it 189 removes part-a2 from the URN and checks whether it has a signal for 190 the less-specific URN urn:alert:category-a:part-a1. If it has no 191 signal for that URN, it gives up on the URN entirely (since 192 urn:alert:category-a doesn't exist, and can be considered to express 193 nothing about the call), and the chosen signal is the default signal 194 of the UA, the signal that is used when there is no Alert-Info. 196 But let us suppose the UA has a signal for urn:alert:category-a:part- 197 a1, and chooses that signal when processing the first URN. All 198 processing after this point will be restricted to signals that 199 express urn:alert:category-a:part-a1, or a more specific URN of the 200 category category-a. 202 The UA then goes on to examine the next URN, urn:alert:category- 203 b:part-b1:part-b2. If there is a signal that expresses both 204 urn:alert:category-a:part-a1 and urn:alert:category-b:part-b1:part- 205 b2, then the UA chooses that signal. If there is no such signal, the 206 second URN is reduced to urn:alert:category-b:part-b1, and the UA 207 checks for a signal that expresses that URN along with 208 urn:alert:category-a:part-a1. If there is no such signal that 209 matches that relaxed requirement, the second URN is reduced to 210 urn:alert:category-b, which is discarded, and the chosen signal for 211 the first URN is chosen for the second URN. In any case, all 212 processing after this point will be restricted to signals that 213 express urn:alert:category-a:part-a1 or a more specific URN of the 214 category category-a, and also express the chosen part of 215 urn:alert:category-b:part-b1:part-b2. 217 This process is continued until the last "alert" URN is processed; 218 the signal chosen for the last URN is the signal that the UA uses. 220 1.2. Summary of the New Resolution Algorithm 222 The purpose of this document is to describe a resolution algorithm 223 that conforms to section 11.1 of [RFC7462] but is simpler than the 224 algorithm described in section 12 of [RFC7462]: Once the user agent 225 designer has chosen a set of signals and the URNs that they express, 226 a finite state machine is constructed that selects alerting signals 227 based on the URNs in the Alert-Info header field(s) in a SIP message. 229 o The designer selects the set of signals that the user agent 230 produces, matching each signal to the "alert" URN or the 231 combination of "alert" URNs which are the meaning carried by the 232 signal. 234 o Based on the user agent's signals and their meanings, the designer 235 constructs an "alphabet" containing a finite number of symbols; 236 each possible "alert" URN is mapped into one particular symbol. 238 o The designer constructs a finite state machine (FSM) whose input 239 is the alphabet of symbols and whose states describe the 240 information extracted from the Alert-Info URNs. 242 o Each state of the FSM has an associated signal. Processing the 243 Alert-Info URNs will leave the FSM in some particular state; the 244 UA renders the signal that is attached to that final state. 246 To select a ring tone or ringback tone based on a SIP message, the 247 user agent processes the "alert" URNs in the Alert-Info header field 248 from left to right. Initially the FSM is in a designated initial 249 state. The user agent maps each successive URN into the 250 corresponding symbol, and then executes the state transition of the 251 FSM specified by the symbol. The state of the FSM after processing 252 the URNs determines which signal the user agent will render to the 253 user. 255 Note that the user agent generally has two FSMs, because a user agent 256 usually wants to signal different information in ring tones than it 257 signals in ringback tones. One FSM is used to select the ring tone 258 to render for an incoming INVITE request. The other FSM is used to 259 select the ringback tone to render based on an incoming provisional 260 response to an outgoing INVITE request. Both FSMs are constructed in 261 the same way, but the constructions are based on different lists of 262 signals and corresponding URNs. 264 All of the steps of the method after the designer has selected the 265 signals and their URNs are algorithmic, and the algorithm of those 266 steps assures that the operation of the FSM will satisfy the 267 constraints of section 11.1 of [RFC7462]. A Python implementation of 268 the algorithmic steps is provided in [code]. 270 In simple situations, a suitable FSM or equivalent ad-hoc code can be 271 constructed by hand using ad-hoc analysis. Generally, this is only 272 practical in situations where a small number of alert categories and 273 alert indications are signaled and the categories interact in a 274 simple, uniform way. E.g., the examples in Section 5 and Section 6 275 could be constructed by ad-hoc analysis. But automatic processing is 276 valuable if the situation is too complicated to construct a correct 277 FSM by ad-hoc analysis, or if the set of signals will change too 278 frequently for human production to be economical. 280 2. Selecting the Signals and Their Corresponding "alert" URNs 282 The designer must select signals that the UA will generate and define 283 the meanings that the signals will have to the user. Based on this, 284 the designer determines for each signal the "alert" URN or 285 combination of "alert" URNs that indicate that meaning in SIP 286 messages, and consequently should elicit that signal from the UA. 288 For example, suppose the UA has a particular ring tone for calls from 289 an external source. A call from an external source is marked with 290 the URN urn:alert:source:external (specified in section 9 of 291 [RFC7462]). Thus, the table of signals includes: 293 Signal URN(s) 294 ---------------------------- ------------------------------- 295 external source urn:alert:source:external 297 Similarly, if the UA has a particular ring tone for calls from an 298 internal source, the table includes: 300 Signal URN(s) 301 ---------------------------- ------------------------------- 302 internal source urn:alert:source:internal 304 If the UA has ring tones for calls that are marked as having higher 305 or lower priority, then the table includes: 307 Signal URN(s) 308 ---------------------------- ------------------------------- 309 high priority urn:alert:priority:high 310 low priority urn:alert:priority:low 312 Note that the UA must be able to signal for a message that has no 313 "alert" URNs in the Alert-Info header field, which means that there 314 must always be a default signal which has zero corresponding URNs: 316 Signal URN(s) 317 ---------------------------- ------------------------------- 318 default (none) 320 A signal can be defined to indicate a combination of conditions. For 321 instance, a signal that is used only for high-priority, internal- 322 source calls expresses two URNs, and will only be used when both URNs 323 are present in Alert-Info: 325 Signal URN(s) 326 ------------------------------ ------------------------------- 327 high priority, internal source urn:alert:priority:high, 328 urn:alert:source:internal 330 A signal can be defined to cover a number of related conditions by 331 specifying a URN that is the common prefix of the URNs for the 332 various conditions. For instance, the URNs for "recall due to 333 callback", "recall due to call hold", and "recall due to transfer" 334 all start with urn:alert:service:recall, and so one signal can be 335 provided for all of them by: 337 Signal URN(s) 338 ---------------------------- ------------------------------- 339 recall urn:alert:service:recall 341 But if a specific signal is also provided for "recall due to 342 callback" by this entry: 344 Signal URN(s) 345 ---------------------------- ------------------------------- 346 recall generally urn:alert:service:recall 347 recall due to callback urn:alert:service:recall:callback 349 then if the message contains urn:alert:service:recall:callback, the 350 "recall due to callback" signal will be chosen instead of "recall 351 generally" because the UA chooses the signal that most completely 352 expresses the information in the Alert-Info header field. 354 The designer may wish to define extension URNs that provide more 355 specific information about a call than the standard "alert" URNs do. 356 One method is to add additional components to standard URNs. For 357 instance, an extra-high priority could be indicated by the URN 358 urn:alert:priority:high:extra-high@example. The final "extra- 359 high@example" is an "alert-ind-part" that is a private extension. 360 (See sections 7 and 10.2 of [RFC7462] for a discussion of private 361 extensions.) In any case, adding an alert-ind-part to a URN makes 362 its meaning more specific, in that any call to which the longer URN 363 can be applied can also have the shorter URN applied. In this case, 364 "extra-high-priority calls" are considered a subset of "high-priority 365 calls". 367 Signal URN(s) 368 --------------------- ------------------------------- 369 high priority urn:alert:priority:high 370 extra high priority urn:alert:priority:high:extra@example.com 372 Of course, for this extension to be useful, the senders of SIP 373 messages (e.g., other UAs) must generate the extension URN in 374 suitable circumstances. 376 In some circumstances, the designer may want to create an entirely 377 new category of "alert" URNs to indicate a type of information that 378 is not indicated by any standard category of URNs. In that case, the 379 designer uses a private extension as the alert-category (the third 380 component of the URN), combined with whatever alert-ind-part (fourth 381 component) values are desired. For example, a simplified version of 382 the U.S. military security designations could be: 384 Signal URN(s) 385 ----------------------- ------------------------------- 386 unclassified urn:alert:security@example:unclassified 387 confidential urn:alert:security@example:confidential 388 secret urn:alert:security@example:secret 389 top-secret urn:alert:security@example:top-secret 391 The designer should ensure that the new alert-category is orthogonal 392 to all defined standard alert-categories, in that any combination of 393 one of the new URNs with one of the standard URNs is meaningful in 394 that there could be a message carrying both URNs. 396 In addition, the set of alert-ind-parts for the new alert-category 397 should be comprehensive and disjoint, in that every message can be 398 described by exactly one of them. 400 3. General Considerations for Processing Alert-Info 402 In this section, we will discuss various considerations which arise 403 when processing Alert-Info. These have to be taken care of properly 404 in order to conform to the standards, as well as to endure a good 405 user experience. But since they are largely independent of the 406 generated finite state machine and its processing, they are gathered 407 here in a separate section. 409 The UA may have a number of different finite state machines (FSMs) 410 for processing URNs. Generally, there will be different FSMs for 411 processing Alert-Info in incoming INVITE requests and for incoming 412 provisional responses to outgoing INVITE requests. But any situation 413 that changes the set of signals that the UA is willing to generate 414 specifies a different set of signals and corresponding URNs, and thus 415 generates a different FSM. For example, if a call is active on the 416 UA, all audible signals may become unavailable, or audible signals 417 may be available only if urn:alert:priority:high is specified. 419 Similarly, if the set of signals is customized by user action or 420 local policy, the generated FSM must be updated. This can be done by 421 regenerating it according to the method described here, or by 422 generating a "generic" FSM and instantiating it based on the 423 available signals. (See Section 12 for a discussion of this.) 425 Note that the values in an Alert-Info header field are allowed to be 426 URIs of any scheme, and within the "urn" scheme, are allowed to have 427 any namespace [RFC3261]. The processing of URIs that are not "alert" 428 URNs is not considered by this document, nor is that processing 429 specified by [RFC7462]. But the algorithm designer must consider 430 what to do with such URIs if they are encountered. The simplest 431 choice is to ignore them. Alternatively, the algorithm may examine 432 the URI to determine if it names an alerting signal or describes how 433 to retrieve an alerting signal, and if so, choose to render that 434 signal, rather than processing the "alert" URNs to select a signal. 435 In any case, the remainder of this document assumes that the signal 436 is to be chosen based on the "alert" URNs in Alert-Info, and that all 437 Alert-Info URIs that are not "alert" URNs have been removed. 439 The UA may also receive "alert" URNs that are semantically invalid in 440 various ways. E.g., the URN may have only three components, despite 441 that all valid "alert" URNs have at least one alert-ind-part, and 442 thus four components. The only useful strategy is to ignore such 443 URNs (and possibly log them for analysis). 445 The method described here is robust in its handling of categories and 446 alert-ind-parts which are unknown to the UA, and as a consequence, it 447 is also robust if they are not valid standardized URNs. Thus, these 448 error conditions need not be handled specially. 450 4. Constructing the Finite State Machine for a Very Simple Example 452 Constructing the FSM involves: 454 1. Listing the URNs which are expressed by the various signals of 455 the user agent. 457 2. From the expressed URNs, constructing the finite alphabet of 458 symbols into which input URNs are mapped and which drive the 459 state transitions of the FSM. 461 3. Constructing the states of the FSM and the transitions between 462 them. 464 4. Selecting a signal to be associated with each FSM state. 466 We will explain the process using a very simple example in which 467 there are two signals, one expressing "internal source" and one 468 expressing "external source", along with a default signal (for when 469 there is no source information to signal). The "internal source" 470 signal expresses urn:alert:source:internal, and the "external source" 471 signal expresses urn:alert:source:external. 473 4.1. Listing the Expressed URNs 475 The first step is to establish for each of the user agent's signals 476 what call characteristics it represents, which is to say, the set of 477 "alert" URNs which are its information content. 479 Signal URN(s) 480 ---------------------------- ------------------------------- 481 default (none) 482 internal source urn:alert:source:internal 483 external source urn:alert:source:external 485 From the totality of these expressed URNs, the designer can then 486 determine which sets of URNs must be distinguished from each other. 487 In our simple example, the expressed URNs are: 489 urn:alert:source:external 490 urn:alert:source:internal 492 4.2. Constructing the Alphabet 494 In order to reduce the infinite set of possible "alert" URNs to a 495 finite alphabet of input symbols which cause the FSM's transitions, 496 the designer must partition the "alert" URNs into a finite set of 497 categories. 499 Once we've listed all the expressed URNs, we can list all of the 500 alert-categories that are relevant to the user agent's signaling; 501 "alert" URNs in any other alert-category cannot affect the signaling 502 and can be ignored. (The easiest method to ignore the non-relevant 503 URNs is to skip over them during Alert-Info processing. A more 504 formal method is to map all of them into one "Other" symbol, and then 505 for each state of the FSM, have the Other symbol transition to that 506 same state.) 508 Within each relevant alert-category, we now define a distinct symbol 509 for every expressed URN and for all of their "ancestor" URNs (those 510 that can be created by removing one or more trailing alert-ind- 511 parts). In order to name the symbols in a way that distinguishes 512 them from the corresponding URNs, we remove the initial "urn:alert:" 513 and capitalize each alert-ind-part. Thus in our example, we get 514 these symbols: 516 Source 517 Source:External 518 Source:Internal 520 Note that there is a "Source" symbol even though there is no 521 corresponding URN. (urn:alert:source is not a valid URN -- see 522 [RFC7462] section 7 -- although the processing algorithm must be 523 prepared to screen out such a purported URN if it appears in the 524 Alert-Info header field.) However, its existence as a symbol will be 525 useful later when we construct the FSM. 527 For each of these symbols, we add a symbol that classifies URNs that 528 extend the symbol's corresponding URN with alert-ind-parts that 529 cannot be expressed by signals: 531 Source:Other 532 Source:External:Other 533 Source:Internal:Other 535 The latter two classify URNs like 536 urn:alert:source:external:foo@example, which extend URNs that we 537 already have symbols for. The first is for classifying URNs, such as 538 urn:alert:source:bar@example, which have first alert-ind-parts that 539 contradict all the "source" URNs that the user agent can signal. 541 These steps give us this set of symbols: 543 Source 544 Source:External 545 Source:External:Other 546 Source:Internal 547 Source:Internal:Other 548 Source:Other 550 We can then simplify the set of symbols by removing the ones like 551 Source:External:Other and Source:Internal:Other that consist of 552 adding "Other" to a symbol which corresponds to an expressed URN 553 which is not ancestral to any other expressed URNs. This works 554 because adding further alert-ind-parts to a URN which is a leaf in 555 regard to the set of signals has no additional effect. In this 556 example, urn:alert:source:external:foo@example has the same effect as 557 urn:alert:source:external, both for causing a signal to be chosen as 558 well as for suppressing the effect of later URNs. 560 This leaves the following symbols for the "source" category: 562 Source 563 Source:External 564 Source:Internal 565 Source:Other 567 These can be visually summarized by showing the infinite tree of 568 possible source "alert" URNs and how it is partitioned into subtrees 569 that map to each of these symbols. We also mark with "*" the 570 expressed URNs. 572 urn:alert 573 | 574 { | } 575 { source } --> 1 576 { | } 577 | 578 +--------------------+------------------+ 579 | | | 580 { | } { | } { | } 581 { external* } --> 2 { internal* } --> 3 { ... } --> 4 582 { | } { | } { } 583 { ... } { ... } 584 { } { } 586 1 = Source 587 2 = Source:External 588 3 = Source:Internal 589 4 = Source:Other 591 4.3. Constructing the States and Transitions 593 The user agent processes the Alert-Info URNs left-to-right using a 594 finite state machine (FSM), with each successive URN causing the FSM 595 to transition to a new state. Each state of the FSM records the 596 information which has so far been extracted from the URNs. The state 597 of the FSM after processing all the URNs determines which signal the 598 user agent will render to the user. 600 We label each state with a set of symbols, one from each relevant 601 category, which describe the information that's been extracted from 602 all of the URNs that have so far been processed. The initial state 603 is labeled with the "null" symbols that are just the category names, 604 because no information has yet been recorded. In our simple example, 605 the initial state is labeled "Source", since that's the only relevant 606 category. 608 State: Source (initial state) 610 Each state has a corresponding alerting signal, which is the signal 611 that the user agent will produce when URN processing leaves the FSM 612 in that state. The signal is the one that best expresses the 613 information that has been extracted from the URNs. Usually the 614 choice of signal is obvious to the designer, but there are certain 615 constraints that the choice must satisfy. The main constraint is 616 that the signal's expressed URNs must be semantic supersets of (i.e., 617 identical to or a prefix of) the URNs corresponding to the symbols in 618 the state's label. In particular, if the expressed URN of the signal 619 in a certain category is shorter than the state's label, we show that 620 in the state's name by putting parentheses around the trailing part 621 of the symbol that is not expressed by the signal. For instance, if 622 the symbol in the label is "Source:External" but the signal only 623 expresses "Source" (i.e., no "source" URN at all), then the symbol in 624 the label is modified to be "Source:(External)". 626 The reason for this unintuitive construction is that in some states, 627 the FSM has recorded information that the chosen signal cannot 628 express. 630 Note that the parentheses are part of the state name, so in some 631 circumstances there may be two or more distinct states labeled with 632 the same symbols, but with different placement of parentheses within 633 the symbols. These similar state names are relevant when the FSM can 634 record information from multiple "alert" URNs but cannot express all 635 of them -- depending on the order in which the URNs appear, the UA 636 may have to render different signals, so it needs states that record 637 the same information but render different subsets of that 638 information. 640 The initial state's label is the string of null symbols for the 641 relevant categories, so the only allowed signal is the default 642 signal, which expresses no URNs: 644 State: Source (initial state) 645 Signal: default 647 From each state, we must construct the transition for each possible 648 input symbol. For a particular state and symbol, we construct the 649 label of the destination state by combining the input symbol with the 650 symbol in the start state's label for the same category. If one of 651 the symbols is a prefix of the other, we select the longer one; if 652 not, we select the symbol in the start state's label. 654 Thus, in our simple example, the initial state has the following 655 transitions: 657 State: Source (initial state) 658 Signal: default 659 Transitions: 660 Source:External -> Source:External 661 Source:Internal -> Source:Internal 662 Source:Other -> Source:Other 664 In all of these transitions, the input symbol is compatible with the 665 matching label of the state, "Source", so the destination state's 666 label is the full input symbol. 668 However, there is a further constraint on the destination state: Its 669 signal must express URNs that at least contain the expressed URNs of 670 the signal of the start state. Within that constraint, and being 671 compatible with the destination state's label, for the category of 672 the input URN, the destination state's signal must express the 673 longest URN that can be expressed by any signal. 675 In our example, this means that the destination Source:External state 676 has the "external source" signal, which expresses 677 urn:alert:source:external. Since that signal expresses all of the 678 state's label, it is the chosen state. Similarly, the destination 679 Source:Internal state has the "internal source" signal. But for the 680 transition on input Source:Other, the "Source:Other" state must have 681 the default signal, as there is no signal that expresses 682 urn:alert:source:[some-unknown-alert-ind-part]. So the destination 683 state is "Source:(Other)", where the parentheses record that the 684 "Other" part of the label is not expressed by the state's signal. 686 Thus, the initial state and the states it can transition to are: 688 State: Source (initial state) 689 Signal: default 690 Transitions: 691 Source:External -> Source:External 692 Source:Internal -> Source:Internal 693 Source:Other -> Source:(Other) 695 State: Source:External 696 Signal: external source (urn:alert:source:external) 698 State: Source:Internal 699 Signal: internal source (urn:alert:source:internal) 701 State: Source:(Other) 702 Signal: default 704 Looking at the state Source:External, we see that it is incompatible 705 with all input symbols other than Source:External, and thus all of 706 its transitions are to itself: 708 State: Source:External 709 Signal: external source (urn:alert:source:external) 710 Transitions: 711 Source:External -> Source:External 712 Source:Internal -> Source:External 713 Source:Other -> Source:External 715 and similarly: 717 State: Source:Internal 718 Signal: internal source (urn:alert:source:internal) 719 Transitions: 720 Source:External -> Source:Internal 721 Source:Internal -> Source:Internal 722 Source:Other -> Source:Internal 724 State: Source:(Other) 725 Signal: default 726 Transitions: 727 Source:External -> Source:(Other) 728 Source:Internal -> Source:(Other) 729 Source:Other -> Source:(Other) 731 4.4. Summary 733 The FSM can be constructed by processing the file "very-simple.txt" 734 with the program "alert-info-fsm.py" in [code]. The program's output 735 shows the stages of the construction, which are: 737 1. The signals have the meanings: 739 Signal URN(s) 740 ---------------------------- ------------------------------- 741 default (none) 742 internal source urn:alert:source:internal 743 external source urn:alert:source:external. 745 2. The expressed URNs are 747 urn:alert:source:external 748 urn:alert:source:internal 750 3. The relevant categories of "alert" URNs are only: 752 source 754 4. Thus, the infinite universe of possible "alert" URNs can be 755 reduced to these symbols, which are the categories of URNs that 756 are different in ways that are significant to the resolution 757 process: 759 Source 760 Source:External 761 Source:Internal 762 Source:Other 764 5. The FSM is: 766 State: Source (initial state) 767 Signal: default 768 Transitions: 769 Source:External -> Source:External 770 Source:Internal -> Source:Internal 771 Source:Other -> Source:(Other) 773 State: Source:External 774 Signal: external source (urn:alert:source:external) 775 Transitions: 776 Source:External -> Source:External 777 Source:Internal -> Source:External 778 Source:Other -> Source:External 780 State: Source:Internal 781 Signal: internal source (urn:alert:source:internal) 782 Transitions: 783 Source:External -> Source:Internal 784 Source:Internal -> Source:Internal 785 Source:Other -> Source:Internal 787 State: Source:(Other) 788 Signal: default 789 Transitions: 790 Source:External -> Source:(Other) 791 Source:Internal -> Source:(Other) 792 Source:Other -> Source:(Other) 794 * Each state is labeled by a set of symbols which describe the 795 information which has been extracted from the URNs so far. 797 * Each state has a signal which is a semantic superset of the 798 state's label, i.e., the signal's expressed URNs match the 799 initial portion of the label symbols. If Alert-Info 800 processing finishes with the FSM in a state, the user agent 801 will render the state's signal to the user. 803 * The state's label is marked to show what subset of the symbols 804 are expressed by the state's signal. Two states can have the 805 same label but different signals. 807 * If a transition's input symbol is compatible with (is a 808 semantic subset) of the start state's label for that category, 809 the destination state's label is updated with the input 810 symbol. If not, the destination state is the start state. 811 This is how the state's label records what information has 812 been accumulated while processing the Alert-Info URNs. 814 * A transition's destination state has a signal which 815 semantically subsets the start state's signal as much as 816 possible in the category of the input symbol. (In most cases, 817 the choice of signal is unique. In rare cases there may be 818 more than one signal that meets this criterion, so the 819 designer may have some flexibility.) 821 4.5. Examples of Processing Alert-Info URNs 823 In the trivial case where the user agent receives no Alert-Info URNs, 824 then processing begins and ends with the FSM in the initial state and 825 selects the default signal. 827 If the user agent receives 829 Alert-Info: 831 then processing progresses: 833 State: Source 834 Process: Source:Internal (urn:alert:source:internal) 835 State: Source:Internal 836 Signal: internal source 838 If the user agent receives 840 Alert-Info: , 841 843 then processing progresses: 845 State: Source 846 Process: Source:External (urn:alert:source:external) 847 State: Source:External 848 Process: Source:Internal (urn:alert:source:internal) 849 State: Source:External 850 Signal: external source 852 If the user agent receives 854 Alert-Info: , 855 857 then processing progresses: 859 State: Source 860 Process: Source:Other (urn:alert:source:unclassified) 861 State: Source:(Other) 862 Process: Source:Internal (urn:alert:source:internal) 863 State: Source:(Other) 864 Signal: default 866 If the user agent receives 868 Alert-Info: , 869 871 then processing progresses: 873 State: Source 874 Ignore: urn:alert:priority:high 875 State: Source 876 Process: Source:Internal (urn:alert:source:internal) 877 State: Source:Internal 878 Signal: internal source 880 5. Example with "source" and "priority" URNs 882 Now consider an example where the user agent can signal "external 883 source", "internal source", "low priority", and "high priority" 884 individually or in any combination of source and priority, along with 885 a default signal. This example is essentially the cartesian product 886 of two copies of the example in Section 4, one dealing with the 887 call's source and one dealing with the call's priority. So there is 888 a total of 9 signals: 890 Signal URN(s) 891 ---------------------------- ------------------------------- 892 default (none) 893 external source urn:alert:source:external 894 internal source urn:alert:source:internal 895 low priority urn:alert:priority:low 896 low priority/external source urn:alert:priority:low, 897 urn:alert:source:external 898 low priority/internal source urn:alert:priority:low, 899 urn:alert:source:internal 900 high priority urn:alert:priority:high 901 high priority/external source urn:alert:priority:high, 902 urn:alert:source:external 903 high priority/internal source urn:alert:priority:high, 904 urn:alert:source:internal 906 The expressed URNs are: 908 urn:alert:source:external 909 urn:alert:source:internal 910 urn:alert:priority:low 911 urn:alert:priority:high 913 The relevant categories of "alert" URNs are only: 915 source 916 priority 918 The alphabet of symbols is: 920 Source 921 Source:External 922 Source:Internal 923 Source:Other 924 Priority 925 Priority:Low 926 Priority:High 927 Priority:Other 929 The 16 states are as follows, where 10 states have a simple structure 930 because from them, no further information can be recorded. 932 State: Priority/Source 933 Signal: default 934 Transitions: 935 Priority:Other -> Priority:(Other)/Source 936 Priority:High -> Priority:High/Source 937 Priority:Low -> Priority:Low/Source 938 Source:Other -> Priority/Source:(Other) 939 Source:External -> Priority/Source:External 940 Source:Internal -> Priority/Source:Internal 942 State: Priority:(Other)/Source 943 Signal: default 944 Transitions: 945 Priority:Other -> Priority:(Other)/Source 946 Priority:High -> Priority:(Other)/Source 947 Priority:Low -> Priority:(Other)/Source 948 Source:Other -> Priority:(Other)/Source:(Other) 949 Source:External -> Priority:(Other)/Source:External 950 Source:Internal -> Priority:(Other)/Source:Internal 952 State: Priority:(Other)/Source:(Other) 953 Signal: default 954 Transitions: 955 any -> Priority:(Other)/Source:(Other) 957 State: Priority:(Other)/Source:External 958 Signal: external source 959 Transitions: 960 any -> Priority:(Other)/Source:External 962 State: Priority:(Other)/Source:Internal 963 Signal: internal source 964 Transitions: 965 any -> Priority:(Other)/Source:Internal 967 State: Priority:High/Source 968 Signal: high priority 969 Transitions: 970 Priority:Other -> Priority:High/Source 971 Priority:High -> Priority:High/Source 972 Priority:Low -> Priority:High/Source 973 Source:Other -> Priority:High/Source:(Other) 974 Source:External -> Priority:High/Source:External 975 Source:Internal -> Priority:High/Source:Internal 977 State: Priority:High/Source:(Other) 978 Signal: high priority 979 Transitions: 980 any -> Priority:High/Source:(Other) 982 State: Priority:High/Source:External 983 Signal: high priority/external source 984 Transitions: 985 any -> Priority:High/Source:External 987 State: Priority:High/Source:Internal 988 Signal: high priority/internal source 989 Transitions: 990 any -> Priority:High/Source:Internal 992 State: Priority:Low/Source 993 Signal: low priority 994 Transitions: 995 Priority:Other -> Priority:Low/Source 996 Priority:High -> Priority:Low/Source 997 Priority:Low -> Priority:Low/Source 998 Source:Other -> Priority:Low/Source:(Other) 999 Source:External -> Priority:Low/Source:External 1000 Source:Internal -> Priority:Low/Source:Internal 1002 State: Priority:Low/Source:(Other) 1003 Signal: low priority 1004 Transitions: 1005 any -> Priority:Low/Source:(Other) 1007 State: Priority:Low/Source:External 1008 Signal: low priority/external source 1009 Transitions: 1010 any -> Priority:Low/Source:External 1012 State: Priority:Low/Source:Internal 1013 Signal: low priority/internal source 1014 Transitions: 1015 any -> Priority:Low/Source:Internal 1017 State: Priority/Source:(Other) 1018 Signal: default 1019 Transitions: 1020 Priority:Other -> Priority:(Other)/Source:(Other) 1021 Priority:High -> Priority:High/Source:(Other) 1022 Priority:Low -> Priority:Low/Source:(Other) 1023 Source:Other -> Priority/Source:(Other) 1024 Source:External -> Priority/Source:(Other) 1025 Source:Internal -> Priority/Source:(Other) 1027 State: Priority/Source:External 1028 Signal: external source 1029 Transitions: 1030 Priority:Other -> Priority:(Other)/Source:External 1031 Priority:High -> Priority:High/Source:External 1032 Priority:Low -> Priority:Low/Source:External 1033 Source:Other -> Priority/Source:External 1034 Source:External -> Priority/Source:External 1035 Source:Internal -> Priority/Source:External 1037 State: Priority/Source:Internal 1038 Signal: internal source 1039 Transitions: 1040 Priority:Other -> Priority:(Other)/Source:Internal 1041 Priority:High -> Priority:High/Source:Internal 1042 Priority:Low -> Priority:Low/Source:Internal 1043 Source:Other -> Priority/Source:Internal 1044 Source:External -> Priority/Source:Internal 1045 Source:Internal -> Priority/Source:Internal 1047 An example of processing that involves multiple "source" URNs and one 1048 "priority" URN: 1050 Alert-Info: , 1051 , 1052 1054 State: Source/Priority 1055 Process: Source:Internal (urn:alert:source:internal) 1056 State: Source:Internal/Priority 1057 Process: Source:(Other) (urn:alert:source:unclassified) 1058 State: Source:Internal/Priority 1059 Process: Priority:High (urn:alert:priority:high) 1060 State: Source:Internal/Priority:High 1061 Signal: internal source/high priority 1063 6. Example 1 of RFC 7462 1065 A more complicated example is in section 12.2.1 of [RFC7462]. It is 1066 like the example in Section 5 of this document, except that the user 1067 agent can only signal "external source", "internal source", "low 1068 priority", and "high priority" individually but not in combination, 1069 as well as a default signal: 1071 Signal URN(s) 1072 ---------------------------- ------------------------------- 1073 default (none) 1074 internal source urn:alert:source:external 1075 external source urn:alert:source:internal 1076 high low urn:alert:priority:low 1077 high priority urn:alert:priority:high 1079 The signals can express the following URNs: 1081 urn:alert:source:external 1082 urn:alert:source:internal 1083 urn:alert:priority:low 1084 urn:alert:priority:high 1086 The relevant categories of "alert" URNs are: 1088 source 1089 priority 1091 The alphabet of symbols is: 1093 Source 1094 Source:External 1095 Source:Internal 1096 Source:Other 1097 Priority 1098 Priority:Low 1099 Priority:High 1100 Priority:Other 1102 In this example, the FSM has 20 states because both "source" and 1103 "priority" URNs are recorded, but the order in which the two appear 1104 affects the signal: 1106 State: Priority/Source 1107 Signal: default 1108 Transitions: 1109 Priority:Other -> Priority:(Other)/Source 1110 Priority:High -> Priority:High/Source 1111 Priority:Low -> Priority:Low/Source 1112 Source:Other -> Priority/Source:(Other) 1113 Source:External -> Priority/Source:External 1114 Source:Internal -> Priority/Source:Internal 1116 State Priority:(Other)/Source can transition to states that can 1117 signal source, because the recorded priority can't be signaled and 1118 thus does not block the signaling of the source: 1120 State: Priority:(Other)/Source 1121 Signal: default 1122 Transitions: 1123 Priority:Other -> Priority:(Other)/Source 1124 Priority:High -> Priority:(Other)/Source 1125 Priority:Low -> Priority:(Other)/Source 1126 Source:Other -> Priority:(Other)/Source:(Other) 1127 Source:External -> Priority:(Other)/Source:External 1128 Source:Internal -> Priority:(Other)/Source:Internal 1130 State: Priority:(Other)/Source:(Other) 1131 Signal: default 1132 Transitions: 1133 any -> Priority:(Other)/Source:(Other) 1135 State: Priority:(Other)/Source:External 1136 Signal: external source 1137 Transitions: 1138 any -> Priority:(Other)/Source:External 1140 State: Priority:(Other)/Source:Internal 1141 Signal: internal source 1142 Transitions: 1143 any -> Priority:(Other)/Source:Internal 1145 Because there are no signals for combinations of "source" and 1146 "priority" URNs, processing a "source" URN from the state 1147 Priority:High/Source leads to a state that records the priority 1148 information, but does not signal it: 1150 State: Priority:High/Source 1151 Signal: high priority 1152 Transitions: 1153 Priority:Other -> Priority:High/Source 1154 Priority:High -> Priority:High/Source 1155 Priority:Low -> Priority:High/Source 1156 Source:Other -> Priority:High/Source:(Other) 1157 Source:External -> Priority:High/Source:(External) 1158 Source:Internal -> Priority:High/Source:(Internal) 1160 State: Priority:High/Source:(Other) 1161 Signal: high priority 1162 Transitions: 1163 any -> Priority:High/Source:(Other) 1165 From the state Priority:High/Source, "source" URNs transition to 1166 states that record both source and priority but signal only priority, 1167 one of which is Priority:High/Source:(External). But from Priority/ 1168 Source:External, the symbol Priority:High transitions to the state 1169 Priority:(High)/Source:External, which records the same information 1170 but signals the source, not the priority. -- One state is reached by 1171 processing a "priority" URN and then a "source" URN, whereas the 1172 other is reached by processing a "source" URN and then a "priority" 1173 URN. 1175 State: Priority:High/Source:(External) 1176 Signal: high priority 1177 Transitions: 1178 any -> Priority:High/Source:(External) 1180 State: Priority:High/Source:(Internal) 1181 Signal: high priority 1182 Transitions: 1183 any -> Priority:High/Source:(Internal) 1185 And similarly for Priority:Low/Source: 1187 State: Priority:Low/Source 1188 Signal: low priority 1189 Transitions: 1190 Priority:Other -> Priority:Low/Source 1191 Priority:High -> Priority:Low/Source 1192 Priority:Low -> Priority:Low/Source 1193 Source:Other -> Priority:Low/Source:(Other) 1194 Source:External -> Priority:Low/Source:(External) 1195 Source:Internal -> Priority:Low/Source:(Internal) 1197 State: Priority:Low/Source:(Other) 1198 Signal: low priority 1199 Transitions: 1200 any -> Priority:Low/Source:(Other) 1202 State: Priority:Low/Source:(External) 1203 Signal: low priority 1204 Transitions: 1205 any -> Priority:Low/Source:(External) 1207 State: Priority:Low/Source:(Internal) 1208 Signal: low priority 1209 Transitions: 1210 any -> Priority:Low/Source:(Internal) 1212 State: Priority/Source:(Other) 1213 Signal: default 1214 Transitions: 1215 Priority:Other -> Priority:(Other)/Source:(Other) 1216 Priority:High -> Priority:High/Source:(Other) 1217 Priority:Low -> Priority:Low/Source:(Other) 1218 Source:Other -> Priority/Source:(Other) 1219 Source:External -> Priority/Source:(Other) 1220 Source:Internal -> Priority/Source:(Other) 1222 State: Priority/Source:External 1223 Signal: external source 1224 Transitions: 1225 Priority:Other -> Priority:(Other)/Source:External 1226 Priority:High -> Priority:(High)/Source:External 1227 Priority:Low -> Priority:(Low)/Source:External 1228 Source:Other -> Priority/Source:External 1229 Source:External -> Priority/Source:External 1230 Source:Internal -> Priority/Source:External 1232 State: Priority:(High)/Source:External 1233 Signal: external source 1234 Transitions: 1235 any -> Priority:(High)/Source:External 1237 State: Priority:(Low)/Source:External 1238 Signal: external source 1239 Transitions: 1240 any -> Priority:(Low)/Source:External 1242 State: Priority/Source:Internal 1243 Signal: internal source 1244 Transitions: 1245 Priority:Other -> Priority:(Other)/Source:Internal 1246 Priority:High -> Priority:(High)/Source:Internal 1247 Priority:Low -> Priority:(Low)/Source:Internal 1248 Source:Other -> Priority/Source:Internal 1249 Source:External -> Priority/Source:Internal 1250 Source:Internal -> Priority/Source:Internal 1252 State: Priority:(High)/Source:Internal 1253 Signal: internal source 1254 Transitions: 1255 any -> Priority:(High)/Source:Internal 1257 State: Priority:(Low)/Source:Internal 1258 Signal: internal source 1259 Transitions: 1260 any -> Priority:(Low)/Source:Internal 1262 As an example of processing, if the user agent receives 1264 Alert-Info: 1266 then processing progresses: 1268 State: Priority/Source 1269 Process: Source:Internal (urn:alert:source:internal) 1270 State: Priority/Source:Internal 1271 Signal: internal source 1273 A more complicated example involves multiple "source" URNs which do 1274 not select a non-default signal and one "priority" URN which can be 1275 signaled: 1277 Alert-Info: , 1278 , 1279 1281 State: Priority/Source 1282 Process: Source:Other (urn:alert:source:unclassified) 1283 State: Priority/Source:(Other) 1284 Process: Source:Internal (urn:alert:source:internal) 1285 State: Priority/Source:(Other) 1286 Process: Priority:High (urn:alert:priority:high) 1287 State: Priority:High/Source:(Other) 1288 Signal: high priority 1290 Since the only characteristic of a state that affects the output of 1291 the FSM is the state's signal, several groups of states in this FSM 1292 can be merged using standard FSM optimization algorithms: 1294 states with signal "high priority": 1295 Priority:High/Source 1296 Priority:High/Source:(Other) 1297 Priority:High/Source:(External) 1298 Priority:High/Source:(Internal) 1300 states with signal "low priority": 1301 Priority:Low/Source 1302 Priority:Low/Source:(Other) 1303 Priority:Low/Source:(External) 1304 Priority:Low/Source:(Internal) 1306 states with signal "external source": 1307 Priority/Source:External 1308 Priority:(High)/Source:External 1309 Priority:(Low)/Source:External 1310 Priority:(Other)/Source:External 1312 states with signal "internal source": 1313 Priority/Source:Internal 1314 Priority:(High)/Source:Internal 1315 Priority:(Low)/Source:Internal 1316 Priority:(Other)/Source:Internal 1318 This reduces the FSM to 7 states. 1320 7. Examples 2, 3, and 4 of RFC 7462 1322 Examples 2, 3, and 4 of [RFC7462] are similar to the example in 1323 Section 5, but they do not include a signal for the combination 1324 "internal source, low priority" to make resolution examples work 1325 asymmetrically. 1327 The FSM for this example has the same alphabet as the FSM of 1328 Section 5. Most of the states of this FSM are the same as the states 1329 of the FSM of Section 5, but the state Source:Internal/Priority:Low 1330 is missing because there is no signal for that combination. It is 1331 replaced by two states: One state is Source:Internal/Priority:(Low); 1332 it records that Source:Internal was specified first (and is to be 1333 signaled) and that Priority:Low was specified later (and can not be 1334 signaled -- but it still prevents any further "priority" URN from 1335 having an effect). The other state is 1336 Source:(Internal)/Priority:Low; it records the reverse sequence of 1337 events. 1339 The changes in the FSM are: 1341 State: Priority:Low/Source 1342 Signal: low priority 1343 Transitions: 1344 Source:Internal -> Priority:Low/Source:(Internal) 1345 (other transitions unchanged) 1347 State: Priority:Low/Source:(Internal) 1348 Signal: low priority 1349 Transitions: 1350 any -> Priority:Low/Source:(Internal) 1352 State: Priority/Source:Internal 1353 Signal: internal source 1354 Transitions: 1355 Priority:Low -> Priority:(Low)/Source:Internal 1356 (other transitions unchanged) 1358 State: Priority:(Low)/Source:Internal 1359 Signal: internal source 1360 Transitions: 1361 any -> Priority:(Low)/Source:Internal 1363 An example of processing that involves multiple "source" URNs and one 1364 "priority" URN: 1366 Alert-Info: , 1367 , 1368 1370 State: Priority/Source 1371 Process: Source:Internal (urn:alert:source:internal) 1372 State: Priority/Source:Internal 1373 Process: Source:Other (urn:alert:source:unclassified) 1374 State: Priority/Source:Internal 1375 Process: Priority:High (urn:alert:priority:high) 1376 State: Priority:High/Source:Internal 1377 Signal: internal source/high priority 1379 If the user agent receives 1381 Alert-Info: 1383 State: Priority/Source 1384 Process: Source:Internal (urn:alert:source:internal) 1385 State: Priority/Source:Internal 1386 Signal: internal source 1388 If the user agent receives 1390 Alert-Info: , 1391 1393 State: Priority/Source 1394 Process: Source:External (urn:alert:source:external) 1395 State: Priority/Source:External 1396 Process: Priority:Low (urn:alert:priority:low) 1397 State: Priority:Low/Source:External 1398 Signal: external source/low priority 1400 Suppose the same user agent receives 1402 Alert-Info: , 1403 1405 Note that there is no signal that corresponds to this combination. 1406 In that case, the processing is: 1408 State: Priority/Source 1409 Process: Source:Internal (urn:alert:source:internal) 1410 State: Priority/Source:Internal 1411 Process: Priority:Low (urn:alert:priority:low) 1412 State: Priority:(Low)/Source:Internal 1413 Signal: internal source 1415 If the order of the URNs is reversed, what is signaled is the meaning 1416 of now-different first URN: 1418 Alert-Info: , 1419 1421 State: Priority/Source 1422 Process: Priority:Low (urn:alert:priority:low) 1423 State: Priority:Low/Source 1424 Process: Source:Internal (urn:alert:source:internal) 1425 State: Priority:Low/Source:(Internal) 1426 Signal: low priority 1428 Notice that the existence of the new states prevents later URNs of a 1429 category from overriding earlier URNs of that category, even if the 1430 earlier one was not itself signalable and the later one would be 1431 signalable in the absence of the earlier one: 1433 Alert-Info: , 1434 , 1435 1437 State: Priority/Source 1438 Process: Priority:Low (urn:alert:priority:low) 1439 State: Priority:Low/Source 1440 Process: Source:Internal (urn:alert:source:internal) 1441 State: Priority:Low/Source:(Internal) 1442 Process: Source:External (urn:alert:source:external) 1443 State: Priority:Low/Source:(Internal) 1444 Signal: low priority 1446 This situation shows the necessity of states whose labels contain 1447 parentheses. If the second transition had been to the state 1448 Priority:Low/Source (on the basis that there is no proper state 1449 Priority:Low/Source:Internal), then the third transition would have 1450 been to the state Priority:Low/Source:External, and the signal would 1451 have been "external source/low priority". 1453 8. An Example that Subsets Internal Sources 1455 In the example of Section 4, there are signals for "external source" 1456 and "internal source". Let us add to that example a signal for 1457 "source internal from a VIP". That last signal expresses the private 1458 extension URN urn:alert:source:internal:vip@example, which is a 1459 subset of urn:alert:source:internal, which is expressed by the 1460 "source internal" signal. There is a total of 3 expressed URNs, one 1461 of which is a subset of another: 1463 urn:alert:source:internal 1464 urn:alert:source:internal:vip@example 1465 urn:alert:source:external 1467 This generates the following alphabet of symbols, which includes two 1468 Other symbols for the category source: 1470 Source 1471 Source:Internal 1472 Source:Internal:Vip@example 1473 Source:Internal:Other 1474 Source:Other 1476 9. An Example of "alert:service" URNs 1478 In this example there are signals for "service forward" (the call has 1479 been forwarded) and "source recall callback" (a recall due to a 1480 callback). This gives 2 expressed URNs: 1482 urn:alert:service:forward 1483 urn:alert:service:recall:callback 1485 This generates the following alphabet of symbols. Note that there 1486 are two "Other" symbols, because the "alert:service" URNs have an 1487 additional level of qualification. 1489 Service 1490 Service:Forward 1491 Service:Recall 1492 Service:Recall:Callback 1493 Service:Recall:Other 1494 Service:Other 1496 10. An Example Using Country Codes 1498 In this example, we consider how a UA generates ringback signals when 1499 the UA wishes to reproduce the traditional behavior that the caller 1500 hears the ringback signals defined by the telephone service in the 1501 callee's country, rather than the ringback signals defined by the 1502 service in the caller's country. In the Alert-Info header field of 1503 the 180 Ringing provisional response, we assume that the called UA 1504 provides an "alert:country" URN containing the ISO 3166-1 alpha-2 1505 country code of the callee's country. 1507 The UA has a default signal and a "non-country" signal for 1508 urn:alert:service:call-waiting. For the example country with code 1509 "XA", the UA has a default signal and signals for 1510 urn:alert:service:call-waiting and urn:alert:service:forward. For 1511 the example country with code "XB", the UA has a default signal and a 1512 signal for urn:alert:service:forward. These inconsistencies between 1513 the non-country signals and the country signals are chosen to 1514 demonstrate the flexibility of the construction method, showing that 1515 three systems of signals can be combined correctly even when the 1516 systems were established without coordination between them. 1518 The signals are: 1520 Signal URN(s) 1521 ---------------------------- ------------------------------- 1522 default (none) 1523 call-waiting urn:alert:service:call-waiting 1525 XA default urn:alert:country:xa 1526 XA call-waiting urn:alert:country:xa, 1527 urn:alert:service:call-waiting 1528 XA forward urn:alert:country:xa, 1529 urn:alert:service:forward 1531 XB default urn:alert:country:xb 1532 XB forward urn:alert:country:xb, 1533 urn:alert:service:forward 1535 The expressed URNs are: 1537 urn:alert:country:xa 1538 urn:alert:country:xb 1539 urn:alert:service:call-waiting 1540 urn:alert:service:forward 1542 The relevant categories of "alert" URNs are only: 1544 country 1545 service 1547 The alphabet of symbols is: 1549 Country 1550 Country:[other] 1551 Country:Xa 1552 Country:Xb 1553 Service 1554 Service:[other] 1555 Service:Call-waiting 1556 Service:Forward 1558 The 15 states are as follows: 1560 State: 0 Country/Service 1561 Signal: default 1562 Transitions: 1563 Country:[other] -> 1 Country:([other])/Service 1564 Country:Xa -> 5 Country:Xa/Service 1565 Country:Xb -> 9 Country:Xb/Service 1566 Service:[other] -> 13 Country/Service:([other]) 1567 Service:Call-waiting -> 14 Country/Service:Call-waiting 1568 Service:Forward -> 16 Country/Service:(Forward) 1570 State: 1 Country:([other])/Service 1571 Signal: default 1572 Transitions: 1573 Country:[other] -> 1 Country:([other])/Service 1574 Country:Xa -> 1 Country:([other])/Service 1575 Country:Xb -> 1 Country:([other])/Service 1576 Service:[other] -> 2 Country:([other])/Service:([other]) 1577 Service:Call-waiting -> 3 Country:([other])/Service:Call-waiting 1578 Service:Forward -> 4 Country:([other])/Service:(Forward) 1580 State: 2 Country:([other])/Service:([other]) 1581 Signal: default 1582 Transitions: 1583 any -> 2 Country:([other])/Service:([other]) 1585 State: 3 Country:([other])/Service:Call-waiting 1586 Signal: call-waiting 1587 Transitions: 1588 any -> 3 Country:([other])/Service:Call-waiting 1590 State: 4 Country:([other])/Service:(Forward) 1591 Signal: default 1592 Transitions: 1593 any -> 4 Country:([other])/Service:(Forward) 1595 State: 5 Country:Xa/Service 1596 Signal: XA default 1597 Transitions: 1598 Country:[other] -> 5 Country:Xa/Service 1599 Country:Xa -> 5 Country:Xa/Service 1600 Country:Xb -> 5 Country:Xa/Service 1601 Service:[other] -> 6 Country:Xa/Service:([other]) 1602 Service:Call-waiting -> 7 Country:Xa/Service:Call-waiting 1603 Service:Forward -> 8 Country:Xa/Service:Forward 1605 State: 6 Country:Xa/Service:([other]) 1606 Signal: XA default 1607 Transitions: 1608 any -> 6 Country:Xa/Service:([other]) 1610 State: 7 Country:Xa/Service:Call-waiting 1611 Signal: XA call-waiting 1612 Transitions: 1613 any -> 7 Country:Xa/Service:Call-waiting 1615 State: 8 Country:Xa/Service:Forward 1616 Signal: XA forward 1617 Transitions: 1618 any -> 8 Country:Xa/Service:Forward 1620 State: 9 Country:Xb/Service 1621 Signal: XB default 1622 Transitions: 1623 Country:[other] -> 9 Country:Xb/Service 1624 Country:Xa -> 9 Country:Xb/Service 1625 Country:Xb -> 9 Country:Xb/Service 1626 Service:[other] -> 10 Country:Xb/Service:([other]) 1627 Service:Call-waiting -> 11 Country:Xb/Service:(Call-waiting) 1628 Service:Forward -> 12 Country:Xb/Service:Forward 1630 State: 10 Country:Xb/Service:([other]) 1631 Signal: XB default 1632 Transitions: 1633 any -> 10 Country:Xb/Service:([other]) 1635 State: 11 Country:Xb/Service:(Call-waiting) 1636 Signal: XB default 1637 Transitions: 1638 any -> 11 Country:Xb/Service:(Call-waiting) 1640 State: 12 Country:Xb/Service:Forward 1641 Signal: XB forward 1642 Transitions: 1643 any -> 12 Country:Xb/Service:Forward 1645 State: 13 Country/Service:([other]) 1646 Signal: default 1647 Transitions: 1648 Country:[other] -> 2 Country:([other])/Service:([other]) 1649 Country:Xa -> 6 Country:Xa/Service:([other]) 1650 Country:Xb -> 10 Country:Xb/Service:([other]) 1651 Service:[other] -> 13 Country/Service:([other]) 1652 Service:Call-waiting -> 13 Country/Service:([other]) 1653 Service:Forward -> 13 Country/Service:([other]) 1655 State: 14 Country/Service:Call-waiting 1656 Signal: call-waiting 1657 Transitions: 1658 Country:[other] -> 3 Country:([other])/Service:Call-waiting 1659 Country:Xa -> 7 Country:Xa/Service:Call-waiting 1660 Country:Xb -> 15 Country:(Xb)/Service:Call-waiting 1661 Service:[other] -> 14 Country/Service:Call-waiting 1662 Service:Call-waiting -> 14 Country/Service:Call-waiting 1663 Service:Forward -> 14 Country/Service:Call-waiting 1665 State: 15 Country:(Xb)/Service:Call-waiting 1666 Signal: call-waiting 1667 Transitions: 1668 any -> 15 Country:(Xb)/Service:Call-waiting 1670 State: 16 Country/Service:(Forward) 1671 Signal: default 1672 Transitions: 1673 Country:[other] -> 4 Country:([other])/Service:(Forward) 1674 Country:Xa -> 8 Country:Xa/Service:Forward 1675 Country:Xb -> 12 Country:Xb/Service:Forward 1676 Service:[other] -> 16 Country/Service:(Forward) 1677 Service:Call-waiting -> 16 Country/Service:(Forward) 1678 Service:Forward -> 16 Country/Service:(Forward) 1680 Call-waiting can be signaled in conjunction with country XA, but not 1681 in conjunction with country XB as the UA does not have a signal to 1682 present call waiting alerts for country XB. Thus the ordering of 1683 urn:alert:service:call-waiting with urn:alert:country:xa does not 1684 matter, but if urn:alert:country:xb appears before 1685 urn:alert:service:call-waiting, call-waiting cannot be signaled. On 1686 the other hand, if urn:alert:service:call-waiting appears before 1687 urn:alert:country:xb, then call-waiting is signaled, but using the 1688 non-country signal. 1690 Alert-Info: urn:alert:country:xa, 1691 urn:alert:service:call-waiting 1693 State: 0 Country/Service 1694 Process: Country:Xa (urn:alert:country:xa) 1695 State: 5 Country:Xa/Service 1696 Process: Service:Call-waiting (urn:alert:service:call-waiting) 1697 State: 7 Country:Xa/Service:Call-waiting 1698 Signal: XA call-waiting 1700 Alert-Info: urn:alert:service:call-waiting, 1701 urn:alert:country:xa 1703 State: 0 Country/Service 1704 Process: Service:Call-waiting (urn:alert:service:call-waiting) 1705 State: 14 Country/Service:Call-waiting 1706 Process: Country:Xa (urn:alert:country:xa) 1707 State: 7 Country:Xa/Service:Call-waiting 1708 Signal: XA call-waiting 1710 Alert-Info: urn:alert:country:xb, 1711 urn:alert:service:call-waiting 1713 State: 0 Country/Service 1714 Process: Country:Xb (urn:alert:country:xb) 1715 State: 9 Country:Xb/Service 1716 Process: Service:Call-waiting (urn:alert:service:call-waiting) 1717 State: 11 Country:Xb/Service:(Call-waiting) 1718 Signal: XB default 1720 Alert-Info: urn:alert:service:call-waiting, 1721 urn:alert:country:xb 1723 State: 0 Country/Service 1724 Process: Service:Call-waiting (urn:alert:service:call-waiting) 1725 State: 14 Country/Service:Call-waiting 1726 Process: Country:Xb (urn:alert:country:xb) 1727 State: 15 Country:(Xb)/Service:Call-waiting 1728 Signal: call-waiting 1730 11. Prioritizing Signals 1732 The specifications in [RFC7462] are oriented toward giving the sender 1733 of Alert-Info control over which of the "alert" URNs are most 1734 important. But in some situations, the user agent may prefer to 1735 prioritize expressing one URN category over another regardless of the 1736 order their URNs appear in Alert-Info. This section describes how 1737 that can be accommodated within the framework of [RFC7462], and 1738 presents an example FSM resulting from that approach. 1740 This example uses the signals of Section 6, viz., "external source", 1741 "internal source", "low priority" and "high priority", but this time, 1742 we want to signal "high priority" in preference to any other signal 1743 that might be applicable. 1745 We accommodate this within the framework of [RFC7462] by assigning 1746 the signal "high priority" for each of these combinations of URNs: 1748 urn:alert:priority:high 1749 urn:alert:priority:high, urn:alert:source:internal 1750 urn:alert:priority:high, urn:alert:source:external 1752 The result is that the "high priority" signal is the "best" signal 1753 for any combination of urn:alert:priority:high with "source" URNs. 1755 The intermediate steps of the method produce the same results as 1756 before. The signals can express the following URNs: 1758 urn:alert:source:external 1759 urn:alert:source:internal 1760 urn:alert:priority:low 1761 urn:alert:priority:high 1763 The relevant categories of "alert" URNs are: 1765 source 1766 priority 1768 The alphabet of symbols is: 1770 Source 1771 Source:External 1772 Source:Internal 1773 Source:Other 1774 Priority 1775 Priority:Low 1776 Priority:High 1777 Priority:Other 1779 When the FSM is constructed, it is the same as the FSM for Section 6, 1780 except that certain states are effectively renamed and merged, 1781 because any "source" is defined to be expressed if high priority is 1782 expressed: 1784 Priority:(High)/Source:External and 1785 Priority:High/Source:(External) become: 1786 State: Priority:High/Source:External 1787 Signal: high priority 1789 Priority:(High)/Source:Internal and 1790 Priority:High/Source:(Internal) become: 1791 State: Priority:High/Source:Internal 1792 Signal: high priority 1794 This reduces the FSM to 18 states. In addition, these two new 1795 states, along with a number of other states, can be merged by FSM 1796 optimization, since all of them have the signal "high priority" and 1797 from them, there are no transitions to states outside this set. The 1798 final FSM has 10 states. 1800 12. Dynamic Sets of Signals 1802 This section discusses how to construct FSMs for a user agent that 1803 allows variable sets of signals, for example, if the user can 1804 configure the use of ringtones. Several approaches can be used: 1806 o Whenever the set of ringtones is changed, re-execute the processes 1807 of Section 4. 1809 o Whenever the set of ringtones is changed, rebuild the list of 1810 expressed URNs (Section 4.1) and reconstruct the alphabet of 1811 symbols (Section 4.2). Then use an algorithm for dynamically 1812 constructing states of the FSM as they are needed during Alert- 1813 Info processing. 1815 o If the sets of possible URNs expressed by the ringtones is 1816 sufficiently limited, the steps of Section 4 can be carried out 1817 "generically", and the generic FSM can be specialized for the 1818 current ringtone configuration. 1820 The remainder of this section gives an example of the third approach. 1822 For the example, we will use a set of ringtones that express the 1823 identify of the caller. To signal this information, a private 1824 extension "alert" URN category is used, "caller@example": 1826 urn:alert:caller@example:alice@example.com 1827 urn:alert:caller@example:bob@example.com 1828 etc. 1830 which we can express by the generic pattern 1831 urn:alert:caller@example:IDENTITY 1833 where "IDENTITY" is replaced in succession by the set of caller 1834 identities that have their own ringtones to generate the set of 1835 expressed URNs. 1837 The alphabet is then: 1839 Caller@example 1840 Caller@example:IDENTITY 1841 Caller@example:Other 1843 where "IDENTITY" is replaced in succession by the set of caller 1844 identities. The "Caller@example:Other" symbol includes all URNs of 1845 the category "caller@example" that are not included in any of the 1846 other symbols. 1848 The states and transitions of the FSM are: 1850 State: Caller@example (initial state) 1851 Signal: default 1852 Transitions: 1853 Caller@example:IDENTITY -> Caller@example:IDENTITY 1854 Caller@example:Other -> Caller@example:(Other) 1856 State: Caller@example:IDENTITY 1857 Signal: signal for caller IDENTITY 1858 Transitions: 1859 any -> Caller@example:IDENTITY 1861 State: Caller@example:(Other) 1862 Signal: default 1863 Transitions: 1864 any -> Caller@example:(Other) 1866 where again, the second state is replicated once for each caller 1867 identity that has a ringtone, with "IDENTITY" replaced with the 1868 caller identity. 1870 13. Revision History 1872 [Note to RFC Editor: Please remove this entire section upon 1873 publication as an RFC.] 1875 13.1. Changes from draft-worley-alert-info-fsm-07 to draft-worley- 1876 alert-info-fsm-08 1878 Correct the discussion in the example of Section 10. 1880 Revamp the introduction. 1882 Use the term "resolve" for processing "alert" URNs to select a 1883 signal. 1885 13.2. Changes from draft-worley-alert-info-fsm-06 to draft-worley- 1886 alert-info-fsm-07 1888 Editorial improvements from independent submission reviewer. 1890 13.3. Changes from draft-worley-alert-info-fsm-05 to draft-worley- 1891 alert-info-fsm-06 1893 Editorial improvements from independent submission reviewer. 1895 Add note at end of introduction that you can do this by hand in 1896 simple cases. 1898 Add the country-code example. 1900 13.4. Changes from draft-worley-alert-info-fsm-04 to draft-worley- 1901 alert-info-fsm-05 1903 Editorial improvements. 1905 13.5. Changes from draft-worley-alert-info-fsm-03 to draft-worley- 1906 alert-info-fsm-04 1908 Editorial improvements. 1910 13.6. Changes from draft-worley-alert-info-fsm-02 to draft-worley- 1911 alert-info-fsm-03 1913 Correct indenting of some lines. 1915 13.7. Changes from draft-worley-alert-info-fsm-01 to draft-worley- 1916 alert-info-fsm-02 1918 Recast exposition to feature the implementation of the construction 1919 algorithm. 1921 13.8. Changes from draft-worley-alert-info-fsm-00 to draft-worley- 1922 alert-info-fsm-01 1924 Reorganized the text, including describing how the FSM states are 1925 constructed. 1927 14. References 1929 14.1. Normative References 1931 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1932 A., Peterson, J., Sparks, R., Handley, M., and E. 1933 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1934 DOI 10.17487/RFC3261, June 2002, 1935 . 1937 [RFC7462] Liess, L., Ed., Jesske, R., Johnston, A., Worley, D., and 1938 P. Kyzivat, "URNs for the Alert-Info Header Field of the 1939 Session Initiation Protocol (SIP)", RFC 7462, 1940 DOI 10.17487/RFC7462, March 2015, 1941 . 1943 14.2. Informative References 1945 [code] Worley, D., "draft-worley-alert-info-fsm.aux", February 1946 2017, . 1949 Acknowledgments 1951 Thanks to Paul Kyzivat, whose relentless identification of the 1952 weaknesses of earlier versions made the final document much, much 1953 better than it would have been, by changing it from the exposition of 1954 a concept into a practical tool. Thanks to Rifaat Shekh-Yusef, Eric 1955 Burger, and Gonzalo Camarillo for their thorough reviews. Thanks to 1956 the Independent Submissions Editor, Nevil Brownlee, for his work 1957 obtaining reviewers. 1959 Author's Address 1961 Dale R. Worley 1962 Ariadne Internet Services 1963 738 Main St. 1964 Waltham, MA 02451 1965 US 1967 Email: worley@ariadne.com