[http](structured fields) 諸々の編集

• “header” → “field”
• 二重否定（ unless it is not ）の誤訳
• pad の対訳
• 余計に思われる訳注を除去
• 編集時の遺物を削除
• 新たなデータ型に関する訳注を追加
など

Author: triple-underscore

http-structured-fields-ja.html

@@ -509,8 +509,9 @@
 有効桁数:significant digits:~
 生産器:producer::~
 消費器:consumer::~
-pad:
-	~padするもの:padding
+補充-:pad:~
+補充:pad:~
+	補充するもの:padding
 合成-:synthesize:~
 	0 個以上の:optional
 等距離:equidistant:~
@@ -1166,14 +1167,16 @@ <h3>【この訳に特有な表記規約】</h3>
 
 <p>
 この仕様に定義される，すべての`有構造~data型$は、
-より汎用な~data型（例：`~list$）と区別するため， %~sf型~名 （例： `~sf~list$）の様に表記される（
-"sf" は `Structured Field^en の略語
+より汎用な~data型（例：`~list$）と明瞭に判別-可能にするため
+（例えば，これらの型を参照する他の仕様において），
+%~sf型~名 （例： `~sf~list$）の様に表記される
+（ "sf" は `Structured Field^en の略語
 — 原文では、
 これらの型~名は， "`List^en" の様に大文字を用いて区別されている）。
 `有構造~data型$は、
 概念的には
 ( 汎用な~data型, とり得る値に対する制約 )
-の組と捉えられる。
+の組として捉えれる。
 </p>
 
 		</section>
@@ -1201,7 +1204,7 @@ <h2 title="Defining New Structured Fields">2. 新たな有構造~fieldの定義-
 	<li>
 <p>
 当の~fieldは、
-次のどれに該当するか識別すること：
+次に挙げる どれに該当するか識別すること：
 </p>
 		<ul>
 			<li>
@@ -1297,8 +1300,9 @@ <h2 title="Defining New Structured Fields">2. 新たな有構造~fieldの定義-
 </p>
 
 <p>
-~field定義が この仕様を利用できるのは、
-`~field値$の一部分ではなく，値~全体~用に限られる。
+~field定義は、［
+`~field値$の一部分ではなく，値~全体
+］用に限り，この仕様を利用できる。
 ◎
 Field definitions can only use this specification for the entire field value, not a portion thereof.
 </p>
@@ -1320,7 +1324,7 @@ <h2 title="Defining New Structured Fields">2. 新たな有構造~fieldの定義-
 <p>
 この仕様は、
 実装が~supportする様々な構造の長さや個数~用に最小を定義する。
-ほとんどの事例では最大~sizeは指定しないが、
+ほとんどの事例では，最大~sizeを指定しないが、
 策定者は，［
 ~HTTP実装が［
 個々の~fieldの~size／
@@ -1518,11 +1522,10 @@ <h3 title="Preserving Extensibility">2.3. 拡張能の保全-法</h3>
 未知な~keyが在っても
 — および，値やその型が未知な場合も —
 無視するよう要求することにより，前方-互換性も許容できる。
-そうすれば，後続な仕様は、
-追加的な~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.
 </p>
@@ -1557,6 +1560,11 @@ <h3 title="Using New Structured Types in Extensions">2.4. 拡張における新
 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.
 </p>
 
+<p class="trans-note">【
+この節は、
+`~sf表示~文字列$にも同様に適用される。
+】</p>
+
 <p>
 この制限は、
 ~fieldに対する将来の拡張にも適用される。
@@ -1867,10 +1875,11 @@ <h4 title="Parameters">3.1.2. ~sf~parameter群</h4>
 ］に結付けられる
 `~sf~parameter群@
 （ `Parameters^en ）は、
-各［
+それを成す各`~entry$map
+—
 `~sf~parameter@
-（ `Parameter^en ）と称される`~entry$map
-］が次のように制約される`有順序~map$である：
+（ `Parameter^en ） —
+が次のように制約される`有順序~map$である：
 </p>
 <ul>
 	<li>
@@ -1989,12 +1998,14 @@ <h4>3.1.2.1. ~sf~key</h4>
 それは、
 次のように制約される`文字列$である：
 </p>
-
 <ul>
 	<li>
-1 個以上の，次に挙げる
+空でない
+</li>
+	<li>
+どの文字も，次に挙げる
 `~key文字@
-のみからなる
+である
 ⇒＃
 `~ASCII英小文字$,
 `~ASCII数字$,
@@ -2267,6 +2278,10 @@ <h3 title="Items">3.3. ~sf~item</h3>
 ］は，どれも`文字列$であるが、
 実装は，型に応じて別々に扱えるよう型~情報を保持する必要がある
 （ `B§ ）。
+】【
+`~sf日時$, `~sf表示~文字列$は、
+`~RFC 8941$ には無かった型である
+— `2.4§を見よ。
 】</p>
 ◎
 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).
@@ -2423,7 +2438,7 @@ <h4 title="Strings">3.3.3. ~sf文字列</h4>
 （ `String^en ）は、
 次のように制約される文字列である
 ⇒
-それを成すどの文字も，`制御~文字$以外の`~ASCII文字$【！`RFC0020$r】（すなわち， ` ^ch 〜 `~^ch ）である
+どの文字も，`制御~文字$以外の`~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.
@@ -2500,9 +2515,12 @@ <h4 title="Tokens">3.3.4. ~sf~token</h4>
 </p>
 <ul>
 	<li>
-1 個以上の，次に挙げる
+空でない
+</li>
+	<li>
+どの文字も，次に挙げる
 `~token文字@
-のみからなる
+である
 ⇒＃
 `tchar$p に許容される~octet,
 `:^ch,
