webtrans-overview-ja.html

<!DOCTYPE html><html lang="ja"><head><meta charset="utf-8">
<title>The WebTransport Protocol Framework（日本語訳）</title>

<link rel="stylesheet" href="common.css" type="text/css">
<link rel="stylesheet" href="http-common.css" type="text/css">

<style>
.frame-type {
	font-family: sans-serif0, sans-serif;
	color: var(--K-color);
}
</style>


<script src="common0.js"></script>
<script src="common1.js" async></script>

<script>

Util.ready = function(){
	const source_data = {
		toc_main: 'MAIN0',
		generate: expand,
	};
	Util.switchWordsInit(source_data);
}

function expand(){
	const class_map = this.class_map;
	const tag_map = this.tag_map;
	const link_map = this.link_map;

	return this.html.replace(
		/%[\w\-~一-鿆あ-ん]+|`(.+?)([$@\^§])(\w*)/g,
		create_html
	);

	function create_html(match, key, indicator, klass){

if(!key) {//%
	return `<var>${match.slice(1)}</var>`;
}

let href = '';
let href1 = '';
{
	const n = key.indexOf('＠');
	if(n > 0) {
		href1 = key.slice(n + 1);
		key = key.slice(0, n);
	}
}
let text = key;

switch(klass){
case 'r':
	text = `[${key}]`;
	href = `#${key}`;
	break;
case 'en':
	return `<span lang="en">${key}</span>`;
	break;
}

let tag = tag_map[klass];
if(tag) {
	let classname = class_map[klass];
	classname = classname ? ` class="${classname}"` : '';
	text = `<${tag}${classname}>${text}</${tag}>`;
}

if(indicator !== '^'){
	href = href1 || link_map[ klass ? `${klass}.${key}` : key ] || href;
	if(!href){
		console.log(match); // check error
		return match;
	}

	switch(indicator){
	case '$':
		text = `<a href="${href}">${text}</a>`;
		break;
	case '§':
		text = ` <a href="${href}">§ ${text}</a> `;
		break;
	case '@':
		text = `<dfn id="${href.slice(1)}">${text}</dfn>`;
		break;
	}
}

return text;

	}
}

</script>


<script type="text/plain" id="_source_data">

●●options

spec_date:2024-10-22
trans_update:2024-11-11
source_checked:230906
original_url:https://ietf-wg-webtrans.github.io/draft-ietf-webtrans-overview/draft-ietf-webtrans-overview.html
	abbr_url:WT-OVERVIEW
spec_status:IETFID
page_state_key:HTTP
no_original_dfn:true
	ref_id_prefix:
ref_rfc:true
site_nav:network
trans_1st_pub:2023-12-13

●●original_urls

●●class_map
ft:frame-type
2119:rfc2119

●●tag_map
2119:em
ft:code
c:code
cite:cite
i:i

●●original_id_map
abstract:

●●link_map

依拠-可能:#reliable
不依拠-可能:#unreliable

~reset:~RFCx/rfc9000#stream-operations

●●words_table1
WEBTRANSPORT:webtransport-ja.html
RFC6455:RFC6455-ja.html

●●words_table

	●名称
WebSocket:
WebRTC:
DTLS:
SCTP:
WebTransport:
UDP:
ICE:
RTT:
QUIC:
MTU:
TCP:
TLS:
STUN:
URI:
HTTP3:HTTP/3
HTTP2:HTTP/2

	^i:FIN
	^ft:DATAGRAM
	~CSP:Content Security Policy
	~IANA
	`RFC7675$r:STUN Consent Freshness `RFC7675$r
	^cite:WebTransport Protocol Framework

	●transport／network
open:
close:
handshake::::ハンドシェイク
socket::::ソケット
pool:
	~pool法:pooling
端点:endpoint::~::エンドポイント
経路:path::~
多重化-:multiplex::~
再伝送:retransmission::~
	伝送し直:retransmit
送信器:sender::~
受信器:receiver::~
輻輳:congestion::~
喪失-:lose::~
	喪失した:lost
middlebox:

不依拠-:unrely:~
	不依拠-可能:unreliable

	相手の端点:peer
	^en:peer-to-peer
	^en:head-of-line blocking
	^en:browser-to-browser settings
	^en:userspace
	~transport層を成す:transport-layer 〜
	送信-側:send-side
	`Data Recvd^i:Data Recvd

	●stream
datagram::::データグラム
流入:incoming::~
流出:outgoing::~
一方向:unidirectional::~
双方向:bidirectional::~
一方通行:one-way:~

書込め:writeでき::書き込め
書込n:write::書き込み
reset:

	●処理
確立:establishment:~
不可分:atomic:~
	不可分に:atomically
機械:machine::~
満杯:full:~
軽量:lightweight:~
給-:supply:~
優先度:priority:~
rate::::レート
待機中:outstanding:~
渡され:passされ:~
渡す:passする:~
撤回-:retract:~
認知-:acknowledge:~
commit:
	いつでも:at any time

	完了:for it to be completed

	●保安
走査-:scan:~
露呈-:reveal::露わに
再現:replay::~
認証:authentication::~
証明書:certificate::~
潜在的:potential:~
	信用-済みでない:untrusted
	安全でない:unsafe

	●仕様
	mailing::::メーリング
	repository::::リポジトリ

独立性:independence:~
依存性:dependency:~
目指す:aimする:~
同意:consent:~
理論:theory:~
採用:adoption:~
欠点:drawback:~
模倣-:simulate:~
	-:highlight
確認-:confirm:~
満足-:satisfy:~
視点:perspective:~
実体:entity::~
合意-:agree:~
硬直化:ossification:~
指向な:orientedな:~
全般的:overall:~
収まら:fitし:~
	〜が上手く収まらない:makes it a poor fit for
	〜に上手く収まらない:fits poorly with
妨げる:preventする:~

	交換-可能:interchangeable
	要請-者:requester
	必要がある:have to
	ついて来る:comes with
	それでも:nevertheless 〜 still
	一つは:On one hand
	もう一つは:On the other hand
	になり得る:potential
	になり得る:potentially
	難がある:suffer form
	できるようにする:letting
	起因する:stem from
	制約されない:has an unrestricted
	特に:notably
	指す:refer
	に利するため:behalf
	来ている:coming
	最善な労:best-effort
	予め見做され:presume
	用意がある:willing
	`任意選択^2119:OPTIONAL
	`ナラナイ^2119:MUST
	`ナラナイ^2119:SHALL
	`ベキ^2119:SHOULD
	`ヨイ^2119:MAY
	し得るようにする：may end-up
	抽象-化して見えなくする:abstract away
	要を成す:key
	構造は〜に基づく:structured around
	注記:note
	とは限らない:not necessarily
	課す:impose
	関心を失った:not interested in
	要請-者:requester
	限られる:a limited number of
	-:combined with
	十分:enough
	足りる:suffice
	注目すべき:notable
	事実:fact
	区別:distinction

	●未分類
