docs: rewrite reference and clarify interface abstraction

contents/5.1-wip-over-http.md

@@ -1,33 +1,33 @@
 # 5.1. WIP over HTTP
 
-WIP over HTTPは、[3. Protocol](3-protocol.md)のlogical data modelをHTTP request / responseとJSONへ対応付ける標準Transport Bindingである。[5. Transport Bindings](5-transports.md)の共通要件に従う。
+WIP over HTTPは、[3. Protocol](3-protocol.md)のlogical data modelをHTTP request / responseとJSONへ対応付ける標準Transport Bindingである。HTTP上の表現は、[5. Transport Bindings](5-transports.md)の共通要件に従って定める。
 
 ## 目的と範囲
 
-このbindingは、次のCore interactionをHTTPへ対応付ける。
+HTTPへ対応付けるCore interactionは、次の三つである。
 
 - `observe`
 - `fetch_interface`
 - `call_operation`
 
-HTTP version、communication scheme、TLS、authentication方式、connection reuse、multiplexing、proxy、gateway、cache、Host内部のframework、backend接続方式は規定しない。HTTP実装とdeploymentは、それらをWIPとは独立して選択する。複数のCore interactionが必要な場合も、それぞれを独立したHTTP request / responseとして交換する。
+HTTP version、communication scheme、TLS、authentication方式、connection reuse、multiplexing、proxy、gateway、cache、Host内部のframework、backend接続方式は規定しない。これらはHTTP実装とdeploymentが、WIPとは独立して選択する。複数のCore interactionが必要な場合も、それぞれを独立したHTTP request / responseとして交換する。
 
-OperationがWebSocket等のendpointをApplication dataとして返すことは妨げない。そのendpoint上のprotocol、状態、lifecycleはWIPの規定対象外である。
+Operationは、WebSocket等のendpointをApplication dataとして返してよい。ただし、そのendpoint上のprotocol、状態、lifecycleは、WIPの規定対象外である。
 
 ## Endpoint
 
-WIP endpointは、一つのWorldspace access surfaceを指すabsolute hierarchical base URLである。Endpoint URLのpath prefixはdeploymentが任意に選択できる。Clientはorigin直下、`/wip`等の既定prefix、またはWorldspace pathとの対応を仮定しない。
+WIP endpointは、一つのWorldspace access surfaceを指すabsolute hierarchical base URLである。URLのpath prefixはdeploymentが任意に選択できる。Clientはorigin直下や`/wip`等の既定prefixを仮定せず、Worldspace pathとの対応も仮定しない。
 
-Endpoint URLは次を満たす。
+Endpoint URLには、次の条件を適用する。
 
 - HTTP実装がrequest先として使用できるabsolute URLである。
 - Authorityとhostを持つ。
 - Queryとfragmentを持たない。
 - Pathが`/`で終わるcanonical formである。
 
-利用者から末尾`/`のないURLを受け付ける実装は、routeを解決する前に`/`を追加してcanonical formへ変換する。URL schemeと通信securityの選択はHTTP実装とdeploymentの責務であり、このbindingは制約しない。
+利用者から末尾`/`のないURLを受け付ける実装は、routeを解決する前に`/`を追加し、canonical formへ変換する。URL schemeと通信securityはHTTP実装とdeploymentが選択し、このbindingは制約しない。
 
-各routeはendpoint URLをbase URLとして、次のrelative referenceをRFC 3986に従って解決する。すべてのinteractionは`POST`を使用する。
+各routeは、endpoint URLをbase URLとして、次のrelative referenceをRFC 3986に従って解決する。すべてのinteractionで`POST`を使用する。
 
 | Interaction | Method | Relative reference |
 | --- | --- | --- |
@@ -35,27 +35,27 @@ Endpoint URLは次を満たす。
 | `fetch_interface` | `POST` | `v1/fetch_interface` |
 | `call_operation` | `POST` | `v1/call_operation` |
 
-`v1`はWIP over HTTP Bindingのmajor versionである。Interactionごとに独立したrouteを設定したり、固定suffixを別名へ置き換えたりしない。
+`v1`は、WIP over HTTP Bindingのmajor versionを表す。Interactionごとに独立したrouteを設定したり、固定suffixを別名へ置き換えたりしない。
 
-例えば、次のendpointを指定した場合、
+例えば、endpointが次のURLである場合、
 
 ```text
 http://gateway.example/tenants/acme/filesystem/wip/
 ```
 
-`observe` routeは次になる。
+`observe` routeは次のURLになる。
 
 ```text
 http://gateway.example/tenants/acme/filesystem/wip/v1/observe
 ```
 
-Endpointのpath prefixはHTTP deployment上のroutingであり、Worldspace内のpathではない。Worldspace pathはrequest bodyのlogical fieldとして渡す。標準route URLはqueryを持たず、query付きURLまたは追加path segmentを同じrouteとして扱わない。
+このpath prefixはHTTP deployment上のroutingであり、Worldspace内のpathではない。Worldspace pathは、request bodyのlogical fieldとして渡す。標準route URLはqueryを持たず、query付きURLや追加path segmentを同じrouteとして扱わない。
 
