RFC 9651 — Structured Field Values for HTTP（日本語訳）

◎要約

この文書は、新たな`~HTTP~field$の仕様から利用するために、一連の~data型, それらに結付けられる~algoを述べる。それは、 ~HTTP~field（`~header$／`~trailer$）を［より容易に定義して, より安全に取扱う］ために意図される。そのような~HTTP~fieldは、［ `有構造~field$／`有構造~header$／`有構造~trailer$ ］と称される。 ◎ This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields.

この文書は、 `~RFC 8941$ を廃用にする。 ◎ This document obsoletes RFC 8941.

1. 序論

新たな`~HTTP~field$（`~header$／`~trailer$）の構文を指定することは、骨の折れる~taskである。 `HTTP$r `新たな~fieldに対する考慮点＠~HTTPinfra#considerations.for.new.fields§ による指導はあれど、将来有望な`~HTTP~field$の策定者にとって，多くの裁定 — および陥穽 — がある。 ◎ Specifying the syntax of new HTTP header (and trailer) fields is an onerous task; even with the guidance in Section 16.3.2 of [HTTP], there are many decisions -- and pitfalls -- for a prospective HTTP field author.

~fieldを定義したなら、それ~~専用の［構文解析器／直列化器］も書く必要があることが多い — 各`~field値$には、共通な構文にも見える様な少しばかり異なる取扱いがあるので。 ◎ Once a field is defined, bespoke parsers and serializers often need to be written, because each field value has a slightly different handling of what looks like common syntax.

これらの問題に取組むため，この文書は、新たな~HTTP`~field値$の定義における利用-用に，一連の共通な~data構造を導入する。特に，`~field値$~用の汎用かつ抽象的な~modelを — その~modelを`~HTTP~field$ `HTTP$r 内で表出するための具象的な直列化とともに — 定義する。 ◎ This document introduces a set of common data structures for use in definitions of new HTTP field values to address these problems. In particular, it defines a generic, abstract model for them, along with a concrete serialization for expressing that model in HTTP [HTTP] header and trailer fields.

`~HTTP~field$のうち［ `有構造~header$／ `有構造~trailer$ ］ — 当の~fieldが［ `~header$, `~trailer$ ］どちらにもなり得る場合は`有構造~field$ — として定義されるものは、この仕様に定義される各種型を利用して，その構文と基本的な取扱い規則を定義する — それにより、［仕様の書き手による定義, 実装による取扱い］をどちらも単純~化する。 ◎ An HTTP field that is defined as a "Structured Header" or "Structured Trailer" (if the field can be either, it is a "Structured Field") uses the types defined in this specification to define its syntax and basic handling rules, thereby simplifying both its definition by specification writers and handling by implementations.

加えて，~HTTPの将来~versionは、これらの構造が成す抽象-~modelに対し，代替な直列化を定義し得る — ［その~modelを利用する~fieldを定義し直すことなく，より効率的に伝送する］ことを許容するため。 ◎ Additionally, future versions of HTTP can define alternative serializations of the abstract model of these structures, allowing fields that use that model to be transmitted more efficiently without being redefined.

注記：この文書の目標は、既存の`~HTTP~field$の構文を定義し直すことではない。ここに述べる仕組みは、［明示的にそれを任意選択する~fieldに限り，利用される］ことが意図される。 ◎ Note that it is not a goal of this document to redefine the syntax of existing HTTP fields; the mechanisms described herein are only intended to be used with fields that explicitly opt into them.

`2§ では、［ ~HTTP~fieldを有構造~fieldとして指定する方法］を述べる。 ◎ Section 2 describes how to specify a Structured Field.

`3§ では、［有構造~field内で利用できる，各種抽象-~data型］を定義する。 ◎ Section 3 defines a number of abstract data types that can be used in Structured Fields.

それらの抽象-型は、 `4§ に述べる~algoを利用して，~HTTP`~field値$［へ直列化できる／から構文解析できる］。 ◎ Those abstract types can be serialized into and parsed from HTTP field values using the algorithms described in Section 4.

1.1. 意図的に厳密な処理

この仕様は、一連の段からなる~algoを利用して，構文解析と直列化の挙動を意図的に厳密に定義する — ~errorの取扱いは、演算をまるごと失敗させる他には定義されない。 ◎ This specification intentionally defines strict parsing and serialization behaviors using step-by-step algorithms; the only error handling defined is to fail the entire operation altogether.

それは、忠実な実装を奨励して，良好な相互運用能を得るために設計されている。したがって，入力に~~寛容であることにより~~親切であろうと試行する実装は、相互運用能を悪化させることになる — そうすると、類似な（が、微妙に異なる見込みが高い）対処法を実装する他の実装に，しわ寄せが行くことになるので。 ◎ It is designed to encourage faithful implementation and good interoperability. Therefore, an implementation that tried to be helpful by being more tolerant of input would make interoperability worse, since that would create pressure on other implementations to implement similar (but likely subtly different) workarounds.

言い換えれば、厳密な処理は，この仕様を成す意図的な特能である — それは、生産器が不適合tな入力をより早く発見して正せるようにして，さもなければ生じることになる［相互運用能／~security ］の課題を避けれるようにする。 ◎ In other words, strict processing is an intentional feature of this specification; it allows non-conformant input to be discovered and corrected by the producer early and avoids both interoperability and security issues that might otherwise result.

注記：この厳密さの結果として，ある~fieldが複数の主体により付加される場合（例：`媒介者$や`送信者$における異なる~component）、ある主体による値に~errorがあれば，当の`~field値$全体の構文解析を失敗させる見込みが高い。 ◎ Note that as a result of this strictness, if a field is appended to by multiple parties (e.g., intermediaries or different components in the sender), an error in one party's value is likely to cause the entire field value to fail parsing.

1.2. 表記上の規約

この文書~内の~keyword "MUST" … 【以下、この段落の内容は`~IETF日本語訳共通~page＠~IETFcommon#requirements-notation$に移譲。】 ◎ 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.

この文書は、 `RFC5234$r の［ `VCHAR$P, `SP$P, `DIGIT$P, `ALPHA$P, `DQUOTE$P ］規則を利用する — 文脈に依存して［各~文字／それらに対応する~ASCII~byte ］を指定するために。また、同じ目的で `HTTP$r の［ `tchar$p, `OWS$p ］規則も利用する。 ◎ This document uses the VCHAR, SP, DIGIT, ALPHA, and DQUOTE rules from [RFC5234] to specify characters and/or their corresponding ASCII bytes, depending on context. It uses the tchar and OWS rules from [HTTP] for the same purpose.

この文書は、各種~algoを利用して，構文解析と直列化の挙動を指定する。 `~HTTP~field$を構文解析する実装の挙動は、 ~algoに従うそれと判別-不能でなければナラナイ。 ◎ This document uses algorithms to specify parsing and serialization behaviors. When parsing from HTTP fields, implementations MUST have behavior that is indistinguishable from following the algorithms.

`~HTTP~field$へ直列化するための各~algoは、そのような表現を生産するときに推奨される仕方を定義する。それらの~algoは、その出力が `4.2§ に述べる構文解析~algoにより正しく取扱われる限り，どう実装されてもヨイ。 ◎ For serialization to HTTP fields, the algorithms define the recommended way to produce them. Implementations MAY vary from the specified behavior so long as the output is still correctly handled by the parsing algorithm described in Section 4.2.

【この訳に特有な表記規約】

◎表記記号

~algoや定義を［明確化する／精緻化する／簡潔に述べる］ため、この訳では `INFRA$r に定義される各種用語, 表記法を取り入れている。それに伴い、原文から構成を違えている~algoもある。

この仕様に定義される，すべての`有構造~data型$は、より汎用な~data型（例：`~list$）と明瞭に判別-可能にするため（例えば，これらの型を参照する他の仕様において）， %~sf型~名（例： `~sf~list$）の様に表記される（ "sf" は `Structured Field^en の略語 — 原文では、これらの型~名は， "`List^en" の様に大文字を用いて区別されている）。 `有構造~data型$は、概念的には ( 汎用な~data型, とり得る値に対する制約 ) の組として捉えれる。

2. 新たな有構造~fieldの定義-法

`~HTTP~field$を有構造~fieldとして指定するためには、策定者は以下に従う必要がある： ◎ To specify an HTTP field as a Structured Field, its authors need to:

この仕様を規範的に参照すること。 ~fieldの［ `受信者$／生成器］は、この文書の要件が効果を及ぼすことを知る必要があるので。 ◎ Normatively reference this specification. Recipients and generators of the field need to know that the requirements of this document are in effect.
当の~fieldは、次に挙げるどれに該当するか識別すること：
- `有構造~header@ （ `Structured Header^en ）（すなわち，`~header節$内に限り利用され得る — 共通的な事例）
- `有構造~trailer@ （ `Structured Trailer^en ）（すなわち，`~trailer節$内に限り利用され得る）
- `有構造~field@ （ `Structured Field^en ）（~header節, ~trailer節どちらにも利用され得る）
【これらの命名~規約が適用されるのは、 ~field定義に限られる：この仕様のように［有構造~header／有構造~trailer ］を一般に取扱う必要がある所では、それらの総称として “有構造~field” が利用されよう（個々の~fieldが［ ~header節, ~trailer節］どちらかに限られるとしても）。有構造~fieldとして定義されたものでも、 ~header節に現れるものに限定するときは， “有構造~header” と称されよう。】
◎ Identify whether the field is a Structured Header (i.e., it can only be used in the header section -- the common case), a Structured Trailer (only in the trailer section), or a Structured Field (both).
`~field値$の型を［ `~sf~list$／`~sf辞書$／`~sf~item$ ］として指定すること。 ◎ Specify the type of the field value; either List (Section 3.1), Dictionary (Section 3.2), or Item (Section 3.3).
`~field値$の意味論を定義すること。 ◎ Define the semantics of the field value.
`~field値$が利用される際に追加的な拘束があれば、拘束に違反した場合の帰結とともに指定すること。 ◎ Specify any additional constraints upon the field value, as well as the consequences when those constraints are violated.

すなわち，~field定義は、概して，~top-level型 — `~sf~list$／`~sf辞書$／`~sf~item$ — を指定してから†，それに［許容-可能な型, 対する拘束］を定義することになる。例えば，`~sf~list$として定義された~headerは、それを成す~memberたちを［すべて`~sf整数$とすることも，何種かの型の混成とすることも］あろう。あるいは，`~sf~item$として定義された~headerは、その値として，`~sf文字列$ — それも、文字 `Q^ch から始まるもの，あるいは小文字のみからなるもの — に限り許容することもあろう。同様に， `~sf内縁~list$は、 ~field定義にて明示的に許容される場合に限り，妥当になる。 ◎ Typically, this means that a field definition will specify the top-level type -- List, Dictionary, or Item -- and then define its allowable types and constraints upon them. For example, a header defined as a List might have all Integer members, or a mix of types; a header defined as an Item might allow only Strings, and additionally only strings beginning with the letter "Q", or strings in lowercase. Likewise, Inner Lists (Section 3.1.1) are only valid when a field definition explicitly allows them.

【† `~sf文字列$など他の型の値をとるかのように指定する仕様もあるかもしれないが、それは，［ `~field値$の型は`~sf~item$であって，その値は`~sf文字列$に制約される］ものと指定することと同義になる（ `2.3§ ）。】

~fieldが`~sf表示~文字列$を利用する場合、許容-可能な~Unicode符号位置を注意深く指定することを勧める — 例えば， `PRECIS$r からの~profileの利用を指定することにより。 ◎ Fields that use the Display String type are advised to carefully specify their allowable Unicode code points; for example, specifying the use of a profile from [PRECIS].

~field定義は、［ `~field値$の一部分ではなく，値~全体］用に限り，この仕様を利用できる。 ◎ Field definitions can only use this specification for the entire field value, not a portion thereof.

各仕様は、有構造~fieldの［ `~field名$／`~field値$ ］を指して — 必要に応じて適切に — 次のいずれかとして称せる ⇒＃ “有構造~header名”, “有構造~trailer名”, “有構造~field名” ／ “有構造~header値”, “有構造~trailer値”, “有構造~field値” ◎ Specifications can refer to a field name as a "Structured Header name", "Structured Trailer name", or "Structured Field name" as appropriate. Likewise, they can refer its field value as a "Structured Header value", "Structured Trailer value", or "Structured Field value" as necessary.

この仕様は、実装が~supportする様々な構造の長さや個数~用に最小を定義する。ほとんどの事例では，最大~sizeを指定しないが、策定者は，［ ~HTTP実装が［個々の~fieldの~size／ ~fieldの総数／ `~field節$の~size ］に様々な制限を課す］ことを自覚するべきである。 ◎ This specification defines minimums for the length or number of various structures supported by implementations. It does not specify maximum sizes in most cases, but authors should be aware that HTTP implementations do impose various limits on the size of individual fields, the total number of fields, and/or the size of the entire header or trailer section.

2.1. 例

架空の `Foo-Example^h ~headerは、次のように指定されるかもしれない： ◎ A fictitious Foo-Example header field might be specified as:

42. `Foo-Example^h ~header ◎ 42. Foo-Example Header Field

`Foo-Example^h ~HTTP~headerは、 ~messageが~Fooをどれだけ有するかについての情報を伝達する。 ◎ The Foo-Example HTTP header field conveys information about how much Foo the message has.

`Foo-Example^h は、 `~sf~item$を値にとる有構造~headerである `RFC9651^r 。値は`~sf整数$でなければナラナイ（ `RFC9651^r, § 3.3.1 ）。 ◎ Foo-Example is an Item Structured Header Field [RFC9651]. Its value MUST be an Integer (Section 3.3.1 of [RFC9651]).

その値は、 ~message内にある~Fooの量を指示する。値は 0 以上 10 以下でなければナラナイ — 他の値に対しては、 ~header全体を無視しなければナラナイ。 ◎ Its value indicates the amount of Foo in the message, and it MUST be between 0 and 10, inclusive; other values MUST cause the entire header field to be ignored.

`~sf~parameter群$を成す`~sf~parameter$として次が定義される — 下の処理~要件を見よ ⇒＃ ~keyは `foourl^l, 値は~message用の~Foo~URLを伝達している`~sf文字列$である（ `RFC9651^r, § 3.3.3 ） ◎ The following parameter is defined: • A parameter whose key is "foourl", and whose value is a String (Section 3.3.3 of [RFC9651]), conveying the Foo URL for the message. See below for processing requirements.

`~sf~parameter$ `foourl^l は、 `URI-reference^p （ `3986/4.1$rfc ）を値にとる。値が妥当な `URI-reference^p でない場合、当の~header全体を無視しなければナラナイ。値が相対~参照（ `3986/4.2$rfc ）である場合、利用する前に解決しなければナラナイ（ `3986/5$rfc ）。 ◎ "foourl" contains a URI-reference (Section 4.1 of [RFC3986]). If its value is not a valid URI-reference, the entire header field MUST be ignored. If its value is a relative reference (Section 4.2 of [RFC3986]), it MUST be resolved (Section 5 of [RFC3986]) before being used.

例えば： ◎ For example:
Foo-Example: 2; foourl="https://foo.example.com/"

2.2. ~errorの取扱い