無符号:unsigned:~
側:side:~
交換-:exchange:~
card::::カード
保つ:keepする:~
対応-:correspond:~
component::::コンポーネント
kernel::::カーネル

	~byte列:sequence of bytes
	生きたまま保つ:keep-alive
	〜までに~sizeが抑えられ:sufficiently small
	〜までに~sizeが抑えられ:sufficiently lightweight
	〜 ~bitの:〜-bit
	二つの:dual
	~access可能にならない:would be 〜inaccessible
	現在:currently
	含め:including
	全体が:entirely
	同時に:simultaneously
	様々な:various
	順序どおり:in order
	最~大:largest
	大きく:substantially
	空~文字列:""
	以降は:as soon as
	全般:-wide
	一緒:together
	↔ 間:between
	到達-可能でない:unreachable
	低-:low-
	速く:fast
	~sizeに~~上限がある:size-bounded
	~sizeに~~上限がある:size-bound
	広い:wide
	しない限り:without

●●ref_normative

[QUIC]
    Iyengar, J., Ed. and M. Thomson, Ed., ＜QUIC: A UDP-Based Multiplexed and Secure Transport＞, ~RFC9000, May 2021
[RFC2119]
    Bradner, S., ＜Key words for use in RFCs to Indicate Requirement Levels＞, BCP 14, ~RFC2119, March 1997
[RFC3986]
    Berners-Lee, T., Fielding, R., and L. Masinter, ＜Uniform Resource Identifier (URI): Generic Syntax＞, STD 66, ~RFC3986
[RFC6454]
    Barth, A., ＜The Web Origin Concept＞, ~RFC6454
[RFC8174]
    Leiba, B., ＜Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words＞, BCP 14, ~RFC8174
[RFC8446]
    Rescorla, E., ＜The Transport Layer Security (TLS) Protocol Version 1.3＞, ~RFC8446

●●ref_informative

[CSP]
    W3C, ＜Content Security Policy Level 3＞, October 2024
    URL: https://www.w3.org/TR/CSP/
[RFC5681]
    Allman, M., Paxson, V., and E. Blanton, ＜TCP Congestion Control＞, ~RFC5681, September 2009
[RFC6455]
    Fette, I. and A. Melnikov, ＜The WebSocket Protocol＞, ~RFC6455
[RFC7675]
    Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. Thomson, ＜Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness＞, ~RFC7675, October 2015
[RFC8831]
    Jesup, R., Loreto, S., and M. Tüxen, ＜WebRTC Data Channels＞, ~RFC8831, January 2021
[RFC9000]
    Iyengar, J., Ed. and M. Thomson, Ed., ＜QUIC: A UDP-Based Multiplexed and Secure Transport＞, ~RFC9000, May 2021
[RFC9002]
    Iyengar, J., Ed. and I. Swett, Ed., ＜QUIC Loss Detection and Congestion Control＞, ~RFC9002, May 2021
[RFC9147]
    Rescorla, E., Tschofenig, H., and N. Modadugu, ＜The Datagram Transport Layer Security (DTLS) Protocol Version 1.3＞, ~RFC9147, April 2022
[RFC9220]
    Hamilton, R., ＜Bootstrapping WebSockets with HTTP/3＞, ~RFC9220, June 2022
[RFC9221]
    Pauly, T., Kinnear, E., and D. Schinazi, ＜An Unreliable Datagram Extension to QUIC＞, ~RFC9221, March 2022

●●trans_metadata
<p>
~THIS_PAGEは、
~IETF により Internet-Draft として公開された，
<a href="~SPEC_URL">The WebTransport Protocol Framework</a>
を日本語に翻訳したものです。
~PUB
</p>

●●spec_metadata

Workgroup
	WEBTRANS
位置付け
	Internet-Draft
意図される位置付け
	Standards Track
失効日
	日付から半年後
編集／著作者アドレス
	<a href="mailto:vasilvv@google.com">Victor Vasiliev</a> (Google)
commit 履歴
	https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/commits/main
課題追跡
	https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues
メーリングリスト
	<a href="mailto:webtransport@ietf.org">webtransport@ietf.org</a> (<a href="https://mailarchive.ietf.org/arch/search/?email_list=webtransport">archive</a>)

</script>

</head>

<body>

<header>
	<hgroup>
<h1>WebTransport プロトコルフレームワーク</h1>
<p lang="en">The WebTransport Protocol Framework</p>

	</hgroup>
</header>

<div id="MAIN" hidden>
	<section id="abstract">
◎要約

<p>
`~WebTransport~protocol~framework^cite は、
~Web~security~modelにより拘束された~clientが~secureかつ多重化された~transportを利用して~remote~serverと通信することを可能化する。
それは、［
信用-済みでない応用に公開しても安全な~protocol
］たちが成す集合からなり，［
個々の~protocolが，互いに交換-可能に利用される
］ことを許容する抽象-~modelである。
◎
The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with an abstract model that allows them to be used interchangeably.
</p>

<p>
この文書は、
~WebTransportに利用される~protocolに対する全般的な要件，
それらの~protocolに共通な特能
（うち一部は、
任意選択で~supportし得る）
を定義する。
◎
This document defines the overall requirements on the protocols used in WebTransport, as well as the common features of the protocols, support for some of which may be optional.
</p>

	</section>
	<section>
<h2 title="Note to Readers">読者~向け注記</h2>

<p>
この草案について論を交わす場や この草案の課題は、
冒頭の “`この文書についての詳細＠#_spec_metadata$” の中（末尾）から見出せる。
◎
Discussion of this draft takes place on the WebTransport mailing list (webtransport@ietf.org), which is archived at &lt;https://mailarchive.ietf.org/arch/search/?email_list=webtransport&gt;.
◎
The repository tracking the issues for this draft can be found at &lt;https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues&gt;.＼
</p>

<p>
この文書に対応している~web~API草案は、
`WebTransport＠~WEBTRANSPORT$cite
にて見出せる。
◎
The web API draft corresponding to this document can be found at &lt;https://wicg.github.io/web-transport/&gt;.
</p>

	</section>
	<section id="status-of-memo">
<h2 title="Status of This Memo">このメモの位置付け</h2>

<p class="trans-note">【
この節の内容は
`~IETF日本語訳 共通~page＠~IETFcommon#status-draft$に移譲。
】</p>