-Clientは異なるcanonical endpoint間でKnown Space、Object observation、Interface observation、validatorを混在させない。同じendpointでも認証主体、tenant、capability、その他のsecurity contextによって異なるWorldspaceが見える場合、それらを異なるeffective Worldspace viewとして分離する。
+Clientは、異なるcanonical endpoint間でKnown Space、Object observation、Interface observation、validatorを混在させない。同じendpointでも、認証主体、tenant、capability、その他のsecurity contextによって異なるWorldspaceが見える場合は、異なるeffective Worldspace viewとして分離する。
 
 ## HTTP request metadata
 
-標準routeへのrequestは次を満たす。
+標準routeへのrequestには、次の条件を適用する。
 
 - Methodは`POST`。
 - `Content-Type`は`application/json`または`application/json; charset=utf-8`。
@@ -63,15 +63,15 @@ Clientは異なるcanonical endpoint間でKnown Space、Object observation、Int
 - 標準Clientは`Accept: application/json`を送る。
 - Request URLは標準routeと完全に一致し、queryを持たない。
 
-Media typeとparameter名の比較はHTTPの規則に従ってcase-insensitiveに行う。`charset`を指定する場合は`utf-8`だけを許可する。同じparameterの重複、UTF-8以外のcharset、その他のmedia type parameterを標準bindingでは使用しない。
+Media typeとparameter名は、HTTPの規則に従ってcase-insensitiveに比較する。`charset`を指定する場合に許可するのは`utf-8`だけである。同じparameterの重複、UTF-8以外のcharset、その他のmedia type parameterは、標準bindingでは使用しない。
 
-`Accept`がないrequestをHostは受理してよい。`Accept`がある場合はHTTP content negotiationの規則を適用し、`application/json`に対するeffective quality valueが正である場合だけJSON responseを返す。
+Hostは、`Accept`がないrequestを受理してよい。`Accept`がある場合はHTTP content negotiationの規則を適用し、`application/json`に対するeffective quality valueが正である場合だけ、JSON responseを返す。
 
-すべての実装はHTTP identity content codingを扱える。Requestまたはresponseのcontent codingはoptionalなHTTP機能であり、本bindingは特定の圧縮方式を必須にしない。Hostが対応しないrequest content codingはTransport-levelの`415 Unsupported Media Type`として拒否する。Clientが対応しないresponse content codingはTransport failureとして扱う。
+すべての実装はHTTP identity content codingを扱える。Requestとresponseのcontent codingはoptionalなHTTP機能であり、このbindingは特定の圧縮方式を必須にしない。Hostが対応しないrequest content codingは、Transport-levelの`415 Unsupported Media Type`として拒否する。Clientが対応しないresponse content codingは、Transport failureとして扱う。
 
 ## Routeとmetadataのfailure
 
-Route、method、content negotiation、Transport authenticationはlogical WIP requestの外側にある。次のresponseはProtocol error envelopeを要求しない。
+Route、method、content negotiation、Transport authenticationは、logical WIP requestの外側で扱う。次のresponseには、Protocol error envelopeを要求しない。
 
 | 条件 | HTTP response |
 | --- | --- |
@@ -82,25 +82,25 @@ Route、method、content negotiation、Transport authenticationはlogical WIP re
 | Transport authenticationが必要 | `401 Unauthorized`、必要なら`WWW-Authenticate` |
 | Endpoint access surface全体へのaccess拒否 | `403 Forbidden` |
 
-Clientはこれらを`InvalidRequest`、`NotFound`、`PermissionDenied`等へ変換しない。
+Clientは、これらを`InvalidRequest`、`NotFound`、`PermissionDenied`等へ変換しない。
 
-標準route、method、media type、authenticationが受理された後、bodyがmalformed JSONである、logical requestへdecodeできない、required fieldがない、未知fieldがある、またはfield semanticsに違反する場合、Hostは`400 Bad Request`と`invalid_request`のProtocol error envelopeを返す。
+一方、標準route、method、media type、authenticationを受理した後に、bodyがmalformed JSONである、logical requestへdecodeできない、required fieldがない、未知fieldがある、またはfield semanticsに違反する場合は、Protocol failureとなる。Hostは`400 Bad Request`と、`invalid_request`のProtocol error envelopeを返す。
 
-HTTP server、proxy、gateway、またはClientの運用設定によってmessage size、timeout、rate等の上限に達した場合はTransport failureである。HTTP statusが後述するProtocol error mappingと同じでも、validなProtocol error envelopeを持たないresponseをProtocol failureへ変換しない。
+HTTP server、proxy、gateway、Clientの運用設定によってmessage size、timeout、rate等の上限に達した場合は、Transport failureである。HTTP statusがProtocol error mappingと同じでも、validなProtocol error envelopeを持たないresponseをProtocol failureへ変換しない。
 
 ## HTTP response
 
-各interactionが成功した場合、Hostは`200 OK`を返し、response bodyへ対応するProtocol responseを直接encodeする。Success bodyを`result`等の共通envelopeで包まない。
+各interactionが成功した場合、Hostは`200 OK`を返す。Response bodyには、対応するProtocol responseを直接encodeし、`result`等の共通envelopeで包まない。
 
-Protocol failureの場合、Hostは非2xx statusを返し、bodyへ本章のProtocol error envelopeをencodeする。
+Protocol failureの場合は非2xx statusを返し、bodyにProtocol error envelopeをencodeする。
 
-WIP Hostが生成するbody付きresponseは`Content-Type: application/json`または`application/json; charset=utf-8`を持つ。Protocol successまたはProtocol failureのbodyはUTF-8 JSON textである。
+WIP Hostが生成するbody付きresponseは、`Content-Type: application/json`または`application/json; charset=utf-8`を持つ。Protocol successとProtocol failureのbodyは、いずれもUTF-8 JSON textである。
 
