[要約] RFC 8433は、Alert-Info URNの解決を簡素化する方法を提案している。目的は、Alert-Info URNの解決プロセスを効率化し、通信ネットワークのパフォーマンスを向上させることである。
Independent Submission D. Worley
Request for Comments: 8433 Ariadne
Category: Informational August 2018
ISSN: 2070-1721
A Simpler Method for Resolving Alert-Info URNs
Alert-Info URNを解決するためのより簡単な方法
Abstract
概要
The "alert" namespace of Uniform Resource Names (URNs) can be used in the Alert-Info header field of Session Initiation Protocol (SIP) requests and responses to inform a voice over IP (VoIP) telephone (user agent) of the characteristics of the call that the user agent has originated or terminated. The user agent must resolve the URNs into a signal; that is, it must select the best available signal to present to its user to indicate the characteristics of the call.
Uniform Resource Name（URN）の「アラート」名前空間は、Session Initiation Protocol（SIP）要求および応答のAlert-Infoヘッダーフィールドで使用して、Voice over IP（VoIP）電話（ユーザーエージェント）に次の特性を通知できます。ユーザーエージェントが発信または終了した通話。ユーザーエージェントは、URNを信号に解決する必要があります。つまり、コールの特性を示すために、ユーザーに提示するのに最適な信号を選択する必要があります。
RFC 7462 describes a non-normative algorithm for signal selection. This document describes a more efficient alternative algorithm: a user agent's designer can, based on the user agent's signals and their meanings, construct a finite state machine (FSM) to process the URNs to select a signal in a way that obeys the restrictions given in the definition of the "alert" URN namespace.
RFC 7462は、信号選択のための非規範的アルゴリズムを記述しています。このドキュメントでは、より効率的な代替アルゴリズムについて説明します。ユーザーエージェントの設計者は、ユーザーエージェントの信号とその意味に基づいて、有限状態マシン（FSM）を構築し、URNを処理して、以下に示す制限に従う方法で信号を選択できます。 「アラート」URN名前空間の定義。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFC Editorは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8433.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8433で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Governing Resolution Algorithms ...............4
1.2. Summary of the New Resolution Algorithm ....................5
1.3. Conventions Used in This Document ..........................7
2. Selecting the Signals and Their Corresponding "alert" URNs ......7
3. General Considerations for Processing Alert-Info ................9
4. Constructing the Finite State Machine for a Very Simple
Example ........................................................10
4.1. Listing the Expressed URNs ................................11
4.2. Constructing the Alphabet of Symbols ......................11
4.3. Constructing the States and Transitions ...................13
4.4. Summary ...................................................17
4.5. Examples of Processing Alert-Info URNs ....................19
5. Further Examples ...............................................20
5.1. Example with "source" and "priority" URNs .................20
5.2. Example 1 of RFC 7462 .....................................24
5.3. Examples 2, 3, and 4 of RFC 7462 ..........................30
5.4. An Example That Subsets Internal Sources ..................33
5.5. An Example of "alert:service" URNs ........................34
5.6. An Example Using Country Codes ............................34
6. Prioritizing Signals ...........................................40
7. Dynamic Sets of Signals ........................................41
8. Security Considerations ........................................43
9. IANA Considerations ............................................43
10. References ....................................................44
10.1. Normative References .....................................44
10.2. Informative References ...................................44
Acknowledgments ...................................................45
Author's Address ..................................................45
When a SIP user agent (UA) server receives an incoming INVITE request, it chooses an alerting signal (the ring tone) to present to its user (the called user) by processing the Alert-Info header field(s) in the incoming INVITE request [RFC3261]. Similarly, a SIP UA client determines an alerting signal (the ringback tone) to present to its user (the calling user) by processing the Alert-Info header field(s) in the incoming provisional response(s) to its outgoing INVITE request.
SIPユーザーエージェント（UA）サーバーは、着信INVITE要求を受信すると、着信INVITEのAlert-Infoヘッダーフィールドを処理して、ユーザー（着信ユーザー）に提示するアラート信号（呼び出し音）を選択します。リクエスト[RFC3261]。同様に、SIP UAクライアントは、発信INVITE要求に対する着信暫定応答のAlert-Infoヘッダーフィールドを処理することにより、ユーザー（呼び出し元ユーザー）に提示するアラート信号（リングバックトーン）を決定します。
[RFC3261] envisioned that the Alert-Info header field value would be a URL that the UA could use to retrieve the encoded media of the signal. This usage has security problems and is inconvenient to implement in practice.
[RFC3261]は、Alert-Infoヘッダーフィールド値が、UAが信号のエンコードされたメディアを取得するために使用できるURLになることを想定していました。この使用法にはセキュリティ上の問題があり、実際に実装するのは不便です。
[RFC7462] introduced an alternative practice: the Alert-Info values can be URNs in the "alert" URN namespace that specify features of the call or of the signal that should be signaled to the user. [RFC7462] defined a large set of "alert" URNs and procedures for extending the set.
[RFC7462]は代替の方法を導入しました：Alert-Info値は、ユーザーに通知する必要があるコールまたは信号の機能を指定する「アラート」URN名前空間のURNにすることができます。 [RFC7462]は、「アラート」URNの大規模なセットと、セットを拡張するための手順を定義しました。
A UA is unlikely to provide more than a small set of alerting signals, and there are an infinite number of possible combinations of "alert" URNs. Thus, a UA is often required to select an alerting signal that renders only a subset of the information in the Alert-Info header field(s) -- which is the resolution process for "alert" URNs. The requirements for resolving "alert" URNs are given in Section 11.1 of [RFC7462].
UAがアラート信号の小さなセット以上のものを提供することはほとんどなく、「アラート」URNの可能な組み合わせは無限にあります。したがって、UAは、「アラート」URNの解決プロセスであるAlert-Infoヘッダーフィールドの情報のサブセットのみをレンダリングするアラート信号を選択する必要があることがよくあります。 「アラート」URNを解決するための要件は、[RFC7462]のセクション11.1に記載されています。
Section 12 of [RFC7462] gives a (non-normative) resolution algorithm for selecting a signal that satisfies the requirements of Section 11.1 of that document. That algorithm can be used regardless of the set of alerting signals that the UA provides and their specified meanings. The existence of the algorithm defined in [RFC7462] demonstrates that the resolution requirements can always be satisfied. However, the algorithm is complex and slow.
[RFC7462]のセクション12は、そのドキュメントのセクション11.1の要件を満たす信号を選択するための（非規範的）解決アルゴリズムを示しています。このアルゴリズムは、UAが提供するアラート信号のセットとその指定された意味に関係なく使用できます。 [RFC7462]で定義されたアルゴリズムの存在は、解像度要件が常に満たされることを示しています。ただし、アルゴリズムは複雑で低速です。
The purpose of this document is to describe an improved implementation -- a more efficient resolution algorithm for selecting signals that conforms to the requirements of Section 11.1 of [RFC7462]. (Of course, like any such algorithm, it is non-normative, and the implementation is free to use any algorithm that conforms to the requirements of Section 11.1 of [RFC7462].)
このドキュメントの目的は、改良された実装、つまり[RFC7462]のセクション11.1の要件に準拠する信号を選択するためのより効率的な解決アルゴリズムを説明することです。 （もちろん、そのようなアルゴリズムと同様に、これは非規範的であり、実装は[RFC7462]のセクション11.1の要件に準拠する任意のアルゴリズムを自由に使用できます。）
In the algorithm defined in this document, once the UA designer has chosen the set of signals that the UA produces and the "alert" URNs that they express, a finite state machine (FSM) is constructed that selects alerting signals based on the URNs in the Alert-Info header field(s) in a SIP message. The incoming "alert" URNs are preprocessed in a straightforward manner into a sequence of "symbols" drawn from a fixed finite set; these symbols are then used as input to the FSM. After processing the input, the state of the FSM selects the correct alerting signal to present to the user.
このドキュメントで定義されているアルゴリズムでは、UAデザイナーがUAが生成する信号のセットと、それらが表す「アラート」URNを選択すると、有限状態マシン（FSM）が構築され、そのURNに基づいてアラート信号を選択しますSIPメッセージのAlert-Infoヘッダーフィールド。着信する「アラート」URNは、直接有限な方法で前処理されて、固定有限セットから抽出された一連の「シンボル」になります。これらのシンボルは、FSMへの入力として使用されます。入力を処理した後、FSMの状態は、ユーザーに提示する正しいアラート信号を選択します。
Both the preprocessor and the FSM are determined only by the selected set of signals and the set of "alert" URNs expressed by the signals, so the processing machinery can be fixed at the time of designing the UA.
プリプロセッサとFSMはどちらも、選択された信号のセットと、信号によって表される「アラート」URNのセットによってのみ決定されるため、UAの設計時に処理機械を修正できます。
The requirements for the resolution of "alert" URNs are given in Section 11.1 of [RFC7462] and can be described as follows:
「アラート」URNの解決の要件は[RFC7462]のセクション11.1に記載されており、次のように説明できます。
o The "alert" URNs are processed from left to right. Each "alert" URN has precedence over all URNs that follow it, and its interpretation is subordinate to all URNs that precede it.
o 「アラート」URNは左から右に処理されます。各「アラート」URNは、それに続くすべてのURNよりも優先され、その解釈は、それに先行するすべてのURNに従属します。
o As each URN is processed, one of the UA's signals is chosen that expresses that URN as far as can be done without reducing the degree to which any of the preceding URNs were expressed by the signal chosen for the preceding URN. Thus, as processing proceeds, the chosen signals become increasingly specific and contain more information, but all of the information about a particular URN that is expressed by the signal chosen for that URN is also expressed by the signals chosen for all following URNs.
o 各URNが処理されると、先行するURNに対して選択された信号によって先行URNが表現された度合いを低下させることなく実行できる限り、そのURNを表現するUAの信号の1つが選択されます。したがって、処理が進むにつれて、選択された信号は次第に固有になり、より多くの情報を含みますが、そのURNに対して選択された信号によって表される特定のURNに関するすべての情報は、後続のすべてのURNに対して選択された信号によっても表されます。
o If the entirety of the current URN cannot be expressed by any allowed signal, then each of the trailing alert-ind-parts (the sections separated by colons) is in turn removed until the reduced URN can be expressed by some signal that also expresses at least the same reduced versions of the preceding URNs that were expressed by the signal chosen for the preceding URN. This can be described as "a signal that expresses as much of the current URN as possible while still expressing as much of the previous URNs as the preceding signal did."
o 現在のURN全体が許可された信号で表現できない場合は、後続のAlert-ind-parts（コロンで区切られたセクション）が順番に削除され、削減されたURNが、前のURNに対して選択された信号によって表された前のURNの同じ縮小バージョン。これは、「現在のURNをできるだけ多く表現しながら、以前のURNを以前の信号と同じくらい多く表現する信号」と表現できます。
So, for instance, consider processing
したがって、たとえば、処理を検討してください
Alert-Info: urn:alert:category-a:part-a1:part-a2,
urn:alert:category-b:part-b1:part-b2
If the UA has no signal for urn:alert:category-a:part-a1:part-a2, it removes part-a2 from the URN and checks whether it has a signal for the less-specific URN urn:alert:category-a:part-a1. If it has no signal for that URN, it gives up on the URN entirely (since urn:alert:category-a doesn't exist and can be considered to express nothing about the call), and the chosen signal is the default signal of the UA, i.e., the signal that is used when there is no Alert-Info.
UAにurn：alert：category-a：part-a1：part-a2の信号がない場合、UAはURNからpart-a2を削除し、固有性の低いURN urn：alert：category-の信号があるかどうかを確認しますa：パート-a1。そのURNに対するシグナルがない場合は、URNを完全に放棄します（urn：alert：category-aは存在せず、呼び出しについて何も表現していないと見なすことができるため）、選択されたシグナルは、 UA、つまりAlert-Infoがない場合に使用される信号。
But let us suppose the UA has a signal for urn:alert:category-a:part-a1 and chooses that signal when processing the first URN. All processing after this point will be restricted to signals that express urn:alert:category-a:part-a1 or a more specific URN of the category "category-a".
しかし、UAにurn：alert：category-a：part-a1のシグナルがあり、最初のURNを処理するときにそのシグナルを選択するとします。この時点以降のすべての処理は、urn：alert：category-a：part-a1またはカテゴリ「category-a」のより具体的なURNを表す信号に制限されます。
The UA then goes on to examine the next URN, urn:alert:category-b:part-b1:part-b2. If there is a signal that expresses both urn:alert:category-a:part-a1 and urn:alert:category-b:part-b1:part-b2, then the UA chooses that signal. If there is no such signal, the second URN is reduced to urn:alert:category-b:part-b1, and the UA checks for a signal that expresses that URN along with urn:alert:category-a:part-a1. If there is no such signal that matches that relaxed requirement, the second URN is reduced to urn:alert:category-b, which is discarded, and the chosen signal for the first URN is chosen for the second URN. In any case, all processing after this point will be restricted to signals that express urn:alert:category-a:part-a1 or a more specific URN of the category "category-a" and that also express the chosen part of urn:alert:category-b:part-b1:part-b2.
次に、UAは次のURN urn：alert：category-b：part-b1：part-b2を調べます。 urn：alert：category-a：part-a1とurn：alert：category-b：part-b1：part-b2の両方を表す信号がある場合、UAはその信号を選択します。そのような信号がない場合、2番目のURNはurn：alert：category-b：part-b1に削減され、UAはurn：alert：category-a：part-a1とともにそのURNを表す信号をチェックします。その緩和された要件に一致するそのような信号がない場合、2番目のURNはurn：alert：category-bに削減され、破棄され、最初のURNに選択された信号が2番目のURNに選択されます。いずれの場合でも、この時点以降のすべての処理は、urn：alert：category-a：part-a1またはカテゴリ「category-a」のより具体的なURNを表し、urnの選択された部分も表す信号に制限されます。 alert：category-b：part-b1：part-b2。
This process is continued until the last "alert" URN is processed; the signal chosen for the last URN is the signal that the UA uses.
このプロセスは、最後の「アラート」URNが処理されるまで続行されます。最後のURNに選択された信号は、UAが使用する信号です。
The purpose of this document is to describe a resolution algorithm that conforms to Section 11.1 of [RFC7462] but is simpler than the algorithm described in Section 12 of [RFC7462]: once the UA designer has chosen a set of signals and the URNs that they express, an FSM is constructed that selects alerting signals based on the URNs in the Alert-Info header field(s) in a SIP message.
このドキュメントの目的は、[RFC7462]のセクション11.1に準拠するが、[RFC7462]のセクション12で説明されているアルゴリズムよりも簡単な解決アルゴリズムを説明することです。UAデザイナーが一連の信号とそのURNを選択すると、明示的に、FSMは、SIPメッセージのAlert-InfoヘッダーフィールドのURNに基づいてアラート信号を選択するように構築されます。
o The designer selects the set of signals that the UA produces, matching each signal to a set of "alert" URNs that together specify the meaning that is carried by the signal. (If the signal is a "default" signal that has no specific meaning, the set is empty. If the signal carries the meaning of one "alert" URN, the set contains that URN. If the signal carries a meaning that is the logical AND of two or more "alert" URNs, the set contains those URNs.)
o 設計者は、UAが生成する信号のセットを選択し、各信号を、信号によって伝えられる意味を一緒に指定する「アラート」URNのセットと照合します。 （シグナルが特定の意味を持たない「デフォルト」シグナルである場合、セットは空です。シグナルが1つの「アラート」URNの意味を運ぶ場合、セットはそのURNを含みます。シグナルが論理的な意味を持つ場合2つ以上の「アラート」URNのAND、およびセットにはそれらのURNが含まれます。）
o Based on the UA's signals and their meanings, the designer constructs an "alphabet" containing a finite number of symbols; each possible "alert" URN is mapped into one particular symbol.
o UAの信号とその意味に基づいて、デザイナーは有限数のシンボルを含む「アルファベット」を作成します。可能な「アラート」URNはそれぞれ、1つの特定のシンボルにマッピングされます。
o The designer constructs an FSM whose input is the alphabet of symbols and whose states describe the information extracted from the Alert-Info URNs.
o 設計者は、入力がシンボルのアルファベットであり、その状態がAlert-Info URNから抽出された情報を記述するFSMを構築します。
o Each state of the FSM has an associated signal. Processing the Alert-Info URNs will leave the FSM in some particular state; the UA renders the signal that is attached to that final state.
o FSMの各状態には、関連する信号があります。 Alert-Info URNを処理すると、FSMは特定の状態のままになります。 UAは、その最終状態に関連付けられている信号をレンダリングします。
To select a ring tone or ringback tone based on a SIP message, the UA processes the "alert" URNs in the Alert-Info header field from left to right. Initially, the FSM is in a designated initial state. The UA maps each successive URN into the corresponding symbol and then executes the state transition of the FSM specified by the symbol. The state of the FSM after processing the URNs determines which signal the UA will render to the user.
SIPメッセージに基づいて着信音または着信音を選択するために、UAはAlert-Infoヘッダーフィールドの「アラート」URNを左から右に処理します。最初、FSMは指定された初期状態にあります。 UAは、連続する各URNを対応するシンボルにマッピングし、そのシンボルで指定されたFSMの状態遷移を実行します。 URNの処理後のFSMの状態により、UAがユーザーに表示する信号が決まります。
Note that the UA generally has two FSMs, because a UA usually wants to signal different information in ring tones than it signals in ringback tones. One FSM is used to select the ring tone to render for an incoming INVITE request. The other FSM is used to select the ringback tone to render based on an incoming provisional response to an outgoing INVITE request. Both FSMs are constructed in the same way, but the constructions are based on different lists of signals and corresponding URNs.
UAは通常、リングバックトーンでシグナリングするのとは異なる情報をリングトーンでシグナリングしたいため、UAには通常2つのFSMがあることに注意してください。 1つのFSMを使用して、着信INVITE要求に対してレンダリングする着信音を選択します。もう1つのFSMは、発信INVITE要求に対する着信暫定応答に基づいてレンダリングするリングバックトーンを選択するために使用されます。両方のFSMは同じ方法で構築されますが、構築は信号と対応するURNの異なるリストに基づいています。
All of the steps of the method after the designer has selected the signals and their URNs are algorithmic, and the algorithm of those steps ensures that the operation of the FSM will satisfy the constraints of Section 11.1 of [RFC7462]. A Python implementation of the algorithmic steps is provided in [code].
設計者が信号とそのURNを選択した後のメソッドのすべてのステップはアルゴリズムに基づいており、それらのステップのアルゴリズムにより、FSMの動作が[RFC7462]のセクション11.1の制約を満たすことが保証されます。アルゴリズムのステップのPython実装が[コード]で提供されています。
In simple situations, a suitable FSM or equivalent ad hoc code can be constructed by hand using ad hoc analysis. Generally, this is only practical in situations where a small number of alert-categories and alert-indications are signaled and the categories interact in a simple, uniform way. For example, the examples in Sections 5.1 and 5.2 could be constructed by ad hoc analysis. But automatic processing is valuable if the situation is too complicated to construct a correct FSM by ad hoc analysis, or if the set of signals will change too frequently for human production to be economical.
単純な状況では、適切なFSMまたは同等のアドホックコードを、アドホック分析を使用して手動で作成できます。一般に、これは少数のアラートカテゴリとアラート表示が通知され、カテゴリが単純で均一な方法で相互作用する状況でのみ実用的です。たとえば、セクション5.1および5.2の例は、アドホック分析によって作成できます。しかし、状況が複雑すぎてアドホック分析で正しいFSMを構築できない場合や、信号のセットが頻繁に変化して人間の生産が経済的にならない場合は、自動処理が役立ちます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The designer must select signals that the UA will generate and define the meanings that the signals will have to the user. Based on this, the designer determines for each signal the "alert" URN or combination of "alert" URNs that (1) indicate that signal's meaning in SIP messages and (2) consequently should elicit that signal from the UA.
設計者は、UAが生成する信号を選択し、信号がユーザーに対して持つ意味を定義する必要があります。これに基づいて、設計者は各信号について「アラート」URNまたは「アラート」URNの組み合わせを決定します。これは、（1）SIPメッセージでの信号の意味を示し、（2）結果としてUAからその信号を引き出す必要があります。
For example, suppose the UA has a particular ring tone for calls from an external source. A call from an external source is marked with the URN urn:alert:source:external (specified in Section 9 of [RFC7462]). Thus, the table of signals includes:
たとえば、UAが外部ソースからの呼び出しに対して特定の呼び出し音を持っているとします。外部ソースからの呼び出しは、URN urn：alert：source：externalでマークされます（[RFC7462]のセクション9で指定）。したがって、信号の表には次のものが含まれます。
Signal URN(s)
---------------------------- -------------------------------
external source urn:alert:source:external
Similarly, if the UA has a particular ring tone for calls from an internal source, the table includes:
同様に、UAが内部ソースからの呼び出しに対して特定の呼び出しトーンを持っている場合、テーブルには次のものが含まれます。
Signal URN(s)
---------------------------- -------------------------------
internal source urn:alert:source:internal
If the UA has ring tones for calls that are marked as having higher or lower priority, then the table includes:
UAに、優先度が高いか低いとマークされているコールの呼び出しトーンがある場合、テーブルには次のものが含まれます。
Signal URN(s)
---------------------------- -------------------------------
high priority urn:alert:priority:high
low priority urn:alert:priority:low
Note that the UA must be able to signal for a message that has no "alert" URNs in the Alert-Info header field, which means that there must always be a default signal that has zero corresponding URNs:
UAは、Alert-Infoヘッダーフィールドに「アラート」URNがないメッセージを通知できる必要があることに注意してください。つまり、対応するURNがゼロのデフォルト信号が常に存在する必要があります。
Signal URN(s)
---------------------------- -------------------------------
default (none)
A signal can be defined to indicate a combination of conditions. For instance, a signal that is used only for high-priority, internal-source calls expresses two URNs and will only be used when both URNs are present in Alert-Info:
条件の組み合わせを示す信号を定義できます。たとえば、高優先度の内部ソース呼び出しにのみ使用される信号は2つのURNを表し、両方のURNがAlert-Infoに存在する場合にのみ使用されます。
Signal URN(s)
------------------------------ -------------------------------
high priority, internal source urn:alert:priority:high,
urn:alert:source:internal
A signal can be defined to cover a number of related conditions by specifying a URN that is the common prefix of the URNs for the various conditions. For instance, the URNs for "recall due to callback", "recall due to call hold", and "recall due to transfer" all start with urn:alert:service:recall, and so one signal can be provided for all of them by:
信号は、さまざまな条件のURNの共通のプレフィックスであるURNを指定することにより、いくつかの関連する条件をカバーするように定義できます。たとえば、「コールバックによるリコール」、「コールホールドによるリコール」、および「転送によるリコール」のURNはすべてurn：alert：service：recallで始まるため、これらすべてに1つのシグナルを提供できます。沿って：
Signal URN(s)
---------------------------- -------------------------------
recall urn:alert:service:recall
But if a specific signal is also provided for "recall due to callback" by this entry:
ただし、このエントリによって「コールバックによるリコール」のために特定のシグナルも提供されている場合：
Signal URN(s)
---------------------------- ---------------------------------
recall generally urn:alert:service:recall
recall due to callback urn:alert:service:recall:callback
then if the message contains urn:alert:service:recall:callback, the "recall due to callback" signal will be chosen instead of "recall generally" because the UA chooses the signal that most completely expresses the information in the Alert-Info header field.
次に、メッセージにurn：alert：service：recall：callbackが含まれている場合、UAがAlert-Infoヘッダーの情報を最も完全に表す信号を選択するため、「recall due to callback」ではなく「recall due to callback」信号が選択されます。フィールド。
The designer may wish to define extension URNs that provide more specific information about a call than the standard "alert" URNs do. One method is to add additional components to standard URNs. For instance, an extra-high priority could be indicated by the URN urn:alert:priority:high:extra@example. The final "extra@example" is an "alert-ind-part" that is a private extension. (See Sections 7 and 10.2 of [RFC7462] for a discussion of private extensions.) In any case, adding an alert-ind-part to a URN makes its meaning more specific, in that any call to which the longer URN can be applied can also have the shorter URN applied. In this case, "extra-high-priority calls" are considered a subset of "high-priority calls".
設計者は、標準の「アラート」URNよりも詳細なコール情報を提供する拡張URNを定義したい場合があります。 1つの方法は、標準のURNにコンポーネントを追加することです。たとえば、非常に高い優先度は、URN urn：alert：priority：high：extra @ exampleで示すことができます。最後の「extra @ example」は、プライベート拡張である「alert-ind-part」です。 （プライベート拡張の説明については、[RFC7462]のセクション7および10.2を参照してください。）いずれの場合でも、URNにalert-ind-partを追加すると、より長いURNを適用できる呼び出しで、その意味がより具体的になります。より短いURNを適用することもできます。この場合、「超優先コール」は「高優先コール」のサブセットと見なされます。
Signal URN(s)
--------------------- -----------------------------------------
high priority urn:alert:priority:high
extra-high priority urn:alert:priority:high:extra@example.com
Of course, for this extension to be useful, the senders of SIP messages (e.g., other UAs) must generate the extension URN in suitable circumstances.
もちろん、この拡張が役立つためには、SIPメッセージの送信者（他のUAなど）が適切な状況で拡張URNを生成する必要があります。
In some circumstances, the designer may want to create an entirely new category of "alert" URNs to indicate a type of information that is not indicated by any standard category of URNs. In that case, the designer uses a private extension as the alert-category (the third component of the URN), combined with whatever alert-ind-part (fourth component) values are desired. For example, a simplified version of the U.S. military security designations could be:
状況によっては、設計者が「アラート」URNのまったく新しいカテゴリを作成して、URNの標準カテゴリでは示されない情報のタイプを示す場合があります。その場合、設計者はプライベート拡張をアラートカテゴリ（URNの3番目のコンポーネント）として使用し、必要なアラートインパート（4番目のコンポーネント）値と組み合わせます。たとえば、米国の軍事安全保障指定の簡略版は次のようになります。
Signal URN(s)
----------------------- ---------------------------------------
unclassified urn:alert:security@example:unclassified
confidential urn:alert:security@example:confidential
secret urn:alert:security@example:secret
top secret urn:alert:security@example:top-secret
The designer should ensure that the new alert-category is orthogonal to all defined standard alert-categories, in that any combination of one of the new URNs with one of the standard URNs is meaningful in that there could be a message carrying both URNs.
新しいURNのいずれかと標準URNのいずれかとの任意の組み合わせが、両方のURNを運ぶメッセージが存在する可能性があるという意味で、新しいアラートカテゴリがすべての定義された標準アラートカテゴリに直交することを確認する必要があります。
In addition, the set of alert-ind-parts for the new alert-category should be comprehensive and disjoint, in that every message can be described by exactly one of them.
さらに、新しいアラートカテゴリのアラートインパートのセットは、すべてのメッセージをそれらの1つだけで説明できるという点で、包括的で互いに素である必要があります。
In this section, we will discuss various considerations that arise when processing Alert-Info. These have to be taken care of properly in order to conform to the standards, as well as to ensure a good user experience. But since they are largely independent of the generated FSM and its processing, they are gathered here in a separate section.
このセクションでは、Alert-Infoの処理時に発生するさまざまな考慮事項について説明します。これらは、標準に準拠し、優れたユーザーエクスペリエンスを保証するために、適切に処理する必要があります。ただし、これらは生成されたFSMとその処理から大きく独立しているため、ここでは別のセクションにまとめています。
The UA may have a number of different FSMs for processing URNs. Generally, there will be different FSMs for processing Alert-Info in incoming INVITE requests and for incoming provisional responses to outgoing INVITE requests. But any situation that changes the set of signals that the UA is willing to generate specifies a different set of signals and corresponding URNs and thus generates a different FSM.
UAは、URNを処理するためのいくつかの異なるFSMを持つことができます。通常、着信INVITE要求でAlert-Infoを処理するためと、発信INVITE要求に対する着信暫定応答のために、異なるFSMがあります。ただし、UAが生成しようとする信号のセットを変更する状況では、異なる信号のセットと対応するURNが指定されるため、異なるFSMが生成されます。
For example, if a call is active on the UA, all audible signals may become unavailable, or audible signals may be available only if urn:alert:priority:high is specified.
たとえば、UAで通話がアクティブな場合、すべての可聴信号が利用できなくなったり、urn：alert：priority：highが指定されている場合にのみ可聴信号が利用可能になる場合があります。
Similarly, if the set of signals is customized by user action or local policy, the generated FSM must be updated. This can be done by (1) regenerating it according to the method described here or (2) generating a "generic" FSM and instantiating it based on the available signals. (See Section 7 for a discussion of this.)
同様に、信号のセットがユーザーアクションまたはローカルポリシーによってカスタマイズされている場合、生成されたFSMを更新する必要があります。これは、（1）ここで説明する方法に従って再生成するか、（2）「汎用」FSMを生成して、使用可能な信号に基づいてインスタンス化することで実行できます。 （これについては、セクション7を参照してください。）
Note that the values in an Alert-Info header field are allowed to be URIs of any scheme and, within the "urn" scheme, are allowed to have any namespace [RFC3261]. The processing of URIs that are not "alert" URNs is not considered by this document, nor is that processing specified by [RFC7462]. But the algorithm designer must consider what to do with such URIs if they are encountered. The simplest choice is to ignore them. Alternatively, the algorithm may examine the URI to determine if it names an alerting signal or describes how to retrieve an alerting signal, and, if so, choose to render that signal rather than process the "alert" URNs to select a signal. In any case, the remainder of this document assumes that (1) the signal is to be chosen based on the "alert" URNs in Alert-Info and (2) all Alert-Info URIs that are not "alert" URNs have been removed.
Alert-Infoヘッダーフィールドの値は、任意のスキームのURIであることが許可され、「urn」スキーム内では、任意のネームスペースを持つことが許可されていることに注意してください[RFC3261]。 「アラート」URNではないURIの処理は、このドキュメントでは考慮されておらず、[RFC7462]で指定されている処理も考慮されていません。ただし、アルゴリズムの設計者は、このようなURIが発生した場合の対処法を検討する必要があります。最も簡単な選択はそれらを無視することです。または、アルゴリズムはURIを調べて、アラート信号に名前を付けるか、アラート信号を取得する方法を説明するかを決定し、そうであれば、「アラート」URNを処理して信号を選択するのではなく、その信号をレンダリングすることを選択します。いずれの場合でも、このドキュメントの残りの部分では、（1）Alert-Infoの「アラート」URNに基づいて信号が選択されること、および（2）「アラート」URNではないすべてのAlert-Info URIが削除されていることを前提としています。 。
The UA may also receive "alert" URNs that are semantically invalid in various ways. For example, the URN may have only three components, despite the fact that all valid "alert" URNs have at least one alert-ind-part and thus four components. The only useful strategy is to ignore such URNs (and possibly log them for analysis).
UAは、意味的に無効な「アラート」URNをさまざまな方法で受け取る場合もあります。たとえば、すべての有効な「アラート」URNには少なくとも1つのアラートインパート、つまり4つのコンポーネントがあるという事実にもかかわらず、URNには3つのコンポーネントしかない場合があります。唯一の有用な戦略は、そのようなURNを無視することです（そして、分析のためにログに記録することもできます）。
The method described here is robust in its handling of categories and alert-ind-parts that are unknown to the UA; as a consequence, it is also robust if they are not valid standardized URNs. Thus, these error conditions need not be handled specially.
ここで説明する方法は、UAに認識されていないカテゴリとアラートインパートの処理において堅牢です。結果として、それらが有効な標準化されたURNでない場合も堅牢です。したがって、これらのエラー状態を特別に処理する必要はありません。
Constructing the FSM involves:
FSMの構築には以下が含まれます。
1. Listing the URNs that are expressed by the various signals of the UA.
1. UAのさまざまな信号によって表されるURNのリスト。
2. From the expressed URNs, constructing the finite alphabet of symbols into which input URNs are mapped and that drive the state transitions of the FSM.
2. 表現されたURNから、入力URNがマップされ、FSMの状態遷移を駆動するシンボルの有限アルファベットを構築します。
3. Constructing the states of the FSM and the transitions between them.
3. FSMの状態とそれらの間の遷移の構築。
4. Selecting a signal to be associated with each FSM state.
4. 各FSM状態に関連付ける信号を選択します。
We will explain the process using a very simple example in which there are two signals -- one expressing "internal source" and one expressing "external source" -- along with a default signal (for when there is no source information to signal). The "internal source" signal expresses urn:alert:source:internal, and the "external source" signal expresses urn:alert:source:external.
「内部ソース」を表す信号と「外部ソース」を表す信号の2つの信号と、デフォルトの信号（信号を送るソース情報がない場合）がある非常に単純な例を使用して、プロセスを説明します。 「内部ソース」信号はurn：alert：source：internalを表し、「外部ソース」信号はurn：alert：source：externalを表します。
The first step is to establish for each of the UA's signals what call characteristics it represents, which is to say, the set of "alert" URNs that are its information content.
最初のステップは、UAの各信号に対して、それが表す呼び出し特性、つまり、その情報コンテンツである「アラート」URNのセットを確立することです。
Signal URN(s)
---------------------------- -------------------------------
default (none)
internal source urn:alert:source:internal
external source urn:alert:source:external
From the totality of these expressed URNs, the designer can then determine which sets of URNs must be distinguished from each other. In our simple example, the expressed URNs are:
これらの表現されたURNの全体から、設計者は、どのURNのセットを互いに区別する必要があるかを決定できます。簡単な例では、表現されたURNは次のとおりです。
urn:alert:source:external
urn:alert:source:internal
In order to reduce the infinite set of possible "alert" URNs to a finite alphabet of input symbols that cause the FSM's transitions, the designer must partition the "alert" URNs into a finite set of categories.
可能な「アラート」URNの無限セットを、FSMの遷移を引き起こす入力シンボルの有限アルファベットに減らすために、設計者は「アラート」URNをカテゴリーの有限セットに分割する必要があります。
Once we've listed all the expressed URNs, we can list all of the alert-categories that are relevant to the UA's signaling; "alert" URNs in any other alert-category cannot affect the signaling and can be ignored. (The easiest way to ignore the non-relevant URNs is to skip over them during Alert-Info processing. A more formal method is to map all of them into one "Other" symbol and then, for each state of the FSM, have the "Other" symbol transition to that same state.) Within each relevant alert-category, we now define a distinct symbol for every expressed URN and for all of their "ancestor" URNs (those that can be created by removing one or more trailing alert-ind-parts). In order to name the symbols in a way that distinguishes them from the corresponding URNs, we remove the initial "urn:alert:" and capitalize each alert-ind-part. Thus, in our example, we get these symbols:
表現されたすべてのURNをリストしたら、UAのシグナリングに関連するすべてのアラートカテゴリをリストできます。他のアラートカテゴリの「アラート」URNはシグナリングに影響を与えることができないため、無視できます。 （無関係なURNを無視する最も簡単な方法は、Alert-Info処理中にそれらをスキップすることです。より正式な方法は、それらすべてを1つの「その他」シンボルにマップし、FSMの各状態に対して、 「その他」のシンボルは同じ状態に遷移します。）関連する各アラートカテゴリ内で、表現されたすべてのURNとすべての「祖先」URN（1つ以上の後続アラートを削除することで作成できるURN）に個別のシンボルを定義します。 -ind-parts）。シンボルに対応するURNと区別する方法で名前を付けるために、最初の "urn：alert："を削除し、各アラートインパートを大文字にします。したがって、この例では、次のシンボルを取得します。
Source Source:External Source:Internal
ソースソース：外部ソース：内部
Note that there is a "Source" symbol even though there is no corresponding URN. (urn:alert:source is not a valid URN -- see Section 7 of [RFC7462] -- although the processing algorithm must be prepared to screen out such a purported URN if it appears in the Alert-Info header field.) However, its existence as a symbol will be useful later when we construct the FSM.
対応するURNがない場合でも、「ソース」記号があることに注意してください。 （urn：alert：sourceは有効なURNではありません-[RFC7462]のセクション7をご覧ください-ただし、Alert-InfoヘッダーフィールドにこのようなURNが表示された場合、そのようなURNを排除するために処理アルゴリズムを準備する必要があります）。ただし、シンボルとしての存在は、後でFSMを構築するときに役立ちます。
For each of these symbols, we add a symbol that classifies URNs that extend the symbol's corresponding URN with alert-ind-parts that cannot be expressed by signals:
これらのシンボルごとに、シンボルに対応するURNを拡張するURNを分類するシンボルを追加します。これは、シグナルでは表現できないアラートインパートです。
Source:Other
Source:External:Other
Source:Internal:Other
The latter two classify URNs, such as urn:alert:source:external:foo@example, that extend URNs that we already have symbols for. The first is for classifying URNs, such as urn:alert:source:bar@example, that have first alert-ind-parts that contradict all the "source" URNs that the UA can signal.
後者の2つは、urn：alert：source：external：foo @ exampleなど、すでにシンボルがあるURNを拡張するURNを分類します。 1つ目は、urn：alert：source：bar @ exampleなど、UAが通知できるすべての「ソース」URNと矛盾する最初のalert-ind-partsがあるURNを分類するためのものです。
These steps give us this set of symbols:
これらの手順により、次の一連のシンボルが得られます。
Source Source:External Source:External:Other Source:Internal Source:Internal:Other Source:Other
ソースソース：外部ソース：外部：その他ソース：内部ソース：内部：その他ソース：その他
We can then simplify the set of symbols by removing the ones like Source:External:Other and Source:Internal:Other that consist of adding "Other" to a symbol that corresponds to an expressed URN that is not ancestral to any other expressed URNs. This works because adding further alert-ind-parts to a URN that is a leaf in regard to the set of signals has no additional effect. In this example, urn:alert:source:external:foo@example has the same effect as urn:alert:source:external for both (1) causing a signal to be chosen and (2) suppressing the effect of later URNs.
次に、他の表現されたURNの祖先ではない表現されたURNに対応するシンボルに「その他」を追加することで構成されるSource：External：OtherやSource：Internal：Otherのようなものを削除することにより、シンボルのセットを簡略化できます。これは、シグナルのセットに関してリーフであるURNにさらにalert-ind-partsを追加しても追加の効果がないため機能します。この例では、urn：alert：source：external：foo @ exampleはurn：alert：source：externalと同じ効果があり、（1）信号が選択され、（2）以降のURNの効果が抑制されます。
This leaves the following symbols for the "source" category:
これにより、「ソース」カテゴリに次の記号が残ります。
Source Source:External Source:Internal Source:Other
ソースソース：外部ソース：内部ソース：その他
These can be visually summarized by showing the infinite tree of possible source "alert" URNs and how it is partitioned into subtrees that map to each of these symbols. We also mark with "*" the expressed URNs.
これらは、考えられるソース「アラート」URNの無限ツリーと、これらの各シンボルにマップするサブツリーに分割される方法を示すことにより、視覚的に要約できます。また、表現されたURNを「*」でマークします。
urn:alert
|
{ | }
{ source } --> 1
{ | }
|
+--------------------+------------------+
| | |
{ | } { | } { | }
{ external* } --> 2 { internal* } --> 3 { ... } --> 4
{ | } { | } { }
{ ... } { ... }
{ } { }
1 = Source
2 = Source:External
3 = Source:Internal
4 = Source:Other
The UA processes the Alert-Info URNs from left to right using an FSM, with each successive URN causing the FSM to transition to a new state. Each state of the FSM records the information that has so far been extracted from the URNs. The state of the FSM after processing all the URNs determines which signal the UA will render to the user.
UAは、FSMを使用してAlert-Info URNを左から右に処理します。連続する各URNにより、FSMは新しい状態に移行します。 FSMの各状態は、これまでにURNから抽出された情報を記録します。すべてのURNを処理した後のFSMの状態により、UAがユーザーに表示する信号が決まります。
We label each state with a set of symbols, one from each relevant category, that describe the information that's been extracted from all of the URNs that have so far been processed. The initial state is labeled with the "null" symbols that are just the category names, because no information has yet been recorded. In our simple example, the initial state is labeled "Source", since that's the only relevant category.
各状態には、関連する各カテゴリから1つずつ、これまでに処理されたすべてのURNから抽出された情報を表す一連の記号でラベルを付けます。情報がまだ記録されていないため、初期状態には、単にカテゴリ名である「null」記号が付いています。簡単な例では、初期状態は「ソース」というラベルが付けられています。これが唯一の関連カテゴリだからです。
State: Source (initial state)
状態：ソース（初期状態）
Each state has a corresponding alerting signal, which is the signal that the UA will produce when URN processing leaves the FSM in that state. The signal is the one that best expresses the information that has been extracted from the URNs. Usually, the choice of signal is obvious to the designer, but there are certain constraints that the choice must satisfy. The main constraint is that the signal's expressed URNs must be semantic supersets of (i.e., identical to or a prefix of) the URNs corresponding to the symbols in the state's label. In particular, if the expressed URN of the signal in a certain category is shorter than the state's label, we show that in the state's name by putting parentheses around the trailing part of the symbol that is not expressed by the signal. For instance, if the symbol in the label is "Source:External" but the signal only expresses "Source" (i.e., no "source" URN at all), then the symbol in the label is modified to be "Source:(External)".
各状態には対応するアラート信号があり、これはURN処理がFSMをその状態のままにしたときにUAが生成する信号です。信号は、URNから抽出された情報を最もよく表す信号です。通常、信号の選択は設計者には明白ですが、選択が満たす必要がある特定の制約があります。主な制約は、信号の表現されたURNが、状態のラベル内のシンボルに対応するURNのセマンティックスーパーセット（つまり、そのプレフィックス）でなければならないことです。特に、特定のカテゴリの信号の表現されたURNが州のラベルより短い場合は、信号で表現されていないシンボルの末尾部分を括弧で囲むことにより、州の名前でそれを示します。たとえば、ラベルのシンボルが "Source：External"であるが、信号が "Source"のみを表す（つまり、 "source" URNがまったくない）場合、ラベルのシンボルは "Source：（External"に変更されます。 ）」
The reason for this nonintuitive construction is that in some states, the FSM has recorded information that the chosen signal cannot express.
この直感的でない構造の理由は、一部の州では、FSMが選択した信号が表現できない情報を記録しているためです。
Note that the parentheses are part of the state name, so in some circumstances there may be two or more distinct states labeled with the same symbols but with different placement of parentheses within the symbols. These similar state names are relevant when the FSM can record information from multiple "alert" URNs but cannot express all of them -- depending on the order in which the URNs appear, the UA may have to render different signals, so it needs states that record the same information but render different subsets of that information.
括弧は状態名の一部であるため、状況によっては、同じ記号でラベル付けされた2つ以上の異なる状態があり、記号内の括弧の配置が異なる場合があります。これらの同様の状態名は、FSMが複数の「アラート」URNからの情報を記録できるが、それらのすべてを表現できない場合に関連します。URNが出現する順序によっては、UAが異なる信号をレンダリングする必要がある場合があるため、次の状態が必要です。同じ情報を記録しますが、その情報の異なるサブセットをレンダリングします。
The initial state's label is the string of null symbols for the relevant categories, so the only allowed signal is the default signal, which expresses no URNs:
初期状態のラベルは、関連するカテゴリのnullシンボルの文字列であるため、許可される信号はデフォルトの信号のみであり、URNを表しません。
State: Source (initial state) Signal: default
状態：ソース（初期状態）信号：デフォルト
From each state, we must construct the transition for each possible input symbol. For a particular current state and symbol, we construct the label of the next state by combining the input symbol with the symbol in the current state's label for the same category. If one of the symbols is a prefix of the other, we select the longer one; if not, we select the symbol in the current state's label.
各状態から、可能な入力シンボルごとに遷移を作成する必要があります。特定の現在の状態とシンボルについて、同じカテゴリの現在の状態のラベルにあるシンボルと入力シンボルを組み合わせて、次の状態のラベルを作成します。シンボルの1つが他のシンボルのプレフィックスである場合、長い方を選択します。そうでない場合は、現在の状態のラベルでシンボルを選択します。
Thus, in our simple example, the initial state has the following transitions:
したがって、この簡単な例では、初期状態には次の遷移があります。
State: Source (initial state)
Signal: default
Transitions:
Source:External -> Source:External
Source:Internal -> Source:Internal
Source:Other -> Source:Other
In all of these transitions, the input symbol is compatible with the matching label of the current state, "Source", so the next state's label is the full input symbol.
これらすべての遷移では、入力シンボルは現在の状態の一致するラベル「ソース」と互換性があるため、次の状態のラベルは完全な入力シンボルです。
However, there is a further constraint on the next state: its signal must express URNs that at least contain the expressed URNs of the signal of the current state. Within that constraint, and being compatible with the next state's label, for the category of the input URN, the next state's signal must express the longest URN that can be expressed by any signal.
ただし、次の状態にはさらに制約があります。その信号は、現在の状態の信号の表現されたURNを少なくとも含むURNを表現する必要があります。その制約内で、次の状態のラベルと互換性があるため、入力URNのカテゴリーでは、次の状態の信号は、任意の信号で表現できる最も長いURNを表す必要があります。
In our example, this means that the next Source:External state has the "external source" signal, which expresses urn:alert:source:external. Since that signal expresses all of the state's label, it is the chosen state. Similarly, the next Source:Internal state has the "internal source" signal. But for the transition on input Source:Other, the "Source:Other" state must have the default signal, as there is no signal that expresses urn:alert:source:[some-unknown-alert-ind-part]. So the next state is "Source:(Other)", where the parentheses record that the "Other" part of the label is not expressed by the state's signal.
この例では、これは、次のSource：External状態が「external source」信号を持ち、urn：alert：source：externalを表すことを意味します。その信号は州のすべてのラベルを表すので、選択された州です。同様に、次のSource：Internal状態には「内部ソース」信号があります。ただし、入力Source：Otherでの遷移の場合、urn：alert：source：[some-unknown-alert-ind-part]を表す信号がないため、「Source：Other」状態にはデフォルト信号が必要です。したがって、次の状態は "Source：（Other）"です。括弧は、ラベルの "Other"部分が状態の信号によって表現されていないことを記録します。
Thus, the current state and the next states that it can transition to are:
したがって、遷移できる現在の状態と次の状態は次のとおりです。
State: Source (initial state)
Signal: default
Transitions:
Source:External -> Source:External
Source:Internal -> Source:Internal
Source:Other -> Source:(Other)
State: Source:External
Signal: external source (urn:alert:source:external)
State: Source:Internal
Signal: internal source (urn:alert:source:internal)
State: Source:(Other) Signal: default
状態：ソース：（その他）信号：デフォルト
Looking at the state Source:External, we see that it is incompatible with all input symbols other than Source:External, and thus all of its transitions are to itself:
状態Source：Externalを見ると、Source：External以外のすべての入力シンボルと互換性がないことがわかります。したがって、その遷移はすべてそれ自体に対して行われます。
State: Source:External
Signal: external source (urn:alert:source:external)
Transitions:
Source:External -> Source:External
Source:Internal -> Source:External
Source:Other -> Source:External
and similarly:
同様に：
State: Source:Internal
Signal: internal source (urn:alert:source:internal)
Transitions:
Source:External -> Source:Internal
Source:Internal -> Source:Internal
Source:Other -> Source:Internal
State: Source:(Other)
Signal: default
Transitions:
Source:External -> Source:(Other)
Source:Internal -> Source:(Other)
Source:Other -> Source:(Other)
The FSM can be constructed by processing the file "very-simple.txt" with the program "alert-info-fsm.py" in [code]. The program's output shows the stages of the construction, which are as follows:
FSMは、[very-simple.txt]ファイルを[code]のプログラム "alert-info-fsm.py"で処理することで構築できます。プログラムの出力は、次のような構築の段階を示しています。
1. The signals have the meanings:
1. 信号の意味は次のとおりです。
Signal URN(s)
---------------------------- -------------------------------
default (none)
internal source urn:alert:source:internal
external source urn:alert:source:external
2. The expressed URNs are:
2. 表現されるURNは次のとおりです。
urn:alert:source:external
urn:alert:source:internal
3. The relevant categories of "alert" URNs are only:
3. 「アラート」URNの関連カテゴリは次のとおりです。
source
ソース
4. Thus, the infinite universe of possible "alert" URNs can be reduced to these symbols, which are the categories of URNs that are different in ways that are significant to the resolution process:
4. したがって、可能な「アラート」URNの無限のユニバースは、解決プロセスにとって重要な方法で異なるURNのカテゴリーである次のシンボルに削減できます。
Source Source:External Source:Internal Source:Other
ソースソース：外部ソース：内部ソース：その他
5. The FSM is:
5. FSMは次のとおりです。
State: Source (initial state)
Signal: default
Transitions:
Source:External -> Source:External
Source:Internal -> Source:Internal
Source:Other -> Source:(Other)
State: Source:External
Signal: external source (urn:alert:source:external)
Transitions:
Source:External -> Source:External
Source:Internal -> Source:External
Source:Other -> Source:External
State: Source:Internal
Signal: internal source (urn:alert:source:internal)
Transitions:
Source:External -> Source:Internal
Source:Internal -> Source:Internal
Source:Other -> Source:Internal
State: Source:(Other)
Signal: default
Transitions:
Source:External -> Source:(Other)
Source:Internal -> Source:(Other)
Source:Other -> Source:(Other)
* Each state is labeled by a set of symbols that describe the information that has been extracted from the URNs so far.
* 各状態は、これまでにURNから抽出された情報を説明する一連の記号でラベル付けされています。
* Each state has a signal that is a semantic superset of the state's label, i.e., the signal's expressed URNs match the initial portion of the label symbols. If Alert-Info processing finishes with the FSM in a state, the UA will render the state's signal to the user.
* 各状態には、状態のラベルのセマンティックスーパーセットである信号があります。つまり、信号の表現されたURNはラベルシンボルの最初の部分と一致します。 FSMがある状態でAlert-Info処理が完了すると、UAは状態の信号をユーザーにレンダリングします。
* The state's label is marked to show what subset of the symbols are expressed by the state's signal. Two states can have the same label but different signals.
* 状態のラベルは、状態の信号によって表されるシンボルのサブセットを示すためにマークされます。 2つの状態は同じラベルを持つことができますが、信号は異なります。
* If a transition's input symbol is compatible with (is a semantic subset of) the current state's label for that category, the next state's label is updated with the input symbol. If not, the next state is the current state. This is how the state's label records what information has been accumulated while processing the Alert-Info URNs.
* 遷移の入力シンボルがそのカテゴリの現在の状態のラベルと互換性がある（その意味的サブセットである）場合、次の状態のラベルは入力シンボルで更新されます。そうでない場合、次の状態は現在の状態です。これは、状態のラベルがAlert-Info URNの処理中に蓄積された情報を記録する方法です。
* A transition's next state has a signal that semantically subsets the current state's signal as much as possible in the category of the input symbol. (In most cases, the choice of signal is unique. In rare cases, there may be more than one signal that meets this criterion, so the designer may have some flexibility.)
* 遷移の次の状態には、現在の状態の信号を意味的に入力シンボルのカテゴリで可能な限りサブセット化する信号があります。 （ほとんどの場合、信号の選択は一意です。まれに、この基準を満たす信号が複数存在する可能性があるため、設計者にある程度の柔軟性がある場合があります。）
In the trivial case where the UA receives no Alert-Info URNs, processing begins and ends with the FSM in the initial state, and the default signal is selected.
UAがAlert-Info URNを受信しない些細なケースでは、初期状態のFSMで処理が開始および終了し、デフォルトの信号が選択されます。
If the UA receives
UAが受信した場合
Alert-Info: <urn:alert:source:internal>
then processing progresses:
その後、処理が進行します。
State: Source
Process: Source:Internal (urn:alert:source:internal)
State: Source:Internal
Signal: internal source
If the UA receives
UAが受信した場合
Alert-Info: <urn:alert:source:external>,
<urn:alert:source:internal>
then processing progresses:
その後、処理が進行します。
State: Source
Process: Source:External (urn:alert:source:external)
State: Source:External
Process: Source:Internal (urn:alert:source:internal)
State: Source:External
Signal: external source
If the UA receives
UAが受信した場合
Alert-Info: <urn:alert:source:unclassified>,
<urn:alert:source:internal>
then processing progresses:
その後、処理が進行します。
State: Source
Process: Source:Other (urn:alert:source:unclassified)
State: Source:(Other)
Process: Source:Internal (urn:alert:source:internal)
State: Source:(Other)
Signal: default
If the UA receives
UAが受信した場合
Alert-Info: <urn:alert:priority:high>,
<urn:alert:source:internal>
then processing progresses:
その後、処理が進行します。
State: Source
Ignore: urn:alert:priority:high
State: Source
Process: Source:Internal (urn:alert:source:internal)
State: Source:Internal
Signal: internal source
Now consider an example where the UA can signal "external source", "internal source", "low priority", and "high priority" individually or in any combination of source and priority, along with a default signal. This example is essentially the Cartesian product of two copies of the example in Section 4: one dealing with the call's source and one dealing with the call's priority. So there are a total of 9 signals:
ここで、UAが「外部ソース」、「内部ソース」、「低優先度」、および「高優先度」を個別に、またはソースと優先度の任意の組み合わせで、デフォルトの信号とともに通知できる例を考えます。この例は基本的に、セクション4の例の2つのコピーのデカルト積です。1つは呼び出しのソースを扱い、もう1つは呼び出しの優先度を扱います。したがって、合計9つの信号があります。
Signal URN(s)
---------------------------- -------------------------------
default (none)
external source urn:alert:source:external
internal source urn:alert:source:internal
low priority urn:alert:priority:low
low priority/external source urn:alert:priority:low,
urn:alert:source:external
low priority/internal source urn:alert:priority:low,
urn:alert:source:internal
high priority urn:alert:priority:high
high priority/external source urn:alert:priority:high,
urn:alert:source:external
high priority/internal source urn:alert:priority:high,
urn:alert:source:internal
The expressed URNs are:
表現されるURNは次のとおりです。
urn:alert:source:external
urn:alert:source:internal
urn:alert:priority:low
urn:alert:priority:high
The relevant categories of "alert" URNs are only:
「アラート」URNの関連カテゴリは次のとおりです。
source priority
ソースの優先度
The alphabet of symbols is:
記号のアルファベットは次のとおりです。
Source Source:External Source:Internal Source:Other Priority Priority:Low Priority:High Priority:Other
ソースソース：外部ソース：内部ソース：その他の優先度優先度：低優先度：高優先度：その他
The 16 states are as follows, where 9 states are "sink" states from which no further information can be recorded, as all transitions from the state lead to itself.
16の状態は次のとおりです。9つの状態は「シンク」状態であり、状態からのすべての遷移がそれ自体につながるため、それ以上の情報を記録できません。
State: Priority/Source
Signal: default
Transitions:
Priority:Other -> Priority:(Other)/Source
Priority:High -> Priority:High/Source
Priority:Low -> Priority:Low/Source
Source:Other -> Priority/Source:(Other)
Source:External -> Priority/Source:External
Source:Internal -> Priority/Source:Internal
State: Priority:(Other)/Source
Signal: default
Transitions:
Priority:Other -> Priority:(Other)/Source
Priority:High -> Priority:(Other)/Source
Priority:Low -> Priority:(Other)/Source
Source:Other -> Priority:(Other)/Source:(Other)
Source:External -> Priority:(Other)/Source:External
Source:Internal -> Priority:(Other)/Source:Internal
State: Priority:(Other)/Source:(Other)
Signal: default
Transitions:
any -> Priority:(Other)/Source:(Other)
State: Priority:(Other)/Source:External
Signal: external source
Transitions:
any -> Priority:(Other)/Source:External
State: Priority:(Other)/Source:Internal
Signal: internal source
Transitions:
any -> Priority:(Other)/Source:Internal
State: Priority:High/Source
Signal: high priority
Transitions:
Priority:Other -> Priority:High/Source
Priority:High -> Priority:High/Source
Priority:Low -> Priority:High/Source
Source:Other -> Priority:High/Source:(Other)
Source:External -> Priority:High/Source:External
Source:Internal -> Priority:High/Source:Internal
State: Priority:High/Source:(Other)
Signal: high priority
Transitions:
any -> Priority:High/Source:(Other)
State: Priority:High/Source:External
Signal: high priority/external source
Transitions:
any -> Priority:High/Source:External
State: Priority:High/Source:Internal
Signal: high priority/internal source
Transitions:
any -> Priority:High/Source:Internal
State: Priority:Low/Source
Signal: low priority
Transitions:
Priority:Other -> Priority:Low/Source
Priority:High -> Priority:Low/Source
Priority:Low -> Priority:Low/Source
Source:Other -> Priority:Low/Source:(Other)
Source:External -> Priority:Low/Source:External
Source:Internal -> Priority:Low/Source:Internal
State: Priority:Low/Source:(Other)
Signal: low priority
Transitions:
any -> Priority:Low/Source:(Other)
State: Priority:Low/Source:External
Signal: low priority/external source
Transitions:
any -> Priority:Low/Source:External
State: Priority:Low/Source:Internal
Signal: low priority/internal source
Transitions:
any -> Priority:Low/Source:Internal
State: Priority/Source:(Other)
Signal: default
Transitions:
Priority:Other -> Priority:(Other)/Source:(Other)
Priority:High -> Priority:High/Source:(Other)
Priority:Low -> Priority:Low/Source:(Other)
Source:Other -> Priority/Source:(Other)
Source:External -> Priority/Source:(Other)
Source:Internal -> Priority/Source:(Other)
State: Priority/Source:External
Signal: external source
Transitions:
Priority:Other -> Priority:(Other)/Source:External
Priority:High -> Priority:High/Source:External
Priority:Low -> Priority:Low/Source:External
Source:Other -> Priority/Source:External
Source:External -> Priority/Source:External
Source:Internal -> Priority/Source:External
State: Priority/Source:Internal
Signal: internal source
Transitions:
Priority:Other -> Priority:(Other)/Source:Internal
Priority:High -> Priority:High/Source:Internal
Priority:Low -> Priority:Low/Source:Internal
Source:Other -> Priority/Source:Internal
Source:External -> Priority/Source:Internal
Source:Internal -> Priority/Source:Internal
An example of processing that involves multiple "source" URNs and one "priority" URN:
複数の「ソース」URNと1つの「優先」URNを伴う処理の例：
Alert-Info: <urn:alert:source:internal>,
<urn:alert:source:unclassified>,
<urn:alert:priority:high>
in which case processing progresses:
その場合、処理が進行します。
State: Source/Priority
Process: Source:Internal (urn:alert:source:internal)
State: Source:Internal/Priority
Process: Source:(Other) (urn:alert:source:unclassified)
State: Source:Internal/Priority
Process: Priority:High (urn:alert:priority:high)
State: Source:Internal/Priority:High
Signal: internal source/high priority
A more complicated example is provided in Section 12.2.1 of [RFC7462]. It is like the example in Section 5.1 of this document, except that the UA can only signal "external source", "internal source", "low priority", and "high priority" individually but not in combination, as well as a default signal:
より複雑な例は、[RFC7462]のセクション12.2.1にあります。これは、UAが「外部ソース」、「内部ソース」、「低優先度」、および「高優先度」を個別にのみ通知でき、組み合わせてではなく、デフォルトだけを通知できることを除いて、このドキュメントのセクション5.1の例に似ています。信号：
Signal URN(s)
---------------------------- -------------------------------
default (none)
internal source urn:alert:source:external
external source urn:alert:source:internal
low priority urn:alert:priority:low
high priority urn:alert:priority:high
The signals can express the following URNs:
信号は次のURNを表すことができます。
urn:alert:source:external
urn:alert:source:internal
urn:alert:priority:low
urn:alert:priority:high
The relevant categories of "alert" URNs are:
「アラート」URNの関連カテゴリは次のとおりです。
source priority
ソースの優先度
The alphabet of symbols is:
記号のアルファベットは次のとおりです。
Source Source:External Source:Internal Source:Other Priority Priority:Low Priority:High Priority:Other
ソースソース：外部ソース：内部ソース：その他の優先度優先度：低優先度：高優先度：その他
In this example, the FSM has 20 states because both "source" and "priority" URNs are recorded, but the order in which the two appear affects the signal:
この例では、「ソース」と「優先度」の両方のURNが記録されるため、FSMには20の状態がありますが、2つが現れる順序は信号に影響します。
State: Priority/Source
Signal: default
Transitions:
Priority:Other -> Priority:(Other)/Source
Priority:High -> Priority:High/Source
Priority:Low -> Priority:Low/Source
Source:Other -> Priority/Source:(Other)
Source:External -> Priority/Source:External
Source:Internal -> Priority/Source:Internal
State Priority:(Other)/Source can transition to states that can signal the source, because the recorded priority can't be signaled and thus does not block the signaling of the source:
状態の優先度：（その他）/ソースは、ソースを通知できる状態に遷移できます。これは、記録された優先度を通知できないため、ソースの通知をブロックしないためです。
State: Priority:(Other)/Source
Signal: default
Transitions:
Priority:Other -> Priority:(Other)/Source
Priority:High -> Priority:(Other)/Source
Priority:Low -> Priority:(Other)/Source
Source:Other -> Priority:(Other)/Source:(Other)
Source:External -> Priority:(Other)/Source:External
Source:Internal -> Priority:(Other)/Source:Internal
State: Priority:(Other)/Source:(Other)
Signal: default
Transitions:
any -> Priority:(Other)/Source:(Other)
State: Priority:(Other)/Source:External
Signal: external source
Transitions:
any -> Priority:(Other)/Source:External
State: Priority:(Other)/Source:Internal
Signal: internal source
Transitions:
any -> Priority:(Other)/Source:Internal
Because there are no signals for combinations of "source" and "priority" URNs, processing a "source" URN from the state Priority:High/Source leads to a state that records the priority information but does not signal it:
「ソース」と「優先度」のURNの組み合わせにはシグナルがないため、Priority：High / Source状態から「ソース」のURNを処理すると、優先度情報を記録するがシグナルは送信しない状態になります。
State: Priority:High/Source
Signal: high priority
Transitions:
Priority:Other -> Priority:High/Source
Priority:High -> Priority:High/Source
Priority:Low -> Priority:High/Source
Source:Other -> Priority:High/Source:(Other)
Source:External -> Priority:High/Source:(External)
Source:Internal -> Priority:High/Source:(Internal)
State: Priority:High/Source:(Other)
Signal: high priority
Transitions:
any -> Priority:High/Source:(Other)
From the state Priority:High/Source, "source" URNs transition to states that record both source and priority but signal only priority, one of which is Priority:High/Source:(External). But from Priority/Source:External, the symbol Priority:High transitions to the state Priority:(High)/Source:External, which records the same information but signals the source, not the priority. One state is reached by processing a "priority" URN and then a "source" URN, whereas the other is reached by processing a "source" URN and then a "priority" URN.
状態Priority：High / Sourceから、「ソース」URNは、ソースと優先順位の両方を記録するが、優先順位のみを通知する状態に移行します。そのうちの1つは、Priority：High / Source：（External）です。しかし、Priority / Source：Externalから、シンボルPriority：Highは、状態Priority：（High）/ Source：Externalに遷移します。これは、同じ情報を記録しますが、優先度ではなくソースに信号を送ります。 1つの状態は「優先」URNを処理してから「ソース」URNを処理することで到達し、もう1つの状態は「ソース」URNを処理してから「優先」URNを処理することで到達します。
State: Priority:High/Source:(External)
Signal: high priority
Transitions:
any -> Priority:High/Source:(External)
State: Priority:High/Source:(Internal)
Signal: high priority
Transitions:
any -> Priority:High/Source:(Internal)
and similarly for Priority:Low/Source:
同様に、優先度：低/ソース：
State: Priority:Low/Source
Signal: low priority
Transitions:
Priority:Other -> Priority:Low/Source
Priority:High -> Priority:Low/Source
Priority:Low -> Priority:Low/Source
Source:Other -> Priority:Low/Source:(Other)
Source:External -> Priority:Low/Source:(External)
Source:Internal -> Priority:Low/Source:(Internal)
State: Priority:Low/Source:(Other)
Signal: low priority
Transitions:
any -> Priority:Low/Source:(Other)
State: Priority:Low/Source:(External)
Signal: low priority
Transitions:
any -> Priority:Low/Source:(External)
State: Priority:Low/Source:(Internal)
Signal: low priority
Transitions:
any -> Priority:Low/Source:(Internal)
State: Priority/Source:(Other)
Signal: default
Transitions:
Priority:Other -> Priority:(Other)/Source:(Other)
Priority:High -> Priority:High/Source:(Other)
Priority:Low -> Priority:Low/Source:(Other)
Source:Other -> Priority/Source:(Other)
Source:External -> Priority/Source:(Other)
Source:Internal -> Priority/Source:(Other)
State: Priority/Source:External
Signal: external source
Transitions:
Priority:Other -> Priority:(Other)/Source:External
Priority:High -> Priority:(High)/Source:External
Priority:Low -> Priority:(Low)/Source:External
Source:Other -> Priority/Source:External
Source:External -> Priority/Source:External
Source:Internal -> Priority/Source:External
State: Priority:(High)/Source:External
Signal: external source
Transitions:
any -> Priority:(High)/Source:External
State: Priority:(Low)/Source:External
Signal: external source
Transitions:
any -> Priority:(Low)/Source:External
State: Priority/Source:Internal
Signal: internal source
Transitions:
Priority:Other -> Priority:(Other)/Source:Internal
Priority:High -> Priority:(High)/Source:Internal
Priority:Low -> Priority:(Low)/Source:Internal
Source:Other -> Priority/Source:Internal
Source:External -> Priority/Source:Internal
Source:Internal -> Priority/Source:Internal
State: Priority:(High)/Source:Internal
Signal: internal source
Transitions:
any -> Priority:(High)/Source:Internal
State: Priority:(Low)/Source:Internal
Signal: internal source
Transitions:
any -> Priority:(Low)/Source:Internal
As an example of processing, if the UA receives
処理の例として、UAが
Alert-Info: <urn:alert:source:internal>
then processing progresses:
その後、処理が進行します。
State: Priority/Source
Process: Source:Internal (urn:alert:source:internal)
State: Priority/Source:Internal
Signal: internal source
A more complicated example involves multiple "source" URNs that do not select a non-default signal and one "priority" URN that can be signaled:
より複雑な例には、デフォルト以外の信号を選択しない複数の「ソース」URNと、シグナリング可能な1つの「優先」URNが含まれます。
Alert-Info: <urn:alert:source:unclassified>,
<urn:alert:source:internal>,
<urn:alert:priority:high>
in which case processing progresses:
その場合、処理が進行します。
State: Priority/Source
Process: Source:Other (urn:alert:source:unclassified)
State: Priority/Source:(Other)
Process: Source:Internal (urn:alert:source:internal)
State: Priority/Source:(Other)
Process: Priority:High (urn:alert:priority:high)
State: Priority:High/Source:(Other)
Signal: high priority
The only output of the FSM is the state's signal. Based on this, several groups of states in this FSM can be merged using standard FSM optimization algorithms:
FSMの唯一の出力は、状態の信号です。これに基づいて、このFSMのいくつかの状態グループを、標準のFSM最適化アルゴリズムを使用してマージできます。
states with signal "high priority":
Priority:High/Source
Priority:High/Source:(Other)
Priority:High/Source:(External)
Priority:High/Source:(Internal)
states with signal "low priority":
Priority:Low/Source
Priority:Low/Source:(Other)
Priority:Low/Source:(External)
Priority:Low/Source:(Internal)
states with signal "external source":
Priority/Source:External
Priority:(High)/Source:External
Priority:(Low)/Source:External
Priority:(Other)/Source:External
states with signal "internal source":
Priority/Source:Internal
Priority:(High)/Source:Internal
Priority:(Low)/Source:Internal
Priority:(Other)/Source:Internal
This reduces the FSM to eight states:
これにより、FSMは8つの状態に減少します。
Priority/Source
Priority:(Other)/Source
Priority:(Other)/Source:(Other)
Priority:High/Source [aggregated]
Priority:Low/Source [aggregated]
Priority/Source:(Other)
Priority/Source:External [aggregated]
Priority/Source:Internal [aggregated]
Examples 2, 3, and 4 of [RFC7462] are similar to the example in Section 5.1 of this document, but they do not include a signal for the combination "internal source, low priority" to make resolution examples work asymmetrically.
[RFC7462]の例2、3、および4は、このドキュメントのセクション5.1の例に似ていますが、解像度の例を非対称に動作させるための「内部ソース、低優先度」の組み合わせの信号は含まれていません。
The FSM for this example has the same alphabet as the FSM of Section 5.1. Most of the states of this FSM are the same as the states of the FSM of Section 5.1, but the state Source:Internal/Priority:Low is missing because there is no signal for that combination. It is replaced by two states:
この例のFSMは、セクション5.1のFSMと同じアルファベットです。このFSMの状態のほとんどは、セクション5.1のFSMの状態と同じですが、その組み合わせに信号がないため、状態Source：Internal / Priority：Lowがありません。次の2つの状態に置き換えられます。
1. One state is Source:Internal/Priority:(Low); it records that Source:Internal was specified first (and is to be signaled) and that Priority:Low was specified later (and cannot be signaled -- but it still prevents any further "priority" URNs from having an effect).
1. 1つの状態はSource：Internal / Priority：（Low）;です。これは、Source：Internalが最初に指定された（そして通知される）こと、およびPriority：Lowが後で指定された（そして通知されない）ことを記録しますが、それでも「優先度」のURNが影響を与えることを防ぎます）
2. The other state is Source:(Internal)/Priority:Low; it records the reverse sequence of events.
2. もう1つの状態は、ソース：（内部）/優先度：低です。イベントの逆のシーケンスを記録します。
The changes in the FSM are:
FSMの変更点は次のとおりです。
State: Priority:Low/Source
Signal: low priority
Transitions:
Source:Internal -> Priority:Low/Source:(Internal)
(other transitions unchanged)
State: Priority:Low/Source:(Internal)
Signal: low priority
Transitions:
any -> Priority:Low/Source:(Internal)
State: Priority/Source:Internal
Signal: internal source
Transitions:
Priority:Low -> Priority:(Low)/Source:Internal
(other transitions unchanged)
State: Priority:(Low)/Source:Internal
Signal: internal source
Transitions:
any -> Priority:(Low)/Source:Internal
An example of processing that involves multiple "source" URNs and one "priority" URN:
複数の「ソース」URNと1つの「優先」URNを伴う処理の例：
Alert-Info: <urn:alert:source:internal>,
<urn:alert:source:unclassified>,
<urn:alert:priority:high>
then processing progresses:
その後、処理が進行します。
State: Priority/Source
Process: Source:Internal (urn:alert:source:internal)
State: Priority/Source:Internal
Process: Source:Other (urn:alert:source:unclassified)
State: Priority/Source:Internal
Process: Priority:High (urn:alert:priority:high)
State: Priority:High/Source:Internal
Signal: internal source/high priority
If the UA receives
UAが受信した場合
Alert-Info: <urn:alert:source:internal>
then processing progresses:
その後、処理が進行します。
State: Priority/Source
Process: Source:Internal (urn:alert:source:internal)
State: Priority/Source:Internal
Signal: internal source
If the UA receives
UAが受信した場合
Alert-Info: <urn:alert:source:external>,
<urn:alert:priority:low>
then processing progresses:
その後、処理が進行します。
State: Priority/Source
Process: Source:External (urn:alert:source:external)
State: Priority/Source:External
Process: Priority:Low (urn:alert:priority:low)
State: Priority:Low/Source:External
Signal: external source/low priority
Suppose the same UA receives
同じUAが受信するとします
Alert-Info: <urn:alert:source:internal>,
<urn:alert:priority:low>
Note that there is no signal that corresponds to this combination. In that case, the processing is:
この組み合わせに対応する信号がないことに注意してください。その場合、処理は次のとおりです。
State: Priority/Source
Process: Source:Internal (urn:alert:source:internal)
State: Priority/Source:Internal
Process: Priority:Low (urn:alert:priority:low)
State: Priority:(Low)/Source:Internal
Signal: internal source
If the order of the URNs is reversed, what is signaled is the meaning of the now-different first URN:
URNの順序が逆になっている場合、通知されるのは、現在異なる最初のURNの意味です。
Alert-Info: <urn:alert:priority:low>,
<urn:alert:source:internal>
State: Priority/Source
Process: Priority:Low (urn:alert:priority:low)
State: Priority:Low/Source
Process: Source:Internal (urn:alert:source:internal)
State: Priority:Low/Source:(Internal)
Signal: low priority
Notice that the existence of the new states prevents later URNs of a category from overriding earlier URNs of that category, even if the earlier one was not itself signalable and the later one would be signalable in the absence of the earlier one:
新しい状態の存在により、カテゴリのそれ以降のURNがそのカテゴリの以前のURNを上書きすることが防止されます。
Alert-Info: <urn:alert:priority:low>,
<urn:alert:source:internal>,
<urn:alert:source:external>
State: Priority/Source
Process: Priority:Low (urn:alert:priority:low)
State: Priority:Low/Source
Process: Source:Internal (urn:alert:source:internal)
State: Priority:Low/Source:(Internal)
Process: Source:External (urn:alert:source:external)
State: Priority:Low/Source:(Internal)
Signal: low priority
This situation shows the necessity of states whose labels contain parentheses. If the second transition had been to the state Priority:Low/Source (on the basis that there is no proper state Priority:Low/Source:Internal), then the third transition would have been to the state Priority:Low/Source:External, and the signal would have been "external source/low priority".
この状況は、ラベルに括弧が含まれている状態の必要性を示しています。 2番目の遷移がPriority：Low / Source状態になった場合（適切な状態Priority：Low / Source：Internalがないことに基づいて）、3番目の遷移はPriority：Low / Source：External状態になります。 、信号は「外部ソース/低優先度」でした。
In the example of Section 4, there are signals for "external source" and "internal source". Let us add to that example a signal for "source internal from a VIP (Very Important Person)". That last signal expresses the private extension URN urn:alert:source:internal:vip@example, which is a subset of urn:alert:source:internal, which is expressed by the "source internal" signal. There are a total of three expressed URNs, one of which is a subset of another:
セクション4の例では、「外部ソース」と「内部ソース」の信号があります。その例に、「VIP（非常に重要な人物）からの内部ソース」の信号を追加します。最後の信号は、プライベート拡張URN urn：alert：source：internal：vip @ exampleを表しています。これは、「source internal」信号によって表されるurn：alert：source：internalのサブセットです。表現されたURNは合計3つあり、そのうちの1つは別のサブセットです。
urn:alert:source:internal
urn:alert:source:internal:vip@example
urn:alert:source:external
This generates the following alphabet of symbols, which includes two "Other" symbols for the "source" category:
これにより、次の記号のアルファベットが生成されます。これには、「ソース」カテゴリの2つの「その他」記号が含まれています。
Source
Source:Internal
Source:Internal:Vip@example
Source:Internal:Other
Source:Other
In this example, there are signals for "service forward" (the call has been forwarded) and "source recall callback" (a recall due to a callback). This gives two expressed URNs:
この例では、「サービス転送」（呼び出しが転送された）および「ソース再呼び出しコールバック」（コールバックによる再呼び出し）の信号があります。これにより、2つの表現されたURNが得られます。
urn:alert:service:forward
urn:alert:service:recall:callback
This generates the following alphabet of symbols. Note that there are two "Other" symbols, because the "alert:service" URNs have an additional level of qualification.
これにより、次の記号のアルファベットが生成されます。 「alert：service」URNには追加の資格レベルがあるため、「その他」の記号は2つあることに注意してください。
Service Service:Forward Service:Recall Service:Recall:Callback Service:Recall:Other Service:Other
サービスサービス：転送サービス：リコールサービス：リコール：コールバックサービス：リコール：その他のサービス：その他
In this example, we consider how a UA generates ringback signals when the UA wishes to reproduce the traditional behavior where the caller hears the ringback signals defined by the telephone service in the callee's country rather than the ringback signals defined by the service in the caller's country. In the Alert-Info header field of the 180 (Ringing) provisional response, we assume that the called UA provides an "alert:country" URN [RFC7462] containing the ISO 3166-1 [ISO-3166-1] alpha-2 country code of the callee's country.
この例では、呼び出し元が呼び出し元の国のサービスによって定義されたリングバック信号ではなく呼び出し元の国の電話サービスによって定義されたリングバック信号を聞く従来の動作をUAが再現したいときに、UAがリングバック信号を生成する方法を検討します。 。 180（Ringing）暫定応答のAlert-Infoヘッダーフィールドでは、呼び出されたUAがISO 3166-1 [ISO-3166-1] alpha-2国を含む「alert：country」URN [RFC7462]を提供すると想定します呼び出し先の国のコード。
The UA has a default signal and a "non-country" signal for urn:alert:service:call-waiting. For the example country with code "XA", the UA has a default signal and signals for urn:alert:service:call-waiting and urn:alert:service:forward. For the example country with code "XB", the UA has a default signal and a signal for urn:alert:service:forward. These inconsistencies between the non-country signals and the country signals are chosen to demonstrate the flexibility of the construction method, showing that three systems of signals can be combined correctly even when the systems were established without coordination between them.
UAには、urn：alert：service：call-waitingのデフォルトシグナルと「非国別」シグナルがあります。コード「XA」の例の国では、UAにデフォルトのシグナルとurn：alert：service：call-waitingおよびurn：alert：service：forwardのシグナルがあります。コード「XB」の例の国では、UAにはデフォルトのシグナルとurn：alert：service：forwardのシグナルがあります。非国別信号と国別信号のこれらの不整合は、工法の柔軟性を示すために選択され、3つの信号システムが調整なしで確立されている場合でも、システムを正しく組み合わせることができることを示しています。
The signals are:
信号は次のとおりです。
Signal URN(s)
-------------------------- ----------------------------------
default (none)
call-waiting urn:alert:service:call-waiting
XA default urn:alert:country:xa
XA call-waiting urn:alert:country:xa,
urn:alert:service:call-waiting
XA forward urn:alert:country:xa,
urn:alert:service:forward
XB default urn:alert:country:xb
XB forward urn:alert:country:xb,
urn:alert:service:forward
The expressed URNs are:
表現されるURNは次のとおりです。
urn:alert:country:xa
urn:alert:country:xb
urn:alert:service:call-waiting
urn:alert:service:forward
The relevant categories of "alert" URNs are only:
「アラート」URNの関連カテゴリは次のとおりです。
country service
カントリーサービス
The alphabet of symbols is:
記号のアルファベットは次のとおりです。
Country Country:[other] Country:Xa Country:Xb Service Service:[other] Service:Call-waiting Service:Forward
国国：[その他]国：Xa国：Xbサービスサービス：[その他]サービス：キャッチホンサービス：転送
The 17 states are as follows:
17州は次のとおりです。
State: 0 Country/Service
Signal: default
Transitions:
Country:[other] -> 1 Country:([other])/Service
Country:Xa -> 5 Country:Xa/Service
Country:Xb -> 9 Country:Xb/Service
Service:[other] -> 13 Country/Service:([other])
Service:Call-waiting -> 14 Country/Service:Call-waiting
Service:Forward -> 16 Country/Service:(Forward)
State: 1 Country:([other])/Service
Signal: default
Transitions:
Country:[other] -> 1 Country:([other])/Service
Country:Xa -> 1 Country:([other])/Service
Country:Xb -> 1 Country:([other])/Service
Service:[other] -> 2 Country:([other])/Service:([other])
Service:Call-waiting -> 3 Country:([other])/Service:Call-waiting
Service:Forward -> 4 Country:([other])/Service:(Forward)
State: 2 Country:([other])/Service:([other])
Signal: default
Transitions:
any -> 2 Country:([other])/Service:([other])
State: 3 Country:([other])/Service:Call-waiting
Signal: call-waiting
Transitions:
any -> 3 Country:([other])/Service:Call-waiting
State: 4 Country:([other])/Service:(Forward)
Signal: default
Transitions:
any -> 4 Country:([other])/Service:(Forward)
State: 5 Country:Xa/Service
Signal: XA default
Transitions:
Country:[other] -> 5 Country:Xa/Service
Country:Xa -> 5 Country:Xa/Service
Country:Xb -> 5 Country:Xa/Service
Service:[other] -> 6 Country:Xa/Service:([other])
Service:Call-waiting -> 7 Country:Xa/Service:Call-waiting
Service:Forward -> 8 Country:Xa/Service:Forward
State: 6 Country:Xa/Service:([other])
Signal: XA default
Transitions:
any -> 6 Country:Xa/Service:([other])
State: 7 Country:Xa/Service:Call-waiting
Signal: XA call-waiting
Transitions:
any -> 7 Country:Xa/Service:Call-waiting
State: 8 Country:Xa/Service:Forward
Signal: XA forward
Transitions:
any -> 8 Country:Xa/Service:Forward
State: 9 Country:Xb/Service
Signal: XB default
Transitions:
Country:[other] -> 9 Country:Xb/Service
Country:Xa -> 9 Country:Xb/Service
Country:Xb -> 9 Country:Xb/Service
Service:[other] -> 10 Country:Xb/Service:([other])
Service:Call-waiting -> 11 Country:Xb/Service:(Call-waiting)
Service:Forward -> 12 Country:Xb/Service:Forward
State: 10 Country:Xb/Service:([other])
Signal: XB default
Transitions:
any -> 10 Country:Xb/Service:([other])
State: 11 Country:Xb/Service:(Call-waiting)
Signal: XB default
Transitions:
any -> 11 Country:Xb/Service:(Call-waiting)
State: 12 Country:Xb/Service:Forward
Signal: XB forward
Transitions:
any -> 12 Country:Xb/Service:Forward
State: 13 Country/Service:([other])
Signal: default
Transitions:
Country:[other] -> 2 Country:([other])/Service:([other])
Country:Xa -> 6 Country:Xa/Service:([other])
Country:Xb -> 10 Country:Xb/Service:([other])
Service:[other] -> 13 Country/Service:([other])
Service:Call-waiting -> 13 Country/Service:([other])
Service:Forward -> 13 Country/Service:([other])
State: 14 Country/Service:Call-waiting
Signal: call-waiting
Transitions:
Country:[other] -> 3 Country:([other])/Service:Call-waiting
Country:Xa -> 7 Country:Xa/Service:Call-waiting
Country:Xb -> 15 Country:(Xb)/Service:Call-waiting
Service:[other] -> 14 Country/Service:Call-waiting
Service:Call-waiting -> 14 Country/Service:Call-waiting
Service:Forward -> 14 Country/Service:Call-waiting
State: 15 Country:(Xb)/Service:Call-waiting
Signal: call-waiting
Transitions:
any -> 15 Country:(Xb)/Service:Call-waiting
State: 16 Country/Service:(Forward)
Signal: default
Transitions:
Country:[other] -> 4 Country:([other])/Service:(Forward)
Country:Xa -> 8 Country:Xa/Service:Forward
Country:Xb -> 12 Country:Xb/Service:Forward
Service:[other] -> 16 Country/Service:(Forward)
Service:Call-waiting -> 16 Country/Service:(Forward)
Service:Forward -> 16 Country/Service:(Forward)
Call-waiting can be signaled in conjunction with country XA but not in conjunction with country XB, as the UA does not have a signal to present call-waiting alerts for country XB. Thus, the ordering of urn:alert:service:call-waiting with urn:alert:country:xa does not matter, but if urn:alert:country:xb appears before urn:alert:service:call-waiting, call-waiting cannot be signaled.
UAは国XBと組み合わせてではなく、国XAと組み合わせて信号を送ることができます。これは、UAが国XBの呼び出しを待っているアラートを提示する信号を持っていないためです。したがって、urn：alert：service：call-waitingとurn：alert：country：xaの順序は重要ではありませんが、urn：alert：country：xbがurn：alert：service：call-waiting、call-waitingの前にある場合信号を送ることはできません。
On the other hand, if urn:alert:service:call-waiting appears before urn:alert:country:xb, then call-waiting is signaled, but using the non-country signal.
一方、urn：alert：service：call-waitingがurn：alert：country：xbの前に表示される場合は、call-waitingが通知されますが、国以外の信号が使用されます。
Alert-Info: urn:alert:country:xa,
urn:alert:service:call-waiting
State: 0 Country/Service
Process: Country:Xa (urn:alert:country:xa)
State: 5 Country:Xa/Service
Process: Service:Call-waiting (urn:alert:service:call-waiting)
State: 7 Country:Xa/Service:Call-waiting
Signal: XA call-waiting
Alert-Info: urn:alert:service:call-waiting,
urn:alert:country:xa
State: 0 Country/Service
Process: Service:Call-waiting (urn:alert:service:call-waiting)
State: 14 Country/Service:Call-waiting
Process: Country:Xa (urn:alert:country:xa)
State: 7 Country:Xa/Service:Call-waiting
Signal: XA call-waiting
Alert-Info: urn:alert:country:xb,
urn:alert:service:call-waiting
State: 0 Country/Service
Process: Country:Xb (urn:alert:country:xb)
State: 9 Country:Xb/Service
Process: Service:Call-waiting (urn:alert:service:call-waiting)
State: 11 Country:Xb/Service:(Call-waiting)
Signal: XB default
Alert-Info: urn:alert:service:call-waiting,
urn:alert:country:xb
State: 0 Country/Service
Process: Service:Call-waiting (urn:alert:service:call-waiting)
State: 14 Country/Service:Call-waiting
Process: Country:Xb (urn:alert:country:xb)
State: 15 Country:(Xb)/Service:Call-waiting
Signal: call-waiting
The specifications provided in [RFC7462] are oriented toward giving the sender of Alert-Info control over which of the "alert" URNs are most important. But in some situations, the UA may prefer to prioritize expressing one URN category over another regardless of the order in which their URNs appear in Alert-Info. This section describes how that can be accommodated within the framework of [RFC7462] and presents an example FSM resulting from that approach.
[RFC7462]で提供される仕様は、どの「アラート」URNが最も重要であるかをAlert-Infoの送信者に制御させることを目的としています。ただし、状況によっては、UAは、URNがAlert-Infoに表示される順序に関係なく、あるURNカテゴリを別のカテゴリよりも優先して表現することを優先する場合があります。このセクションでは、[RFC7462]のフレームワーク内でこれに対応する方法について説明し、そのアプローチから得られるFSMの例を示します。
This example uses the signals of Section 5.2, viz., "external source", "internal source", "low priority", and "high priority", but this time, we want to signal "high priority" in preference to any other signal that might be applicable.
この例では、セクション5.2、「外部ソース」、「内部ソース」、「低優先度」、「高優先度」のシグナルを使用していますが、今回は、「高優先度」を他のシグナルよりも優先してシグナルします。該当する可能性のある信号。
We accommodate this within the framework of [RFC7462] by assigning the signal "high priority" for each of these combinations of URNs:
これらのURNの組み合わせのそれぞれに信号「高優先度」を割り当てることにより、[RFC7462]の枠組み内でこれに対応します。
urn:alert:priority:high
urn:alert:priority:high, urn:alert:source:internal
urn:alert:priority:high, urn:alert:source:external
The result is that the signal "high priority" is the "best" signal for any combination of urn:alert:priority:high with "source" URNs.
その結果、信号「高優先度」は、urn：alert：priority：highと「ソース」URNの任意の組み合わせに対して「最高」の信号になります。
Constructing the symbols produces the same results as before. The signals can express the following URNs:
シンボルを作成しても、以前と同じ結果が得られます。信号は次のURNを表すことができます。
urn:alert:source:external
urn:alert:source:internal
urn:alert:priority:low
urn:alert:priority:high
The relevant categories of "alert" URNs are:
「アラート」URNの関連カテゴリは次のとおりです。
source priority
ソースの優先度
The alphabet of symbols is:
記号のアルファベットは次のとおりです。
Source Source:External Source:Internal Source:Other Priority Priority:Low Priority:High Priority:Other
ソースソース：外部ソース：内部ソース：その他の優先度優先度：低優先度：高優先度：その他
When the FSM is constructed, it is the same as the FSM of Section 5.2, except that certain states are effectively renamed and merged, because any "source" is defined to be expressed if high priority is expressed:
FSMが構築されるとき、セクション5.2のFSMと同じですが、高優先度が表現されている場合に「ソース」が表現されるように定義されているため、特定の状態が効果的に名前変更およびマージされます。
Priority:(High)/Source:External and Priority:High/Source:(External) become:
優先度:(高）/ソース：外部および優先度：高/ソース:(外部）は次のようになります。
State: Priority:High/Source:External
Signal: high priority
Priority:(High)/Source:Internal and Priority:High/Source:(Internal) become:
優先度：（高）/ソース：内部および優先度：高/ソース：（内部）は次のようになります。
State: Priority:High/Source:Internal
Signal: high priority
This reduces the FSM to 18 states. In addition, these two new states, along with a number of other states, can be merged by FSM optimization, since all of them have the signal "high priority" and from them, there are no transitions to states outside this set. The optimized FSM has 10 states.
これにより、FSMは18の状態に減少します。さらに、これらの2つの新しい状態は、他の多くの状態と同様に、FSM最適化によってマージできます。これらのすべての状態には「高優先度」の信号があり、これらからは、このセットの外側の状態への遷移はありません。最適化されたFSMには10の状態があります。
This section discusses how to construct FSMs for a UA that allows variable sets of signals -- for example, if the user can configure the use of ring tones. Several approaches can be used:
このセクションでは、信号の可変セットを許可するUAのFSMを構築する方法について説明します（たとえば、ユーザーが呼び出し音の使用を構成できる場合）。いくつかのアプローチを使用できます。
o Whenever the set of ring tones is changed, re-execute the processes of Section 4.
o 着信音のセットが変更されるたびに、セクション4のプロセスを再実行します。
o Whenever the set of ring tones is changed, rebuild the list of expressed URNs (Section 4.1) and reconstruct the alphabet of symbols (Section 4.2). Then, use an algorithm for dynamically constructing the states of the FSM as needed during Alert-Info processing.
o 着信音のセットが変更されるたびに、表現されたURNのリストを再構築し（セクション4.1）、記号のアルファベットを再構築します（セクション4.2）。次に、Alert-Info処理中に必要に応じて、アルゴリズムを使用してFSMの状態を動的に構築します。
o If the sets of possible URNs expressed by the ring tones are sufficiently limited, the steps of Section 4 can be carried out "generically", and the generic FSM can be specialized for the current ring tone configuration.
o 着信音によって表される可能なURNのセットが十分に制限されている場合は、セクション4の手順を「一般的に」実行でき、汎用FSMを現在の着信音の構成に特化できます。
The remainder of this section gives an example of the third approach.
このセクションの残りの部分では、3番目のアプローチの例を示します。
For the example, we will use a set of ring tones that express the identity of the caller. To signal this information, a private extension "alert" URN category, "caller@example", is used:
For the example, we will use a set of ring tones that express the identity of the caller. To signal this information, a private extension "alert" URN category, "caller@example", is used:
urn:alert:caller@example:alice@example.com urn:alert:caller@example:bob@example.com etc.
urn：alert：caller @ example：alice@example.com urn：alert：caller @ example：bob@example.comなど
which we can express by the generic pattern
一般的なパターンで表現できます
urn:alert:caller@example:IDENTITY
where "IDENTITY" is replaced in succession by the set of caller identities that have their own ring tones to generate the set of expressed URNs.
ここで、「IDENTITY」は、一連の発信者IDに連続して置き換えられ、独自の呼び出しトーンを使用して、表現されたURNのセットを生成します。
The alphabet is then:
アルファベットは次のとおりです。
Caller@example
Caller@example:IDENTITY
Caller@example:Other
where "IDENTITY" is replaced in succession by the set of caller identities. The "Caller@example:Other" symbol includes all URNs of the category "caller@example" that are not included in any of the "Caller@example:IDENTITY" symbols, i.e, where the second alert-ind-part is not one of the known caller identities.
where "IDENTITY" is replaced in succession by the set of caller identities. The "Caller@example:Other" symbol includes all URNs of the category "caller@example" that are not included in any of the "Caller@example:IDENTITY" symbols, i.e, where the second alert-ind-part is not one of the known caller identities.
The states and transitions of the FSM are:
FSMの状態と遷移は次のとおりです。
State: Caller@example (initial state)
Signal: default
Transitions:
Caller@example:IDENTITY -> Caller@example:IDENTITY
Caller@example:Other -> Caller@example:(Other)
State: Caller@example:IDENTITY
Signal: signal for caller IDENTITY
Transitions:
any -> Caller@example:IDENTITY
State: Caller@example:(Other)
Signal: default
Transitions:
any -> Caller@example:(Other)
where again, the second state is replicated once for each caller identity that has a ring tone, with "IDENTITY" replaced with the caller identity.
where again, the second state is replicated once for each caller identity that has a ring tone, with "IDENTITY" replaced with the caller identity.
The security considerations discussed in Section 16 of [RFC7462] regarding the use and processing of "alert" URNs MUST be followed when the algorithm described in this document is used.
このドキュメントで説明されているアルゴリズムを使用する場合は、[アラート] URNの使用と処理に関する[RFC7462]のセクション16で説明されているセキュリティ上の考慮事項に従う必要があります。
Like any implementation of [RFC7462], implementations of the algorithm defined in this document MUST take into account that the value of a received Alert-Info header field may contain URIs of any scheme, may contain syntactically invalid values, and may be syntactically invalid overall. The handling of syntactically invalid values is specified by [RFC3261]. The handling of URIs other than "alert" URIs is outside the scope of this document (and outside the scope of [RFC7462]) and MAY be subject to local policy.
[RFC7462]の実装と同様に、このドキュメントで定義されているアルゴリズムの実装では、受信したAlert-Infoヘッダーフィールドの値にスキームのURIが含まれている可能性があり、構文的に無効な値が含まれている可能性があり、全体的に構文的に無効である可能性があることを考慮しなければなりません。 。構文的に無効な値の処理は、[RFC3261]で指定されています。 「アラート」URI以外のURIの処理は、このドキュメントの範囲外（および[RFC7462]の範囲外）であり、ローカルポリシーの対象となる場合があります。
Like the algorithm described in Section 12 of [RFC7462], the output of the algorithm defined in this document is limited to a choice among the signals that it has been configured for, limiting the security issues regarding the processing of its output. This algorithm will use at most linear time and constant space to process a sequence of "alert" URNs. This is significantly more efficient than the algorithm of [RFC7462] and minimizes the security vulnerabilities of this processing step that are due to resource consumption.
[RFC7462]のセクション12で説明されているアルゴリズムと同様に、このドキュメントで定義されているアルゴリズムの出力は、構成されている信号からの選択に限定されており、その出力の処理に関するセキュリティの問題を制限しています。このアルゴリズムは、一連の「アラート」URNを処理するために、最大で線形時間と一定のスペースを使用します。これは[RFC7462]のアルゴリズムよりもはるかに効率的であり、リソース消費によるこの処理ステップのセキュリティ脆弱性を最小限に抑えます。
However, the process defined in this document for constructing an FSM can use more than linear time and constant space -- probably exponential time and space in the worst case. This SHOULD be taken into consideration whenever an FSM is constructed using this algorithm and MUST be taken into consideration when it is done dynamically by a UA. Whenever an FSM is constructed by a process that is not under the direct supervision of a human user, procedures MUST be used to ensure that (1) the processing and memory consumption are limited to acceptable amounts and (2) if the FSM construction is aborted due to excessive consumption, the designated consumers of the FSM MUST have appropriate fallback procedures.
ただし、FSMを構築するためにこのドキュメントで定義されているプロセスでは、線形の時間と一定の空間以上のものを使用できます。最悪の場合、指数関数的な時間と空間です。これは、FSMがこのアルゴリズムを使用して構築されるときは常に考慮に入れられるべきであり、UAによって動的に行われるときは考慮に入れられなければなりません（MUST）。 FSMが人間のユーザーの直接の監督下にないプロセスによって構築されている場合は常に、手順を使用して、（1）処理とメモリの消費が許容量に制限されていること、および（2）FSMの構築が中止されている場合に使用する必要があります。過度の消費のため、FSMの指定された消費者は適切なフォールバック手順を持っている必要があります。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[ISO-3166-1] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", ISO Standard 3166-1:2013, November 2013, <https://www.iso.org/iso-3166-country-codes.html>.
[ISO-3166-1] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", ISO Standard 3166-1:2013, November 2013, <https://www.iso.org/iso-3166-country-codes.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC7462] Liess, L., Ed., Jesske, R., Johnston, A., Worley, D., and P. Kyzivat, "URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)", RFC 7462, DOI 10.17487/RFC7462, March 2015, <https://www.rfc-editor.org/info/rfc7462>.
[RFC7462] Liess、L.、Ed。、Jesske、R.、Johnston、A.、Worley、D。、およびP. Kyzivat、「Session Initiation Protocol（SIP）のAlert-InfoヘッダーフィールドのURN」、 RFC 7462、DOI 10.17487 / RFC7462、2015年3月、<https://www.rfc-editor.org/info/rfc7462>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[code] Worley, D., "draft-worley-alert-info-fsm.aux", February 2017, <http://svn.resiprocate.org/rep/ ietf-drafts/worley/draft-worley-alert-info-fsm.aux>.
[code] Worley, D., "draft-worley-alert-info-fsm.aux", February 2017, <http://svn.resiprocate.org/rep/ ietf-drafts/worley/draft-worley-alert-info-fsm.aux>.
Acknowledgments
謝辞
Thanks to Paul Kyzivat, whose relentless identification of the weaknesses of earlier versions made the final document much, much better than it would have been, by changing it from the exposition of a concept into a practical tool. Thanks to Rifaat Shekh-Yusef, Eric Burger, and Gonzalo Camarillo for their thorough reviews. Thanks to the earlier Independent Submissions Editor, Nevil Brownlee, for his work obtaining reviewers, and the later Independent Submissions Editor, Adrian Farrel, for prompting me to write the Security Considerations section (which I had expected to be trivial but was not).
以前のバージョンの弱点を容赦なく特定したPaul Kyzivatのおかげで、コンセプトの説明から実用的なツールに変更することで、最終的なドキュメントは以前よりもはるかに良くなりました。徹底的なレビューを提供してくれたRifaat Shekh-Yusef、Eric Burger、およびGonzalo Camarilloに感謝します。以前の独立した投稿の編集者であるNevil Brownleeがレビューアーを取得してくれたことに感謝し、後の独立した投稿の編集者であるAdrian Farrelがセキュリティに関する考慮事項のセクション（私は取るに足らないと思っていましたが、そうではありませんでした）を書くように促してくれたことに感謝します。
Author's Address
著者のアドレス
Dale R. Worley Ariadne Internet Services 738 Main St. Waltham, MA 02451 United States of America
デールR.ウォーリーアリアドネインターネットサービス738 Main St. Waltham、MA 02451アメリカ合衆国
Email: worley@ariadne.com