構文解析に失敗したときは、当の~field全体が無視される（ `4.2§ を見よ）。 ~field定義は、これを上書きできない — そうすると，汎用~softwareによる取扱いを予め除外することになるので。 ~field定義は、追加的な拘束に限り追加できる（例： `~sf整数$や`~sf~decimal$の数量-範囲／ `~sf文字列$や`~sf~token$の形式／ `~sf辞書$を成す~memberの値に許容される型／ `~sf~list$を成す`~sf~item$の個数）。 ◎ When parsing fails, the entire field is ignored (see Section 4.2). Field definitions cannot override this because doing so would preclude handling by generic software; they can only add additional constraints (for example, on the numeric range of Integers and Decimals, the format of Strings and Tokens, the types allowed in a Dictionary's values, or the number of Items in a List).

~fieldに特有な拘束に違反したときは、当の~field定義が他の取扱い要件を定義しない限り，~field全体が無視される。例えば、ある`~header$が［ `~sf~item$として定義され，`~sf整数$をとるものと要求されていた］が，`~sf文字列$を受信した場合、その~fieldの定義にて他が明示的に指定されない限り，それは無視されるべきである。 ◎ When field-specific constraints are violated, the entire field is also ignored, unless the field definition defines other handling requirements. For example, if a header field is defined as an Item and required to be an Integer, but a String is received, it should be ignored unless that field's definition explicitly specifies otherwise.

2.3. 拡張能の保全-法

有構造~fieldは、拡張-可能になるよう設計された — ある~fieldに許容-可能な［構文, 意味論］は、予知されないときでも，制御された流儀で［改変する／追加する］ことが必要yあることが多いことが経験から示されたので。 ◎ Structured Fields are designed to be extensible because experience has shown that, even when it is not foreseen, it is often necessary to modify and add to the allowable syntax and semantics of a field in a controlled fashion.

［ `~sf~item$／`~sf内縁~list$ ］は、拡張能の仕組みとして，`~sf~parameter群$を許容する。これは、もっと情報を収容するために必要なら，それらの値は後で拡張され得ることを意味する。前方-互換性を保全するため、 ~field仕様が［認識されない`~sf~parameter$が在ることを~error条件として定義する］ことは，忌避される。 ◎ Both Items and Inner Lists allow Parameters as an extensibility mechanism; this means that their values can later be extended to accommodate more information, if need be. To preserve forward compatibility, field specifications are discouraged from defining the presence of an unrecognized parameter as an error condition.

拡張能を保全するため、 ~field仕様には，［ `~sf~item$／`~sf~list$ ／`~sf辞書$ ］いずれかとして定義することが要求される。誤って別の型として定義された~field（例： `~sf整数$ ）は、 `~sf~item$である（すなわち，`~sf~parameter群$を許容する）ものと見做される。 ◎ Field specifications are required to be either an Item, List, or Dictionary to preserve extensibility. Fields that erroneously defined as another type (e.g., Integer) are assumed to be Items (i.e., they allow Parameters).

さらに，［この拡張能が将来にも可用になることを確約する］ため, および［完全な構文解析器の実装を利用することを奨励する］ため、 ~field定義は，［送信者は “潤滑（ `grease^en ）” ~parameter†を追加する］ものと指定できる。仕様は、［ある定義-済み~patternに収まる`~sf~parameter$は、すべて，この利用~用に予約される］ものと制定して，それらが要請のある一部分として送信されるよう奨励することもできる。これは、受信者が`~sf~parameter$を織り込まない構文解析器を書くのを忌避するよう促す。 ◎ To further assure that this extensibility is available in the future, and to encourage consumers to use a complete parser implementation, a field definition can specify that "grease" parameters be added by senders. A specification could stipulate that all parameters that fit a defined pattern are reserved for this use and then encourage them to be sent on some portion of requests. This helps to discourage recipients from writing a parser that does not account for Parameters.

【† ~TLSの `GREASE^en と同様な発想による（ `参考＠https://jovi0608.hatenablog.com/entry/2016/10/02/101233$）、［不適合な実装を早期に発見して，技術的~負債を残さないようにする］ための［ ~randomに選ばれ，未定義になる~key ］を持つ~parameterと見受けられる（`課題 #1015＠https://github.com/httpwg/http-extensions/issues/1015$ に論点がある）。】

`~sf辞書$を利用する仕様は、未知な~keyが在っても — および，値やその型が未知な場合も — 無視するよう要求することにより，前方-互換性も許容できる。そうしておけば、後続な仕様は，追加的な~keyを — 適切な拘束も指定した上で — 追加できる。 ◎ Specifications that use Dictionaries can also allow for forward compatibility by requiring that the presence of -- as well as value and type associated with -- unknown keys be ignored. Subsequent specifications can then add additional keys, specifying constraints on them as appropriate.

有構造~fieldに対する拡張は、［自身が定義する値に対する拘束を`~field値$が満たさない場合には、 ~field値~全体を無視する］よう，当の拡張を解する受信者に対し要求できる。 ◎ An extension to a Structured Field can then require that an entire field value be ignored by a recipient that understands the extension if constraints on the value it defines are not met.

2.4. 拡張における新たな有構造~型の利用-法

~field定義は，有構造~field用の特定の~RFCを参照する必要があるので、その値に利用するために可用な型は，その~RFC内に定義されたものに制限されることに注意。例えば，ある~fieldの定義が［この文書／`~RFC 8941$ ］を参照する場合、その`~field値$には， `~sf日時$型を利用-［できる／できない］ — `~sf日時$型は、 `~RFC 8941$ 実装においては妥当でないものとして扱われる（したがって破棄される）ことになるので。 ◎ Because a field definition needs to reference a specific RFC for Structured Fields, the types available for use in its value are limited to those defined in that RFC. For example, a field whose definition references this document can have a value that uses the Date type (Section 3.3.7), whereas a field whose definition references RFC 8941 cannot because it will be treated as invalid (and therefore discarded) by implementations of that specification.

【この節は、 `~sf表示~文字列$にも同様に適用される。】

この制限は、 ~fieldに対する将来の拡張にも適用される。例えば、 `~RFC 8941$ への参照を伴って定義された`~field$は， `~sf日時$型を利用し得ない — 一部の受信者は、それを処理するときに，依然として~RFC 8941 に基づく構文解析器を利用しているかもしれないので。 ◎ This limitation also applies to future extensions to a field; for example, a field that is defined with a reference to RFC 8941 cannot use the Date type because some recipients might still be using a parser based on RFC 8941 to process it.

しかしながら、この文書は，`~RFC 8941$ と後方-互換になるよう設計された。この文書に与えた要件を実装する構文解析器は、妥当な有構造~fieldのうち，その定義が~RFC 8941 を参照するものも構文解析できる。 ◎ However, this document is designed to be backward compatible with RFC 8941; a parser that implements the requirements here can also parse valid Structured Fields whose definitions reference RFC 8941.

有構造~field用の実装を［より新たな改訂~仕様（この文書など）を~supportするよう昇格する］ことは、一部の~field値を処理したとき，［それまでの~RFCでは妥当でなかったものが妥当になる］かもしれないアリ性を持ち込む。 ◎ Upgrading a Structured Fields implementation to support a newer revision of the specification (such as this document) brings the possibility that some field values that were invalid according to the earlier RFC might become valid when processed.

例えば，ある~field~instanceは、当の~fieldの定義が`~sf日時$を収容しない場合でも，構文上は妥当な`~sf日時$を包含するかもしれない。 `~RFC 8941$ に基づく実装は、そのような~field~instanceの構文解析に失敗することになろう — `~sf日時$はその仕様においては定義されないので。その実装がこの仕様に昇格された場合、構文解析は成功するようになろう。一部の事例では，［結果の`~sf日時$値は~fieldに特有な~logicにより却下される］ことになるが、 ~field内の値のうち他では無視されるもの（拡張~parameterなど）は，検出されないかもしれない — その結果，当の~fieldは後続に受容され処理されるかもしれない。 ◎ For example, a field instance might contain a syntactically valid Date (Section 3.3.7), even though that field's definition does not accommodate Dates. An implementation based on RFC 8941 would fail parsing such a field instance because it is not defined in that specification. If that implementation were upgraded to this specification, parsing would now succeed. In some cases, the resulting Date value will be rejected by field-specific logic, but values in fields that are otherwise ignored (such as extension parameters) might not be detected, and the field might subsequently be accepted and processed.

3. 有構造~data型

この節では、 `有構造~field$が利用する各種抽象-型の概観†を供すると伴に，それら各~型が~textな~HTTP~field【すなわち，`~field値$】へどう直列化されるかについて概略的な記述と例を与える。それらが~textな~HTTP~field［からどう構文解析されるか／へどう直列化されるか］についての詳細†は、 `4§が指定する。 ◎ This section provides an overview of the abstract types that Structured Fields use and gives a brief description and examples of how each of those types are serialized into textual HTTP fields. Section 4 specifies the details of how they are parsed from and serialized into textual HTTP fields.

【† すなわち、これら型の定義を成す詳細は，規範的には `4§ を成す各~algoの中で定義される。しかしながら，この訳では、それらの~algo内で同じ文言を繰返す代わりに，この節の中で当の詳細を定義として — 当の型を包摂する汎用な型（`~list$など）の値が，当の型を成すために要求される制約として — 述べることにする。】

要約すれば： ◎ In summary:

`~HTTP~field$の`~field値$として定義できる~top-level型には、次に挙げる 3 種がある ⇒＃ `~sf~list$, `~sf辞書$, `~sf~item$ ◎ There are three top-level types that an HTTP field can be defined as: Lists, Dictionaries, and Items.
［ `~sf~list$, `~sf辞書$ ］は、容器であり，その各~memberは［ `~sf~item$／`~sf内縁~list$ ］を値にとり得る（後者は、それ自体が`~sf~item$たちが成す`~list$である）。 ◎ Lists and Dictionaries are containers; their members can be Items or Inner Lists (which are themselves arrays of Items).
［ `~sf~item$, `~sf内縁~list$ ］は、 `~sf~parameter群$を伴い得る。 ◎ Both Items and Inner Lists can be Parameterized with key/value pairs.

3.1. ~sf~list

`~sf~list@ （ `List^en ）は、各`~item$が［ `~sf~item$／`~sf内縁~list$ ］に制約される`~list$である。 ◎ Lists are arrays of zero or more members, each of which can be an Item (Section 3.3) or an Inner List (Section 3.1.1), both of which can be Parameterized (Section 3.1.2).

空な`~sf~list$は、当の~field全体を直列化しないことにより表される。これは、 `~sf~list$として定義された~fieldの既定の値は，空になることを含意する。 ◎ An empty List is denoted by not serializing the field at all. This implies that fields defined as Lists have a default empty value.

`~sf~list$を成す~memberどうしは， ~textな`~HTTP~field$内に直列化されるときは、［前後に 0 個以上の空白を伴う `,^ch ］で分離される。 ◎ When serialized as a textual HTTP field, each member is separated by a comma and optional whitespace.＼

例えば，`~sf~token$たちが成す`~sf~list$を値にとるものと定義される~fieldは、次の様な見かけになる： ◎ For example, a field whose value is defined as a List of Tokens could look like:

Example-List: sugar, tea, rum

`~sf~list$を成す~memberたちは、同じ`~field節$内では — `HTTP$r `~fieldの順序＠~HTTPinfra#fields.order§ に従って — 複数個の`~field行l$に分割し得ることに注意。 ◎ Note that Lists can have their members split across multiple lines of the same header or trailer section, as per Section 5.3 of [HTTP];＼

例えば，次は： ◎ for example, the following are equivalent:

Example-List: sugar, tea, rum

次と等価になる： ◎ and

Example-List: sugar, tea
Example-List: rum

しかしながら，`~sf~list$を成す個々の~memberは、複数個の`~field行l$に安全に分割し得ない — 詳細は `4.2§ を見よ。 ◎ However, individual members of a List cannot be safely split between lines; see Section 4.2 for details.

構文解析器は、 `~sf~list$を成す~memberとして 1024 個までは~supportしなければナラナイ。 ~field仕様は、 `~sf~list$を成す［個々の~memberの型／~memberの個数］を必要に応じて拘束し得る。 ◎ Parsers MUST support Lists containing at least 1024 members. Field specifications can constrain the types and cardinality of individual List values as they require.

3.1.1. ~sf内縁~list

`~sf内縁~list@ （ `Inner List^en 【 “~top-level構造でない~list” 】）は、次の 2 つからなる`~tuple$である：

各`~item$が`~sf~item$に制約される`~list$
`~sf~parameter群$

【 ~sf内縁~listが “~parameterを伴わない” という句は、これが空であることと同義になる（［伴わないこと, 空であること］を判別するような要件は、指定し得ない — どちらであれ，直列化した結果においては空になるので、そのような要件は施行し得ない）。】

◎ An Inner List is an array of zero or more Items (Section 3.3). Both the individual Items and the Inner List itself can be Parameterized (Section 3.1.2).

`~sf内縁~list$は，~textな`~HTTP~field$内に直列化されるときは、各`~sf~item$どうしを 1 個~以上の ` ^ch で区切った上で【`~sf~parameter群$を除く】全体を丸括弧で括って表される。 ◎ When serialized in a textual HTTP field, Inner Lists are denoted by surrounding parenthesis, and their values are delimited by one or more spaces.＼

［ `~sf文字列$たちが成す`~sf内縁~list$ ］たちが成す`~sf~list$を値にとるように定義された~fieldは、次の様な見かけになる： ◎ A field whose value is defined as a List of Inner Lists of Strings could look like:

Example-List: ("foo" "bar"), ("baz"), ("bat" "one"), ()

この例における最後の~member（ `()^c ）は、空な~sf内縁~listを表すことに注意。 ◎ Note that the last member in this example is an empty Inner List.

`~sf~list$を成す［ `~sf内縁~list$, およびそれを成すある`~sf~item$ ］どちらも`~sf~parameter群$を伴うように定義された~headerは、次の様な見かけになる： ◎ A header field whose value is defined as a List of Inner Lists with Parameters at both levels could look like:

Example-List: ("foo"; a=1;b=2);lvl=5, ("bar" "baz");lvl=1

構文解析器は、 `~sf内縁~list$を成す`~item$として 256 個までは~supportしなければナラナイ。 ~field仕様は、 `~sf内縁~list$を成す［個々の~memberの型／~memberの個数］を必要に応じて拘束し得る。 ◎ Parsers MUST support Inner Lists containing at least 256 members. Field specifications can constrain the types and cardinality of individual Inner List members as they require.

3.1.2. ~sf~parameter群

各［ `~sf~item$ ／ `~sf内縁~list$ ］に結付けられる `~sf~parameter群@ （ `Parameters^en ）は、それを成す各`~entry$map — `~sf~parameter@ （ `Parameter^en ） — が次のように制約される`有順序~map$である：

`~key$mapは、 `~sf~key$である
`値$mapは、 `~sf裸~item$である

◎ Parameters are an ordered map of key-value pairs that are associated with an Item (Section 3.3) or Inner List (Section 3.1.1). The keys are unique within the scope of the Parameters they occur within, and the values are bare items (i.e., they themselves cannot be parameterized; see Section 3.3).

実装は、 `~sf~parameter群$への［ ~indexによる~access, ~keyによる~access ］どちらも供さなければナラナイ。仕様は、 ~accessする手段にどちらを利用してもヨイ。 ◎ Implementations MUST provide access to Parameters both by index and by key. Specifications MAY use either means of accessing them.

`~sf~parameter群$を成す各`~sf~parameter$【！ordered, and】の`~sf~key$は，大文字を包含し得ないことに注意。 ◎ Note that parameters are ordered, and parameter keys cannot contain uppercase letters.

各`~sf~parameter$は，~textな`~HTTP~field$内に直列化されるときは、 `;^ch を接頭することにより，他【！`~sf~item$／`~sf内縁~list$／他の`~sf~parameter$】と分離される。 ◎ When serialized in a textual HTTP field, a Parameter is separated from its Item or Inner List and other Parameters by a semicolon.＼

例えば： ◎ For example:

Example-List: abc;a=1;b=2; cde_456, (ghi;jk=4 l);q="9";r=w

【 `abc;…,^c は`~sf~item$ ／ `(ghi;jk=4 l)…^c は`~sf内縁~list$ 】

`~sf真偽値$ ~T を値にとる`~sf~parameter$を直列化するときには、その値を省略しなければナラナイ。 ◎ Parameters whose value is Boolean (see Section 3.3.6) true MUST omit that value when serialized.＼

例えば、 `~sf~parameter$［ `a^c は ~T, `b^c は ~F ］をとる場合の結果は： ◎ For example, the "a" parameter here is true, while the "b" parameter is false:

Example-Integer: 1; a; b=?0

この要件は、直列化に限られることに注意。構文解析器には、 `~sf~parameter$内に`~sf真偽値$ ~T が出現しても正しく取扱うことが，依然として要求される。 ◎ Note that this requirement is only on serialization; parsers are still required to correctly handle the true value when it appears in a parameter.

構文解析器は、［ `~sf~item$／`~sf内縁~list$ ］の`~sf~parameter群$を成す`~sf~parameter$として 256 個までは~supportしなければナラナイ。 ~field仕様は、 `~sf~parameter群$を成す［ `~sf~parameter$たちの順序／個々の`~sf~parameter$の型］を必要に応じて拘束し得る。 ◎ Parsers MUST support at least 256 parameters on an Item or Inner List,＼ and support parameter keys with at least 64 characters.（ → § key へ移動）＼ Field specifications can constrain the order of individual parameters, as well as their values' types as required.

3.1.2.1. ~sf~key

【この節は、他所を集約するための，この訳による追加。】

`~sf~key@ は、［ `~sf~parameter群$／`~sf辞書$ ］を成す`~key$mapを与える。それは、次のように制約される`文字列$である：

空でない
どの文字も，次に挙げる `~key文字@ である ⇒＃ `~ASCII英小文字$, `~ASCII数字$, `_^ch, `-^ch, `.^ch, `*^ch
最初の文字は［ `~ASCII英小文字$ ／ `*^ch ］

構文解析器は、 `~sf~key$を成す文字として 64 個までは~supportしなければナラナイ。

3.2. ~sf辞書

`~sf辞書@ （ `Dictionary^en ）は、各`~entry$mapが次のように制約される`有順序~map$である：

`~key$mapは、（短い~textな名前を成す）`~sf~key$である
`値$mapは、［ `~sf~item$／`~sf内縁~list$ ］である

◎ Dictionaries are ordered maps of key-value pairs, where the keys are short textual strings and the values are Items (Section 3.3) or arrays of Items, both of which can be Parameterized (Section 3.1.2). There can be zero or more members, and their keys are unique in the scope of the Dictionary they occur within.

実装は、 `~sf辞書$への［ ~indexによる~access, ~keyによる~access ］両者を供さなければナラナイ。仕様は、 ~memberに~accessする手段にどちらを利用してもヨイ。 ◎ Implementations MUST provide access to Dictionaries both by index and by key. Specifications MAY use either means of accessing the members.

`~sf~list$と同じく，空な`~sf辞書$は、当の~field全体を省略することにより表現される。これは、 `~sf辞書$として定義された~fieldの既定の値は，空になることを含意する。 ◎ As with Lists, an empty Dictionary is represented by omitting the entire field. This implies that fields defined as Dictionaries have a default empty value.

~field仕様は、 `~sf辞書$の意味論を，概して［個々の~memberに対し，［その値に許容される型（たち）, その省略可否］をその~keyにより指定する］ことにより定義することになる。 `受信者$は、［未定義／未知］な~keyを伴う~memberを — ~field仕様が特定的にそれを許容しないものとしている場合を除き — 無視しなければナラナイ。 ◎ Typically, a field specification will define the semantics of Dictionaries by specifying the allowed type(s) for individual members by their keys, as well as whether their presence is required or optional. Recipients MUST ignore members whose keys are undefined or unknown, unless the field's specification specifically disallows them.

`~sf辞書$を成す~memberたちは，~textな`~HTTP~field$内に直列化されるときは、【！ordered as serialized and】［前後に 0 個以上の空白を伴う `,^ch ］で互いに分離される。各~memberの~keyは、大文字を包含し得ない。各~memberの~keyと値は、［空白は伴わない `=^ch ］で分離される。 ◎ When serialized as a textual HTTP field, members are ordered as serialized and separated by a comma with optional whitespace. Member keys cannot contain uppercase characters. Keys and values are separated by "=" (without whitespace).＼

例えば： ◎ For example:

Example-Dict: en="Applepie", da=:w4ZibGV0w6ZydGU=:

この例における最後の `=^l は、 `~sf~byte列$を含めた結果に因ることに注意。 ◎ Note that in this example, the final "=" is due to the inclusion of a Byte Sequence; see Section 3.3.5.

~memberのうち`~sf真偽値$ ~T を値にとる`~sf~item$を直列化するときには、その値を省略しなければナラナイ。 ◎ Members whose value is Boolean (see Section 3.3.6) true MUST omit that value when serialized.＼

次の例の~member［ `b^c, `c^c ］は、どちらも ~T を値にとる： ◎ For example, here both "b" and "c" are true:

Example-Dict: a=?0, b, c; foo=bar

この要件は、直列化に限られることに注意。構文解析器には、 `~sf辞書$を成す各~memberに出現する`~sf真偽値$ ~T を正しく取扱うことが依然として要求される。 ◎ Note that this requirement is only on serialization; parsers are still required to correctly handle the true Boolean value when it appears in Dictionary values.

`~sf~token$たちが成す`~sf内縁~list$を値にとる~memberを伴う`~sf辞書$： ◎ A Dictionary with a member whose value is an Inner List of Tokens:

Example-Dict: rating=1.5, feelings=(joy sadness)

各~memberの値として［ `~sf~item$, `~sf内縁~list$ ］が混在する`~sf辞書$の例 — うちいくつか（ `c^c, `d^c ）は、 `~sf~parameter群$も伴う: ◎ A Dictionary with a mix of Items and Inner Lists, some with parameters:

Example-Dict: a=(1 2), b=3, c=4;aa=bb, d=(5 6);valid

`~sf辞書$を成す~memberたちは、同じ`~field節$内では，複数個の`~field行l$に分割し得ることに注意。 ◎ Note that Dictionaries can have their members split across multiple lines of the same header or trailer section;＼

例えば，次は： ◎ for example, the following are equivalent:

Example-Dict: foo=1, bar=2

次と等価になる： ◎ and

Example-Dict: foo=1
Example-Dict: bar=2

しかしながら，`~sf辞書$を成す個々の~memberは、複数個の`~field行l$に安全に分割し得ない。詳細は `4.2§ を見よ。 ◎ However, individual members of a Dictionary cannot be safely split between lines; see Section 4.2 for details.

構文解析器は、 `~sf辞書$を成す~memberとして 1024 個までは~supportしなければナラナイ。 ~field仕様は、 `~sf辞書$を成す［ ~memberたちの順序／個々の~memberの型］を必要に応じて拘束し得る。 ◎ Parsers MUST support Dictionaries containing at least 1024 key/value pairs and keys with at least 64 characters.（ → § key へ移動）＼ Field specifications can constrain the order of individual Dictionary members, as well as their values' types as required.

3.3. ~sf~item

`~sf~item@ （ `Item^en ）は、次の 2 つからなる`~tuple$である：

~sf~itemの値を与える，`~sf裸~item$
`~sf~parameter群$

【 ~sf~itemが “~parameterを伴わない” という句は、これが空であることと同義になる（`~sf内縁~list$のときと同じく）。】

`~sf裸~item@ （ `Bare Item^en ）は、次に挙げるいずれかの型として排他的に識別される値である ⇒＃ `~sf整数$, `~sf~decimal$, `~sf文字列$, `~sf~token$, `~sf~byte列$, `~sf真偽値$, `~sf日時$, `~sf表示~文字列$【！原文抜け】

【例えば［ `~sf文字列$, `~sf~token$, `~sf表示~文字列$ ］は，どれも`文字列$であるが、実装は，型に応じて別々に扱えるよう型~情報を保持する必要がある（ `B§ ）。】【 `~sf日時$, `~sf表示~文字列$は、 `~RFC 8941$ には無かった型である — `2.4§を見よ。】

◎ An Item can be an Integer (Section 3.3.1), a Decimal (Section 3.3.2), a String (Section 3.3.3), a Token (Section 3.3.4), a Byte Sequence (Section 3.3.5), a Boolean (Section 3.3.6), or a Date (Section 3.3.7). It can have associated parameters (Section 3.1.2).

例えば，`~sf整数$を値にとるものと定義される~headerは、次の様な見かけになる: ◎ For example, a header field that is defined to be an Item that is an Integer might look like:

Example-Integer: 5

あるいは，~parameterを伴う場合は： ◎ or with parameters:

Example-Integer: 5; foo=bar

3.3.1. ~sf整数

`~sf整数@ （ `Integer^en ）は、 `IEEE754$r との互換性を得るため†，次のように制約される整数である ⇒ 範囲 { −999999999999999 〜 999999999999999 } に入る（すなわち， 15 桁まで, 有符号）。 ◎ Integers have a range of -999,999,999,999,999 to 999,999,999,999,999 inclusive (i.e., up to fifteen digits, signed), for IEEE 754 compatibility [IEEE754].

【† すなわち、実装が整数を double 型の値として保持する場合に，文字列との相互変換が往復することを確保するため。】

例えば： ◎ For example:

Example-Integer: 42

桁数が 15 を超える整数は、何種類かの仕方で~supportできる — 例えば，［ `~sf文字列$／ `~sf~byte列$／ ~parameterに対する係数として動作する`~sf整数$ ］を利用するなど。 ◎ Integers larger than 15 digits can be supported in a variety of ways; for example, by using a String (Section 3.3.3), a Byte Sequence (Section 3.3.5), or a parameter on an Integer that acts as a scaling factor.

`~sf整数$を［頭部に 0 を伴うよう（例： `0002^l, `-01^l ）／有符号な 0 （ `-0^l ）］に直列化することもアリだが【そうしても構文解析できるが】、実装は，これらの区別を保全しないであろう。 ◎ While it is possible to serialize Integers with leading zeros (e.g., "0002", "-01") and signed zero ("-0"), these distinctions may not be preserved by implementations.

◎ （和訳には不要な内容なので省略） Note that commas in Integers are used in this section's prose only for readability; they are not valid in the wire format.

3.3.2. ~sf~decimal

`~sf~decimal@ （ `Decimal^en ）は、有符号な実数であり，その整数~成分は 12 桁まで（絶対値として 0 〜 999999999999 ）, 小数~成分は 3 桁まで（同 0.000 〜 0.999 ）に制約される（いずれも 10 進記数法で）。 ◎ Decimals are numbers with an integer and a fractional component. The integer component has at most 12 digits; the fractional component has at most three digits.

【 `~sf整数$のときと同様，合わせて 15 桁までにされているのは、実装が`~sf~decimal$を（例えば演算~用に） double 型の値として保持する場合に，それらの相互変換が往復すること — `~sf~decimal$を double 型に変換してから`~sf~decimal$に変換した（丸めた）結果が同じ値に戻ること — を確保することにある。小数~成分が 3 桁までにされているのは、［それ以上を要する利用事例は今の所無い／帯域幅の節約／相互運用能］などが理由に挙げられている。（`課題 #982＠https://github.com/httpwg/http-extensions/issues/982$）】

例えば，`~sf~decimal$を値にとるように定義される~headerは、次の様な見かけになる： ◎ For example, a header whose value is defined as a Decimal could look like:

Example-Decimal: 4.5

`~sf~decimal$を［頭部に 0 を伴うよう（例： `0002.5^l, `-01.334^l ）／尾部に 0 を伴うよう（例： `5.230^l, `-0.40^l ）／有符号な 0 （例： `-0.0^l ）］に直列化することもアリだが【そうしても構文解析できるが】、実装は，これらの区別を保全しないであろう。 ◎ While it is possible to serialize Decimals with leading zeros (e.g., "0002.5", "-01.334"), trailing zeros (e.g., "5.230", "-0.40"), and signed zero (e.g., "-0.0"), these distinctions may not be preserved by implementations.

`~decimalを直列化する$~algoは、小数~成分~内の 3 桁を超える精度を伴う入力を丸めることに注意。代替な丸め策が欲される場合、直列化の前に生じるよう，当の~field定義により指定されるべきである。 ◎ Note that the serialization algorithm (Section 4.1.5) rounds input with more than three digits of precision in the fractional component. If an alternative rounding strategy is desired, this should be specified by the field definition to occur before serialization.

3.3.3. ~sf文字列

`~sf文字列@ （ `String^en ）は、次のように制約される文字列である ⇒ どの文字も，`制御~文字$以外の`~ASCII文字$【！`RFC0020$r】（すなわち， ` ^ch 〜 `~^ch ）である（ `HTAB^P, `LF^P, `CR^P, 等々は除外されることに注意） ◎ Strings are zero or more printable ASCII [RFC0020] characters (i.e., the range %x20 to %x7E). Note that this excludes tabs, newlines, carriage returns, etc.

`~sf文字列$においては、 ~ASCII以外の文字は直に~supportされない — それらは、相互運用能の課題をいくつかもたらすことに加え， `~field値$にそれらが要求されるのは少数の例外に限られるので。 ◎ Non-ASCII characters are not directly supported in Strings because they cause a number of interoperability issues, and -- with few exceptions -- field values do not require them.

`~field値$が~ASCIIでない内容を伝達することが必要yな場合、 `~sf表示~文字列$を指定できる。 ◎ When it is necessary for a field value to convey non-ASCII content, a Display String (Section 3.3.8) can be specified.

`~sf文字列$は，~textな`~HTTP~field$内に直列化されるときは、二重引用符 `"^ch （ `DQUOTE$P ）で区切られ，各［ `"^ch ／ `\^ch ］は `\^ch を利用して~escapeされる。 ◎ When serialized in a textual HTTP field, Strings are delimited with double quotes, using a backslash ("\") to escape double quotes and backslashes.＼

例えば： ◎ For example:

Example-String: "hello world"

`~sf文字列$が区切子として利用するのは `"^ch に限られることに注意 — 一重引用符 `'^ch は`~sf文字列$を区切らない。更には、 ~escapeできる文字は［ `"^ch ／ `\^ch ］に限られる — `\^ch の直後にある他の文字は、構文解析を失敗させなければナラナイ。 ◎ Note that Strings only use DQUOTE as a delimiter; single quotes do not delimit Strings. Furthermore, only DQUOTE and "\" can be escaped; other characters after "\" MUST cause parsing to fail.

構文解析器は、（【~escapeを】復号した後の）`~sf文字列$を成す文字として 1024 個までは~supportしなければナラナイ。 ◎ Parsers MUST support Strings (after any decoding) with at least 1024 characters.

3.3.4. ~sf~token

`~sf~token@ （ `Token^en ）は、短い~textな単語であり，次のように制約される文字列である：

空でない
どの文字も，次に挙げる `~token文字@ である ⇒＃ `tchar$p に許容される~octet, `:^ch, `/^ch
最初の文字は［ `~ASCII英字$ ／ `*^ch ］

◎ Tokens are short textual words that begin with an alphabetic character or "*", followed by zero to many token characters, which are the same as those allowed by the "token" ABNF rule defined in [HTTP] plus the ":" and "/" characters.

例： ◎ For example:

Example-Token: foo123/456

構文解析器は、 `~sf~token$を成す文字として 512 個までは~supportしなければナラナイ。 ◎ Parsers MUST support Tokens with at least 512 characters.

`~sf~token$は、主に，既存の~HTTP~fieldの~data~modelとの互換性を得るために定義される — 実装によっては、追加的な手続きを利用することが要求され得ることに注意。よって、新たな~fieldには，`~sf文字列$を利用することが奨励される。 ◎ Note that Tokens are defined largely for compatibility with the data model of existing HTTP fields and may require additional steps to use in some implementations. As a result, new fields are encouraged to use Strings.

3.3.5. ~sf~byte列

有構造~field内には、 `~sf~byte列@ （ `Byte Sequence^en ）を伝達できる — それは、任意の`~byte列$である。 ◎ Byte Sequences can be conveyed in Structured Fields.

`~sf~byte列$は，~textな`~HTTP~field$内に直列化されるときは、 `base64$p を利用して符号化された上で（ `4648/4$rfc ）， `:^ch で区切られる。 ◎ When serialized in a textual HTTP field, a Byte Sequence is delimited with colons and encoded using base64 ([RFC4648], Section 4).＼

例えば： ◎ For example:

Example-ByteSequence: :cHJldGVuZCB0aGlzIGlzIGJpbmFyeSBjb250ZW50Lg==:

構文解析器は、復号-後における`~sf~byte列$を成す~octetとして，16384 【 ~EQ 1024 × 16 】個までは~supportしなければナラナイ。 ◎ Parsers MUST support Byte Sequences with at least 16384 octets after decoding.

3.3.6. ~sf真偽値

有構造~field内には `~sf真偽値@ （ `Boolean^en ）を伝達できる — それは、 `真偽値$（すなわち，~T／~F ）である。 ◎ Boolean values can be conveyed in Structured Fields.

`~sf真偽値$は，~textな`~HTTP~field$内に直列化されるときは、［ ~T 値を表す `?1^l ／ ~F 値を表す `?0^l ］で指示される。 ◎ When serialized in a textual HTTP field, a Boolean is indicated with a leading "?" character followed by a "1" for a true value or "0" for false.＼

例えば： ◎ For example:

Example-Boolean: ?1

［ `~sf辞書$を成す各~entryの値／各`~sf~parameter$の値］における`~sf真偽値$ ~T は、【直列化されるときには，】値を省略することで指示されることに注意。 ◎ Note that in Dictionary (Section 3.2) and Parameter (Section 3.1.2) values, Boolean true is indicated by omitting the value.

3.3.7. ~sf日時

有構造~field内には `~sf日時@ （ `Date^en ）を伝達できる。 ◎ Date values can be conveyed in Structured Fields.

`~sf日時$の~data~modelは、 `~sf整数$に類似する【~dataとしては，`~sf整数$と同じだが、直列化-法／構文解析-法は異なる】 — それは、 `1970-01-01T00:00:00Z^c からの［閏秒は除外した（場合によっては負な）秒数］を表現する。 ~textな~HTTP~fieldにおけるそれらの直列化も，それに則って`~sf整数$に類似するが、先頭の "`@^c" で判別される。 ◎ Dates have a data model that is similar to Integers, representing a (possibly negative) delta in seconds from 1970-01-01T00:00:00Z, excluding leap seconds. Accordingly, their serialization in textual HTTP fields is similar to that of Integers, distinguished from them with a leading "@".

例えば： ◎ For example:

Example-Date: @1659578233

構文解析器は、 `~sf日時$用の値として， 1年〜 9999年までのすべての日を~supportしなければナラナイ（すなわち、 `1970-01-01T00:00:00Z^c からの秒数として， −62135596800 〜 253402214400 ）。 ◎ Parsers MUST support Dates whose values include all days in years 1 to 9999 (i.e., -62,135,596,800 to 253,402,214,400 delta seconds from 1970-01-01T00:00:00Z).

3.3.8. ~sf表示~文字列

`~sf表示~文字列@ （ `Display String^en ）は、 `~scalar値~文字列$である。それは、 `~sf文字列$と違って，~Unicode`~scalar値$（`~surrogate$でない符号位置）も許容される。 ◎ Display Strings are similar to Strings, in that they consist of zero or more characters, but they allow Unicode scalar values (i.e., all Unicode code points except for surrogates), unlike Strings.

`~sf表示~文字列$は、［末端-利用者に表示されるので，~ASCIIでない内容を運ぶ必要もある事例］用の利用に意図される。［ `~sf文字列$／`~sf~token$ ］で必要十分な状況においては、その利用は，`推奨されない^2119 — ~Unicodeには、正しく取扱うことを困難にする［処理-法の考慮点（例：正規化）／ ~securityの考慮点（例：同形異字語（ `homograph^en ）攻撃）］があるので。 ◎ Display Strings are intended for use in cases where a value is displayed to end users and therefore may need to carry non-ASCII content. It is NOT RECOMMENDED that they be used in situations where a String (Section 3.3.3) or Token (Section 3.3.4) would be adequate because Unicode has processing considerations (e.g., normalization) and security considerations (e.g., homograph attacks) that make it more difficult to handle correctly.

`~sf表示~文字列$は、値に利用される言語を指示しないことに注意。必要yなら，別々に行える（例：~parameterを伴わせて）。 ◎ Note that Display Strings do not indicate the language used in the value; that can be done separately if necessary (e.g., with a parameter).

~textな`~HTTP~field$においては、 `~sf表示~文字列$は — ~ASCIIでない文字は~percent-符号化されることを除いて — `~sf文字列$と類似な方式で表現される。それらは、先頭の "`%^c" により，`~sf文字列$から判別される。 ◎ In textual HTTP fields, Display Strings are represented in a manner similar to Strings, except that non-ASCII characters are percent-encoded; there is a leading "%" to distinguish them from Strings.

例えば： ◎ For example:

Example-DisplayString: %"This is intended for display to `%c3%bcsers^."

【 `%c3%bc^c は文字 ü を~UTF-8符号化してから~percent-符号化した結果を成す 2 個の 16 進~数字。】

`~sf表示~文字列$を取扱う際の追加的な~securityの考慮点は、 `6§ を見よ。 ◎ See Section 6 for additional security considerations when handling Display Strings.

4. ~HTTPにおける有構造~fieldによる作業-法

この節は、 § `有構造~data型$にて定義される各種抽象-型を，~textな`~field値$ — あるいはそれと互換な他の符号化法（例： `HTTP/2$r においては、 `HPACK$r による圧縮が適用される前のそれ） — へ直列化する方法, およびそれらから構文解析する方法を定義する。 ◎ This section defines how to serialize and parse the abstract types defined by Section 3 into textual HTTP field values and other encodings compatible with them (e.g., in HTTP/2 [HTTP/2] before compression with HPACK [HPACK]).

4.1. 有構造~fieldの直列化-法

この節に定義される~algoは、汎用な~data型を入力にとるように設計されている（ `B§ ）。 `有構造~data型$をそのような~data型として内部的に保持する実装は、この節にて定義される各種直列化~algoにおいて，どこかで ~Assert に違反した場合には、直列化~全体を失敗させるとする。【この要件は、以下を簡潔に述べるための，この訳による追加。】

所与の（ %構造 ) に対し，［ ~HTTP`~field値$に利用するに相応しい~ASCII文字列］を返す。 ◎ Given a structure defined in this specification, return an ASCII string suitable for use in an HTTP field value.

~IF［ %構造は［ `有順序~map$ ／ `~list$ ］である］~AND［ %構造は空である］ ⇒ ~RET — 当の~fieldは直列化しない（すなわち， `field-name$p, `field-value$p 両者とも省略する） ◎ If the structure is a Dictionary or List and its value is empty (i.e., it has no members), do not serialize the field at all (i.e., omit both the field-name and field-value).
%出力~文字列 ~LET %構造に応じて ⇒＃ `~list$であるならば `~listを直列化する$( %構造 ) ／ `有順序~map$であるならば `辞書を直列化する$( %構造 ) ／ ~ELSE_ `~itemを直列化する$( %構造 ) ◎ If the structure is a List, let output_string be the result of running Serializing a List (Section 4.1.1) with the structure. ◎ Else, if the structure is a Dictionary, let output_string be the result of running Serializing a Dictionary (Section 4.1.2) with the structure. ◎ Else, if the structure is an Item, let output_string be the result of running Serializing an Item (Section 4.1.3) with the structure. ◎ Else, fail serialization.
~RET `~ASCII符号化する$( %出力~文字列 ) 【！ `RFC0020$r を利用して，を~byte列に変換した結果】 ◎ Return output_string converted into an array of bytes, using ASCII encoding [RFC0020].

4.1.1. `~sf~list$の直列化-法

所与の ( `~list$ %入力~list ) に対し，［ ~HTTP`~field値$に利用するに相応しい~ASCII文字列］を返す： ◎ Given an array of (member_value, parameters) tuples as input_list, return an ASCII string suitable for use in an HTTP field value.

%出力~list ~LET 新たな`~list$ ◎ Let output be an empty string.
%入力~list を成す ~EACH( %~item ) に対し ⇒ %出力~list に次の結果を`付加する$ ⇒ %~item に応じて ⇒＃ `~list$であるならば `内縁~listを直列化する$( %~item ) ／ ~ELSE_ `~itemを直列化する$( %~item ) ◎ For each (member_value, parameters) of input_list: • If member_value is an array, append the result of running Serializing an Inner List (Section 4.1.1.1) with (member_value, parameters) to output. • Otherwise, append the result of running Serializing an Item (Section 4.1.3) with (member_value, parameters) to output.
~RET %出力~list を［ `,^ch, ` ^ch ］並びで`連結する$ ◎ • If more member_values remain in input_list: •• Append "," to output. •• Append a single SP to output. ◎ Return output.

4.1.1.1. `~sf内縁~list$の直列化-法

所与の ( `~list$ %内縁~list ) に対し，［ ~HTTP`~field値$に利用するに相応しい~ASCII文字列］を返す。 ◎ Given an array of (member_value, parameters) tuples as inner_list, and parameters as list_parameters, return an ASCII string suitable for use in an HTTP field value.

%出力~item~list ~LET 新たな`~list$ ◎ ↓
%内縁~list を成す ~EACH( %~item ) に対し ⇒ %出力~item~list に次の結果を`付加する$ ⇒ `~itemを直列化する$( %~item ) ◎ Let output be the string "(". ◎ For each (member_value, parameters) of inner_list: • Append the result of running Serializing an Item (Section 4.1.3) with (member_value, parameters) to output. • If more values remain in inner_list, append a single SP to output.
~RET 次を順に`連結する$ ⇒＃ `(^ch, %出力~item~list を ` ^ch で`連結する$, `)^ch, `~parameter群を直列化する$( %内縁~list の`~sf~parameter群$ ) ◎ ↑ ◎ Append ")" to output. ◎ Append the result of running Serializing Parameters (Section 4.1.1.2) with list_parameters to output. ◎ Return output.

4.1.1.2. `~sf~parameter群$の直列化-法

所与の ( `有順序~map$ %入力~parameter群 ) に対し，［ ~HTTP`~field値$に利用するに相応しい~ASCII文字列］を返す： ◎ Given an ordered Dictionary as input_parameters (each member having a param_key and a param_value), return an ASCII string suitable for use in an HTTP field value.

%出力 ~LET 空~文字列 ◎ Let output be an empty string.
%入力~parameter群を成す ~EACH( %~parameter~key → %~parameter値 ) に対し： ◎ For each param_key with a value of param_value in input_parameters:
1. %出力に `;^ch を付加する ◎ Append ";" to output.
2. %出力に次の結果を付加する ⇒ `~keyを直列化する$( %~parameter~key ) ◎ Append the result of running Serializing a Key (Section 4.1.1.3) with param_key to output.
3. ~IF［ %~parameter値は`~sf真偽値$ ~T である］ ⇒ ~CONTINUE ◎ If param_value is not Boolean true:
4. %出力に `=^ch を付加する ◎ Append "=" to output.
5. %出力に次の結果を付加する ⇒ `裸~itemを直列化する$( %~parameter値 ) ◎ Append the result of running Serializing a bare Item (Section 4.1.3.1) with param_value to output.
~RET %出力 ◎ Return output.

4.1.1.3. `~sf~key$の直列化-法

所与の ( %入力~key ) に対し，［ ~HTTP`~field値$に利用するに相応しい~ASCII文字列］を返す： ◎ Given a key as input_key, return an ASCII string suitable for use in an HTTP field value.

~Assert： %入力~key は`~sf~key$である ◎ Convert input_key into a sequence of ASCII characters; if conversion fails, fail serialization. ◎ If input_key contains characters not in lcalpha, DIGIT, "_", "-", ".", or "*", fail serialization. ◎ If the first character of input_key is not lcalpha or "*", fail serialization.
~RET %入力~key ◎ Let output be an empty string. ◎ Append input_key to output. ◎ Return output.

4.1.2. `~sf辞書$の直列化-法

所与の ( `有順序~map$ %入力~辞書 ) に対し，［ ~HTTP`~field値$に利用するに相応しい~ASCII文字列］を返す： ◎ Given an ordered Dictionary as input_dictionary (each member having a member_key and a tuple value of (member_value, parameters)), return an ASCII string suitable for use in an HTTP field value.

%出力~list ~LET 新たな`~list$ ◎ Let output be an empty string.
%入力~辞書を成す ~EACH( %~member~key → %~member値 ) に対し： ◎ For each member_key with a value of (member_value, parameters) in input_dictionary:
1. %出力 ~LET `~keyを直列化する$( %~member~key ) ◎ Append the result of running Serializing a Key (Section 4.1.1.3) with member's member_key to output.
2. ~IF［ %~member値は`~sf~item$であって，その値は`~sf真偽値$ ~T である］ ⇒ %出力に次の結果を付加する ⇒ `~parameter群を直列化する$( %~member値の`~sf~parameter群$ ) ◎ If member_value is Boolean true: • Append the result of running Serializing Parameters (Section 4.1.1.2) with parameters to output.
3. ~ELSE ◎ Otherwise:
  1. %出力に `=^ch を付加する ◎ Append "=" to output.
  2. %出力に %~member値の型に応じて，次の結果を付加する ⇒＃ `~list$であるならば `内縁~listを直列化する$( %~member値 ) ／ ~ELSE_ `~itemを直列化する$( %~member値 ) ◎ If member_value is an array, append the result of running Serializing an Inner List (Section 4.1.1.1) with (member_value, parameters) to output. ◎ Otherwise, append the result of running Serializing an Item (Section 4.1.3) with (member_value, parameters) to output.
4. %出力~list に %出力を`付加する$ ◎ ↓If more members remain in input_dictionary: • Append "," to output. • Append a single SP to output.
~RET 次の結果 ⇒ %出力~list を［ `,^ch, ` ^ch ］並びで`連結する$ ◎ ↑ ◎ Return output.

4.1.3. `~sf~item$の直列化-法

所与の ( %~item ) に対し，［ ~HTTP`~field値$に利用するに相応しい~ASCII文字列］を返す： ◎ Given an Item as bare_item and Parameters as item_parameters, return an ASCII string suitable for use in an HTTP field value.

~Assert： %~item は ( 任意の値 %値, `有順序~map$ %~parameter群 ) からなる`~tuple$である ◎ ↑
~RET 次を順に`連結する$ ⇒＃ `裸~itemを直列化する$( %値 ), `~parameter群を直列化する$( %~parameter群 ) ◎ Let output be an empty string. ◎ Append the result of running Serializing a Bare Item (Section 4.1.3.1) with bare_item to output. ◎ Append the result of running Serializing Parameters (Section 4.1.1.2) with item_parameters to output. ◎ Return output.

4.1.3.1. `~sf裸~item$の直列化-法

所与の ( %入力~item ) に対し，［ ~HTTP`~field値$に利用するに相応しい~ASCII文字列］を返す： ◎ Given an Item as input_item, return an ASCII string suitable for use in an HTTP field value.

~RET %入力~item の型に応じて：
- `~sf整数$ ⇒ `整数を直列化する$( %入力~item ) ◎ If input_item is an Integer, return the result of running Serializing an Integer (Section 4.1.4) with input_item.
- `~sf~decimal$ ⇒ `~decimalを直列化する$( %入力~item ) ◎ If input_item is a Decimal, return the result of running Serializing a Decimal (Section 4.1.5) with input_item.
- `~sf文字列$ ⇒ `文字列を直列化する$( %入力~item ) ◎ If input_item is a String, return the result of running Serializing a String (Section 4.1.6) with input_item.
- `~sf~token$ ⇒ `~tokenを直列化する$( %入力~item ) ◎ If input_item is a Token, return the result of running Serializing a Token (Section 4.1.7) with input_item.
- `~sf~byte列$ ⇒ `~byte列を直列化する$( %入力~item ) ◎ If input_item is a Byte Sequence, return the result of running Serializing a Byte Sequence (Section 4.1.8) with input_item.
- `~sf真偽値$ ⇒ `真偽値を直列化する$( %入力~item ) ◎ If input_item is a Boolean, return the result of running Serializing a Boolean (Section 4.1.9) with input_item.
- `~sf日時$ ⇒ `日時を直列化する$( %入力~item ) ◎ If input_item is a Date, return the result of running Serializing a Date (Section 4.1.10) with input_item.
- `~sf表示~文字列$ ⇒ `表示~文字列を直列化する$( %入力~item ) ◎ If input_item is a Display String, return the result of running Serializing a Display String (Section 4.1.11) with input_item.
- その他の型 ⇒ ~Assert：この事例は生じ得ない ◎ Otherwise, fail serialization.

4.1.4. `~sf整数$の直列化-法

所与の ( %入力~整数 ) に対し，［ ~HTTP`~field値$に利用するに相応しい~ASCII文字列］を返す： ◎ Given an Integer as input_integer, return an ASCII string suitable for use in an HTTP field value.

~Assert： %入力~整数は整数である ◎ If input_integer is not an integer in the range of -999,999,999,999,999 to 999,999,999,999,999 inclusive, fail serialization. ◎ ↓
%符号 ~LET 空~文字列 ◎ Let output be an empty string.
~IF［ %入力~整数 ~LT 0 ］ ⇒＃ %符号 ~SET `-^ch； %入力~整数 ~SET %入力~整数の絶対値 ◎ If input_integer is less than (but not equal to) 0, append "-" to output.
~Assert： %入力~整数 ~IN { 0 〜 999999999999999 } （ 15 桁まで） ◎ ↑
%整数~部 ~LET %入力~整数を 10 進記数法で， 15 個~以下†の`~ASCII数字$を利用して表現する文字列

【頭部にある `0^ch を除去して最短な表現にするよう，要求されてはいない（ 1 は `01^l 等々に直列化されるかもしれない／ `~decimalを直列化する$ときと違って， 0 も）。】
◎ Append input_integer's numeric value represented in base 10 using only decimal digits to output.
~RET 次を順に`連結する$ ⇒＃ %符号, %整数~部 ◎ Return output.

4.1.5. `~sf~decimal$の直列化-法

所与の ( %入力~decimal ) に対し，［ ~HTTP`~field値$に利用するに相応しい~ASCII文字列］を返す： ◎ Given a decimal number as input_decimal, return an ASCII string suitable for use in an HTTP field value.

~Assert： %入力~decimal は実数である ◎ If input_decimal is not a decimal number, fail serialization.
%入力~decimal をその小数~部が 3 桁までになるよう（ 4 桁~目以降を）丸める — 等距離にある候補が 2 つある場合、小数~部の 3 桁~目が偶数になる方を選ぶとする ◎ If input_decimal has more than three significant digits to the right of the decimal point, round it to three decimal places, rounding the final digit to the nearest value, or to the even value if it is equidistant.
%符号 ~LET 空~文字列 ◎ ↓
~IF［ %入力~decimal ~LT 0 ］ ⇒＃ %符号 ~SET `-^ch； %入力~decimal ~SET %入力~decimal の絶対値 ◎ ↓
%入力~整数 ~LET %入力~decimal の整数~成分 ◎ ↓
~Assert： %入力~整数 ~IN { 0 〜 999999999999 } （ 12 桁まで） ◎ If input_decimal has more than 12 significant digits to the left of the decimal point after rounding, fail serialization.
%整数~部 ~LET `0^ch ◎ ↓
~IF［ %入力~整数 ~NEQ 0 ］ ⇒ %整数~部 ~SET %入力~整数を 10 進記数法で， 12 個~以下†の`~ASCII数字$を利用して表現する文字列

【頭部にある `0^ch を除去して最短な表現にするよう，要求されてはいない（ 1 は `01^l 等々に直列化されるかもしれない）。】
◎ Let output be an empty string. ◎ If input_decimal is less than (but not equal to) 0, append "-" to output. ◎ Append input_decimal's integer component represented in base 10 (using only decimal digits) to output; if it is zero, append "0". ◎ Append "." to output.
%小数~部 ~LET `0^ch ◎ ↓
~IF［ %入力~decimal の小数~成分 ~NEQ 0 ］ ⇒ %小数~部 ~SET 1 〜 3 個†の`~ASCII数字$からなる，次を満たす文字列 ⇒ 先頭に `0.^l を付加して 10 進数として解釈した結果 ~EQ %入力~decimal の小数~成分

【† 尾部にある `0^ch を除去して最短な表現にするよう、明示的に要求されてはいない（ 0.1 は `0.100^l に直列化されるかもしれない）。】
◎ If input_decimal's fractional component is zero, append "0" to output. ◎ Otherwise, append the significant digits of input_decimal's fractional component represented in base 10 (using only decimal digits) to output.
~RET 次を順に`連結する$ ⇒＃ %符号, %整数~部, `.^ch, %小数~部 ◎ Return output.

4.1.6. `~sf文字列$の直列化-法

所与の ( %入力~文字列 ) に対し，［ ~HTTP`~field値$に利用するに相応しい~ASCII文字列］を返す： ◎ Given a String as input_string, return an ASCII string suitable for use in an HTTP field value.

~Assert： %入力~文字列は`~sf文字列$である ◎ Convert input_string into a sequence of ASCII characters; if conversion fails, fail serialization. ◎ If input_string contains characters in the range %x00-1f or %x7f-ff (i.e., not in VCHAR or SP), fail serialization.
%出力 ~LET `"^ch ◎ Let output be the string DQUOTE.
%入力~文字列を成す ~EACH( %文字 ) に対し： ◎ For each character char in input_string:
1. ~IF［ %文字 ~IN { `\^ch, `"^ch } ］ ⇒ %出力に `\^ch を付加する ◎ If char is "\" or DQUOTE: • Append "\" to output.
2. %出力に %文字を付加する ◎ Append char to output.
%出力に `"^ch を付加する ◎ Append DQUOTE to output.
~RET %出力 ◎ Return output.

4.1.7. `~sf~token$の直列化-法

所与の ( %入力~token ) に対し，［ ~HTTP`~field値$に利用するに相応しい~ASCII文字列］を返す： ◎ Given a Token as input_token, return an ASCII string suitable for use in an HTTP field value.

~Assert： %入力~token は`~sf~token$である ◎ Convert input_token into a sequence of ASCII characters; if conversion fails, fail serialization. ◎ If the first character of input_token is not ALPHA or "*", or the remaining portion contains a character not in tchar, ":", or "/", fail serialization.
~RET %入力~token ◎ Let output be an empty string. ◎ Append input_token to output. ◎ Return output.

4.1.8. `~sf~byte列$の直列化-法

所与の ( %入力~byte列 ) に対し，［ ~HTTP`~field値$に利用するに相応しい~ASCII文字列］を返す： ◎ Given a Byte Sequence as input_bytes, return an ASCII string suitable for use in an HTTP field value.

~Assert： %入力~byte列は`~byte列$である ◎ If input_bytes is not a sequence of bytes, fail serialization.
%出力 ~LET 空~文字列 ◎ Let output be an empty string.
%出力に `:^ch を付加する ◎ Append ":" to output.
%出力に次の結果を付加する ⇒ `4648/4$rfc に従って, および下に与える要件を織り込む下で， %入力~byte列を~base64に符号化した結果 ◎ Append the result of base64-encoding input_bytes as per [RFC4648], Section 4, taking account of the requirements below.
%出力に `:^ch を付加する ◎ Append ":" to output.
~RET %出力 ◎ Return output.

`4648/3.2$rfc に従って、符号化された~dataには， `=^ch を補充する（ `pad^en する）ことが要求される。 ◎ The encoded data is required to be padded with "=", as per [RFC4648], Section 3.2.

【すなわち、符号化した結果の長さが 4 の倍数にならない場合，そうなるよう補充する。】

同様に， `4648/3.5$rfc に従って、符号化される~dataにおける補充~bitを 0 に設定するベキである — 実装の拘束に因り，それがアリでない場合を除き。 ◎ Likewise, encoded data SHOULD have pad bits set to zero, as per [RFC4648], Section 3.5, unless it is not possible to do so due to implementation constraints.

【 ~base64単位を成す 6 ~bitと~byte単位を成す 8 ~bitとのずれに因る不足分を（~byte列の末尾に）補充する~bit。】【構文解析器は、補充~bitに関しては，この~algoの出力より~~寛容な形式を受容する（ `4.2.7§ ）。】

4.1.9. `~sf真偽値$の直列化-法

所与の ( %入力~真偽値 ) に対し，［ ~HTTP`~field値$に利用するに相応しい~ASCII文字列］を返す： ◎ Given a Boolean as input_boolean, return an ASCII string suitable for use in an HTTP field value.

~Assert： %入力~真偽値は`真偽値$である ◎ If input_boolean is not a boolean, fail serialization.
~RET %入力~真偽値に応じて ⇒＃ ~T ならば `?1^l ／ ~F ならば `?0^l ◎ Let output be an empty string. ◎ Append "?" to output. ◎ If input_boolean is true, append "1" to output. ◎ If input_boolean is false, append "0" to output. ◎ Return output.

4.1.10. `~sf日時$の直列化-法

所与の ( %入力~日時 ) に対し，［ ~HTTP`~field値$に利用するに相応しい~ASCII文字列］を返す： ◎ Given a Date as input_date, return an ASCII string suitable for use in an HTTP field value.

%出力 ~LET "`@^c" ◎ Let output be "@".
%出力に次の結果を付加する ⇒ `整数を直列化する$( %入力~日時 ) ◎ Append to output the result of running Serializing an Integer with input_date (Section 4.1.4).
~RET %出力 ◎ Return output.

4.1.11. `~sf表示~文字列$の直列化-法

所与の ( %入力~文字列 ) に対し，［ ~HTTP`~field値$に利用するに相応しい~ASCII文字列］を返す： ◎ Given a sequence of Unicode code points as input_sequence, return an ASCII string suitable for use in an HTTP field value.

~Assert： %入力~文字列は`~scalar値~文字列$である ◎ If input_sequence is not a sequence of Unicode code points, fail serialization. ◎ ↓
%~byte列 ~LET `UTF8$r `§ 3＠~RFCx/rfc3629#section-3$ に従って， %入力~文字列に~UTF-8符号化法を適用した結果 ◎ Let byte_array be the result of applying UTF-8 encoding (Section 3 of [UTF8]) to input_sequence. If encoding fails, fail serialization.
%符号化された文字列 ~LET 次を順に`連結する$ ⇒＃ `%^ch, `"^ch ◎ Let encoded_string be a string containing "%" followed by DQUOTE.
%~byte列を成す ~EACH( %~byte ) に対し： ◎ For each byte in byte_array:
1. ~IF［ %~byte ~IN { `25^X（ `%^l ）, `22^X（ `"^l ）, `00-1f^X, `7f-ff^X } ］： ◎ If byte is %x25 ("%"), %x22 (DQUOTE), or in the ranges %x00-1f or %x7f-ff:
  1. %符号化された文字列に `%^ch を付加する ◎ Append "%" to encoded_string.
  2. %符号化された~byte ~LET `4648/8$rfc に従って， %~byte を~base16符号化した結果 ◎ Let encoded_byte be the result of applying base16 encoding (Section 8 of [RFC4648]) to byte,＼
  3. %符号化された文字列に次の結果を付加する ⇒ `~ASCII小文字~化する$( %符号化された~byte ) ◎ with any alphabetic characters converted to lowercase. ◎ Append encoded_byte to encoded_string.
2. ~ELSE ⇒ %符号化された文字列に次の結果を付加する ⇒ `~ASCII復号する$( %~byte ) ◎ Otherwise, decode byte as an ASCII character and append the result to encoded_string.
%符号化された文字列に `%^ch を付加する ◎ Append DQUOTE to encoded_string.
~RET %符号化された文字列 ◎ Return encoded_string.

`UTF8$r は、 `~surrogate$の符号化法を禁制することに注意 — %入力~文字列内にそれらが生じた場合、直列化は失敗することになる。 ◎ Note that [UTF8] prohibits the encoding of code points between U+D800 and U+DFFF (surrogates); if they occur in input_sequence, serialization will fail.

4.2. 有構造~fieldの構文解析-法

受信した［有構造~fieldであることが既知な`~HTTP~field$ ］を構文解析する実装は、［相互運用能や~securityにまで問題をもたらし得る，いくつかの際どい事例］を~careすることが重要になる。この節は、そうするための~algoを指定する。 ◎ When a receiving implementation parses HTTP fields that are known to be Structured Fields, it is important that care be taken, as there are a number of edge cases that can cause interoperability or even security problems. This section specifies the algorithm for doing so.

所与の ( %入力~byte列, %~field型 ) に対し，構文解析された`~field値$を返す： ◎ Given＼

~Assert： %入力~byte列は当の~fieldの `field-value$p を表現する`~byte列$である（その~fieldが無い場合、空~byte列） ◎ an array of bytes as input_bytes that represent the chosen field's field-value (which is empty if that field is not present) and＼
~Assert： %~field型 ~IN { `辞書^i, `~list^i, `~item^i } ◎ field_type (one of "dictionary", "list", or "item"), return the parsed field value.
~IF［ %入力~byte列を成すある~byteは`~ASCII~byte$でない］ ⇒ 構文解析を失敗させる ◎ ↓
%入力~文字列 ~LET `~ASCII復号する$( %入力~byte列 ) ◎ Convert input_bytes into an ASCII string input_string; if conversion fails, fail parsing.
%位置 ~LET %入力~文字列内の先頭を指している`位置~変数$ ⇒ %入力~文字列, %位置は、この~algoが利用するすべての~algoから共有される。

【この段は、この訳による追加。この節~全体を通して，各種~algoは、［構文解析される文字列を保持する %入力~文字列］および［次に構文解析される文字を指す変数 %位置］を利用する~patternに従う（この訳では、そのように改めることにする）。詳細は、以降に現れる %位置↗ という表記も含め，`位置~変数$を参照されたし。】
%入力~文字列内の %位置から ` ^ch からなる`文字~並びを収集する$ ◎ Discard any leading SP characters from input_string.
%出力 ~LET %~field型に応じて，次に与える結果 ⇒＃ `~list^i ならば %入力~文字列から`~listを構文解析する$／ `辞書^i ならば %入力~文字列から`辞書を構文解析する$／ `~item^i ならば %入力~文字列から`~itemを構文解析する$ ◎ If field_type is "list", let output be the result of running Parsing a List (Section 4.2.1) with input_string. ◎ If field_type is "dictionary", let output be the result of running Parsing a Dictionary (Section 4.2.2) with input_string. ◎ If field_type is "item", let output be the result of running Parsing an Item (Section 4.2.3) with input_string.
%入力~文字列内の %位置から ` ^ch からなる`文字~並びを収集する$ ◎ Discard any leading SP characters from input_string.
~IF［ %位置↗ ~NEQ ε ］ ⇒ 構文解析を失敗させる ◎ If input_string is not empty, fail parsing.
~RET %出力 ◎ Otherwise, return output.

構文解析器は、 %入力~byte列を生成する際には，同じ`~field節$を成す`~field行l$のうち［対象の`~field名$に文字大小無視で合致するものすべて］の`~field行l値$を — `HTTP$r `~field行lと結合-済みな~field値＠~HTTPinfra#field.lines§ に従って — `,^ch で分離して 1 個の `field-value$p に結合しなければナラナイ — これは、 `~field値$が正しく処理されることを確約する。 ◎ When generating input_bytes, parsers MUST combine all field lines in the same section (header or trailer) that case-insensitively match the field name into one comma-separated field-value, as per Section 5.2 of [HTTP]; this assures that the entire field value is processed correctly.

［ `~sf~list$／`~sf辞書$ ］に対しては、これには，当の`~field行l値$すべてを正しく連結する効果がある — ~top-level~data構造を成す個々の~memberが複数個の`~field行l$に分割されていない限り。どちらの型も、それ用の構文解析~algoは， ~HTAB を許容する — `~field行l$を結合するとき， ~HTAB を利用する実装もあるかもしれないので。 ◎ For Lists and Dictionaries, this has the effect of correctly concatenating all of the field's lines, as long as individual members of the top-level data structure are not split across multiple field instances. The parsing algorithms for both types allow tab characters, since these might be used to combine field lines by some implementations.

`~sf文字列$は、複数個の`~field行l$に分割されると予測-不能な結果になる — 【結合-時に挿入される】 `,^ch （と省略可能な ` ^ch ）は、構文解析器による文字列~出力の一部を成すことになるので。 `上流$の`媒介者$は，連結を行うかもしれないので、その結果は［直列化器／構文解析器］からは制御し得ない — どちらも同じ主体の制御-下にあるときであっても。 ◎ Strings split across multiple field lines will have unpredictable results, because one or more commas (with optional whitespace) will become part of the string output by the parser. Since concatenation might be done by an upstream intermediary, the results are not under the control of the serializer or the parser, even when they are both under the control of the same party.

［ `~sf~token$／`~sf整数$／`~sf~decimal$／`~sf~byte列$ ］は、複数個の`~field行l$に分割し得ない — 【結合-時に】挿入される `,^ch は，構文解析を失敗させることになるので。 ◎ Tokens, Integers, Decimals, and Byte Sequences cannot be split across multiple field lines because the inserted commas will cause parsing to fail.

構文解析器は、複数の`~field行l$にまたがる`~field値$を処理するとき，いずれかの行lが当の~field用の値として構文解析されないときには，失敗してもヨイ。 ◎ Parsers MAY fail when processing a field value spread across multiple field lines, when one of those lines does not parse as that field.＼

例えば，［ `~sf文字列$【！sf-string】として定義された `Example-String^h ~field ］を取扱っている構文解析は、次の`~field節$を処理するときは，失敗することが許容される： ◎ For example, a parsing handling an Example-String field that's defined as an sf-string is allowed to fail when processing this field section:

Example-String: "foo
Example-String: bar"

構文解析に失敗した場合†、次のいずれかに従わなければナラナイ： ◎ If parsing fails, either＼

当の`~field値$全体を無視する（すなわち、当の~fieldは当の`~field節$内に無かったかのように扱う）。 ◎ the entire field value MUST be ignored (i.e., treated as if the field were not present in the section),＼
代替として，`完全$な~HTTP`~message$を不正形として扱う。 ◎ or alternatively the complete HTTP message MUST be treated as malformed.＼

【† 各~algoにおいては、 “構文解析を失敗させる” という句で指示される。】

相互運用能と安全性を改善するため、この要件は，意図的に厳密である — 有構造~fieldを利用している~field仕様には、この要件を~~緩めることは許容されない。 ◎ This is intentionally strict to improve interoperability and safety, and field specifications that use Structured Fields are not allowed to loosen this requirement.

この要件は、 ~fieldを構文解析しない実装には適用されないことに注意。例えば，`媒介者$には、［ `~message$を回送する前に，失敗している~fieldを剥取る］ことは要求されない。 ◎ Note that this requirement does not apply to an implementation that is not parsing the field;＼ for example, an intermediary is not required to strip a failing field from a message before forwarding it.

4.2.1. ~sf~listの構文解析-法

%入力~文字列から`~sf~list$を構文解析して返す： ◎ Given an ASCII string as input_string, return an array of (item_or_inner_list, parameters) tuples. input_string is modified to remove the parsed value.

%~member群 ~LET 新たな`~list$ ◎ Let members be an empty array.
~WHILE［ %位置↗ ~NEQ ε ］： ◎ While input_string is not empty:
1. %~member群に次の結果を`付加する$ ⇒ %入力~文字列から`~itemまたは内縁~listを構文解析する$ ◎ Append the result of running Parsing an Item or Inner List (Section 4.2.1.1) with input_string to members.
2. %入力~文字列内の %位置から { ` ^ch, ~HTAB } からなる`文字~並びを収集する$ ◎ Discard any leading OWS characters from input_string.
3. ~IF［ %位置↗ ~EQ ε ］ ⇒ ~BREAK ◎ If input_string is empty, return members.
4. ~IF［ %位置↗ ~NEQ `,^ch ］ ⇒ 構文解析を失敗させる ◎ ↓
5. %位置 ~INCBY 1 ⇒ ◎ Consume the first character of input_string; if it is not ",", fail parsing.
6. %入力~文字列内の %位置から { ` ^ch, ~HTAB } からなる`文字~並びを収集する$ ◎ Discard any leading OWS characters from input_string.
7. ~IF［ %位置↗ ~EQ ε ］ ⇒ 構文解析を失敗させる（尾部に余計な `,^ch がある） ◎ If input_string is empty, there is a trailing comma; fail parsing.
~RET %~member群【！No structured data has been found;】 ◎ No structured data has been found; return members (which is empty).

4.2.1.1. `~sf~item$または`~sf内縁~list$の構文解析-法

%入力~文字列から［ `~sf~item$／`~sf内縁~list$ ］を構文解析して返す： ◎ Given an ASCII string as input_string, return the tuple (item_or_inner_list, parameters), where item_or_inner_list can be either a single bare item or an array of (bare_item, parameters) tuples. input_string is modified to remove the parsed value.

~IF［ %位置↗ ~EQ `(^ch ］ ⇒ ~RET %入力~文字列から`内縁~listを構文解析する$ ◎ If the first character of input_string is "(", return the result of running Parsing an Inner List (Section 4.2.1.2) with input_string.
~RET %入力~文字列から`~itemを構文解析する$ ◎ Return the result of running Parsing an Item (Section 4.2.3) with input_string.

4.2.1.2. ~sf内縁~listの構文解析-法

%入力~文字列から`~sf内縁~list$を構文解析して返す： ◎ Given an ASCII string as input_string, return the tuple (inner_list, parameters), where inner_list is an array of (bare_item, parameters) tuples. input_string is modified to remove the parsed value.

~IF［ %位置↗ ~NEQ `(^ch ］ ⇒ 構文解析を失敗させる ◎ ↓
%位置 ~INCBY 1 ◎ Consume the first character of input_string; if it is not "(", fail parsing.
%~list ~LET 新たな`~list$ ◎ Let inner_list be an empty array.
~WHILE［ %位置↗ ~NEQ ε ］： ◎ While input_string is not empty:
1. %入力~文字列内の %位置から ` ^ch からなる`文字~並びを収集する$ ◎ Discard any leading SP characters from input_string.
2. ~IF［ %位置↗ ~EQ `)^ch ］： ◎ If the first character of input_string is ")":
  1. %位置 ~INCBY 1 ◎ Consume the first character of input_string.
  2. %~parameter群 ~LET %入力~文字列から`~parameter群を構文解析する$ ◎ Let parameters be the result of running Parsing Parameters (Section 4.2.3.2) with input_string.
  3. ~RET ( %~list, %~parameter群 ) からなる`~sf内縁~list$ ◎ Return the tuple (inner_list, parameters).
3. %~list に次の結果を`付加する$ ⇒ %入力~文字列から`~itemを構文解析する$ ◎ Let item be the result of running Parsing an Item (Section 4.2.3) with input_string. ◎ Append item to inner_list.
4. ~IF［ %位置↗ ~NIN { ` ^ch, `)^ch } ］ ⇒ 構文解析を失敗させる ◎ If the first character of input_string is not SP or ")", fail parsing.
構文解析を失敗させる（`~sf内縁~list$を閉じる括弧を見出すことなく， %入力~文字列の終端を過ぎた） ◎ The end of the Inner List was not found; fail parsing.

4.2.2. ~sf辞書の構文解析-法

%入力~文字列から`~sf辞書$を構文解析して返す： ◎ Given an ASCII string as input_string, return an ordered map whose values are (item_or_inner_list, parameters) tuples. input_string is modified to remove the parsed value.

%辞書 ~LET 新たな`有順序~map$ ◎ Let dictionary be an empty, ordered map.
~WHILE［ %位置↗ ~NEQ ε ］： ◎ While input_string is not empty:
1. %~key ~LET %入力~文字列から`~keyを構文解析する$ ◎ Let this_key be the result of running Parsing a Key (Section 4.2.3.3) with input_string.
2. ~IF［ %位置↗ ~EQ `=^ch ］ ◎ If the first character of input_string is "=":
  1. %位置 ~INCBY 1 ◎ Consume the first character of input_string.
  2. %~member ~LET %入力~文字列から`~itemまたは内縁~listを構文解析する$ ◎ Let member be the result of running Parsing an Item or Inner List (Section 4.2.1.1) with input_string.
3. ~ELSE ⇒ %~member ~LET ( `~sf真偽値$ ~T, 次の結果 ) からなる`~sf~item$ ⇒ %入力~文字列から`~parameter群を構文解析する$ ◎ Otherwise: • Let value be Boolean true. • Let parameters be the result of running Parsing Parameters (Section 4.2.3.2) with input_string. • Let member be the tuple (value, parameters).
4. %辞書[ %~key ] ~SET %~member ◎ If dictionary already contains a key this_key (comparing character for character), overwrite its value with member. ◎ Otherwise, append key this_key with value member to dictionary.
5. %入力~文字列内の %位置から { ` ^ch, ~HTAB } からなる`文字~並びを収集する$ ◎ Discard any leading OWS characters from input_string.
6. ~IF［ %位置↗ ~EQ ε ］ ⇒ ~BREAK ◎ If input_string is empty, return dictionary.
7. ~IF［ %位置↗ ~NEQ `,^ch ］ ⇒ 構文解析を失敗させる ◎ ↓
8. %位置 ~INCBY 1 ◎ Consume the first character of input_string; if it is not ",", fail parsing.
9. %入力~文字列内の %位置から { ` ^ch, ~HTAB } からなる`文字~並びを収集する$ ◎ Discard any leading OWS characters from input_string.
10. ~IF［ %位置↗ ~EQ ε ］ ⇒ 構文解析を失敗させる（尾部に余計な `,^ch がある） ◎ If input_string is empty, there is a trailing comma; fail parsing.
~RET %辞書【！No structured data has been found;】 ◎ No structured data has been found; return dictionary (which is empty).

`~sf辞書$内で同じ`~sf~key$に複数回遭遇した場合、最後を除き無視されることに注意。 ◎ Note that when duplicate Dictionary keys are encountered, all but the last instance are ignored.

4.2.3. ~sf~itemの構文解析-法

%入力~文字列から`~sf~item$を構文解析して返す： ◎ Given an ASCII string as input_string, return a (bare_item, parameters) tuple. input_string is modified to remove the parsed value.

%裸~item ~LET %入力~文字列から`裸~itemを構文解析する$ ◎ Let bare_item be the result of running Parsing a Bare Item (Section 4.2.3.1) with input_string.
%~parameter群 ~LET %入力~文字列から`~parameter群を構文解析する$ ◎ Let parameters be the result of running Parsing Parameters (Section 4.2.3.2) with input_string.
~RET ( %裸~item, %~parameter群 ) からなる`~sf~item$ ◎ Return the tuple (bare_item, parameters).

4.2.3.1. ~sf裸~itemの構文解析-法

%入力~文字列から`~sf裸~item$を構文解析して返す： ◎ Given an ASCII string as input_string, return a bare Item. input_string is modified to remove the parsed value.

%位置↗ に応じて： ◎ ↓
1. `-^ch ／ `~ASCII数字$ ⇒ ~RET %入力~文字列から`整数または~decimalを構文解析する$ ◎ If the first character of input_string is a "-" or a DIGIT, return the result of running Parsing an Integer or Decimal (Section 4.2.4) with input_string.
2. `"^ch ⇒ ~RET %入力~文字列から`文字列を構文解析する$ ◎ If the first character of input_string is a DQUOTE, return the result of running Parsing a String (Section 4.2.5) with input_string.
3. `*^ch ／ `~ASCII英字$ ⇒ ~RET %入力~文字列から`~tokenを構文解析する$ ◎ If the first character of input_string is an ALPHA or "*", return the result of running Parsing a Token (Section 4.2.6) with input_string.
4. `:^ch ⇒ ~RET %入力~文字列から`~byte列を構文解析する$ ◎ If the first character of input_string is ":", return the result of running Parsing a Byte Sequence (Section 4.2.7) with input_string.
5. `?^ch ⇒ ~RET %入力~文字列から`真偽値を構文解析する$ ◎ If the first character of input_string is "?", return the result of running Parsing a Boolean (Section 4.2.8) with input_string.
6. `@^ch ⇒ ~RET %入力~文字列から`日時を構文解析する$ ◎ If the first character of input_string is "@", return the result of running Parsing a Date (Section 4.2.9) with input_string.
7. `%^ch ⇒ ~RET %入力~文字列から`表示~文字列を構文解析する$ ◎ If the first character of input_string is "%", return the result of running Parsing a Display String (Section 4.2.10) with input_string.
8. その他 ⇒ 構文解析を失敗させる（認識されない型である） ◎ Otherwise, the item type is unrecognized; fail parsing.

4.2.3.2. ~sf~parameter群の構文解析-法

%入力~文字列から`~sf~parameter群$を構文解析して返す： ◎ Given an ASCII string as input_string, return an ordered map whose values are bare Items. input_string is modified to remove the parsed value.

%~parameter群 ~LET 新たな`有順序~map$ ◎ Let parameters be an empty, ordered map.
~WHILE［ %位置↗ ~NEQ ε ］： ◎ While input_string is not empty:
1. ~IF［ %位置↗ ~NEQ `;^ch ］ ⇒ ~BREAK ◎ If the first character of input_string is not ";", exit the loop.
2. %位置 ~INCBY 1 ◎ Consume the ";" character from the beginning of input_string.
3. %入力~文字列内の %位置から ` ^ch からなる`文字~並びを収集する$ ◎ Discard any leading SP characters from input_string.
4. %~parameter~key ~LET %入力~文字列から`~keyを構文解析する$ ◎ Let param_key be the result of running Parsing a Key (Section 4.2.3.3) with input_string.
5. %~parameter値 ~LET `~sf真偽値$ ~T ◎ Let param_value be Boolean true.
6. ~IF［ %位置↗ ~EQ `=^ch ］： ◎ If the first character of input_string is "=":
  1. %位置 ~INCBY 1 ◎ Consume the "=" character at the beginning of input_string.
  2. %~parameter値 ~LET %入力~文字列から`裸~itemを構文解析する$ ◎ Let param_value be the result of running Parsing a Bare Item (Section 4.2.3.1) with input_string.
7. %~parameter群[ %~parameter~key ] ~SET %~parameter値 ◎ If parameters already contains a key param_key (comparing character for character), overwrite its value with param_value. ◎ Otherwise, append key param_key with value param_value to parameters.
~RET %~parameter群 ◎ Return parameters.

`~sf~parameter群$内で同じ`~sf~key$に複数回遭遇した場合、最後を除き無視されることに注意。 ◎ Note that when duplicate parameter keys are encountered, all but the last instance are ignored.

4.2.3.3. ~sf~keyの構文解析-法

%入力~文字列から［ `~sf辞書$／`~sf~parameter群$ ］用の`~sf~key$を構文解析して返す： ◎ Given an ASCII string as input_string, return a key. input_string is modified to remove the parsed value.

~IF［ %位置↗ ~NIN { `~ASCII英小文字$, `*^l } ］ ⇒ 構文解析を失敗させる ◎ If the first character of input_string is not lcalpha or "*", fail parsing.
~RET %入力~文字列内の %位置から`~key文字$からなる`文字~並びを収集する$ ◎ Let output_string be an empty string. ◎ While input_string is not empty: • If the first character of input_string is not one of lcalpha, DIGIT, "_", "-", ".", or "*", return output_string. • Let char be the result of consuming the first character of input_string. • Append char to output_string. ◎ Return output_string.

4.2.4. ~sf整数または~sf~decimalの構文解析-法

%入力~文字列から［ `~sf整数$／`~sf~decimal$ ］を構文解析して返す： ◎ Given an ASCII string as input_string, return an Integer or Decimal. input_string is modified to remove the parsed value.

注記：この~algoは、 `~sf整数$, `~sf~decimal$の両者を構文解析して，対応する構造を返す。 ◎ NOTE: This algorithm parses both Integers (Section 3.3.1) and Decimals (Section 3.3.2), and returns the corresponding structure.

%符号 ~LET 1
~IF［ %位置↗ ~EQ `-^ch ］ ⇒＃ %位置 ~INCBY 1； %符号 ~SET ~MINUS 1
%整数~部 ~LET %入力~文字列内の %位置から`~ASCII数字$からなる`文字~並びを収集する$
~IF［ %整数~部の`長さ$ ~NIN { 1 〜 15 } ］ ⇒ 構文解析を失敗させる
%整数~成分 ~LET %整数~部を 10 進~整数として解釈した結果
~Assert： %整数~成分 ~IN { 0 〜 999999999999999 }
~IF［ %位置↗ ~NEQ `.^ch ］ ⇒ ~RET ( %符号 ~MUL %整数~成分 ) を値にとる`~sf整数$
%位置 ~INCBY 1；
~IF［ %整数~部の`長さ$ ~GT 12 ］ ⇒ 構文解析を失敗させる
~Assert： %整数~成分 ~IN { 0 〜 999999999999 }
%小数~部 ~LET %入力~文字列内の %位置から`~ASCII数字$からなる`文字~並びを収集する$
~IF［ %小数~部の`長さ$ ~NIN { 1 〜 3 } ］ ⇒ 構文解析を失敗させる
%小数~部の末尾に ( 3 ~MINUS %小数~部の`長さ$ ) 個の `0^ch を付加する
%小数~成分 ~LET %小数~部を 10 進~整数として解釈した結果
~Assert： %小数~成分 ~IN { 0 〜 999 }
~RET 次の結果を表現する`~sf~decimal$ ⇒ %符号 ~MUL ( %整数~成分 ~PLUS ( %小数~成分 ~DIV 1000 ) )

◎ Let type be "integer". ◎ Let sign be 1. ◎ Let input_number be an empty string. ◎ If the first character of input_string is "-", consume it and set sign to -1. ◎ If input_string is empty, there is an empty integer; fail parsing. ◎ If the first character of input_string is not a DIGIT, fail parsing. ◎ While input_string is not empty: • Let char be the result of consuming the first character of input_string. • If char is a DIGIT, append it to input_number. • Else, if type is "integer" and char is ".": •• If input_number contains more than 12 characters, fail parsing. •• Otherwise, append char to input_number and set type to "decimal". • Otherwise, prepend char to input_string, and exit the loop.（消費した文字を戻す） • If type is "integer" and input_number contains more than 15 characters, fail parsing. • If type is "decimal" and input_number contains more than 16 characters, fail parsing. ◎ If type is "integer": • Let output_number be an Integer that is the result of parsing input_number as an integer. ◎ Otherwise: • If the final character of input_number is ".", fail parsing. • If the number of characters after "." in input_number is greater than three, fail parsing. • Let output_number be a Decimal that is the result of parsing input_number as a decimal number. ◎ Let output_number be the product of output_number and sign. ◎ Return output_number.

4.2.5. ~sf文字列の構文解析-法

%入力~文字列から`~sf文字列$ （引用符で括られない）を構文解析して返す： ◎ Given an ASCII string as input_string, return an unquoted String. input_string is modified to remove the parsed value.

%出力~文字列 ~LET 空~文字列 ◎ Let output_string be an empty string.
~IF［ %位置↗ ~NEQ `"^ch ］ ⇒ 構文解析を失敗させる ◎ If the first character of input_string is not DQUOTE, fail parsing.
%位置 ~INCBY 1 ◎ Discard the first character of input_string.
~WHILE［ %位置↗ ~NEQ ε ］：
1. ~IF［ %位置↗ ~EQ `"^ch ］ ⇒＃ %位置 ~INCBY 1； ~RET %出力~文字列
2. ~IF［ %位置↗ ~EQ `\^ch ］：
  1. %位置 ~INCBY 1
  2. ~IF［ %位置↗ ~NIN { `"^ch, `\^ch } ］ ⇒ 構文解析を失敗させる
3. ~ELIF［ %位置↗ は`制御~文字$である【！~NIN { `VCHAR$P, ` ^ch }】］ ⇒ 構文解析を失敗させる
4. %出力~文字列に %位置↗ を付加する
5. %位置 ~INCBY 1
◎ While input_string is not empty: • Let char be the result of consuming the first character of input_string. • If char is a backslash ("\"): •• If input_string is now empty, fail parsing. •• Let next_char be the result of consuming the first character of input_string. •• If next_char is not DQUOTE or "\", fail parsing. •• Append next_char to output_string. • Else, if char is DQUOTE, return output_string. • Else, if char is in the range %x00-1f or %x7f-ff (i.e., it is not in VCHAR or SP), fail parsing. • Else, append char to output_string.
構文解析を失敗させる（`~sf文字列$を閉じる `"^ch を見出すことなく %入力~文字列の終端を過ぎた） ◎ Reached the end of input_string without finding a closing DQUOTE; fail parsing.

4.2.6. ~sf~tokenの構文解析-法

%入力~文字列から`~sf~token$を構文解析して返す： ◎ Given an ASCII string as input_string, return a Token. input_string is modified to remove the parsed value.

~IF［ %位置↗ ~NIN { `~ASCII英字$, `*^ch } ］ ⇒ 構文解析を失敗させる ◎ If the first character of input_string is not ALPHA or "*", fail parsing.
~RET %入力~文字列内の %位置↗ から`~token文字$からなる`文字~並びを収集する$ ◎ Let output_string be an empty string. ◎ While input_string is not empty: • If the first character of input_string is not in tchar, ":", or "/", return output_string. • Let char be the result of consuming the first character of input_string. • Append char to output_string. ◎ Return output_string.

4.2.7. ~sf~byte列の構文解析-法

%入力~文字列から`~sf~byte列$を構文解析して返す： ◎ Given an ASCII string as input_string, return a Byte Sequence. input_string is modified to remove the parsed value.

~IF［ %位置↗ ~NEQ `:^ch ］ ⇒ 構文解析を失敗させる ◎ If the first character of input_string is not ":", fail parsing.
%位置 ~INCBY 1 ◎ Discard the first character of input_string.
%~base64内容 ~LET %入力~文字列内の %位置から次に挙げる文字（ `base64$p ）からなる`文字~並びを収集する$ ⇒＃ `~ASCII英字$, `~ASCII数字$, `+^ch, `/^ch, `=^ch ◎ If there is not a ":" character before the end of input_string, fail parsing. ◎ Let b64_content be the result of consuming content of input_string up to but not including the first instance of the character ":". ◎ Consume the ":" character at the beginning of input_string. ◎ If b64_content contains a character not included in ALPHA, DIGIT, "+", "/", and "=", fail parsing.
~IF［ %位置↗ ~NEQ `:^ch ］ ⇒ 構文解析を失敗させる ◎ ↑
%位置 ~INCBY 1 ◎ ↑
%~binary内容 ~LET 次に従う下で， %~base64内容を~base64復号した結果 `RFC4648$r：
- 必要yなら補充するものを合成する（下に与える`受信者$の挙動についての要件に注意）
- ~base64復号-時に失敗した場合、構文解析を失敗させる
◎ Let binary_content be the result of base64-decoding [RFC4648] b64_content, synthesizing padding if necessary (note the requirements about recipient behavior below). If base64 decoding fails, parsing fails.
~RET %~binary内容 ◎ Return binary_content.

構文解析器は、符号化された~dataにおいて： ◎ ↓

`=^ch が適正に補充されていない場合でも（ `4648/3.2$rfc を見よ）、失敗するベキでない — そうし得ないように環境設定されていない限り。 ~base64実装には、その却下を許容しないものもあるので。 ◎ Because some implementations of base64 do not allow rejection of encoded data that is not properly "=" padded (see [RFC4648], Section 3.2), parsers SHOULD NOT fail when "=" padding is not present, unless they cannot be configured to do so.
0 でない補充~bitがある場合でも（ `4648/3.5$rfc を見よ）、失敗するベキでない — そうし得ないように環境設定されていない限り。 ~base64実装には、その却下を許容しないものもあるので。 ◎ Because some implementations of base64 do not allow rejection of encoded data that has non-zero pad bits (see [RFC4648], Section 3.5), parsers SHOULD NOT fail when non-zero pad bits are present, unless they cannot be configured to do so.
`base64$p ~alphabetでない文字に対しては、 `LF$P であろうが，失敗しなければナラナイ — この仕様は、［ `4648/3.1$rfc, `4648/3.3$rfc ］における要件を緩めない。 ◎ This specification does not relax the requirements in Sections 3.1 and 3.3 of [RFC4648]; therefore, parsers MUST fail on characters outside the base64 alphabet and on line feeds in encoded data.

4.2.8. ~sf真偽値の構文解析-法

%入力~文字列から`~sf真偽値$を構文解析して返す： ◎ Given an ASCII string as input_string, return a Boolean. input_string is modified to remove the parsed value.

~IF［ %位置↗ ~NEQ `?^ch ］ ⇒ 構文解析を失敗させる ◎ If the first character of input_string is not "?", fail parsing.
%位置 ~INCBY 1 ◎ Discard the first character of input_string.
~IF［ %位置↗ ~EQ `1^ch ］ ⇒＃ %位置 ~INCBY 1； ~RET `~sf真偽値$ ~T ◎ If the first character of input_string matches "1", discard the first character, and return true.
~IF［ %位置↗ ~EQ `0^ch ］ ⇒＃ %位置 ~INCBY 1； ~RET `~sf真偽値$ ~F ◎ If the first character of input_string matches "0", discard the first character, and return false.
構文解析を失敗させる ◎ No value has matched; fail parsing.

4.2.9. `~sf日時$の構文解析-法

%入力~文字列から`~sf日時$を構文解析して返す： ◎ Given an ASCII string as input_string, return a Date. input_string is modified to remove the parsed value.

~IF［ %位置↗ ~NEQ "`@^c" ］ ⇒ 構文解析を失敗させる ◎ If the first character of input_string is not "@", fail parsing.
%位置 ~INCBY 1 ◎ Discard the first character of input_string.
%出力~日時 ~LET %入力~文字列から`整数または~decimalを構文解析する$ ◎ Let output_date be the result of running Parsing an Integer or Decimal (Section 4.2.4) with input_string.
~IF［ %出力~日時は`~sf~decimal$である］ ⇒ 構文解析を失敗させる ◎ If output_date is a Decimal, fail parsing.
~RET %出力~日時 ◎ Return output_date.

4.2.10. `~sf表示~文字列$の構文解析-法

%入力~文字列から`~sf表示~文字列$を構文解析して返す： ◎ Given an ASCII string as input_string, return a sequence of Unicode code points. input_string is modified to remove the parsed value.

~IF［ %位置↗ ~NEQ `%^ch ］ ⇒ 構文解析を失敗させる ◎ ↓
%位置 ~INCBY 1 ◎ ↓
~IF［ %位置↗ ~NEQ `"^ch ］ ⇒ 構文解析を失敗させる ◎ If the first two characters of input_string are not "%" followed by DQUOTE, fail parsing.
%位置 ~INCBY 1 ◎ Discard the first two characters of input_string.
%~byte列 ~LET 空な`~byte列$ ◎ Let byte_array be an empty byte array.
~WHILE［ %位置↗ ~NEQ ε ］： ◎ While input_string is not empty:
1. %文字 ~LET %位置↗ ◎ ↓
2. %位置 ~INCBY 1 ◎ Let char be the result of consuming the first character of input_string.
3. ~IF［ %文字は`制御~文字$である【！~NIN { `VCHAR$P, ` ^ch }】］ ⇒ 構文解析を失敗させる ◎ If char is in the range %x00-1f or %x7f-ff (i.e., it is not in VCHAR or SP), fail parsing.
4. ~IF［ %文字 ~EQ `%^ch ］：
  1. %~hex列 ~LET 空~文字列
  2. ~EACH( ~index ~IN { 1, 2 } ) に対し：
    1. %文字 ~LET %位置↗
    2. %位置 ~INCBY 1
    3. ~IF［ %文字は`~ASCII~hex数字$でない］ ⇒ 構文解析を失敗させる
    4. %~hex列に %文字を付加する
  3. %~hex列 ~SET `~ASCII大文字~化する$( %~hex列 )
  4. %~octet ~LET `4648/8$rfc に従って， %~hex列を~hex数に復号した結果
  5. %~byte列に %~octet を付加する
  6. ~CONTINUE
  ◎ If char is "%": • Let octet_hex be the result of consuming two characters from input_string. If there are not two characters, fail parsing. • If octet_hex contains characters outside the range %x30-39 or %x61-66 (i.e., it is not in 0-9 or lowercase a-f), fail parsing. • Let octet be the result of hex decoding octet_hex (Section 8 of [RFC4648]). • Append octet to byte_array.
5. ~IF［ %文字 ~EQ `"^ch ］：
  1. %~Unicode連列 ~LET `UTF8$r `§ 3＠~RFCx/rfc3629#section-3$ に従って， %~byte列を~UTF-8文字列として復号した結果 — この復号-時に失敗した場合、構文解析を失敗させる
  2. ~RET %~Unicode連列
  ◎ If char is DQUOTE: • Let unicode_sequence be the result of decoding byte_array as a UTF-8 string (Section 3 of [UTF8]). Fail parsing if decoding fails. • Return unicode_sequence.
6. %~byte列に次の結果を付加する ⇒ `~ASCII符号化する$( %文字 ) ◎ Otherwise, if char is not "%" or DQUOTE: • Let byte be the result of applying ASCII encoding to char. • Append byte to byte_array.
構文解析を失敗させる（`~sf表示~文字列$を閉じる `"^ch を見出すことなく %入力~文字列の終端を過ぎた） ◎ Reached the end of input_string without finding a closing DQUOTE; fail parsing.

5. ~IANA考慮点

~IANAは、 `~HTTP~field名~registry＠~IANA-a/http-fields/$cite に対し： ◎ ↓

次の注記を追加した： ◎ IANA has added the following note to the "Hypertext Transfer Protocol (HTTP) Field Name Registry":
- “有構造~型” 列は、 `~field値$の型（ `RFC9651^r ）（もし在れば）を次に挙げるいずれかとして指示する ⇒ `~sf辞書$／`~sf~list$／`~sf~item$ ◎ The "Structured Type" column indicates the type of the field (per RFC 9651), if any, and may be "Dictionary", "List", or "Item".
- ［ `ALPHA$P ／ "`*^c" ］以外の文字から始まる`~field名$は、 `~sf~token$として表現-可能でないので，そのような名前を指す値を~field値に内包するときに【！being mapped into】互換でなくなり得ることに注意。 ◎ Note that field names beginning with characters other than ALPHA or "*" will not be able to be represented as a Structured Fields Token and therefore may be incompatible with being mapped into field values that refer to it.
新たな列 “有構造~型（ `Structured Type^en ）” を追加した。 ◎ A new column, "Structured Type", has been added to the registry.

次の表tに挙げる既存の各~registry~entryに対し，そこに指示される有構造~型を追加した。【~field名に付与された~linkは、この訳による補完。】

表t 1 — 既存の~field
~field名	有構造~型
`Accept-CH$h	`~sf~list$
`Cache-Status$h	`~sf~list$
`CDN-Cache-Control$h	`~sf辞書$
`Cross-Origin-Embedder-Policy$h	`~sf~item$
`Cross-Origin-Embedder-Policy-Report-Only$h	`~sf~item$
`Cross-Origin-Opener-Policy$h	`~sf~item$
`Cross-Origin-Opener-Policy-Report-Only$h	`~sf~item$
`Origin-Agent-Cluster$h	`~sf~item$
`Priority$h	`~sf辞書$
`Proxy-Status$h	`~sf~list$

◎ The indicated Structured Type for each existing registry entry listed in Table 1 has also been added. ◎ Table 1: Existing Fields ◎ Field Name Structured Type ◎ Accept-CH｜List Cache-Status｜List CDN-Cache-Control｜Dictionary Cross-Origin-Embedder-Policy｜Item Cross-Origin-Embedder-Policy-Report-Only｜Item Cross-Origin-Opener-Policy｜Item Cross-Origin-Opener-Policy-Report-Only｜Item Origin-Agent-Cluster｜Item Priority｜Dictionary Proxy-Status｜List

6. ~securityの考慮点

有構造~fieldにより定義されるほとんどの型の~sizeは、制限されない。その結果、極めて巨大な~fieldは，攻撃~行路にもなり得る（例：資源の消費）。ほとんどの~HTTP実装は、そのような攻撃を軽減するため［個々の~fieldの~size, 各`~field節$の総~size ］を制限する。 ◎ The size of most types defined by Structured Fields is not limited; as a result, extremely large fields could be an attack vector (e.g., for resource consumption). Most HTTP implementations limit the sizes of individual fields as well as the overall header or trailer section size to mitigate such attacks.

ある主体が，［有構造~fieldの意味を変更するような，新たな`~HTTP~field$を注入する能］を有するアリ性もある。これは，一部の状況下では構文解析を失敗させるが、すべてのそのような状況下で依拠-可能に失敗させることはアリでない。 ◎ It is possible for parties with the ability to inject new HTTP fields to change the meaning of a Structured Field. In some circumstances, this will cause parsing to fail, but it is not possible to reliably fail in all such circumstances.

`~sf表示~文字列$は、アリなどの~Unicode`符号位置$も，無毒化を伴わずに伝達し得る。例えば、［ `unassigned^en 符号位置／ `制御~文字$【！(including NUL)】／ `非文字$ ］を包含するかもしれない。したがって，`~sf表示~文字列$を消費している応用は、信用できない内容を表示する前に，それを［ ~filterする／~escapeする］などの策を考慮する必要がある。 `PRECIS$r, `UNICODE-SECURITY$r を見よ。 ◎ The Display String type can convey any possible Unicode code point without sanitization; for example, they might contain unassigned code points, control points (including NUL), or noncharacters. Therefore, applications consuming Display Strings need to consider strategies such as filtering or escaping untrusted content before displaying it. See [PRECIS] and [UNICODE-SECURITY].

付録 A. よくある質問

A.1. なぜ~JSONじゃない？

有構造~field用の早期~提案は，~JSON `RFC8259$r に基づいていたが、その利用を~HTTP~field用に相応しくなるよう拘束することは，それに特有な追加的な取扱いを実装することを［ `送信者$／`受信者$ ］に要求していた。 ◎ Earlier proposals for Structured Fields were based upon JSON [RFC8259]. However, constraining its use to make it suitable for HTTP fields required senders and recipients to implement specific additional handling.

例えば，~JSON仕様には、［巨大な実数／重複する~memberを伴う~obj ］周りに課題がある。これらの課題を避けるための助言も可用であるが（例： `RFC7493$r ）、それには依拠できない。 ◎ For example, JSON has specification issues around large numbers and objects with duplicate members. Although advice for avoiding these issues is available (e.g., [RFC7493]), it cannot be relied upon.

同様に，~JSON文字列は、既定では~Unicode文字列であり，相互運用能の課題になり得るものがいくつかある（例：比較において）。実装者には，不必要な所では~ASCIIでない内容を避けるよう勧めるが、これを施行するのは困難である。 ◎ Likewise, JSON strings are by default Unicode strings, which have a number of potential interoperability issues (e.g., in comparison). Although implementers can be advised to avoid non-ASCII content where unnecessary, this is difficult to enforce.

別の例として、任意な深さまで内容を入子にする~JSONの能も挙げられる。結果の `memory commitment^en 【必要に応じて~~確保する実メモリの~~絶対量】は適さないかもしれないので（例：埋込dその他の，制限された~server配備において）、それを何らかの流儀で制限することが必要yである — しかしながら，既存の~JSON実装にはそのような制限sは無く、制限-が指定されても，一部の~field定義はそれに違反する必要を見出すことになる見込みが高い。 ◎ Another example is JSON's ability to nest content to arbitrary depths. Since the resulting memory commitment might be unsuitable (e.g., in embedded and other limited server deployments), it's necessary to limit it in some fashion; however, existing JSON implementations have no such limits, and even if a limit is specified, it's likely that some field definition will find a need to violate it.

~JSONには広い採用と実装があるので、すべての実装にわたって，そのような追加的な拘束を課すのは困難である。それを施行するのに失敗する配備が一部でもあれば、相互運用能を害することになる。短かく言えば、 ~JSONに似た何かにした場合，人は~JSON［構文解析器／直列化器］を`~field値$に利用したくなりがちになる。 ◎ Because of JSON's broad adoption and implementation, it is difficult to impose such additional constraints across all implementations; some deployments would fail to enforce them, thereby harming interoperability. In short, if it looks like JSON, people will be tempted to use a JSON parser/serializer on field values.

有構造~fieldの主要な目標は，相互運用能を改善して実装を単純~化することにあるので、これらの懸念から，専用の［構文解析器, 直列化器］を要求する形式に至った。 ◎ Since a major goal for Structured Fields is to improve interoperability and simplify implementation, these concerns led to a format that requires a dedicated parser and serializer.

加えて，~JSONは、 `~HTTP~field$内では “まっとうに見えない” 感覚が広く共有されている。 ◎ Additionally, there were widely shared feelings that JSON doesn't "look right" in HTTP fields.

付録 B. 実装~向けの注記

この仕様の汎用な実装は、 ~top-levelの［直列化する機能（ `4.1§ ）／構文解析する機能（ `4.2§ ）］を公開するべきである。それらは、関数にする必要はない — 例えば、各~top-level型~用に異なる~methodを伴う~objとして，実装することもできる。 ◎ A generic implementation of this specification should expose the top-level serialize (Section 4.1) and parse (Section 4.2) functions. They need not be functions;＼ ◎ for example, it could be implemented as an object, with methods for each of the different top-level types.

相互運用能を得るため、汎用な実装は，完全な, かつ~algoに近く従うことが重要になる — `1.1§ を見よ。これを援助するため、当~communityは，共通な~test一式を `https://github.com/httpwg/structured-field-tests＠https://github.com/httpwg/structured-field-tests$ にて保守している。 ◎ For interoperability, it's important that generic implementations be complete and follow the algorithms closely; see Section 1.1. To aid this, a common test suite is being maintained by the community at <https://github.com/httpwg/structured-field-tests>.

実装者は、［ `~sf辞書$／`~sf~parameter群$ ］が順序を保全する~mapであることに注意するべきである。 ~fieldには，これらの~data型に対する順序付けにより意味を伝達しないものもあるが、順序を利用する必要がある応用にも可用なるよう，順序は依然として公開されるべきである。 ◎ Implementers should note that Dictionaries and Parameters are order-preserving maps. Some fields may not convey meaning in the ordering of these data types, but it should still be exposed so that it will be available to applications that need to use it.

同様に，実装は、［ `~sf~token$と`~sf文字列$の区別を保全する］ことが重要なことに注意するべきである。ほとんどの~programming言語は，それ以外の型にきちんと対応付けられる組込みの型を備えるが、［ “~token” を包装する~objを作成する／これらの型が別々であり続けることを確約するような~parameterを関数に利用する］ことも必要yあり得る。 ◎ Likewise, implementations should note that it's important to preserve the distinction between Tokens and Strings. While most programming languages have built-in types that map to the other types well, it may be necessary to create a wrapper "token" object or use a parameter on functions to assure that these types remain separate.

直列化~algoは、どの事例においても［ `有構造~data型§に定義される~data型］に厳密に制限されない仕方で定義される。例えば ~sf~decimal は、より広い入力をとるよう設計されており，許容される値に丸めることになる。 ◎ The serialization algorithm is defined in a way that it is not strictly limited to the data types defined in Section 3 in every case. For example, Decimals are designed to take broader input and round to allowed values.

実装には、構造ごとに，~sizeを — 各~型ごとに定義される最小を満たす限りにおいて — 制限することも許容される。ある構造が実装による制限-を超過するとき、その構造は［構文解析／直列化］に失敗する。 ◎ Implementations are allowed to limit the size of different structures, subject to the minimums defined for each type. When a structure exceeds an implementation limit, that structure fails parsing or serialization.

付録 C. ~ABNF

この節では、 `RFC5234$r による~ABNF記法を利用して，有構造~fieldに期待される構文を具体化する。しかしながら、それは，構文を検証するためとしては利用できない — それだけでは捕捉されない要件もあるので。 ◎ This section uses the Augmented Backus-Naur Form (ABNF) notation [RFC5234] to illustrate the expected syntax of Structured Fields. However, it cannot be used to validate their syntax because it does not capture all requirements.

この節は規範的でない。構文解析~algoと~ABNFの間に不一致がある場合、指定された~algoが優先される。 ◎ This section is non-normative. If there is disagreement between the parsing algorithms and ABNF, the specified algorithms take precedence.

; 【`~sf~list$：】
`sf-list@p
	= `list-member$p *( `OWS$p "," `OWS$p `list-member$p )
`list-member@p
	= `sf-item$p
	/ `inner-list$p

; 【`~sf内縁~list$：】
`inner-list@p
	= "(" *`SP$P [ `sf-item$p *( 1*`SP$P `sf-item$p ) *`SP$P ] ")" `parameters$p

; 【`~sf~parameter群$：】
`parameters@p
	= *( ";" *`SP$P `parameter$p )
`parameter@p
	= `param-key$p [ "=" `param-value$p ]
`param-key@p
	= `key$p
`key@p
	= ( `lcalpha$p / "*" )
	  *( `lcalpha$p / `DIGIT$P / "_" / "-" / "." / "*" )