-HTTP statusは大分類とHTTP infrastructureのための補助情報であり、Protocol failureの意味を決定しない。Clientはstatus、reason phrase、人間向けmessageから`ProtocolErrorCode`を推測しない。
+HTTP statusは、大分類とHTTP infrastructureのための補助情報である。Protocol failureの意味を決定するものではなく、Clientはstatus、reason phrase、人間向けmessageから`ProtocolErrorCode`を推測しない。
 
-非2xx responseが、正しいContent-TypeとvalidなProtocol error envelopeを持たない場合、ClientはTransport failureとして扱う。これにより、proxyやgatewayが生成したresponseをHost由来のProtocol failureと誤認しない。
+非2xx responseが、正しいContent-TypeとvalidなProtocol error envelopeを持たない場合、ClientはTransport failureとして扱う。Proxyやgatewayが生成したresponseを、Host由来のProtocol failureと誤認しないためである。
 
-次は`InvalidResponse`である。
+これに対し、次のresponseは`InvalidResponse`となる。
 
 - `200 OK`以外の2xx statusにvalidなsuccess bodyがある。
 - 2xx statusにProtocol error envelopeがある。
@@ -109,7 +109,7 @@ HTTP statusは大分類とHTTP infrastructureのための補助情報であり
 
 ## JSON共通規則
 
-JSON encodingには次の規則を適用する。
+JSON encodingには、次の規則を適用する。
 
 - JSON textはUTF-8でencodeする。
 - RecordはJSON object、listはJSON arrayで表す。
@@ -123,11 +123,11 @@ JSON encodingには次の規則を適用する。
 - StringへUnicode normalizationを適用しない。
 - JSON syntaxが表現できないNaNと正負Infinityを使用しない。
 
-本章のschema表で`optional`と記していないfieldはrequiredである。
+Schema表で`optional`と記していないfieldは、requiredとして扱う。
 
-`Vec<u8>`はRFC 4648 Section 4のstandard base64 alphabetを使用し、必要な`=` paddingを含むcanonical base64 stringとしてencodeする。Whitespace、URL-safe alphabet、padding省略、同じoctet列に対する別表現を受理しない。
+`Vec<u8>`はcanonical base64 stringとしてencodeする。RFC 4648 Section 4のstandard base64 alphabetを使用し、必要な`=` paddingを含める。Whitespace、URL-safe alphabet、padding省略、同じoctet列に対する別表現は受理しない。
 
-Path、Interface参照、Object identity、名前、validatorの意味はfieldの位置とProtocolの型によって決まる。
+Path、Interface参照、Object identity、名前、validatorの意味は、fieldの位置とProtocolの型によって決まる。JSON上の表現は次のとおりである。
 
 | Logical field | JSON encoding |
 | --- | --- |
@@ -138,11 +138,11 @@ Path、Interface参照、Object identity、名前、validatorの意味はfield
 | `format` | string |
 | Object / Interface validator | canonical base64 string |
 
-JSON serializationのwhitespace、escapeの選択、object member順をcanonical化しない。同じlogical valueがbyte-for-byte同一のJSONになることを要求しない。
+ただし、JSON serialization全体をcanonical化するわけではない。Whitespace、escapeの選択、object member順はcanonical化せず、同じlogical valueがbyte-for-byte同一のJSONになることも要求しない。
 
 ## Interface Reference
 
-`InterfaceReference`は次のexactなJSON objectとしてencodeする。
+`InterfaceReference`は、次のfieldだけを持つexactなJSON objectとしてencodeする。
 
 | Field | JSON type | Presence |
 | --- | --- | --- |