@@ -2514,7 +2532,6 @@ <h4 title="Tokens">3.3.4. ~sf~token</h4>
 ］
 </li>
 </ul>
-
 ◎
 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.
 </div>
@@ -2655,7 +2672,6 @@ <h4 title="Dates">3.3.7. ~sf日時</h4>
 `1970-01-01T00:00:00Z^c からの［
 閏秒は除外した（場合によっては負な）秒数
 ］を表現する。
-~Aaccordingly
 ~textな~HTTP~fieldにおけるそれらの直列化も，それに則って`~sf整数$に類似するが、
 先頭の "`@^c" で判別される。
 ◎
@@ -2807,7 +2823,7 @@ <h3 title="Serializing Structured Fields">4.1. 有構造~fieldの直列化-法</
 ］
 ⇒
 ~RET
-— 当の~headerは直列化しない
+— 当の~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).
@@ -3607,27 +3623,29 @@ <h4 title="Serializing a Byte Sequence">4.1.8. `~sf~byte列$の直列化-法</h4
 
 <p>
 `4648/3.2$rfc に従って、
-符号化された~dataには， `=^ch を~padすることが要求される†。
+符号化された~dataには， `=^ch を補充する（ `pad^en する）ことが要求される。
 ◎
 The encoded data is required to be padded with "=", as per [RFC4648], Section 3.2.
 </p>
 
+<p class="trans-note">【
+すなわち、
+符号化した結果の長さが 4 の倍数にならない場合，そうなるよう補充する。
+】</p>
+
 <p>
 同様に， `4648/3.5$rfc に従って、
-符号化される~dataにおける~pad~bit††は 0 に設定するベキである
-— 実装の拘束に因り，そうするのはアリでない限り。
+符号化される~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.
 </p>
 
-<p class="trans-note">【†
-すなわち、
-符号化した結果の長さが 4 の倍数にならない場合，そうなるよう補充する。
-】【††
+<p class="trans-note">【
 ~base64単位を成す 6 ~bitと~byte単位を成す 8 ~bitとのずれに因る不足分を（~byte列の末尾に）補充する~bit。
 】【
 構文解析器は、
-~padに関しては，この~algoの出力より~~寛容な形式を受容する
+補充~bitに関しては，この~algoの出力より~~寛容な形式を受容する
 （ `4.2.7§ ）。
 】</p>
 
@@ -3723,7 +3741,7 @@ <h4 title="Serializing a Display String">4.1.11. `~sf表示~文字列$の直列
 <ol>
 	<li>
 ~Assert：
-%入力~文字列 は`~scalar値~文字列$である。
+%入力~文字列 は`~scalar値~文字列$である
 ◎
 If input_sequence is not a sequence of Unicode code points, fail serialization.
 ◎
@@ -4029,11 +4047,8 @@ <h3 title="Parsing Structured Fields">4.2. 有構造~fieldの構文解析-法</h
 </ul>
 
 <p class="trans-note">【†
-~algoにおいては、
+各~algoにおいては、
 “構文解析を失敗させる” という句で指示される。
-】【
-どちらに従うかは、
-当の~fieldの仕様にて規定されることもあろう。
 】</p>
 
 <p>
@@ -4047,7 +4062,7 @@ <h3 title="Parsing Structured Fields">4.2. 有構造~fieldの構文解析-法</h
 
 <p>
 この要件は、
-~headerを構文解析しない実装には適用されないことに注意。
+~fieldを構文解析しない実装には適用されないことに注意。
 例えば，`媒介者$には、［
 `~message$を回送する前に，失敗している~fieldを剥取る
 ］ことは要求されない。
@@ -4976,7 +4991,7 @@ <h4 title="Parsing a Byte Sequence">4.2.7. ~sf~byte列の構文解析-法</h4>
 </p>
 		<ul>
 			<li>
-必要yなら~padするものを合成する
+必要yなら補充するものを合成する
 （下に与える`受信者$の挙動についての要件に注意）
 </li>
 			<li>
@@ -5002,7 +5017,7 @@ <h4 title="Parsing a Byte Sequence">4.2.7. ~sf~byte列の構文解析-法</h4>
 ↓</p>
 <ul>
 	<li>
-`=^ch が適正に~padされていない場合でも
+`=^ch が適正に補充されていない場合でも
 （ `4648/3.2$rfc を見よ）、
 失敗するベキでない
 — そうし得ないように環境設定されていない限り。
@@ -5012,7 +5027,7 @@ <h4 title="Parsing a Byte Sequence">4.2.7. ~sf~byte列の構文解析-法</h4>
 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.
 </li>
 	<li>
-0 でない~pad~bitがある場合でも
+0 でない補充~bitがある場合でも
 （ `4648/3.5$rfc を見よ）、
 失敗するベキでない
 — そうし得ないように環境設定されていない限り。
@@ -5027,7 +5042,7 @@ <h4 title="Parsing a Byte Sequence">4.2.7. ~sf~byte列の構文解析-法</h4>
 — この仕様は、［
 `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.
 </li>
@@ -5562,7 +5577,7 @@ <h2 title="Implementation Notes">付録 B. 実装~向けの注記</h2>
 汎用な実装は，完全な, かつ~algoに近く従うことが重要になる
 — `1.1§ を見よ。
 これを援助するため、
-~communityは，共通な~test一式を
+当~communityは，共通な~test一式を
 `https://github.com/httpwg/structured-field-tests＠https://github.com/httpwg/structured-field-tests$
 にて保守している。
 ◎
@@ -5624,7 +5639,7 @@ <h2 title="ABNF">付録 C. ~ABNF</h2>
 この節では、
 `RFC5234$r による<abbr title="Augmented Backus-Naur Form">~ABNF</abbr>記法を利用して，有構造~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.