`lcalpha@p
	= `61-7A^X ; a-z
`param-value@p
	= `bare-item$p

; 【`~sf辞書$：】
`sf-dictionary@p
	= `dict-member$p *( `OWS$p "," `OWS$p `dict-member$p )
`dict-member@p
	= `member-key$p ( `parameters$p / ( "=" `member-value$p ) )
`member-key@p
	= `key$p
`member-value@p
	= `sf-item$p
	/ `inner-list$p

; 【`~sf~item$：】
`sf-item@p
	= `bare-item$p `parameters$p
`bare-item@p
	= `sf-integer$p
	/ `sf-decimal$p
	/ `sf-string$p
	/ `sf-token$p
	/ `sf-binary$p
	/ `sf-boolean$p
	/ `sf-date$p
	/ `sf-displaystring$p

; 【`~sf整数$：】
`sf-integer@p
	= ["-"] 1*15`DIGIT$P
; 【`~sf~decimal$：】
`sf-decimal@p
	= ["-"] 1*12`DIGIT$P "." 1*3`DIGIT$P
; 【`~sf文字列$：】
`sf-string@p
	= `DQUOTE$P *( `unescaped$p / "%" / `bs-escaped$p ) `DQUOTE$P
; 【`~sf~token$：】
`sf-token@p
	= ( `ALPHA$P / "*" ) *( `tchar$p / ":" / "/" )
; 【`~sf~byte列$：】
`sf-binary@p
	= ":" `base64$p ":"
; 【`~sf真偽値$：】
`sf-boolean@p
	= "?" ( "0" / "1" )
; 【`~sf日時$：】
`sf-date@p
	= "@" `sf-integer$p
; 【`~sf表示~文字列$：】
`sf-displaystring@p
	= "%" `DQUOTE$P *( `unescaped$p / "\" / `pct-encoded$p ) `DQUOTE$P

`base64@p
	= *( `ALPHA$P / `DIGIT$P / "+" / "/" ) *"="
`unescaped@p
	= `20-21^X
	/ `23-24^X
	/ `26-5B^X
	/ `5D-7E^X
`bs-escaped@p
	= "\" ( `DQUOTE$P / "\" )
`pct-encoded@p
	= "%" `lc-hexdig$p `lc-hexdig$p
`lc-hexdig@p
	= `DIGIT$P
	/ `61-66^X ; 0-9, a-f

【同じ `member-key$p を伴う複数個の［ `dict-member$p ／ `parameter$p ］が現れても許容され，最後に現れるものが他を上書きする — ［ `辞書を構文解析する§／`~parameter群を構文解析する§ ］を見よ。】

付録 D. `~RFC 8941$ からの変更点

`~HTTP用の有構造~field値^cite 仕様を成すこの改訂には、次に挙げる変更が為された： ◎ This revision of the "Structured Field Values for HTTP" specification has made the following changes:

有構造~型として`~sf日時$を追加した。（ `3.3.7§ ） ◎ Added the Date Structured Type. (Section 3.3.7)
新たな有構造~fieldの定義において~ABNFを利用するよう奨励することをやめた。（ `2§ ） ◎ Stopped encouraging use of ABNF in definitions of new Structured Fields. (Section 2)
~ABNFを規範的でない付録へ移動した。（ `C§ ） ◎ Moved ABNF to an informative appendix. (Appendix C)
`~HTTP~field名~registry＠~IANA-a/http-fields/$citeに “有構造~型” 列を追加した（ `5§ ） ◎ Added a "Structured Type" column to the "Hypertext Transfer Protocol (HTTP) Field Name Registry". (Section 5)
構文解析-時の失敗に対する取扱いを精緻化した。（ `4.2§ ） ◎ Refined parse failure handling. (Section 4.2)
有構造~型として`~sf表示~文字列$を追加した。（ `3.3.8§ ） ◎ Added the Display String Structured Type. (Section 3.3.8)

謝辞

この仕様の開発に詳細な~feedback, 注意深い考慮を寄せられた `Matthew Kerwin^en 氏に。貢献された他の各氏にも： ◎ Many thanks to Matthew Kerwin for his detailed feedback and careful consideration during the development of this specification.

Thanks also to Ian Clelland, Roy Fielding, Anne van Kesteren, Kazuho Oku, Evert Pot, Julian Reschke, Martin Thomson, Mike West, and Jeffrey Yasskin for their contributions.

このメモの位置付け

著作権の告知

1. 序論

1.1. 意図的に厳密な処理

1.2. 表記上の規約

【この訳に特有な表記規約】

2. 新たな有構造~fieldの定義-法

2.1. 例

42. `Foo-Example^h ~header ◎ 42. Foo-Example Header Field

2.2. ~errorの取扱い

2.3. 拡張能の保全-法

2.4. 拡張における新たな有構造~型の利用-法

3. 有構造~data型

3.1. ~sf~list

3.1.1. ~sf内縁~list

3.1.2. ~sf~parameter群

3.1.2.1. ~sf~key

3.2. ~sf辞書

3.3. ~sf~item

3.3.1. ~sf整数

3.3.2. ~sf~decimal

3.3.3. ~sf文字列

3.3.4. ~sf~token

3.3.5. ~sf~byte列

3.3.6. ~sf真偽値

3.3.7. ~sf日時

3.3.8. ~sf表示~文字列

4. ~HTTPにおける有構造~fieldによる作業-法

4.1. 有構造~fieldの直列化-法

4.1.1. `~sf~list$の直列化-法

4.1.1.1. `~sf内縁~list$の直列化-法

4.1.1.2. `~sf~parameter群$の直列化-法

4.1.1.3. `~sf~key$の直列化-法

4.1.2. `~sf辞書$の直列化-法

4.1.3. `~sf~item$の直列化-法

4.1.3.1. `~sf裸~item$の直列化-法

4.1.4. `~sf整数$の直列化-法

4.1.5. `~sf~decimal$の直列化-法

4.1.6. `~sf文字列$の直列化-法

4.1.7. `~sf~token$の直列化-法

4.1.8. `~sf~byte列$の直列化-法

4.1.9. `~sf真偽値$の直列化-法

4.1.10. `~sf日時$の直列化-法

4.1.11. `~sf表示~文字列$の直列化-法

4.2. 有構造~fieldの構文解析-法

4.2.1. ~sf~listの構文解析-法

4.2.1.1. `~sf~item$または`~sf内縁~list$の構文解析-法

4.2.1.2. ~sf内縁~listの構文解析-法

4.2.2. ~sf辞書の構文解析-法

4.2.3. ~sf~itemの構文解析-法

4.2.3.1. ~sf裸~itemの構文解析-法

4.2.3.2. ~sf~parameter群の構文解析-法

4.2.3.3. ~sf~keyの構文解析-法

4.2.4. ~sf整数または~sf~decimalの構文解析-法

4.2.5. ~sf文字列の構文解析-法

4.2.6. ~sf~tokenの構文解析-法

4.2.7. ~sf~byte列の構文解析-法

4.2.8. ~sf真偽値の構文解析-法

4.2.9. `~sf日時$の構文解析-法

4.2.10. `~sf表示~文字列$の構文解析-法

5. ~IANA考慮点

6. ~securityの考慮点

付録 A. よくある質問

A.1. なぜ~JSONじゃない？

付録 B. 実装~向けの注記

付録 C. ~ABNF

付録 D. `~RFC 8941$ からの変更点

謝辞