@@ -156,13 +156,15 @@ JSON serializationのwhitespace、escapeの選択、object member順をcanonical
 }
 ```
 
-`Object.interfaces`の各要素、`FetchInterfaceRequest.interface`、`FetchInterfaceResponse.interface`、`InterfaceTarget.reference`のすべてでこの形を使用する。Scopeの省略、relative scope、`null`、空name、追加member、旧形式のopaque string、`"/github::issue.read"`等の短縮表記stringは認めない。Requestでの違反は`400 Bad Request`と`invalid_request`、responseでの違反はClient-localな`InvalidResponse`とする。
+`Object.interfaces`の各要素、`FetchInterfaceRequest.interface`、`FetchInterfaceResponse.interface`、`InterfaceTarget.reference`で、この形を共通して使用する。Scopeの省略、relative scope、`null`、空name、追加member、旧形式のopaque string、`"/github::issue.read"`等の短縮表記stringは認めない。Requestで違反した場合は`400 Bad Request`と`invalid_request`を返し、responseで違反した場合はClient-localな`InvalidResponse`とする。
 
-参照の比較はJSON decode後の`scope`と`name`の完全一致であり、object member順やJSON escapeの違いは同一性に影響しない。ScopeへURL encoding / decodingを追加せず、name内の`::`や`#`も通常の文字として保持する。ScopeはWorldspace上のpathであり、HTTP endpointのprefixを加えたりscope用のHTTP routeを生成したりしない。合成によるscope変換は[ProtocolのWorldspace composition](3-protocol.md#worldspace-composition)に従う。
+参照は、JSON decode後の`scope`と`name`の完全一致で比較する。Object member順やJSON escapeの違いは、同一性に影響しない。ScopeへURL encoding / decodingを追加せず、name内の`::`や`#`も通常の文字として保持する。
+
+ScopeはWorldspace上のpathである。HTTP endpointのprefixを加えたり、scope用のHTTP routeを生成したりしない。合成によるscope変換は、[ProtocolのWorldspace composition](3-protocol.md#worldspace-composition)に従う。
 
 ## ObjectとObjectObservation
 
-`Object`は次のJSON objectとしてencodeする。
+`Object`は、次のfieldを持つJSON objectとしてencodeする。
 
 | Field | JSON type | Presence |
 | --- | --- | --- |
@@ -172,7 +174,7 @@ JSON serializationのwhitespace、escapeの選択、object member順をcanonical
 | `ref` | string | optional |
 | `validator` | canonical base64 string | optional |
 
-例:
+ObjectのJSON表現の例:
 
 ```json
 {
@@ -187,28 +189,32 @@ JSON serializationのwhitespace、escapeの選択、object member順をcanonical
 }
 ```
 
-`interfaces`のarray順はHostの立項順を保持し、`(scope, name)`の完全一致による重複を含まない。各参照のscopeは観測pathに対してProtocolの祖先制約を満たす。
+`interfaces`のarray順にはHostの立項順を保持し、`(scope, name)`の完全一致による重複を含めない。各参照のscopeは、観測pathに対してProtocolの祖先制約を満たす。
 
-`ObjectObservation`は次のJSON objectとしてencodeする。
+`ObjectObservation`は、Objectとchildrenの観測を次のJSON objectで表す。
 
 | Field | JSON type | Presence |
 | --- | --- | --- |
 | `object` | `Object` | required |
 | `children` | `ObjectObservation`のarray | optional |
 
-`children`の省略は未観測を、空arrayは観測済みで直接のindexable childが存在しないことを表す。Requested depthより浅いnodeでは`children`を必ず含め、depth境界のnodeでは省略する。Success responseはrequested depthまで完全であり、truncated markerやpartial successを返さない。
+`children`の省略は未観測を表す。空arrayは、観測済みで直接のindexable childが存在しないことを表す。Requested depthより浅いnodeでは`children`を必ず含め、depth境界のnodeでは省略する。
+
+Success responseはrequested depthまで完全であり、truncated markerやpartial successを返さない。
 
 ## Interface Descriptor
 
 ### Format discriminator
 
-標準v1のInterface Descriptor formatは`wip-interface/1`である。このformatでは以下のJSON grammarを使用する。
+標準v1のInterface Descriptor formatは、`wip-interface/1`である。このformatのJSON grammarは、以下の定義に従う。
 
-ClientはDescriptor objectのstring `format`を先に読み、対応しないformatを`UnsupportedDescriptorFormat`として扱える。未知formatでもDescriptorはJSON objectであり、string `format`を必ず持つ。それ以外のmemberはそのformat固有であるため、Clientは`wip-interface/1`のschemaで存在、欠落、型を判定せず、内容をOperationへ使用しない。標準v1 Hostは`wip-interface/1`を返す。
+Clientは、Descriptor objectのstring `format`を先に読み、対応しないformatを`UnsupportedDescriptorFormat`として扱える。未知formatでも、DescriptorはJSON objectであり、string `format`を必ず持つ。
+
+それ以外のmemberはformat固有であるため、未知formatを`wip-interface/1`のschemaで検証しない。Memberの存在、欠落、型をこのschemaで判定せず、内容をOperationへ使用しない。標準v1 Hostは`wip-interface/1`を返す。
 
 ### Documentation
 
-`Documentation`は次のJSON objectである。
+`Documentation`は、説明を次のJSON objectで表す。
 
 | Field | JSON type | Presence |
 | --- | --- | --- |
@@ -217,7 +223,7 @@ ClientはDescriptor objectのstring `format`を先に読み、対応しないfor
 
 ### Descriptor root
 
-`InterfaceDescriptor`は次のJSON objectである。
+`InterfaceDescriptor`のrootは、次のJSON objectである。
 
 | Field | JSON type | Presence |
 | --- | --- | --- |
@@ -226,7 +232,7 @@ ClientはDescriptor objectのstring `format`を先に読み、対応しないfor
 | `types` | `TypeDeclaration`のarray | required |
 | `operations` | `OperationDeclaration`のarray | required |
 
-`types`と`operations`のarray順はdeclaration順を保持する。
+`types`と`operations`のarrayには、declaration順を保持する。
 
 ### TypeDeclaration
 
@@ -238,7 +244,7 @@ ClientはDescriptor objectのstring `format`を先に読み、対応しないfor
 
 ### TypeExpr
 
-すべての`TypeExpr`はstring `kind`を持つJSON objectとしてencodeする。`kind`ごとの正確なmemberは次のとおりである。
+すべての`TypeExpr`を、string `kind`を持つJSON objectとしてencodeする。`kind`ごとに持つmemberは、次のものに限定する。
 
 | TypeExpr | `kind` | その他のmember |
 | --- | --- | --- |
@@ -256,7 +262,7 @@ ClientはDescriptor objectのstring `format`を先に読み、対応しないfor
 | Enum | `enum` | required `EnumCase` array `cases` |
 | Union | `union` | required `UnionCase` array `cases` |
 
-例:
+ListのitemsがNamedであるTypeExprの例:
 
 ```json
 {
@@ -268,7 +274,7 @@ ClientはDescriptor objectのstring `format`を先に読み、対応しないfor
 }
 ```
 
-Primitive kindのobjectへ別memberを追加してはならない。例えばUnitは`{"kind":"unit"}`だけで表す。
+Primitive kindのobjectに、別memberを追加してはならない。例えばUnitの表現は、`{"kind":"unit"}`だけである。
 
 ### FieldDeclaration
 
@@ -294,7 +300,7 @@ Primitive kindのobjectへ別memberを追加してはならない。例えばUni
 | `documentation` | `Documentation` | optional |
 | `payload` | `TypeExpr` | optional |
 
-`payload`の省略はpayloadを持たないcaseを表す。
+`payload`を省略したcaseは、payloadを持たない。
 
 ### OperationDeclaration
 
@@ -321,9 +327,9 @@ Primitive kindのobjectへ別memberを追加してはならない。例えばUni
 | `documentation` | `Documentation` | optional |
 | `type` | `TypeExpr` | required |
 
-Descriptorの名前一意性、Named参照、cycle、型整合性等は[3. Protocol](3-protocol.md)に従って検証する。JSON shapeが正しいことだけではvalidなDescriptorにならない。
+JSON shapeの検証だけでは、Descriptorのvalidityは確認できない。名前一意性、Named参照、cycle、型整合性等も、[3. Protocol](3-protocol.md)に従って検証する。
 
-完全なDescriptorの例:
+Typesとoperationsを含む、完全なDescriptorの例:
 
 ```json
 {
@@ -400,15 +406,17 @@ Operationのargumentsとresultは、選択したInterface Descriptorの`TypeExpr
 | Enum | 宣言されたcase名のstring |
 | Union | `$case`と、必要なら`value`を持つobject |
 
-`Json`内部でもnumberは相互運用可能なsafe integerまたはfinite binary64として扱い、Bytesの特別なencodingは適用しない。小数部と指数部を持たずsafe integer範囲にあるJSON numberはlogical `Integer`、それ以外のfiniteなJSON numberはlogical `Number`としてdecodeする。`Json`内のbase64らしいstringをBytesと推測しない。
+`Json`内部のnumberにも、相互運用可能なsafe integerまたはfinite binary64という制約を適用する。小数部と指数部を持たずsafe integer範囲にあるJSON numberはlogical `Integer`として、それ以外のfiniteなJSON numberはlogical `Number`としてdecodeする。
 
-RecordとOperation argumentsでは、`required = false`のfieldまたはparameterを省略できる。省略と`null`は異なる。TypeExprがUnit、Json、またはそれらへ解決されるNamedである場合、存在するmemberの`null`はその型のvalueであり、省略を表さない。それ以外の型で`null`を使用してはならない。
+`Json`内部にはBytesの特別なencodingを適用しない。Base64らしいstringがあっても、Bytesと推測しない。
 
-Record valueはdeclarationされていないmemberを持たない。Operation argumentsはparameter名をmember名とするJSON objectであり、位置引数を使用しない。引数のないOperationは空objectを使用する。
+RecordとOperation argumentsでは、`required = false`のfieldやparameterを省略できる。ただし、省略と`null`は異なる。TypeExprがUnit、Json、またはそれらへ解決されるNamedである場合、存在するmemberの`null`はその型のvalueであり、省略を表さない。それ以外の型では`null`を使用してはならない。
 
-Enumはcase名だけをstringで表し、object envelopeを使用しない。
+Record valueには、declarationされていないmemberを含めない。Operation argumentsは、parameter名をmember名とするJSON objectであり、位置引数を使用しない。引数のないOperationには空objectを使用する。
 
-Payloadを持つUnionは次の形である。
+Enumはcase名だけをstringで表し、object envelopeは使用しない。
+
+Payloadを持つUnionは、`$case`と`value`を持つ次の形で表す。
 
 ```json
 {
@@ -417,7 +425,7 @@ Payloadを持つUnionは次の形である。
 }
 ```
 
-Payloadを持たないUnionは`value`を省略する。
+Payloadを持たないUnionでは、`value`を省略する。
 
 ```json
 {
@@ -425,15 +433,15 @@ Payloadを持たないUnionは`value`を省略する。
 }
 ```
 
-Union objectは`$case`と必要な`value`以外のmemberを持たない。Payloadありcaseでは`value`がrequired、payloadなしcaseでは`value`は禁止される。
+Union objectに含めるmemberは、`$case`と必要な`value`だけである。Payloadありcaseでは`value`がrequiredとなり、payloadなしcaseでは`value`を禁止する。
 
-ClientはDescriptorに従ってvalueをdecodeし、`entry`と宣言された位置のstringだけをWorldspace entryとして認識する。通常のStringやopaqueなJsonに含まれるpathらしいstringをentryとして推測しない。
+Clientは、Descriptorに従ってvalueをdecodeする。Worldspace entryとして認識するのは、`entry`と宣言された位置のstringだけである。通常のStringやopaqueなJsonに含まれるpathらしいstringから、entryを推測しない。
 
 ## `observe`
 
 ### Request
 
-`POST v1/observe`のbodyは次のJSON objectである。
+`POST v1/observe`のbodyには、次のJSON objectを使用する。
 
 | Field | JSON type | Presence |
 | --- | --- | --- |
@@ -449,7 +457,7 @@ ClientはDescriptorに従ってvalueをdecodeし、`entry`と宣言された位
 
 ### Success response
 
-Success bodyはrootの`ObjectObservation`を直接encodeする。
+Success bodyには、rootの`ObjectObservation`を直接encodeする。
 
 ```json
 {
@@ -473,13 +481,13 @@ Success bodyはrootの`ObjectObservation`を直接encodeする。
 }
 ```
 
-Responseのpath、name、depth、children completenessはrequestと[3. Protocol](3-protocol.md)に従って検証する。完全なresponseをresource budget内で構築できない場合、Hostはpartial successではなく`resource_limit_exceeded`を返す。
+Responseのpath、name、depth、children completenessは、requestと[3. Protocol](3-protocol.md)に従って検証する。Hostがresource budget内で完全なresponseを構築できない場合は、partial successにせず、`resource_limit_exceeded`を返す。
 
 ## `fetch_interface`
 
 ### Request
 
-`POST v1/fetch_interface`のbodyは次のJSON objectである。
+`POST v1/fetch_interface`のbodyには、次のJSON objectを使用する。
 
 | Field | JSON type | Presence |
 | --- | --- | --- |
@@ -513,9 +521,11 @@ Responseのpath、name、depth、children completenessはrequestと[3. Protocol]
 }
 ```
 
-Responseの`interface`はrequestと完全一致しなければならない。`scope_ref`、Descriptor、validatorは一つのInterface observationとして扱う。`scope_ref`はscope Objectの`ref`と同じopaque stringであり、base64化しない。Scope Objectが`ref`を持つ場合は含め、持たない場合は省略する。`null`は使用しない。
+Responseの`interface`は、requestと完全一致しなければならない。`scope_ref`、Descriptor、validatorは、一つのInterface observationとして扱う。
 
-Scope Objectに`ref`がない場合のvalidなresponse例:
+`scope_ref`はscope Objectの`ref`と同じopaque stringであり、base64化しない。Scope Objectが`ref`を持つ場合は含め、持たない場合は省略する。`null`は使用しない。
+
+Scope Objectに`ref`がない場合も、次のresponseはvalidである。
 
 ```json
 {
@@ -528,13 +538,13 @@ Scope Objectに`ref`がない場合のvalidなresponse例:
 }
 ```
 
-`scope_ref`もvalidatorもない観測は許可される。Scopeのidentity追跡はできず、Descriptorはその参照の有効期間中immutableとして扱う。
+`scope_ref`もvalidatorもない観測は許可される。この場合、scopeのidentityは追跡できず、Descriptorは参照の有効期間中immutableとして扱う。
 
 ## `call_operation`
 
 ### Request
 
-`POST v1/call_operation`のbodyは次のJSON objectである。
+`POST v1/call_operation`のbodyには、次のJSON objectを使用する。
 
 | Field | JSON type | Presence |
 | --- | --- | --- |
@@ -543,14 +553,14 @@ Scope Objectに`ref`がない場合のvalidなresponse例:
 | `operation` | Operation名のstring | required |
 | `arguments` | 選択したOperation declarationに従うobject | required |
 
-`Target`は次のfieldを持つ。
+`Target`は、pathとoptionalなvalidatorを次のfieldで表す。
 
 | Field | JSON type | Presence |
 | --- | --- | --- |
 | `path` | canonical absolute Worldspace pathのstring | required |
 | `validator` | canonical base64 string | optional |
 
-`InterfaceTarget`は次のfieldを持つ。
+`InterfaceTarget`は、参照とその観測metadataを次のfieldで表す。
 
 | Field | JSON type | Presence |
 | --- | --- | --- |
@@ -576,11 +586,13 @@ Scope Objectに`ref`がない場合のvalidなresponse例:
 }
 ```
 