<!-- 
This Internet-Draft will expire on 9 March 2024.
-->
	</section>
	<section id="copyright">
<h2 title="Copyright Notice">著作権の告知</h2>

<p lang="en">
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
</p>

<p class="trans-note">【
以下、この節の他の内容は
`~IETF日本語訳 共通~page＠~IETFcommon#copyright-notice$に移譲。
】</p>

	</section>

<main id="MAIN0">
	<section id="introduction">
<h2 title="Introduction">1. 序論</h2>

<p class="trans-note">【
この節の内容は `§ 要約a＠#abstract$ と同じなので、
和訳は省略する。
】
◎
The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with an abstract model that allows them to be used interchangeably.
◎
This document defines the overall requirements on the protocols used in WebTransport, as well as the common features of the protocols, support for some of which may be optional.
</p>

		<section id="background">
<h3 title="Background">1.1. 背景0</h3>

<p>
歴史的に，~client↔~server間で双方向な~data~streamが必要な~web応用は、
~WebSocket `RFC6455$r
に依拠することもできた
— それは、
~Web~security~modelと互換な，~messageに基づく~protocolである。
しかしながら、
それが供する抽象-化は，［
~messageたちが成す，順序に`依拠-可能$な単独の~stream
］なので、
そこには渋滞（ `head-of-line blocking^en ）の難がある
— すなわち、
すべての~messageは，［
互いに独立に処理できる場合や，もはや関連しなくなった~messageがある場合
］でも，送信された順序どおりに受信されなければならない。
これには、
待時間に敏感な応用
— 処理能のために［
部分的な`依拠-能＠#reliable$, ~streamの独立性
］に依拠する応用 —
が上手く収まらない。
◎
Historically, web applications that needed a bidirectional data stream between a client and a server could rely on WebSockets [RFC6455], a message-based protocol compatible with the Web security model. However, since the abstraction it provides is a single ordered reliable stream of messages, it suffers from head-of-line blocking, meaning that all messages must be sent and received in order even if they could be processed independently of each other, and some messages may no longer be relevant. This makes it a poor fit for latency-sensitive applications which rely on partial reliability and stream independence for performance.
</p>

<p class="trans-note">【
`依拠-可能@
（ `reliable^en ）とは，上で述べられたとおり、
~dataは送信された順序どおりに（落とされることなく）送達されることが保証されるので，
受信-側は受信した順序に`依拠-可能である^emことを意味する。
`不依拠-可能@
（ `unreliable^en ）は，`依拠-可能$の否定を意味するが、
“依拠-不能”, “依拠-可能でない”, “非~依拠-可能” ではなく，この対訳が選ばれたのは、
その用法に “依拠することなく処理-可能である” という肯定的な意味合いがあることによる。
】</p>

<p>
~Web開発者に可用な既存の~optionとして、
~WebRTC~data~channel `RFC8831$r もある
— それは、
~DTLSにより保護された `peer-to-peer^en ~SCTP~channel用に，~WebSocketの様な~APIを供する。
理論~上は、
この仕様により取組まれる利用事例に，それを利用することもアリである。
しかしながら，実施においては、
次に挙げるものへの依存性に因り，
`browser-to-browser^en 設定群の外側では広い採用が見られない：
◎
One existing option available to Web developers are WebRTC data channels [RFC8831], which provide a WebSocket-like API for a peer-to-peer SCTP channel protected by DTLS. In theory, it is possible to use it for the use cases addressed by this specification. However, in practice, it has not seen wide adoption outside of browser-to-browser settings due to its dependency on＼
</p>
<ul>
	<li>
~ICE
（これは、
~Web~modelに上手く収まらない）
◎
ICE (which fits poorly with the Web model) and＼
</li>
	<li>
`userspace^en ~SCTP
（これは、
他の文脈では利用されていないことに因り，可用な実装が限られる）
◎
userspace SCTP (which has a limited number of implementations available due to not being used in other contexts).
</li>
</ul>

<p>
代替な設計として、
~HTTP3越しに複数の~WebSocket接続を~openすること `RFC9220$r が挙げられよう。
それは、
渋滞を避けることに加え，
~streamを取消す能を
— それに対応する~WebSocket~sessionを~closeすることにより —
供する。
しかしながら，この~approachには、
首に［
各~WebSocketが意味論的に完全に独立な実体である事実
］から起因する，いくつかの欠点がある：
◎
An alternative design would be to open multiple WebSocket connections over HTTP/3 [RFC9220]. That would avoid head-of-line blocking and provide an ability to cancel a stream by closing the corresponding WebSocket session. However, this approach has a number of drawbacks, which all stem primarily from the fact that semantically each WebSocket is a completely independent entity:
</p>
<ul>
	<li>
各~新たな~streamは、
どの応用~protocolを利用するか合意するため，~WebSocket~handshakeを要求することになる
— そのことは、
~clientが~streamへ書込めるようになる前に，
新たな各~streamを確立する際に 1 回以上の~RTT【往復-時間】がかかることを意味する。
◎
Each new stream would require a WebSocket handshake to agree on application
protocol used, meaning that it would take at least one RTT to establish each
new stream before the client can write to it.
</li>
	<li>
~streamを起動できるのは~clientに限られる。
~serverが起動する~streamや
通信を成す他の代替な~mode
（~QUIC `DATAGRAM^ft ~frame `RFC9221$r など）
は可用でない。
◎
Only clients can initiate streams.  Server-initiated streams and other
alternative modes of communication (such as the QUIC DATAGRAM frame
[RFC9221]) are not available.
</li>
	<li>
~streamたちは，通常は~UAにより~poolされることになるが、
そのことは保証されず，［
ある~WebSocketを ある~serverへ対応付ける一般な処理n
］は~clientからは不透明である。
これは、
~systemの中へ予測-不能な処理能~propを導入し，
~streamたちが同じ接続~上にあることに依拠する最適化を妨げる
（一例として、
~clientが~streamごとに異なる再伝送~優先度を要請することは，
アリかもしれないが
— それらの~streamすべてが同じ接続~上にある場合を除き —
ずっと複階的になる）。
◎
While the streams would normally be pooled by the user agent, this is not guaranteed, and the general process of mapping a WebSocket to a server is opaque to the client.  This introduces unpredictable performance properties into the system, and prevents optimizations which rely on the streams being on
the same connection (for instance, it might be possible for the client to request different retransmission priorities for different streams, but that would be much more complex unless they are all on the same connection).
</li>
</ul>

<p>
~WebTransportは、
応用が次のような~transport~objを作成できるようにすることにより，
上に挙げた課題~すべてを避ける
⇒
単独の~transport~objが，
一緒に多重化された複数の~streamを単独の文脈~内に包含でき
（~SCTP, ~HTTP2, ~QUIC, その他と類似に）、
`不依拠-可能$な~datagramを送信するためにも利用できる
（~UDPと類似に）。
◎
WebTransport avoids all of those issues by letting applications create a single transport object that can contain multiple streams multiplexed together in a single context (similar to SCTP, HTTP/2, QUIC and others), and can be also used to send unreliable datagrams (similar to UDP).
</p>

		</section>
		<section id="conventions-and-definitions">
