[要約] RFC 9485 は、I-Regexp という正規表現の一種を定義し、異なる正規表現ライブラリ間での相互運用性を目指しています。
Internet Engineering Task Force (IETF) C. Bormann
Request for Comments: 9485 Universität Bremen TZI
Category: Standards Track T. Bray
ISSN: 2070-1721 Textuality
October 2023
This document specifies I-Regexp, a flavor of regular expression that is limited in scope with the goal of interoperation across many different regular expression libraries.
このドキュメントは、I-ReGexpを指定します。これは、多くの異なる正規表現ライブラリにおける相互操作の目標とともに範囲が制限されている正規表現の風味です。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、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/rfc9485.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9485で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Terminology
2. Objectives
3. I-Regexp Syntax
3.1. Checking Implementations
4. I-Regexp Semantics
5. Mapping I-Regexp to Regexp Dialects
5.1. Multi-Character Escapes
5.2. XSD Regexps
5.3. ECMAScript Regexps
5.4. PCRE, RE2, and Ruby Regexps
6. Motivation and Background
6.1. Implementing I-Regexp
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
This specification describes an interoperable regular expression (abbreviated as "regexp") flavor, I-Regexp.
この仕様では、相互運用可能な正規表現（「regexp」と略される）フレーバー、i-regexpについて説明します。
I-Regexp does not provide advanced regular expression features such as capture groups, lookahead, or backreferences. It supports only a Boolean matching capability, i.e., testing whether a given regular expression matches a given piece of text.
I-ReGexpは、キャプチャグループ、Lookahead、または逆流などの高度な正規表現機能を提供しません。ブールマッチング機能のみをサポートします。つまり、特定の正規表現が特定のテキストと一致するかどうかをテストします。
I-Regexp supports the entire repertoire of Unicode characters (Unicode scalar values); both the I-Regexp strings themselves and the strings they are matched against are sequences of Unicode scalar values (often represented in UTF-8 encoding form [STD63] for interchange).
I-ReGexpは、Unicode文字（Unicode Scalar値）のレパートリー全体をサポートしています。I-ReGexp文字列自体とそれらが一致する文字列の両方は、Unicodeスカラー値のシーケンスです（多くの場合、交換用のUTF-8エンコードフォーム[STD63]で表されます）。
I-Regexp is a subset of XML Schema Definition (XSD) regular expressions [XSD-2].
I-ReGexpは、XMLスキーマ定義（XSD）正規表現[XSD-2]のサブセットです。
This document includes guidance for converting I-Regexps for use with several well-known regular expression idioms.
このドキュメントには、いくつかのよく知られている正規表現イディオムで使用するためにI-ReGexpsを変換するためのガイダンスが含まれています。
The development of I-Regexp was motivated by the work of the JSONPath Working Group (WG). The WG wanted to include support for the use of regular expressions in JSONPath filters in its specification [JSONPATH-BASE], but was unable to find a useful specification for regular expressions that would be interoperable across the popular libraries.
I-ReGexpの開発は、JSONPATHワーキンググループ（WG）の仕事によって動機付けられました。WGは、その仕様[JSonPath-Base]でJSonPathフィルターでの正規表現の使用のサポートを含めたいと考えていましたが、一般的なライブラリ全体で相互運用可能な正規表現の便利な仕様を見つけることができませんでした。
This document uses the abbreviation "regexp" for what is usually called a "regular expression" in programming. The term "I-Regexp" is used as a noun meaning a character string (sequence of Unicode scalar values) that conforms to the requirements in this specification; the plural is "I-Regexps".
このドキュメントでは、プログラミングで通常「正規表現」と呼ばれるものについて、略語「regexp」を使用します。「i-regexp」という用語は、この仕様の要件に準拠する文字文字列（Unicodeスカラー値のシーケンス）を意味する名詞として使用されます。複数形は「i-regexps」です。
This specification uses Unicode terminology; a good entry point is provided by [UNICODE-GLOSSARY].
この仕様では、Unicode用語を使用します。[Unicode-Glossary]によって適切なエントリポイントが提供されます。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The grammatical rules in this document are to be interpreted as ABNF, as described in [RFC5234] and [RFC7405], where the "characters" of Section 2.3 of [RFC5234] are Unicode scalar values.
このドキュメントの文法規則は、[RFC5234]および[RFC7405]で説明されているようにABNFとして解釈されます。ここで、[RFC5234]のセクション2.3の「文字」はユニコードスカラー値です。
I-Regexps should handle the vast majority of practical cases where a matching regexp is needed in a data-model specification or a query-language expression.
I-ReGexpsは、データモデルの仕様またはクエリ言語式で一致するregexpが必要な実際のケースの大部分を処理する必要があります。
At the time of writing, an editor of this document conducted a survey of the regexp syntax used in recently published RFCs. All examples found there should be covered by I-Regexps, both syntactically and with their intended semantics. The exception is the use of multi-character escapes, for which workaround guidance is provided in Section 5.
執筆時点で、このドキュメントの編集者は、最近公開されたRFCSで使用されたRegexp構文の調査を実施しました。そこにあるすべての例は、構文的に、また意図したセマンティクスの両方で、I-regexpsでカバーされるべきです。例外は、セクション5で回避策のガイダンスが提供されているマルチキャラクターエスケープの使用です。
An I-Regexp MUST conform to the ABNF specification in Figure 1.
I-ReGexpは、図1のABNF仕様に準拠する必要があります。
i-regexp = branch *( "|" branch )
branch = *piece
piece = atom [ quantifier ]
quantifier = ( "*" / "+" / "?" ) / range-quantifier
range-quantifier = "{" QuantExact [ "," [ QuantExact ] ] "}"
QuantExact = 1*%x30-39 ; '0'-'9'
atom = NormalChar / charClass / ( "(" i-regexp ")" )
NormalChar = ( %x00-27 / "," / "-" / %x2F-3E ; '/'-'>'
/ %x40-5A ; '@'-'Z'
/ %x5E-7A ; '^'-'z'
/ %x7E-D7FF ; skip surrogate code points
/ %xE000-10FFFF )
charClass = "." / SingleCharEsc / charClassEsc / charClassExpr
SingleCharEsc = "\" ( %x28-2B ; '('-'+'
/ "-" / "." / "?" / %x5B-5E ; '['-'^'
/ %s"n" / %s"r" / %s"t" / %x7B-7D ; '{'-'}'
)
charClassEsc = catEsc / complEsc
charClassExpr = "[" [ "^" ] ( "-" / CCE1 ) *CCE1 [ "-" ] "]"
CCE1 = ( CCchar [ "-" CCchar ] ) / charClassEsc
CCchar = ( %x00-2C / %x2E-5A ; '.'-'Z'
/ %x5E-D7FF ; skip surrogate code points
/ %xE000-10FFFF ) / SingleCharEsc
catEsc = %s"\p{" charProp "}"
complEsc = %s"\P{" charProp "}"
charProp = IsCategory
IsCategory = Letters / Marks / Numbers / Punctuation / Separators /
Symbols / Others
Letters = %s"L" [ ( %s"l" / %s"m" / %s"o" / %s"t" / %s"u" ) ]
Marks = %s"M" [ ( %s"c" / %s"e" / %s"n" ) ]
Numbers = %s"N" [ ( %s"d" / %s"l" / %s"o" ) ]
Punctuation = %s"P" [ ( %x63-66 ; 'c'-'f'
/ %s"i" / %s"o" / %s"s" ) ]
Separators = %s"Z" [ ( %s"l" / %s"p" / %s"s" ) ]
Symbols = %s"S" [ ( %s"c" / %s"k" / %s"m" / %s"o" ) ]
Others = %s"C" [ ( %s"c" / %s"f" / %s"n" / %s"o" ) ]
Figure 1: I-Regexp Syntax in ABNF
図1：ABNFのI-ReGexp構文
As an additional restriction, charClassExpr is not allowed to match [^], which, according to this grammar, would parse as a positive character class containing the single character ^.
追加の制限として、Charclassexprは[ ^]に一致することを許可されていません。これは、この文法によれば、単一の文字 ^を含むポジティブなキャラクタークラスとして解析します。
This is essentially an XSD regexp without:
これは基本的にXSDの再遺伝子型です。
* character class subtraction,
* キャラクタークラスの減算、
* multi-character escapes such as \s, \S, and \w, and
* \ s、\ s、\ wなどのマルチキャラクターエスケープ
* Unicode blocks.
* ユニコードブロック。
An I-Regexp implementation MUST be a complete implementation of this limited subset. In particular, full support for the Unicode functionality defined in this specification is REQUIRED. The implementation:
I-ReGexpの実装は、この限られたサブセットの完全な実装でなければなりません。特に、この仕様で定義されているユニコード機能の完全なサポートが必要です。実装：
* MUST NOT limit itself to 7- or 8-bit character sets such as ASCII, and
* ASCIIなどの7ビットまたは8ビットの文字セットに限定してはなりません。
* MUST support the Unicode character property set in character classes.
* 文字クラスに設定されたUnicode文字プロパティをサポートする必要があります。
A _checking_ I-Regexp implementation is one that checks a supplied regexp for compliance with this specification and reports any problems. Checking implementations give their users confidence that they didn't accidentally insert syntax that is not interoperable, so checking is RECOMMENDED. Exceptions to this rule may be made for low-effort implementations that map I-Regexp to another regexp library by simple steps such as performing the mapping operations discussed in Section 5. Here, the effort needed to do full checking might dwarf the rest of the implementation effort. Implementations SHOULD document whether or not they are checking.
_CHECKING_ I-ReGexp実装は、この仕様のコンプライアンスのために付属のRegexpをチェックし、問題を報告するものです。実装をチェックすると、ユーザーが相互運用できない構文を誤って挿入しなかったという自信があるため、チェックをお勧めします。このルールの例外は、セクション5で説明したマッピング操作を実行するなどの簡単な手順により、I-ReGexpを別のRegexpライブラリにマッピングする低エフォルト実装について行うことができます。実装の取り組み。実装は、チェックしているかどうかを文書化する必要があります。
Specifications that employ I-Regexp may want to define in which cases their implementations can work with a non-checking I-Regexp implementation and when full checking is needed, possibly in the process of defining their own implementation classes.
I-ReGexpを使用する仕様は、その実装が非チェックI-ReGexp実装で機能する場合、およびおそらく独自の実装クラスを定義するプロセスで完全なチェックが必要な場合を定義することを望む場合があります。
This syntax is a subset of that of [XSD-2]. Implementations that interpret I-Regexps MUST yield Boolean results as specified in [XSD-2]. (See also Section 5.2.)
この構文は、[XSD-2]のサブセットのサブセットです。I-ReGexpsを解釈する実装は、[XSD-2]で指定されているように、ブール結果を生成する必要があります。（セクション5.2も参照してください。）
The material in this section is not normative; it is provided as guidance to developers who want to use I-Regexps in the context of other regular expression dialects.
このセクションの資料は規範的ではありません。これは、他の正規表現方言のコンテキストでI-regexpsを使用したい開発者へのガイダンスとして提供されます。
I-Regexp does not support common multi-character escapes (MCEs) and character classes built around them. These can usually be replaced as shown by the examples in Table 1.
I-ReGexpは、一般的なマルチキャラクターエスケープ（MCE）とそれらの周りに構築されたキャラクタークラスをサポートしていません。これらは通常、表1の例に示すように置き換えることができます。
+============+===============+
| MCE/class: | Replace with: |
+============+===============+
| \S | [^ \t\n\r] |
+------------+---------------+
| [\S ] | [^\t\n\r] |
+------------+---------------+
| \d | [0-9] |
+------------+---------------+
Table 1: Example Substitutes for Multi-Character Escapes
表1：マルチキャラクターエスケープの代替品の例
Note that the semantics of \d in XSD regular expressions is that of \p{Nd}; however, this would include all Unicode characters that are digits in various writing systems, which is almost certainly not what is required in IETF publications.
XSD正規表現の\ dのセマンティクスは\ p {nd}のセマンティクスであることに注意してください。ただし、これには、さまざまなライティングシステムの数字であるすべてのUnicode文字が含まれます。
The construct \p{IsBasicLatin} is essentially a reference to legacy ASCII; it can be replaced by the character class [\u0000-\u007f].
コンストラクト\ p {isbasiclatin}は、本質的にレガシーASCIIへの参照です。文字クラス[\ u0000- \ u007f]に置き換えることができます。
Any I-Regexp is also an XSD regexp [XSD-2], so the mapping is an identity function.
I-ReGexpはXSD Regexp [XSD-2]でもあるため、マッピングはID関数です。
Note that a few errata for [XSD-2] have been fixed in [XSD-1.1-2]; therefore, it is also included in the Normative References (Section 9.1). XSD 1.1 is less widely implemented than XSD 1.0, and implementations of XSD 1.0 are likely to include these bugfixes; for the intents and purposes of this specification, an implementation of XSD 1.0 regexps is equivalent to an implementation of XSD 1.1 regexps.
[XSD-2]のいくつかの正誤表は[XSD-1.1-2]で固定されていることに注意してください。したがって、規範的参照（セクション9.1）にも含まれています。XSD 1.1はXSD 1.0よりも広く実装されておらず、XSD 1.0の実装にはこれらのバグ修正が含まれる可能性があります。この仕様の意図と目的のために、XSD 1.0 REGEXPSの実装は、XSD 1.1 Regexpsの実装と同等です。
Perform the following steps on an I-Regexp to obtain an ECMAScript regexp [ECMA-262]:
I-ReGexpで次の手順を実行して、ECMAScript regexp [ECMA-262]を取得します。
* For any unescaped dots (.) outside character classes (first alternative of charClass production), replace the dot with [^\n\r].
* 外部のキャラクタークラス（チャールクラス生産の最初の代替）の外側のドット（。）の場合、ドットを[^\ n \ r]に置き換えます。
* Envelope the result in ^(?: and )$.
* ^（？：and）$の結果を封筒します。
The ECMAScript regexp is to be interpreted as a Unicode pattern ("u" flag; see Section 21.2.2 "Pattern Semantics" of [ECMA-262]).
ECMAScript regexpは、ユニコードパターンとして解釈されます（ "u"フラグ、[ECMA-262]のセクション21.2.2 "パターンセマンティクスを参照）。
Note that where a regexp literal is required, the actual regexp needs to be enclosed in /.
Regexpリテラルが必要な場合、実際のregexpを /に囲む必要があることに注意してください。
To obtain a valid regexp in Perl Compatible Regular Expressions (PCRE) [PCRE2], the Go programming language's RE2 regexp library [RE2], and the Ruby programming language, perform the same steps as in Section 5.3, except that the last step is:
PERL互換性のある正規表現（PCRE）[PCRE2]で有効なRegexpを取得するには、GOプログラミング言語のRE2 REGEXPライブラリ[RE2]、およびRubyプログラミング言語で、セクション5.3と同じ手順を実行します。ただし、最後のステップは次のとおりです。
* Enclose the regexp in \A(?: and )\z.
* \ a（？：and）\ zにregexpを囲みます。
While regular expressions originally were intended to describe a formal language to support a Boolean matching function, they have been enhanced with parsing functions that support the extraction and replacement of arbitrary portions of the matched text. With this accretion of features, parsing-regexp libraries have become more susceptible to bugs and surprising performance degradations that can be exploited in denial-of-service attacks by an attacker who controls the regexp submitted for processing. I-Regexp is designed to offer interoperability and to be less vulnerable to such attacks, with the trade-off that its only function is to offer a Boolean response as to whether a character sequence is matched by a regexp.
正規表現はもともとブールのマッチング関数をサポートする正式な言語を記述することを目的としていましたが、それらは、一致したテキストの任意の部分の抽出と置換をサポートする解析機能で強化されています。この機能の付加により、解析 - レゲックスライブラリは、処理のために提出されたReGEXPを制御する攻撃者がサービス拒否攻撃で利用できるバグや驚くべきパフォーマンスの劣化の影響を受けやすくなりました。I-ReGexpは、相互運用性を提供し、そのような攻撃に対して脆弱ではないように設計されています。その唯一の機能は、文字シーケンスがRegexpによって一致するかどうかについてのブール応答を提供することです。
XSD regexps are relatively easy to implement or map to widely implemented parsing-regexp dialects, with these notable exceptions:
XSD Regexpsは、これらの注目すべき例外を除いて、広く実装された解析対策方言に比較的簡単に実装またはマッピングできます。
* Character class subtraction. This is a very useful feature in many specifications, but it is unfortunately mostly absent from parsing-regexp dialects. Thus, it is omitted from I-Regexp.
* キャラクタークラスの減算。これは多くの仕様において非常に便利な機能ですが、残念ながら、ペルシングレゲックスの方言にはほとんどありません。したがって、I-Regexpから省略されています。
* Multi-character escapes. \d, \w, \s and their uppercase complement classes exhibit a large amount of variation between regexp flavors. Thus, they are omitted from I-Regexp.
* マルチキャラクターエスケープ。\ d、\ w、\ sおよびそれらの大文字の補数クラスは、regexpフレーバー間の大量の変動を示します。したがって、それらはi-regexpから省略されています。
* Not all regexp implementations support access to Unicode tables that enable executing constructs such as \p{Nd}, although the \p/\P feature in general is now quite widely available. While, in principle, it is possible to translate these into character-class matches, this also requires access to those tables. Thus, regexp libraries in severely constrained environments may not be able to support I-Regexp conformance.
* すべてのregexp実装が、\ p {nd}などのコンストラクトを実行できるユニコードテーブルへのアクセスをサポートするわけではありませんが、一般的に\ p/\ p機能は非常に広く利用可能です。原則として、これらをキャラクタークラスの一致に変換することは可能ですが、これにはそれらのテーブルへのアクセスも必要です。したがって、厳しく制約された環境のregexpライブラリは、I-regexpの適合性をサポートできない場合があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
While technically out of the scope of this specification, Section 10 ("Security Considerations") of RFC 3629 [STD63] applies to implementations. Particular note needs to be taken of the last paragraph of Section 3 ("UTF-8 definition") of RFC 3629 [STD63]; an I-Regexp implementation may need to mitigate limitations of the platform implementation in this regard.
技術的にはこの仕様の範囲外ではありませんが、RFC 3629 [STD63]のセクション10（「セキュリティ上の考慮事項」）が実装に適用されます。RFC 3629 [STD63]のセクション3（「UTF-8定義」）の最後の段落（STD63]の特に注意する必要があります。この点に関して、I-ReGexpの実装では、プラットフォームの実装の制限を軽減する必要がある場合があります。
As discussed in Section 6, more complex regexp libraries may contain exploitable bugs, which can lead to crashes and remote code execution. There is also the problem that such libraries often have performance characteristics that are hard to predict, leading to attacks that overload an implementation by matching against an expensive attacker-controlled regexp.
セクション6で説明したように、より複雑なREGEXPライブラリには、クラッシュやリモートコードの実行につながる可能性のある悪用可能なバグが含まれている場合があります。また、そのようなライブラリには、予測が困難なパフォーマンス特性がしばしばあることが多く、高価な攻撃者が制御するregexpと一致させることで実装を過負荷する攻撃につながります。
I-Regexps have been designed to allow implementation in a way that is resilient to both threats; this objective needs to be addressed throughout the implementation effort. Non-checking implementations (see Section 3.1) are likely to expose security limitations of any regexp engine they use, which may be less problematic if that engine has been built with security considerations in mind (e.g., [RE2]). In any case, a checking implementation is still RECOMMENDED.
I-ReGexpsは、両方の脅威に弾力性のある方法で実装を可能にするように設計されています。この目的は、実装の取り組みを通して対処する必要があります。非チェックの実装（セクション3.1を参照）は、使用するRegexpエンジンのセキュリティ制限を公開する可能性があります。これは、そのエンジンがセキュリティ上の考慮事項を念頭に置いて構築されている場合（[RE2]）問題が少ない場合があります。いずれにせよ、チェックの実装が引き続き推奨されます。
Implementations that specifically implement the I-Regexp subset can, with care, be designed to generally run in linear time and space in the input and to detect when that would not be the case (see below).
I-Regexpサブセットを特異的に実装する実装は、注意して、一般に入力の線形時間と空間で実行し、いつそうでないかを検出するように設計することができます（以下を参照）。
Existing regexp engines should be able to easily handle most I-Regexps (after the adjustments discussed in Section 5), but may consume excessive resources for some types of I-Regexps or outright reject them because they cannot guarantee efficient execution. (Note that different versions of the same regexp library may be more or less vulnerable to excessive resource consumption for these cases.)
既存のregexpエンジンは、ほとんどのI-regexps（セクション5で説明した調整後）を簡単に処理できるはずですが、効率的な実行を保証できないため、ある種のI-ReGexpsの過度のリソースを消費するか、完全に拒否する場合があります。（同じregexpライブラリの異なるバージョンは、これらのケースの過剰なリソース消費に対して多かれ少なかれ脆弱である可能性があることに注意してください。）
Specifically, range quantifiers (as in a{2,4}) provide particular challenges for both existing and I-Regexp focused implementations. Implementations may therefore limit range quantifiers in composability (disallowing nested range quantifiers such as (a{2,4}){2,4}) or range (disallowing very large ranges such as a{20,200000}), or detect and reject any excessive resource consumption caused by range quantifiers.
具体的には、範囲の数量詞（{2,4}のように）は、既存とI-ReGexpの両方の焦点を絞った実装の両方に特別な課題を提供します。したがって、実装は、複合性の範囲の数量剤（（{2,4}）{2,4}）または範囲（{20,200000}などの非常に大きな範囲を許可する）を禁止することを許可しない、または検出および拒否を制限する場合があります。範囲数量剤によって引き起こされる過度のリソース消費。
I-Regexp implementations that are used to evaluate regexps from untrusted sources need to be robust in these cases. Implementers using existing regexp libraries are encouraged:
これらの場合、信頼されていないソースからの正規表現を評価するために使用されるI-ReGexp実装は堅牢である必要があります。既存のregexpライブラリを使用する実装者が奨励されます。
* to check their documentation to see if mitigations are configurable, such as limits in resource consumption, and
* 彼らのドキュメントをチェックして、リソース消費の制限など、緩和が構成可能かどうかを確認するには、
* to document their own degree of robustness resulting from employing such mitigations.
* そのような緩和を採用したことから生じる独自の堅牢性を文書化する。
[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>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>.
[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>.
[XSD-1.1-2]
Peterson, D., Ed., Gao, S., Ed., Malhotra, A., Ed.,
Sperberg-McQueen, C. M., Ed., Thompson, H., Ed., and P.
Biron, Ed., "W3C XML Schema Definition Language (XSD) 1.1
Part 2: Datatypes", W3C REC REC-xmlschema11-2-20120405,
W3C REC-xmlschema11-2-20120405, 5 April 2012,
<https://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/>.
[XSD-2] Biron, P., Ed. and A. Malhotra, Ed., "XML Schema Part 2:
Datatypes Second Edition", W3C REC REC-xmlschema-
2-20041028, W3C REC-xmlschema-2-20041028, 28 October 2004,
<https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.
[ECMA-262] Ecma International, "ECMAScript 2020 Language
Specification", Standard ECMA-262, 11th Edition, June
2020, <https://www.ecma-international.org/wp-
content/uploads/ECMA-262.pdf>.
[JSONPATH-BASE]
Gössner, S., Ed., Normington, G., Ed., and C. Bormann,
Ed., "JSONPath: Query expressions for JSON", Work in
Progress, Internet-Draft, draft-ietf-jsonpath-base-20, 25
August 2023, <https://datatracker.ietf.org/doc/html/draft-
ietf-jsonpath-base-20>.
[PCRE2] "Perl-compatible Regular Expressions (revised API:
PCRE2)", <http://pcre.org/current/doc/html/>.
[RE2] "RE2 is a fast, safe, thread-friendly alternative to
backtracking regular expression engines like those used in
PCRE, Perl, and Python. It is a C++ library.", commit
73031bb, <https://github.com/google/re2>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015,
<https://www.rfc-editor.org/info/rfc7493>.
[STD63] Internet Standard 63,
<https://www.rfc-editor.org/info/std63>.
At the time of writing, this STD comprises the following:
Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[UNICODE-GLOSSARY]
Unicode, Inc., "Glossary of Unicode Terms",
<https://unicode.org/glossary/>.
Discussion in the IETF JSONPATH WG about whether to include a regexp mechanism into the JSONPath query expression specification and previous discussions about the YANG pattern and Concise Data Definition Language (CDDL) .regexp features motivated this specification.
IETF JSONPATH WGでの議論JSONPATHクエリ式の仕様に正規表現メカニズムを含めるか、Yangパターンと簡潔なデータ定義言語（CDDL）に関する以前の議論を含めるかどうかについて。
The basic approach for this specification was inspired by "The I-JSON Message Format" [RFC7493].
この仕様の基本的なアプローチは、「I-JSONメッセージ形式」[RFC7493]に触発されました。
Carsten Bormann
Universität Bremen TZI
Postfach 330440
D-28359 Bremen
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Tim Bray
Textuality
Canada
Email: tbray@textuality.com