-`interface.reference`と`operation`は別fieldである。表示用の`/::item-interface-v1#get_related_item`を一つのfieldへencodeしない。`scope_ref`も`InterfaceReference`のmemberや短縮表記の一部にはせず、`InterfaceTarget`の独立したoptional fieldとして送る。
+`interface.reference`と`operation`は、別fieldである。表示用の`/::item-interface-v1#get_related_item`を、一つのfieldへencodeしない。`scope_ref`も`InterfaceReference`のmemberや短縮表記の一部にはせず、`InterfaceTarget`の独立したoptional fieldとして送る。
 
-Clientは`fetch_interface`の観測に`scope_ref`があればコピーし、なければ省略する。`scope_ref`に`null`や非stringを指定したrequestは`invalid_request`である。Validなstringを指定したが現在のscope Objectの`ref`と一致しない場合（現在の`ref`の欠落を含む）は、Protocolの検証順に従って`interface_mismatch`とする。省略時はscope identity preconditionを適用せず、それだけを理由に拒否しない。
+Clientは、`fetch_interface`の観測に`scope_ref`があればコピーし、なければ省略する。`null`や非stringを`scope_ref`に指定したrequestは、`invalid_request`となる。
 
-HostはDescriptorに依存しない`target`、`interface`、`operation`のshapeを検証し、Protocolのerror precedenceに従って現在のObjectとInterface observationを固定した後、そのDescriptorに従って`arguments`をdecodeする。
+Validなstringを指定していても、現在のscope Objectの`ref`と一致しない場合は、Protocolの検証順に従って`interface_mismatch`とする。現在の`ref`が欠落している場合も含む。`scope_ref`を省略した場合はscope identity preconditionを適用せず、省略だけを理由に拒否しない。
+
+Hostはまず、Descriptorに依存しない`target`、`interface`、`operation`のshapeを検証する。次に、Protocolのerror precedenceに従って現在のObjectとInterface observationを固定し、そのDescriptorに従って`arguments`をdecodeする。
 
 ### Success response
 