<h3 title="Conventions and Definitions">1.2. 規約と定義</h3>

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

<p>
~WebTransportは、［
下層の~transport~protocolを抽象-化して見えなくする
］一方で［
~transport層の要を成す少数の側面を応用~開発者に公開する
］ことを目指す~frameworkである。
その構造は、
次に挙げる概念に基づく：
◎
WebTransport is a framework that aims to abstract away the underlying transport protocol while still exposing a few key transport-layer aspects to application developers. It is structured around the following concepts:
</p>
<dl>
	<dt id="webtransport-session">
~WebTransport~session
◎
WebTransport session:
</dt>
	<dd>
~client↔~server間で確立される単独の通信~文脈。
◎
A WebTransport session is a single communication context established between a client and a server.＼
</dd>
	<dd>
それは、
特定の［
~transport層を成す接続
］に対応することもあれば，
既存の多重化された［
~transport層を成す接続
］の中の論理的な実体になることもある。
~WebTransport~sessionどうしは、
一部の~sessionたちが下層の［
~transport層を成す接続
］を共有し得る場合でも，論理的に独立である。
◎
It may correspond to a specific transport-layer connection, or it may be a logical entity within an existing multiplexed transport-layer connection. WebTransport sessions are logically independent from one another even if some sessions can share an underlying transport-layer connection.
</dd>

	<dt id="webtransport-protocol">
~WebTransport~protocol
◎
WebTransport protocol:
</dt>
	<dd>
~WebTransport~sessionを確立するために利用できる特定の~protocol。
◎
A WebTransport protocol is a specific protocol that can be used to establish a WebTransport session.
</dd>

	<dt id="datagram">
~datagram
◎
Datagram:
</dt>
	<dd>
次のような，伝送の単位
⇒＃
その~sizeは（概して経路~MTUに）制限される。
`依拠-可能$に送達されることは期待されない。
当の~transportにより不可分に扱われる。
◎
A datagram is a unit of transmission that is limited in size (typically to the path MTU), does not have an expectation of being delivered reliably, and is treated atomically by the transport.
</dd>

	<dt id="stream">
~stream
◎
Stream:
</dt>
	<dd>
送信器が伝送したとおりの順序で受信している応用へ`依拠-可能$に送達される~byte列。
その長さは，任意になり得るので、
その全体を~memory内に~bufferできるとは限らない。
~WebTransport~protocol, その~APIは、
~stream全体が受信される前に，部分的な~stream~dataを応用に供することが期待される。
◎
A stream is a sequence of bytes that is reliably delivered to the receiving application in the same order as it was transmitted by the sender. Streams can be of arbitrary length, and therefore cannot always be buffered entirely in memory. WebTransport protocols and APIs are expected to provide partial stream data to the application before the stream has been entirely received.
</dd>

	<dt id="message">
~message
◎
Message:
</dt>
	<dd>
［
応用に渡される前に全部的に~bufferできる
］までに~sizeが抑えられた~stream。
◎
A message is a stream that is sufficiently small that it can be fully buffered before being passed to the application.＼
</dd>
	<dd>
~WebTransportは、
~messageを~primitiveとして定義しない
— ~transportの視点からは、
~messageは，［
~streamを応用へ渡す前に~streamを全部的に~bufferする
］ことにより模倣できるので。
しかしながら、
この【~streamと~messageの】区別は，重要である
— 類似な~protocolや~APIのうち一部（特に，~WebSocket `RFC6455$r ）は、
~messageを抽象-化の中核として利用するので。
◎
WebTransport does not define messages as a primitive, since from the transport perspective they can be simulated by fully buffering a stream before passing it to the application. However, this distinction is important to highlight since some of the similar protocols and APIs (notably WebSocket [RFC6455]) use messages as a core abstraction.
</dd>

	<dt id="webtransport-server">
~WebTransport~server
（略して，~server）
◎
Server:
</dt>
	<dd>
流入~WebTransport~sessionを受容する応用。
◎
A WebTransport server is an application that accepts incoming WebTransport sessions.＼
</dd>
	<dd>
~WebTransportが多重化された~protocol（~HTTP2や~HTTP3など）越しに~serveされる事例では、
“~WebTransport~server” は
— 所与の［
~TCP／~UDP
］~socketを~listenしている応用ではなく —
特定の多重化された端点~用の~handler
（例：特定の~HTTP資源を取扱っている応用）
を指す。
◎
In cases when WebTransport is served over a multiplexed protocol (such as HTTP/2 or HTTP/3), "WebTransport server" refers to a handler for a specific multiplexed endpoint (e.g. an application handling specific HTTP resource), rather than the application listening on a given TCP or UDP socket.
</dd>

	<dt id="webtransport-client">
~WebTransport~client
（略して，~client）
◎
Client:
</dt>
	<dd>
~transport~sessionを起動する応用。
◎
A WebTransport client is an application that initiates the transport session＼
</dd>
	<dd>
~clientは、
~securityに関して拘束された文脈~内で走っていることもある
— 一例として、
~browserの内側で走っている~JS応用。
◎
and may be running in a constrained security context, for instance, a JavaScript application running inside a browser.
</dd>

	<dt id="webtransport-ua">
~WebTransport~UA
（略して，~UA）
◎
User agent:
</dt>
	<dd>
［
~host~network~stackへの~accessが制約されない~software~system
］であって，［
~clientに利するために，~transportを作成できる
］もの。
◎
A WebTransport user agent is a software system that has an unrestricted access to the host network stack and can create transports on behalf of the client.
</dd>
</dl>

		</section>
	</section>
	<section id="common-requirements">
<h2 title="Common Transport Requirements">2. 共通な~transport要件</h2>

<p>
~clientは信用-済みとは限らないため，
~Web~security~modelにより拘束される必要があるので、
~WebTransportは，利用される どの特定の~protocolに対しても ある種の要件を課す。
◎
Since clients are not necessarily trusted and have to be constrained by the Web security model, WebTransport imposes certain requirements on any specific protocol used.
</p>

<p>
すべての~WebTransport~protocolは：
◎
↓</p>
<ul>
	<li>
~TLS `RFC8446$r または ~TLSと意味論的に等価な~security~protocol
（一例として, ~DTLS `RFC9147$r ）
を利用しなければ`ナラナイ^2119。
それらの~protocolは、
旧来の~systemとの後方-互換性を目指す場合を除き，
~TLS~version 1.3 以上を利用するベキである。
◎
All WebTransport protocols MUST use TLS [RFC8446] or a semantically equivalent security protocol (for instance, DTLS [RFC9147]). The protocols SHOULD use TLS version 1.3 or later, unless they aim for backwards compatibility with legacy systems.
</li>
	<li>
