docs: simplify WIP interaction model

draft/unresolved-issues.md

@@ -22,7 +22,6 @@
 - Recursive named typeを許可するか。
 - `i64`、`u64`、`bigint`、`decimal`等を追加するか。
 - `description`の必須性と長さ。
-- Guardの具体的schema。
 - error型をOperation outputに含めるか、Protocol errorとして分離するか。
 
 ## WIP over HTTPS

draft/wip-idl.md

@@ -253,7 +253,7 @@ operation refresh {
 
 Outputには任意のtype expressionまたはNamed typeを使用できる。ただし、将来fieldを追加する可能性があるOperationではrecord outputを推奨する。
 
-Operationのname、description、Guardなど、input / output型以外のinterface metadataとの対応付けは[Operation schema](../2.2-operation.md)で定義する。
+Operationのnameやdescriptionなど、input / output型以外のinterface metadataとの対応付けは[Operation schema](../2.2-operation.md)で定義する。
 
 ## Schema exchange
 

draft/wip-over-https.md

@@ -8,11 +8,11 @@ Core Protocolの意味論を変えずに、既存のWebインフラを利用し
 
 ## 方針
 
-標準bindingとしてHTTPSを採用することを第一候補とする。
+初期の標準bindingはHTTPS上のrequest / responseのみを規定する。TLS、認証、Proxy、Gateway、Observability、Caching、connection reuse、multiplexing、compression等の既存機構を利用してよいが、特定のHTTP versionや実装方式を必須にしない。
 
-HTTPSを利用することで、TLS、認証、Proxy、Gateway、Observability、Caching、Streamingなど既存の仕組みを再利用できる。
+OperationがWebSocket等のendpointを通常のdomain valueとして返すことは妨げない。そのendpoint上のprotocol、状態、lifecycleはWIPの規定対象外であり、ClientとHost固有実装の責務とする。
 
-必要に応じてHTTP/2、HTTP/3、SSE、WebSocket等を利用してよい。ただし、これらは通信上の最適化または補助機構であり、WIP Core Protocolの意味論を変更しない。
+双方向socket transportをWIP bindingとして標準化する場合は、将来の独立した拡張として定義する。
 
 ## Binding対象
 
@@ -22,7 +22,7 @@ HTTPSを利用することで、TLS、認証、Proxy、Gateway、Observability
 - `fetch_tree`
 - `call_operation`
 
-具体的なHTTP method、endpoint、content type、error mapping、認証方式、streaming表現などは、このbinding仕様側で定義する。
+具体的なHTTP method、endpoint、content type、error mapping、認証方式、batch表現などは、このbinding仕様側で定義する。
 
 ## WIP IDLの取得