@@ -599,11 +611,11 @@ HostはDescriptorに依存しない`target`、`interface`、`operation`のshape
 }
 ```
 
-`result`はrequestで指定し、Hostがprecondition確認時に固定したOperation declarationのreturn TypeExprに従ってencodeする。
+`result`のencodingには、requestで指定し、Hostがprecondition確認時に固定したOperation declarationのreturn TypeExprを使用する。
 
 ## Validator
 
-Object validatorとInterface validatorは対応するJSON body fieldへcanonical base64としてencodeする。
+Object validatorとInterface validatorは、対応する次のJSON body fieldにcanonical base64としてencodeする。
 
 - `Object.validator`
 - `Target.validator`
@@ -611,7 +623,9 @@ Object validatorとInterface validatorは対応するJSON body fieldへcanonical
 - `InterfaceTarget.validator`
 - `CallOperationResponse.validator`
 
-WIP validatorを`ETag`、`If-Match`、その他のHTTP headerだけへ移してbody fieldを省略してはならない。Host、gateway、HTTP cacheは通常のHTTP representation metadataとして`ETag`等を追加してよいが、その値はWIP validatorと独立している。ClientはHTTP metadataをObject identity、Interface observation、Operation preconditionとして解釈しない。
+WIP validatorを`ETag`、`If-Match`、その他のHTTP headerだけへ移し、body fieldを省略してはならない。
+
+Host、gateway、HTTP cacheは、通常のHTTP representation metadataとして`ETag`等を追加してよい。ただし、その値はWIP validatorとは独立している。ClientはHTTP metadataを、Object identity、Interface observation、Operation preconditionとして解釈しない。
 
 ## Protocol error envelope
 
@@ -626,16 +640,16 @@ WIP validatorを`ETag`、`If-Match`、その他のHTTP headerだけへ移してb
 }
 ```
 