［
~serverからの明示的な同意を得して，それを保守する
］下で~dataを送信するよう，~UAに要求しなければ`ナラナイ^2119。
接続~指向な~protocol（~TCPや~QUICなど）用には、
接続を確立して，それを生きたまま保つための仕組みで足りる。
`RFC7675$r も，この要件を満足している仕組みを成す別の例である。
◎
All WebTransport protocols MUST require the user agent to obtain and maintain explicit consent from the server to send data. For connection-oriented protocols (such as TCP or QUIC), the connection establishment and keep-alive mechanisms suffice. STUN Consent Freshness [RFC7675] is another example of a mechanism satisfying this requirement.
</li>
	<li>
~clientが~dataを送信する~rateを制限しなければ`ナラナイ^2119。
これは~feedbackに基づく輻輳~制御の仕組み
（ `RFC5681$r や `RFC9002$r など）
を介して成遂げられる`ベキ^2119である。
◎
All WebTransport protocols MUST limit the rate at which the client sends data. This SHOULD be accomplished via a feedback-based congestion control mechanism (such as [RFC5681] or [RFC9002]).
</li>
	<li>
同じ~client↔~server間で複数の~sessionを同時に確立することを~supportしなければ`ナラナイ^2119。
◎
All WebTransport protocols MUST support simultaneously establishing multiple sessions between the same client and server.
</li>
	<li>
~WebTransport~serverではない~network端点へ~clientが~transport~sessionを確立することを防止しなければ`ナラナイ^2119。
◎
All WebTransport protocols MUST prevent clients from establishing transport sessions to network endpoints that are not WebTransport servers.
</li>
	<li>
~UA用に，~clientの生成元† `RFC6454$r を~serverへ指示する仕方を供さなければ`ナラナイ^2119。
【† ~browser~UAにおいては、~clientが走っている`環境＠~WAPI#environment$の`生成元＠~WAPI#concept-settings-object-origin$】
◎
All WebTransport protocols MUST provide a way for the user agent to indicate the origin [RFC6454] of the client to the server.
</li>
	<li>
~server端点の所在を~URI `RFC3986$r を利用して述べる仕方を供さなければ`ナラナイ^2119。
これは、
資源を~URIとして表現する様々な~Web~platform特能
— ~CSP `CSP$r など —
との統合を可能化する。
◎
All WebTransport protocols MUST provide a way for a server endpoint location to be described using a URI [RFC3986]. This enables integration with various Web platform features that represent resources as URIs, such as Content Security Policy [CSP].
</li>
</ul>

	</section>
	<section id="session-establishment">
<h2 title="Session Establishment">3. ~sessionの確立</h2>

<p>
~WebTransport~sessionの確立は、
非同期的な処理nである。
~clientの視点からは、
~sessionは，［
~serverが供された生成元と~URIを伴う~sessionを受容する用意がある
］ことが確認されたとき<em>準備済み</em>と見なされる。
~WebTransport~protocolは、
~sessionが準備済みになる前に~dataを送信することを~clientに許容しても`ヨイ^2119
— しかしながら、
~clientから明示的に指示されない限り，
再現~攻撃（ `replay attack^en ）に対し安全でない仕組みを利用しては`ナラナイ^2119。
◎
WebTransport session establishment is an asynchronous process. A session is considered ready from the client's perspective when the server has confirmed that it is willing to accept the session with the provided origin and URI. WebTransport protocols MAY allow clients to send data before the session is ready; however, they MUST NOT use mechanisms that are unsafe against replay attacks without an explicit indication from the client.
</p>

	</section>
	<section id="transport-features">
<h2 title="Transport Features">4. ~transport特能</h2>

<p>
すべての~transport~protocolは、
各~transport~protocolが交換-可能になるよう，
次を供さなければ`ナラナイ^2119
⇒＃
~datagram,
一方向~stream,
双方向~stream
◎
All transport protocols MUST provide datagrams, unidirectional and bidirectional streams in order to make the transport protocols interchangeable.
</p>

		<section id="features-session">
<h3 title="Session-Wide Features">4.1. ~session全般な特能</h3>

<p>
~WebTransport~protocolは、
~sessionに対し，次に挙げる演算を供さなければ`ナラナイ^2119【！SHALL】：
◎
Any WebTransport protocol SHALL provide the following operations on the session:
</p>
<dl>
	<dt id="establish-a-session">
~sessionを確立する
◎
establish a session
</dt>
	<dd>
要請-者の~URI `RFC3986$r を与える下で，
新たな~WebTransport~sessionを作成する。
~WebTransport~sessionが~browser~clientから来ている場合には、
生成元 `RFC6454$r も与えなければ`ナラナイ^2119
— 他の場合、
生成元は`任意選択^2119である。
◎
Create a new WebTransport session given a URI [RFC3986] of the requester. An origin [RFC6454] MUST be given if the WebTransport session is coming from a browser client; otherwise, it is OPTIONAL.
</dd>

	<dt id="terminate-a-session">
~sessionを終了する
◎
terminate a session
</dt>
	<dd>
~sessionを終了する
— ( 無符号な 32 ~bitの~error~code, ~error事由を与える 1024 ~byte以下の文字列 )
を相手の端点へ通信する。
~sessionが終了されて以降、
そこで交換される応用~dataは無くなる。
［
~error~code／文字列
］は、
省略可能であり，既定の値は［
0 ／ 空~文字列
］とする。
~error~codeと文字列の送達は、
最善な労に基づいてもヨイ。
◎
Terminate the session while communicating to the peer an unsigned 32-bit error code and an error reason string of at most 1024 bytes. As soon as the session is terminated, no further application data will be exchanged on it. The error code and string are optional; the default values are 0 and "". The delivery of the error code and string MAY be best-effort.
</dd>
</dl>