-Top-level objectは`error`だけを持つ。`error` objectは次のfieldだけを持つ。
+Top-level objectに含めるのは`error`だけである。`error` objectも、次のfieldだけを持つ。
 
 | Field | JSON type | Presence |
 | --- | --- | --- |
 | `code` | 下表のstableなsnake_case string | required |
 | `message` | boundedな人間向け診断string | required |
 
-Clientは`message`で分岐しない。Hostは秘密情報、credential、非公開Object、backend path、内部stack traceをmessageへ含めない。
+Clientは`message`を分岐に使用しない。Hostは秘密情報、credential、非公開Object、backend path、内部stack traceをmessageへ含めない。
 
-`ProtocolErrorCode`のwire spellingとcanonical HTTP statusは次のとおりである。
+`ProtocolErrorCode`には、次のwire spellingとcanonical HTTP statusを対応付ける。
 
 | Protocol error code | Wire spelling | HTTP status |
 | --- | --- | --- |
@@ -654,35 +668,35 @@ Clientは`message`で分岐しない。Hostは秘密情報、credential、非公
 | `Internal` | `internal` | `500 Internal Server Error` |
 | `OperationOutcomeUnknown` | `operation_outcome_unknown` | `500 Internal Server Error` |
 
-`resource_limit_exceeded`は、observation completeness、logical nesting、collection件数等、WIP Protocolが扱うlogical requestまたはresponseの上限超過を表し、`422 Unprocessable Content`を使用する。HTTP implementationやdeploymentのmessage-size上限超過をこのcodeへ変換しない。
+`resource_limit_exceeded`は、WIP Protocolが扱うlogical requestまたはresponseの上限超過を表す。Observation completeness、logical nesting、collection件数等が対象であり、HTTP statusには`422 Unprocessable Content`を使用する。HTTP implementationやdeploymentのmessage-size上限超過を、このcodeへ変換しない。
 
-Rate limitまたはdeployment concurrency limitによる`429 Too Many Requests`はTransport / deployment concernである。ValidなProtocol error envelopeがない限り`ResourceLimitExceeded`へ変換しない。
+Rate limitやdeployment concurrency limitによる`429 Too Many Requests`は、Transport / deployment concernである。ValidなProtocol error envelopeがない限り、`ResourceLimitExceeded`へ変換しない。
 
-Hostはinteractionごとに[3. Protocol](3-protocol.md)で許可されたcodeだけを返す。ClientがvalidなProtocol error envelopeを取得した場合、HTTP statusがcanonical mappingと一致しなくても回復actionは`code`に従い、statusから別codeを推測しない。Status mismatchはBinding違反として診断してよい。
+Hostは、interactionごとに[3. Protocol](3-protocol.md)で許可されたcodeだけを返す。ClientがvalidなProtocol error envelopeを取得した場合、回復actionは`code`に従う。HTTP statusがcanonical mappingと一致しなくても、statusから別codeを推測しない。Status mismatchは、Binding違反として診断してよい。
 
 `InvalidResponse`と`UnsupportedDescriptorFormat`はClient-local classificationであり、Hostがerror envelopeで返してはならない。Domain failureもProtocol errorへ変換せず、Operation return typeに従うApplication dataとしてencodeする。
 
 ## HTTP authentication boundary
 
-Authentication方式、credential、mTLS、proxy、gateway等はHTTP implementationとdeploymentの関心であり、本bindingは規定しない。
+Authentication方式、credential、mTLS、proxy、gateway等は、HTTP implementationとdeploymentが設定・運用する。このbindingは規定しない。
 
-HTTP layerがWIP interactionを開始せずに返す`401 Unauthorized`または`403 Forbidden`は、validなProtocol error envelopeを持たないTransport failureである。Clientはそれらを`PermissionDenied`へ変換しない。
+HTTP layerがWIP interactionを開始せずに返す`401 Unauthorized`や`403 Forbidden`は、validなProtocol error envelopeを持たないTransport failureである。Clientはこれらを`PermissionDenied`へ変換しない。
 
-WIP interactionを開始した後のObject、Interface、Operation visibilityとauthorizationはProtocol semanticsに従う。Protocolの`PermissionDenied`はvalidなWIP error envelopeを持つ`403 Forbidden`であり、HTTP layerのaccess rejectionと区別する。
+WIP interactionを開始した後のObject、Interface、Operation visibilityとauthorizationは、Protocol semanticsに従う。Protocolの`PermissionDenied`は、validなWIP error envelopeを持つ`403 Forbidden`であり、HTTP layerのaccess rejectionとは区別する。
 
 ## HTTP replay
 
-`3xx` response自体はWIP successまたはProtocol failureではなく、Transport failureである。Endpoint discovery、redirect、proxy routingをどう扱うかはHTTP implementationとdeploymentの責務である。
+`3xx` response自体は、WIP successやProtocol failureではなく、Transport failureである。Endpoint discovery、redirect、proxy routingの扱いは、HTTP implementationとdeploymentが決定する。
 
-ただし、それらの機構によって一つのlogical `call_operation` requestを複数回dispatchしてはならない。Dispatch後にredirect responseを受け取った場合も、methodとbodyを維持して別endpointへ自動再送しない。
+ただし、これらの機構によって、一つのlogical `call_operation` requestを複数回dispatchしてはならない。Dispatch後にredirect responseを受け取った場合も、methodとbodyを維持して別endpointへ自動再送しない。
 
 ## Dispatchとretry
 
-RequestがHostへ送信されていないとTransport実装が証明できるfailureはnot dispatchedである。送信開始後にresponseを取得できない場合、ClientはHostがrequestを受理した可能性を否定しない。
+Failureをnot dispatchedとして扱えるのは、requestがHostへ送信されていないとTransport実装が証明できる場合である。送信開始後にresponseを取得できない場合、ClientはHostがrequestを受理した可能性を否定しない。
 
-`observe`と`fetch_interface`を再送するか、どのtimeout、retry、cancellation policyを使用するかはClientとHTTP実装の責務である。Response ownershipとProtocol上のcache semanticsは[4. Client](4-client.md)に従う。
+`observe`と`fetch_interface`の再送とtimeout・retry・cancellation policyは、ClientとHTTP実装が決定する。Response ownershipとProtocol上のcache semanticsは、[4. Client](4-client.md)に従う。
 
-`call_operation`には次を適用する。
+`call_operation`には、次の規則を適用する。
 
 - Redirect、connection retry、HTTP stackのautomatic replay、proxy retryによって再送しない。
 - `Retry-After`またはHTTP statusだけを理由に再送しない。
@@ -694,15 +708,15 @@ HTTP implementationとdeploymentは、失敗した`POST v1/call_operation`を透
 
 ## HTTP facilitiesとの境界
 
-HTTP cache、proxy、gateway、compression、connection管理、TLS、message size、timeout、concurrency、rate limit等の設定と運用は、本bindingの規定対象外である。
+HTTP cache、proxy、gateway、compression、connection管理、TLS、message size、timeout、concurrency、rate limit等の設定と運用は、このbindingの規定対象外である。
 
-HTTP cache metadataはWIP ClientのKnown Space、Interface cache、Object validator、Interface validatorとは別の機構である。`ETag`、`If-Match`、Age、Last-Modified等をWIP observationまたはvalidatorとして解釈しない。それ以外のHTTP cache policyはHTTP implementationとdeploymentが決定する。
+HTTP cache metadataは、WIP ClientのKnown Space、Interface cache、Object validator、Interface validatorとは別の機構である。`ETag`、`If-Match`、Age、Last-Modified等を、WIP observationやvalidatorとして解釈しない。それ以外のHTTP cache policyは、HTTP implementationとdeploymentが決定する。
 
-HTTP implementationまたはdeploymentの都合でrequestまたはresponseを交換できない場合、ClientはTransport failureとして扱う。WIPはそれらの運用設定を規定せず、そのfailureを`resource_limit_exceeded`その他のProtocol errorへ包み直さない。
+HTTP implementationやdeploymentの都合でrequestやresponseを交換できない場合、ClientはTransport failureとして扱う。WIPはこれらの運用設定を規定せず、そのfailureを`resource_limit_exceeded`その他のProtocol errorへ包み直さない。
 
 ## 非目標
 
-本bindingは次を定義しない。
+このbindingの定義には、次のものを含めない。
 
 - Host内部のAPI、database、filesystem、queueとの接続方法。
 - Endpoint discovery service。