<p>
~WebTransport~protocolは、
次に挙げる~eventを供さなければ`ナラナイ^2119【！SHALL】：
◎
Any WebTransport protocol SHALL provide the following events:
</p>

<dl>
	<dt id="session-terminated">
~sessionは終了された
◎
session terminated event
</dt>
	<dd>
当の~WebTransport~sessionは、［
相手の端点／局所~networking~stack
］により終了されたことを指示する
— 以降，当の~session上では利用者~data【応用~data】を交換し得なくなる。
相手の端点が上の “`~sessionを終了する＠#terminate-a-session$” 演算を遂行した結果として，
~sessionが終了された場合、
対応する ( ~error~code, ~error文字列 ) が供され得る。
◎
Indicates that the WebTransport session has been terminated, either by the peer or by the local networking stack, and no user data can be exchanged on it any further. If the session has been terminated as a result of the peer performing the "terminate a session" operation above, a corresponding error code and an error string can be provided.
</dd>
</dl>

		</section>
		<section id="features-datagrams">
<h3 title="Datagrams">4.2. ~datagram</h3>

<p>
~datagramは、
~sizeが（一般には経路~MTUに）制限された~byte列であり，
【~datagramたちが】`依拠-可能$に伝送されることは期待されない。
~WebTransport~datagramの一般な目標は、
挙動において~UDPと類似する一方で，
`§ 共通な~transport要件＠#common-requirements$
にて表出した要件の~subjectになることである。
◎
A datagram is a sequence of bytes that is limited in size (generally to the path MTU) and is not expected to be transmitted reliably. The general goal for WebTransport datagrams is to be similar in behavior to UDP while being subject to common requirements expressed in Section 2.
</p>

<p>
~WebTransport送信器には、
~datagramを伝送し直すことは期待されない
— 自身が下層の~protocolとして［
~TCPその他の`依拠-可能$な送達しか供せないもの
］を利用している場合には，そうする結果になろうが。
~WebTransport~datagramは、
~flow制御されることは期待されない
— それは、［
受信器は，応用が十分~速く消費しなかった~datagramたちを落とすかもしれない
］ことを意味する。
◎
A WebTransport sender is not expected to retransmit datagrams, though it may end up doing so if it is using TCP or some other underlying protocol that only provides reliable delivery. WebTransport datagrams are not expected to be flow controlled, meaning that the receiver might drop datagrams if the application is not consuming them fast enough.
</p>

<p>
応用には、
自身が送信できる最大な~datagram~sizeが供されなければ`ナラナイ^2119。
この~sizeは、
経路~MTUの発見を遂行した結果から導出される`ベキ^2119である。
◎
The application MUST be provided with the maximum datagram size that it can send. The size SHOULD be derived from the result of performing path MTU discovery.
</p>

<p>
~WebTransport~modelにおいては、［
すべての流出~datagram／
すべての流入~datagram
］は，
~sizeに~~上限がある ある~queue %~queue の中へ配置される
（~network~interface~card~queueと類似な）。
◎
In the WebTransport model, all of the outgoing and incoming datagrams are placed into a size-bound queue (similar to a network interface card queue).
</p>

<p>
~WebTransport~protocolは、
~sessionに対し，次に挙げる演算を供さなければ`ナラナイ^2119【！SHALL】：
◎
Any WebTransport protocol SHALL provide the following operations on the session:
</p>

<dl>
	<dt id="send-a-datagram">
~datagramを送信する
◎
send a datagram
</dt>
	<dd>
所与の~datagram %~datagram を %~queue に~enqueueする
— %~datagram は、
相手の端点へ送信されることになる。
%~queue が満杯な場合、
%~datagram は落とされる結果になり得る。
◎
Enqueues a datagram to be sent to the peer. This can potentially result in the datagram being dropped if the queue is full.
</dd>

	<dt id="receive-a-datagram">
~datagramを受信する
◎
receive a datagram
</dt>
	<dd>
可用なら【 %~queue は空でないなら】，
%~queue から流入~datagramを~dequeueして返す。
◎
Dequeues an incoming datagram, if one is available.
</dd>

	<dt id="get-maxiumum-datagram-size">
最大~datagram~sizeを取得する
◎
get maxiumum datagram size
</dt>
	<dd>
~WebTransport~sessionが送信-可能になるものと期待される最~大な~datagram~sizeを返す。
◎
Returns the largest size of the datagram that a WebTransport session is expected to be able to send.
</dd>
</dl>

		</section>
		<section id="features-streams">
<h3 title="Streams">4.3. ~stream</h3>

<p>
一方向~stream
（ `unidirectional stream^en ）は、
ある一方通行な［
`依拠-可能$な順序どおりな~byteたちが成す~stream
］であり、
その~dataを送信できる端点は，その起動元に限られる。
双方向~stream
（ `bidirectional stream^en ）は、
両~端点にも~dataを送信することを許容する
— それは、
概念的には， 2 つの一方向~streamが成す~pairとして表現し得る。
◎
A unidirectional stream is a one-way reliable in-order stream of bytes where the initiator is the only endpoint that can send data. A bidirectional stream allows both endpoints to send data and can be conceptually represented as a pair of unidirectional streams.
</p>

<p>
~streamは、
一般に，~QUIC~streamの意味論と状態~機械（ `QUIC$r【！`RFC9000$r】 § 2, § 3 ）に従うことが期待される。
<span class="issue">
課題：~streamの状態~機械について，明示的に述べる。
</span>
◎
The streams are in general expected to follow the semantics and the state machine of QUIC streams ([RFC9000], Sections 2 and 3). TODO: describe the stream state machine explicitly.
</p>

<p>
~WebTransport~streamは、
`~reset$され得る。
それは、
当の端点は，当の~streamに関係する~dataを［
送信する／受信する
］ことに関心を失ったことを指示する。
その事例では、
送信器には，［
当の~streamに対しすでに送信した~dataがあっても，それを伝送し直さない
］ことが期待される。
◎
A WebTransport stream can be reset, indicating that the endpoint is not interested in either sending or receiving any data related to the stream. In that case, the sender is expected to not retransmit any data that was already sent on that stream.
</p>

<p>
~streamは、
~messageとして利用できるまでに~sizeが抑えられる`ベキ^2119である。
◎
Streams SHOULD be sufficiently lightweight that they can be used as messages.
</p>

<p id="is-flow-controlled">
~stream上に送信される~dataは、
当の~transport~protocolにより~flow制御される。
加えて，新たな~streamの作成も~flow制御される。
端点が~openできる~streamの個数は、［
相手の端点が，もっと~streamを作成することを明示的に許容する
］までは制限され得る。
~clientの視点からは、
これは，流入~streamたちが成す［
~sizeに~~上限がある~queue
］として呈示される。
◎
Data sent on a stream is flow controlled by the transport protocol. In addition to flow controlling stream data, the creation of new streams is flow controlled as well: an endpoint may only open a limited number of streams until the peer explicitly allows creating more streams. From the perspective of the client, this is presented as a size-bounded queue of incoming streams.
</p>

<p>
~WebTransport~protocolは、
~sessionに対し，次に挙げる演算を供さなければ`ナラナイ^2119【！SHALL】：
◎
Any WebTransport protocol SHALL provide the following operations on the session:
</p>
<dl>
	<dt id="create-a-unidirectional-stream">
一方向~streamを作成する
◎
create a unidirectional stream
</dt>
	<dd>
流出~一方向~streamを作成する
— この演算の完了は、
下層の~protocolの~flow制御により許容されるまで阻まれ得る。
◎
Creates an outgoing unidirectional stream; this operation may block until the flow control of the underlying protocol allows for it to be completed.
</dd>

	<dt id="create-a-bidirectional-stream">
双方向~streamを作成する
◎
create a bidirectional stream
</dt>
	<dd>
流出~双方向~streamを作成する
— この演算の完了は、
下層の~protocolの~flow制御により許容されるまで阻まれ得る。
◎
Creates an outgoing bidirectional stream; this operation may block until the flow control of the underlying protocol allows for it to be completed.
</dd>

	<dt id="receive-a-unidirectional-stream">
一方向~streamを受信する
◎
receive a unidirectional stream
</dt>
	<dd>
流入~一方向~streamたちが成す~queueから，可用な ある~streamを除去する。
◎
Removes a stream from the queue of incoming unidirectional streams, if one is available.
</dd>

	<dt id="receive-a-bidirectional-stream">
双方向~streamを受信する
◎
receive a bidirectional stream
</dt>
	<dd>
流入~一方向【双方向？】~streamたちが成す~queueから，可用な ある~streamを除去する。
◎
Removes a stream from the queue of incoming unidirectional streams, if one is available.
</dd>
</dl>

<p>
~WebTransport~protocolは、
個々の~streamに対し，次に挙げる演算を供さなければ`ナラナイ^2119【！SHALL】：
◎
Any WebTransport protocol SHALL provide the following operations on an individual stream:
</p>

<dl>
	<dt id="send-bytes">
~byte列を送信する
◎
send bytes
</dt>
	<dd>
~byte列を~streamの送信-~bufferの中へ追加する。
送信器は、
`FIN^i も指示できる
— それは、
当の~stream上には送信される新たな~dataは無い事実を通達する。
この演算は、
流入~一方向~stream用には適用-可能でない。
◎
Add bytes into the stream send buffer. The sender can also indicate a FIN, signalling the fact that no new data will be send on the stream. Not applicable for incoming unidirectional streams.
</dd>

	<dt id="receive-bytes">
~byte列を受信する
◎
receive bytes
</dt>
	<dd>
~stream受信-~bufferから~byte列を除去する。
~stream~dataと一緒に `FIN^i も受信され得る。
この演算は、
流出~一方向~streamには適用-可能でない。
◎
Removes bytes from the stream receive buffer. FIN can be received together with the stream data. Not applicable for outgoing unidirectional streams.
</dd>

	<dt id="abort-send-side">
送信-側を中止する
◎
abort send side
</dt>
	<dd>
~streamを成す書込n側を中止したことを指示する通達を相手の端点へ送信する。
送信-~bufferを破棄する
— アリな場合【何が？】、
現在~待機中な［
伝送される／伝送し直される
］~dataは無い。
無符号な 8 ~bitの~error~codeが
相手の端点への通達を成す一部として給され得る
— 省略された場合、
~error~codeは 0 であるものと予め見做される。
◎
Sends a signal to the peer that the write side of the stream has been aborted. Discards the send buffer; if possible, no currently outstanding data is transmitted or retransmitted. An unsigned 8-bit error code can be supplied as a part of the signal to the peer; if omitted, the error code is presumed to be 0.
</dd>

	<dt id="abort-receive-side">
受信-側を中止する
◎
abort receive side
</dt>
	<dd>
~streamを成す読取n側を中止したことを指示する通達を相手の端点へ送信する。
受信-~bufferを破棄する
— 相手の端点には、
概して，それに呼応して対応する送信-側を中止することが期待される。
無符号な 8 ~bitの~error~codeが相手の端点への通達を成す一部として給され得る。
◎
Sends a signal to the peer that the read side of the stream has been aborted. Discards the receive buffer; the peer is typically expected to abort the corresponding send side in response. An unsigned 8-bit error code can be supplied as a part of the signal to the peer.
</dd>
</dl>

<p>
~WebTransport~protocolは、
個々の~stream用に，次に挙げる~eventを供さなければ`ナラナイ^2119【！SHALL】：
◎
Any WebTransport protocol SHALL provide the following events for an individual stream:
</p>

<dl>
	<dt id="send-side-aborted">
送信-側は中止された
◎
send side aborted
</dt>
	<dd>
相手の端点は、
当の~streamを成す受信-側を中止したことを指示する。
相手の端点から無符号な 8 ~bitの~error~codeが可用になることもある。
◎
Indicates that the peer has aborted the corresponding receive side of the stream. An unsigned 8-bit error code from the peer may be available.
</dd>

	<dt id="receive-side-aborted">
受信-側は中止された
◎
receive side aborted
</dt>
	<dd>
相手の端点は、
当の~streamを成す送信-側を中止したことを指示する。
相手の端点から無符号な 8 ~bitの~error~codeが可用になることもある。
◎
Indicates that the peer has aborted the corresponding send side of the stream. An unsigned 8-bit error code from the peer may be available.
</dd>

	<dt id="all data committed">
すべての~dataは~commitされた
◎
all data committed
</dt>
	<dd>
~stream上の流出~dataすべては、
終了~stream指示も含めて，［
送信-側を中止しても，送達されている~dataには効果を及ぼさなくなる状態にある
］ことを指示する。
◎
Indicates that all of the outgoing data on the stream, including the end stream indication, is in the state where aborting the send side would have no further effect on any data being delivered.
</dd>
	<dd>
~HTTP2 の様な~protocol用には、
~stream~dataは，伝送~用に（~kernelの様な）別の~componentへ渡されるかもしれない。
そのような~componentへ~dataが渡されたなら、
接続~全体も中止しない限り，~stream~dataの送信を中止することはアリでないかもしれない。
これらの~protocol用には、
すでに他の~componentへ渡された~dataは~commitされたものと見なされる。
◎
For protocols, like HTTP/2, stream data might be passed to another component (like a kernel) for transmission. Once data is passed to that component it might not be possible to abort the sending of stream data without also aborting the entire connection. For these protocols, data is considered committed once it passes to the other component.
</dd>
	<dd>
~HTTP3の様な，もっと統合された~stackを利用する~protocolは、
~dataを更に処理しないよう撤回-可能かもしれない。
これらの~protocol用には、
~stream上への送信は，すべての~dataが相手の端点により［
受信され, 認知される
］
— ~QUICにおける `Data Recvd^i 状態に対応しているとき —
までの，いつでも中止されるかもしれない。
`QUIC$r `3.1＠~RFCx/rfc9000#section-3.1§ を見よ。
◎
A protocol, like HTTP/3, that uses a more integrated stack might be able to retract data further into the process. For these protocols, sending on a stream might be aborted at any time until all data has been received and acknowledged by the peer, corresponding to the "Data Recvd" state in QUIC; see Section 3.1 of [QUIC].
</dd>
</dl>

		</section>
	</section>
	<section id="transport-properties">
<h2 title="Transport Properties">5. ~transport~prop</h2>

<p>
~WebTransportは、
複数の~protocolが交換-可能に利用されるのを許容するため，それらに共通な意味論を定義する。
それでも、
各~protocolの処理能~propは，応用から~queryすることが求まれるほどに大きく異なり得るが。
◎
WebTransport defines common semantics for multiple protocols to allow them to be used interchangeably. Nevertheless, those protocols still have substantially different performance properties that an application may want to query.
</p>

<p>
最も注目すべき~propは、
`不依拠-可能$な~data送達~用の~supportである。
~protocolは、
~AND↓ を満たすならば，`不依拠-可能$な送達を~supportするものと定義される：
◎
The most notable property is support for unreliable data delivery. The protocol is defined to support unreliable delivery if:
</p>
<ul>
	<li>
~streamを`~reset$した場合、
喪失した~stream~dataは，もはや伝送し直されなくなる。
◎
Resetting a stream results in the lost stream data no longer being retransmitted, and
</li>
	<li>
~datagramは、
決して伝送し直されない。
◎
The datagrams are never retransmitted.
</li>
</ul>

<p>
別の重要な~propは、
~pool法の~supportである。
それは、
次のようにすることを意味する
⇒
複数の~transport~sessionが同じ［
~transport層を成す接続
］を共有し得る
— したがって，輻輳~制御器や他の文脈を共有し得る。
◎
Another important property is pooling support. Pooling means that multiple transport sessions may end up sharing the same transport layer connection, and thus share a congestion controller and other contexts.
</p>

	</section>
	<section id="security-considerations">
<h2 title="Security Considerations">6. ~securityの考慮点</h2>

<p>
信用-済みでない~clientに［
~networkへの適度に低-~levelな~access
］を供することには、
~riskがついて来る。
この文書は、
`§ 共通な~transport要件＠#common-requirements$
にて述べた要件を課すことにより，それらの~riskを軽減する。
◎
Providing untrusted clients with a reasonably low-level access to the network comes with risks. This document mitigates those risks by imposing a set of common requirements described in Section 2.
</p>

<p>
~WebTransportは、
それを実装しているすべての~protocol用に，~TLSの利用を義務付ける。
これには二つの目的がある。
一つは、
~transportを~networkから保護すること
— 潜在的な攻撃者,
~middleboxによる硬直化
【新たに標準~化された拡張に対し誤動作する問題（`参考＠https://en.wikipedia.org/wiki/Protocol_ossification$）】
どちらからも。
もう一つは、
~network要素を潜在的な混同~攻撃
— `RFC6455$r `§ 10.3＠~RFC6455#section-10.3$ にて論じられたものなど —
から保護すること。
◎
WebTransport mandates the use of TLS for all protocols implementing it. This has a dual purpose. On one hand, it protects the transport from the network, including both potential attackers and ossification by middleboxes. On the other hand, it protects the network elements from potential confusion attacks such as the one discussed in Section 10.3 of [RFC6455].
</p>

<p>
懸念になり得るものとして、
接続~errorが挙げられる
— それは、
~transportが作成され得ないときであっても，［
通常は~access可能にならない~network~addressを攻撃者が走査する
］ことを許容するに十分な情報を露呈する。
このことから、
信用-済みでない~clientを走らす~UAは、
~serverが~WebTransport端点であることが確認されるまでは，
詳細な~error情報を供しては`ナラナイ^2119。
例えば、
~network~addressのうち［
到達-可能でないもの,
到達-可能であるが~WebTransport~serverではないもの
］を~clientが判別-可能になってはならない。
◎
One potential concern is that even when a transport cannot be created, the connection error would reveal enough information to allow an attacker to scan the network addresses that would normally be inaccessible. Because of that, the user agent that runs untrusted clients MUST NOT provide any detailed error information until the server has confirmed that it is a WebTransport endpoint. For example, the client must not be able to distinguish between a network address that is unreachable and one that is reachable but is not a WebTransport server.
</p>

<p>
~WebTransportは、
~HTTPに基づく認証を伝統的な手段においては~supportしない。
それは、
~HTTPに基づくとは限らないので，
~HTTP~cookieや~HTTP認証を~supportしない。
~WebTransportは，~TLSを要求するので、
個々の~transport~protocolは，~TLSに基づく認証~能力
— ~client証明書など —
を公開しても`ヨイ^2119。
◎
WebTransport does not support any traditional means of HTTP-based authentication. It is not necessarily based on HTTP, and hence does not support HTTP cookies or HTTP authentication. Since it requires TLS, individual transport protocols MAY expose TLS-based authentication capabilities such as client certificates.
</p>

	</section>
	<section id="iana-considerations">
<h2 title="IANA Considerations">7. ~IANA考慮点</h2>

<p>
この文書には、
~IANAに対する要請は無い。
◎
There are no requests to IANA in this document.
</p>

	</section>
</main></div>