Internet Engineering Task Force (IETF) B. Trammell, Ed.
Request for Comments: 9622 Google Switzerland GmbH
Category: Standards Track M. Welzl, Ed.
ISSN: 2070-1721 University of Oslo
R. Enghardt
Netflix
G. Fairhurst
University of Aberdeen
M. Kühlewind
Ericsson
C. S. Perkins
University of Glasgow
P.S. Tiesel
SAP SE
T. Pauly
Apple Inc.
January 2025
This document describes an abstract Application Programming Interface (API) to the transport layer that enables the selection of transport protocols and network paths dynamically at runtime. This API enables faster deployment of new protocols and protocol features without requiring changes to the applications. The specified API follows the Transport Services Architecture by providing asynchronous, atomic transmission of Messages. It is intended to replace the BSD Socket API as the common interface to the transport layer, in an environment where endpoints could select from multiple network paths and potential transport protocols.
このドキュメントでは、輸送プロトコルとネットワークパスの選択を実行時に動的に可能にする輸送層への抽象アプリケーションプログラミングインターフェイス（API）について説明します。このAPIは、アプリケーションの変更を必要とせずに、新しいプロトコルとプロトコル機能をより速く展開できるようにします。指定されたAPIは、メッセージの非同期、原子伝達を提供することにより、トランスポートサービスアーキテクチャに従います。エンドポイントが複数のネットワークパスと潜在的な輸送プロトコルから選択できる環境で、輸送層への共通インターフェイスとしてBSDソケットAPIを置き換えることを目的としています。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9622.
このドキュメントの現在のステータス、任意のERRATA、およびそれに関するフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9622で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Terminology and Notation
1.2. Specification of Requirements
2. Overview of the API Design
3. API Summary
3.1. Usage Examples
3.1.1. Server Example
3.1.2. Client Example
3.1.3. Peer Example
4. Transport Properties
4.1. Transport Property Names
4.2. Transport Property Types
5. Scope of the API Definition
6. Preestablishment Phase
6.1. Specifying Endpoints
6.1.1. Using Multicast Endpoints
6.1.2. Constraining Interfaces for Endpoints
6.1.3. Protocol-Specific Endpoints
6.1.4. Endpoint Examples
6.1.5. Multicast Examples
6.2. Specifying Transport Properties
6.2.1. Reliable Data Transfer (Connection)
6.2.2. Preservation of Message Boundaries
6.2.3. Configure Per-Message Reliability
6.2.4. Preservation of Data Ordering
6.2.5. Use 0-RTT Session Establishment with a Safely
Replayable Message
6.2.6. Multistream Connections in a Group
6.2.7. Full Checksum Coverage on Sending
6.2.8. Full Checksum Coverage on Receiving
6.2.9. Congestion Control
6.2.10. Keep-Alive Packets
6.2.11. Interface Instance or Type
6.2.12. Provisioning Domain Instance or Type
6.2.13. Use Temporary Local Address
6.2.14. Multipath Transport
6.2.15. Advertisement of Alternative Addresses
6.2.16. Direction of Communication
6.2.17. Notification of ICMP Soft Error Message Arrival
6.2.18. Initiating Side Is Not the First to Write
6.3. Specifying Security Parameters and Callbacks
6.3.1. Allowed Security Protocols
6.3.2. Certificate Bundles
6.3.3. Pinned Server Certificate
6.3.4. Application-Layer Protocol Negotiation
6.3.5. Groups, Ciphersuites, and Signature Algorithms
6.3.6. Session Cache Options
6.3.7. Pre-Shared Key
6.3.8. Connection Establishment Callbacks
7. Establishing Connections
7.1. Active Open: Initiate
7.2. Passive Open: Listen
7.3. Peer-to-Peer Establishment: Rendezvous
7.4. Connection Groups
7.5. Adding and Removing Endpoints on a Connection
8. Managing Connections
8.1. Generic Connection Properties
8.1.1. Required Minimum Corruption Protection Coverage for
Receiving
8.1.2. Connection Priority
8.1.3. Timeout for Aborting Connection
8.1.4. Timeout for Keep-Alive Packets
8.1.5. Connection Group Transmission Scheduler
8.1.6. Capacity Profile
8.1.7. Policy for Using Multipath Transports
8.1.8. Bounds on Send or Receive Rate
8.1.9. Group Connection Limit
8.1.10. Isolate Session
8.1.11. Read-Only Connection Properties
8.2. TCP-Specific Properties: User Timeout Option (UTO)
8.2.1. Advertised User Timeout
8.2.2. User Timeout Enabled
8.2.3. Timeout Changeable
8.3. Connection Lifecycle Events
8.3.1. Soft Errors
8.3.2. Path Change
9. Data Transfer
9.1. Messages and Framers
9.1.1. Message Contexts
9.1.2. Message Framers
9.1.3. Message Properties
9.2. Sending Data
9.2.1. Basic Sending
9.2.2. Send Events
9.2.3. Partial Sends
9.2.4. Batching Sends
9.2.5. Send on Active Open: InitiateWithSend
9.2.6. Priority and the Transport Services API
9.3. Receiving Data
9.3.1. Enqueuing Receives
9.3.2. Receive Events
9.3.3. Receive Message Properties
10. Connection Termination
11. Connection State and Ordering of Operations and Events
12. IANA Considerations
13. Privacy and Security Considerations
14. References
14.1. Normative References
14.2. Informative References
Appendix A. Implementation Mapping
A.1. Types
A.2. Events and Errors
A.3. Time Duration
Appendix B. Convenience Functions
B.1. Adding Preference Properties
B.2. Transport Property Profiles
B.2.1. reliable-inorder-stream
B.2.2. reliable-message
B.2.3. unreliable-datagram
Appendix C. Relationship to the Minimal Set of Transport Services
for End Systems
Acknowledgements
Authors' Addresses
This document specifies an abstract Application Programming Interface (API) that describes the interface component of the high-level Transport Services Architecture defined in [RFC9621]. A Transport Services System supports asynchronous, atomic transmission of Messages over transport protocols and network paths dynamically selected at runtime, in environments where an endpoint selects from multiple network paths and potential transport protocols.
このドキュメントは、[RFC9621]で定義されている高レベルの輸送サービスアーキテクチャのインターフェイスコンポーネントを記述する抽象アプリケーションプログラミングインターフェイス（API）を指定します。トランスポートサービスシステムは、エンドポイントが複数のネットワークパスと潜在的なトランスポートプロトコルから選択する環境で、実行時に動的に選択された輸送プロトコルおよびネットワークパスを介した非同期の原子伝送をサポートします。
Applications that adopt this API will benefit from a wide set of transport features that can evolve over time. This protocol-independent API ensures that the system providing the API can optimize its behavior based on the application requirements and network conditions, without requiring changes to the applications. This flexibility enables faster deployment of new features and protocols and can support applications by offering racing and fallback mechanisms, which otherwise need to be separately implemented in each application. Transport Services Implementations are free to take any desired form as long as the API specification in this document is honored; a non-prescriptive guide to implementing a Transport Services System is available (see [RFC9623]).
このAPIを採用するアプリケーションは、時間とともに進化できる幅広い輸送機能の恩恵を受けるでしょう。このプロトコルに依存しないAPIにより、APIを提供するシステムが、アプリケーションの変更を必要とせずに、アプリケーションの要件とネットワーク条件に基づいて動作を最適化できるようになります。この柔軟性により、新機能とプロトコルの迅速な展開が可能になり、レースとフォールバックのメカニズムを提供することでアプリケーションをサポートできます。このドキュメントのAPI仕様が尊重されている限り、トランスポートサービスの実装は、任意のフォームを自由に取得できます。輸送サービスシステムを実装するための非既知のガイドが利用可能です（[RFC9623]を参照）。
The Transport Services System derives specific path and Protocol Selection Properties and supported transport features from the analysis provided in [RFC8095], [RFC8923], and [RFC8922]. The Transport Services API enables an implementation to dynamically choose a transport protocol rather than statically binding applications to a protocol at compile time. The Transport Services API also provides applications with a way to override transport selection and instantiate a specific stack, e.g., to support servers wishing to listen to a specific protocol. However, forcing a choice to use a specific Protocol Stack is discouraged for general use because it can reduce portability.
輸送サービスシステムは、[RFC8095]、[RFC8923]、および[RFC8922]で提供される分析から特定のパスおよびプロトコル選択プロパティとサポートされた輸送機能を導き出します。Transport Services APIを使用すると、コンパイル時にプロトコルに静的に拘束力のあるアプリケーションではなく、トランスポートプロトコルを動的に選択できるようになります。Transport Services APIは、輸送の選択をオーバーライドし、特定のプロトコルをリッスンしたいサーバーをサポートするための特定のスタックをインスタンス化する方法をアプリケーションに提供します。ただし、特定のプロトコルスタックを使用する選択を強制することは、携帯性を低下させる可能性があるため、一般的な使用には阻止されます。
The Transport Services API is described in terms of:
トランスポートサービスAPIは、次の点で説明されています。
* Objects with which an application can interact;
* アプリケーションが相互作用できるオブジェクト。
* Actions the application can perform on these objects;
* これらのオブジェクトでアプリケーションが実行できるアクション。
* Events, which an object can send to an application to be processed asynchronously; and
* オブジェクトがアプリケーションに送信して非同期に処理できるイベント。そして
* Parameters associated with these actions and events.
* これらのアクションとイベントに関連するパラメーター。
The following notations, which can be combined, are used in this document:
組み合わせることができる次の表記は、このドキュメントで使用されています。
* An action that creates an object:
* オブジェクトを作成するアクション：
Object := Action()
* An action that creates an array of objects:
* オブジェクトの配列を作成するアクション：
[]Object := Action()
* An action that is performed on an object:
* オブジェクトで実行されるアクション：
Object.Action()
* An object sends an event:
* オブジェクトはイベントを送信します。
Object -> Event<>
* An action takes a set of parameters; an event contains a set of parameters. Action and event parameters whose names are suffixed with a question mark are optional:
* アクションはパラメーターのセットを取得します。イベントには、パラメーターのセットが含まれています。名前が疑問符で接尾辞にされたアクションとイベントパラメーターはオプションです。
Action(param0, param1?, ...)
Event<param0, param1?, ...>
Objects that are passed as parameters to actions use call-by-value behavior. Actions not associated with an object are actions on the API; they are equivalent to actions on a per-application global context.
アクションへのパラメーターとして渡されるオブジェクトは、by値の動作を使用します。オブジェクトに関連付けられていないアクションは、API上のアクションです。それらは、アプリケーションごとのグローバルコンテキストでのアクションと同等です。
Events are sent to the application or application-supplied code (e.g., Framers; see Section 9.1.2) for processing; the details of event interfaces are specific to the platform or implementation and can be implemented using other forms of asynchronous processing, as idiomatic for the implementing platform.
イベントは、処理のためにアプリケーションまたはアプリケーションサプライコード（例えば、フレーマー、セクション9.1.2を参照）に送信されます。イベントインターフェイスの詳細は、プラットフォームまたは実装に固有のものであり、実装プラットフォームの慣用として、他の形式の非同期処理を使用して実装できます。
We also make use of the following basic types:
また、次の基本タイプも使用します。
Boolean:
Boolean：
Instances take the value true or false.
インスタンスは値をtrueまたはfalseにします。
Integer:
整数：
Instances take integer values.
インスタンスは整数値を取得します。
Numeric:
数値：
Instances take real number values.
インスタンスは実際の値を取得します。
String:
弦：
Instances are represented in UTF-8.
インスタンスはUTF-8で表されます。
IP Address:
IPアドレス：
An IPv4 address [RFC791] or IPv6 address [RFC4291].
IPv4アドレス[RFC791]またはIPv6アドレス[RFC4291]。
Enumeration:
列挙：
A family of types in which each instance takes one of a fixed, predefined set of values specific to a given enumerated type.
各インスタンスが、特定の列挙型に固有の固定された事前定義された値のセットの1つを取得するタイプのファミリー。
Tuple:
タプル：
An ordered grouping of multiple value types, represented as a comma-separated list in parentheses, e.g., (Enumeration, Preference). Instances take a sequence of values, each valid for the corresponding value type.
括弧内のコンマ分離リストとして表される複数の値タイプの順序付けられたグループ、例えば（列挙、好み）。インスタンスは、それぞれ対応する値タイプに有効な一連の値を取ります。
Array:
配列：
Denoted []Type, an instance takes a value for each of zero or more elements in a sequence of the given Type. An array can be of fixed or variable length.
表示された[]タイプ、インスタンスは、指定されたタイプのシーケンスでゼロ以上の要素のそれぞれに対して値を取得します。配列は、固定または可変の長さである場合があります。
Set:
Set:
An unordered grouping of one or more different values of the same type.
同じタイプの1つ以上の異なる値の順序付けられていないグループ。
For guidance on how these abstract concepts can be implemented in languages in accordance with language-specific design patterns and platform features, see Appendix A.
言語固有の設計パターンとプラットフォーム機能に従って、これらの抽象的な概念を言語で実装する方法についてのガイダンスについては、付録Aを参照してください。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The design of the API specified in this document is based on a set of principles, themselves an elaboration on the architectural design principles defined in [RFC9621]. The API defined in this document provides:
このドキュメントで指定されたAPIの設計は、一連の原則に基づいており、それ自体が[RFC9621]で定義されている建築設計原則の詳細です。このドキュメントで定義されているAPIは次のことを提供します。
* A Transport Services System that can offer a variety of transport protocols, independent of the Protocol Stacks that will be used at runtime. To the degree possible, all common features of these Protocol Stacks are made available to the application in a transport-independent way. This enables applications written for a single API to make use of transport protocols in terms of the features they provide.
* 実行時に使用されるプロトコルスタックとは無関係に、さまざまな輸送プロトコルを提供できる輸送サービスシステム。可能な限り、これらのプロトコルスタックのすべての一般的な機能は、輸送に依存しない方法でアプリケーションで利用可能になります。これにより、単一のAPI用に記述されたアプリケーションが、提供する機能の観点からトランスポートプロトコルを利用できるようになります。
* A unified API to datagram and stream-oriented transports, allowing the use of a common API for Connection establishment and closing.
* データグラムとストリーム指向のトランスポートに統一されたAPIがあり、接続の確立と閉鎖に共通のAPIを使用できます。
* Message-orientation, as opposed to stream-orientation, using application-assisted framing and deframing where the underlying transport does not itself provide the required framing.
* メッセージ指向は、ストリーム指向とは対照的に、アプリケーションアシストフレーミングを使用し、基礎となる輸送自体が必要なフレーミングを提供しない場所での解凍を使用します。
* Asynchronous Connection establishment, transmission, and reception. This allows concurrent operations during establishment and event-driven application interactions with the transport layer.
* 非同期接続の確立、送信、および受信。これにより、輸送層との設立およびイベント駆動型のアプリケーションの相互作用中の同時操作が可能になります。
* Selection between alternate network paths, using additional information about the networks over which a Connection can operate (e.g., Provisioning Domain (PvD) information [RFC7556]) where available.
* 使用可能な場合、接続が動作できるネットワークに関する追加情報（例：プロビジョニングドメイン（PVD）情報[RFC7556]）を使用して、代替ネットワークパス間の選択。
* Explicit support for transport-specific features to be applied, when that particular transport is part of a chosen Protocol Stack.
* その特定の輸送が選択されたプロトコルスタックの一部である場合、輸送固有の機能を適用する明示的なサポート。
* Explicit support for security properties as first-order transport features.
* 一次輸送機能としてのセキュリティプロパティの明示的なサポート。
* Explicit support for configuration of cryptographic identities and transport Security Parameters persistent across multiple Connections.
* 暗号化のアイデンティティの構成と、複数の接続にわたって持続する輸送セキュリティパラメーターの明示的なサポート。
* Explicit support for multistreaming and multipath transport protocols, and the grouping of related Connections into Connection Groups through "cloning" of Connections (see Section 7.4). This function allows applications to take full advantage of new transport protocols supporting these features.
* マルチストリーミングおよびマルチパストランスポートプロトコルの明示的なサポート、および接続の「クローニング」を介した関連する接続のグループ化のグループ化（セクション7.4を参照）。この機能により、アプリケーションはこれらの機能をサポートする新しい輸送プロトコルを最大限に活用できます。
An application primarily interacts with this API through two objects: Preconnections and Connections. A Preconnection object (Section 6) represents a set of Properties and constraints on the selection and configuration of paths and protocols to establish a Connection with an Endpoint. A Connection object represents an instance of a transport Protocol Stack on which data can be sent to and/or received from a Remote Endpoint (i.e., a logical connection that, depending on the kind of transport, can be bidirectional or unidirectional, and that can use a stream protocol or a datagram protocol). Connections are presented consistently to the application, irrespective of whether the underlying transport is connectionless or connection oriented. Connections can be created from Preconnections in three ways:
アプリケーションは、主に、事前接続と接続の2つのオブジェクトを介してこのAPIと相互作用します。事前接続オブジェクト（セクション6）は、エンドポイントとの接続を確立するためのパスとプロトコルの選択と構成のプロパティと制約のセットを表します。接続オブジェクトは、リモートエンドポイントからデータを送信および/または受信できるトランスポートプロトコルスタックのインスタンスを表します（つまり、トランスポートの種類に応じて、双方向または単方向であり、それが可能です。ストリームプロトコルまたはデータグラムプロトコルを使用します）。基礎となる輸送がコネクションレスまたは接続指向であるかどうかに関係なく、接続はアプリケーションに一貫して提示されます。接続は、3つの方法で事前接続から作成できます。
* initiating the Preconnection (i.e., creating a Connection from the Preconnection, actively opening, as in a client; see Initiate in Section 7.1),
* 事前接続の開始（つまり、クライアントのように、積極的に開く前接続から接続を作成します。セクション7.1の開始を参照）、
* listening on the Preconnection (i.e., creating a Listener based on the Preconnection, passively opening, as in a server; see Listen in Section 7.2), or
* 事前接続で聞く（つまり、サーバーのように受動的に開く前のリスナーを作成します。セクション7.2でリッスンを参照）、または
* a rendezvous for the Preconnection (i.e., peer-to-peer Connection establishment; see Rendezvous in Section 7.3).
* 事前接続のランデブー（つまり、ピアツーピア接続確立。セクション7.3のランデブーを参照）。
Once a Connection is established, data can be sent and received on it in the form of Messages. The API supports the preservation of Message boundaries via both explicit Protocol Stack support and application support through a Message Framer that finds Message boundaries in a stream. Messages are received asynchronously through event handlers registered by the application. Errors and other notifications also happen asynchronously on the Connection. It is not necessary for an application to handle all events; some events can have implementation-specific default handlers.
接続が確立されると、データを送信してメッセージの形で受信できます。APIは、明示的なプロトコルスタックサポートとアプリケーションサポートの両方を介して、ストリーム内のメッセージ境界を見つけるメッセージフレーマーを介して、メッセージ境界の保存をサポートします。メッセージは、アプリケーションによって登録されたイベントハンドラーを介して非同期に受信されます。エラーやその他の通知も接続で非同期に発生します。アプリケーションがすべてのイベントを処理する必要はありません。一部のイベントでは、実装固有のデフォルトハンドラーを持つことができます。
The application SHOULD NOT assume that ignoring events (e.g., errors) is always safe.
アプリケーションは、イベント（例えば、エラー）を無視することが常に安全であると想定してはなりません。
The following usage examples illustrate how an application might use the Transport Services API to act as:
次の使用例は、アプリケーションがTransport Services APIを使用してどのように機能するかを示しています。
* a server, by listening for incoming Connections, receiving requests, and sending responses; see Section 3.1.1.
* 着信接続をリッスン、リクエストの受信、および応答の送信により、サーバー。セクション3.1.1を参照してください。
* a client, by connecting to a Remote Endpoint using Initiate, sending requests, and receiving responses; see Section 3.1.2.
* クライアントは、開始を使用してリモートエンドポイントに接続し、リクエストを送信し、応答を受信します。セクション3.1.2を参照してください。
* a peer, by connecting to a Remote Endpoint using Rendezvous while simultaneously waiting for incoming Connections, sending Messages, and receiving Messages; see Section 3.1.3.
* ピア、ランデブーを使用してリモートエンドポイントに接続し、同時に接続を入力し、メッセージを送信し、メッセージを受信するのを待っています。セクション3.1.3を参照してください。
The examples in this section presume that a transport protocol is available between the Local and Remote Endpoints and that this protocol provides reliable data transfer, preservation of data ordering, and preservation of Message boundaries. In this case, the application can choose to receive only complete Messages.
このセクションの例は、ローカルエンドポイントとリモートエンドポイント間でトランスポートプロトコルが利用可能であり、このプロトコルが信頼できるデータ転送、データ順序の保存、およびメッセージ境界の保存を提供すると推定されています。この場合、アプリケーションは完全なメッセージのみを受信することを選択できます。
If none of the available transport protocols provide preservation of Message boundaries, but there is a transport protocol that provides a reliable ordered byte-stream, an application could receive this byte-stream as partial Messages and transform it into application-layer Messages. Alternatively, an application might provide a Message Framer, which can transform a sequence of Messages into a byte-stream and vice versa (Section 9.1.2).
利用可能なトランスポートプロトコルのいずれもメッセージ境界の保存を提供しないが、信頼できる順序付けられたバイトストリームを提供するトランスポートプロトコルがある場合、アプリケーションはこのバイトストリームを部分的なメッセージとして受信し、アプリケーション層メッセージに変換することができます。あるいは、アプリケーションがメッセージフレーマーを提供する場合があり、メッセージのシーケンスをバイトストリームに変換し、その逆にも同様です（セクション9.1.2）。
This is an example of how an application might listen for incoming Connections using the Transport Services API, receive a request, and send a response.
これは、Transport Services APIを使用して、アプリケーションが着信接続を聴き、リクエストを受け取り、応答を送信する方法の例です。
LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithInterface("any")
LocalSpecifier.WithService("https")
TransportProperties := NewTransportProperties()
TransportProperties.Require(preserveMsgBoundaries)
// Reliable data transfer and preserve order are required by default
SecurityParameters := NewSecurityParameters()
SecurityParameters.Set(serverCertificate, myCertificate)
// Specifying a Remote Endpoint is optional when using Listen
Preconnection := NewPreconnection(LocalSpecifier,
TransportProperties,
SecurityParameters)
Listener := Preconnection.Listen()
Listener -> ConnectionReceived<Connection>
// Only receive complete messages in a Conn.Received handler
Connection.Receive()
Connection -> Received<messageDataRequest, messageContext>
//---- Receive event handler begin ----
Connection.Send(messageDataResponse)
Connection.Close()
// Stop listening for incoming Connections
// (this example supports only one Connection)
Listener.Stop()
//---- Receive event handler end ----
This is an example of how an application might open two Connections to a remote application using the Transport Services API, send a request, and receive a response for each of the two Connections. The code designated with comments as "Ready event handler" could, for example, be implemented as a callback function. This function would receive the Connection that it expects to operate on ("Connection" and "Connection2" in the example) handed over using the variable name "C".
これは、アプリケーションがTransport Services APIを使用してリモートアプリケーションへの2つの接続を開き、リクエストを送信し、2つの接続のそれぞれの応答を受信する方法の例です。たとえば、「Ready Event Handler」としてコメントで指定されたコードは、コールバック関数として実装できます。この関数は、変数名「C」を使用して引き渡された（例の「接続」と「接続2」）で動作すると予想される接続を受信します。
RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithHostName("example.com")
RemoteSpecifier.WithService("https")
TransportProperties := NewTransportProperties()
TransportProperties.Require(preserve-msg-boundaries)
// Reliable data transfer and preserve order are required by default
SecurityParameters := NewSecurityParameters()
TrustCallback := NewCallback({
// Verify the identity of the Remote Endpoint and return the result
})
SecurityParameters.SetTrustVerificationCallback(TrustCallback)
// Specifying a Local Endpoint is optional when using Initiate
Preconnection := NewPreconnection(RemoteSpecifier,
TransportProperties,
SecurityParameters)
Connection := Preconnection.Initiate()
Connection2 := Connection.Clone()
Connection -> Ready<>
Connection2 -> Ready<>
//---- Ready event handler for any Connection C begin ----
C.Send(messageDataRequest)
// Only receive complete messages
C.Receive()
//---- Ready event handler for any Connection C end ----
Connection -> Received<messageDataResponse, messageContext>
Connection2 -> Received<messageDataResponse, messageContext>
// Close the Connection in a Receive event handler
Connection.Close()
Connection2.Close()
A Preconnection serves as a template for creating a Connection via initiating, listening, or via rendezvous. Once a Connection has been created, changes made to the Preconnection that was used to create it do not affect this Connection. Preconnections are reusable after being used to create a Connection, whether or not this Connection was closed. Hence, in the above example, it would be correct for the client to initiate a third Connection to the example.com server by continuing as follows:
事前接続は、開始、リスニング、またはランデブーを介して接続を作成するためのテンプレートとして機能します。接続が作成されると、それを作成するために使用された事前接続に変更された変更は、この接続に影響しません。この接続が閉じられているかどうかにかかわらず、接続の作成に使用された後、事前接続は再利用可能です。したがって、上記の例では、次のように継続することにより、クライアントがExample.comサーバーへの3番目の接続を開始することが正しいでしょう。
//.. carry out adjustments to the Preconnection, if desired
Connection3 := Preconnection.Initiate()
This is an example of how an application might establish a Connection with a peer using Rendezvous, send a Message, and receive a Message.
これは、アプリケーションがRendezvousを使用してピアとの接続を確立する方法の例です。メッセージを送信し、メッセージを受信します。
// Configure local candidates: a port on the Local Endpoint
// and via a Session Traversal Utilities for NAT (STUN) server
HostCandidate := NewLocalEndpoint()
HostCandidate.WithPort(9876)
StunCandidate := NewLocalEndpoint()
StunCandidate.WithStunServer(address, port, credentials)
LocalCandidates = [HostCandidate, StunCandidate]
TransportProperties := // ...Configure transport properties
SecurityParameters := // ...Configure security properties
Preconnection := NewPreconnection(LocalCandidates,
[], // No remote candidates yet
TransportProperties,
SecurityParameters)
// Resolve the LocalCandidates. The Preconnection.Resolve()
// call resolves both local and remote candidates; however,
// because the remote candidates have not yet been specified,
// the ResolvedRemote list returned will be empty and is not
// used.
ResolvedLocal, ResolvedRemote = Preconnection.Resolve()
// Application-specific code goes here to send the ResolvedLocal
// list to the peer via some out-of-band signaling channel (e.g.,
// in a SIP message).
...
// Application-specific code goes here to receive RemoteCandidates
// (type []RemoteEndpoint, a list of RemoteEndpoint objects) from
// the peer via the signaling channel.
...
// Add remote candidates and initiate the rendezvous:
Preconnection.AddRemote(RemoteCandidates)
Preconnection.Rendezvous()
Preconnection -> RendezvousDone<Connection>
//---- RendezvousDone event handler begin ----
Connection.Send(messageDataRequest)
Connection.Receive()
//---- RendezvousDone event handler end ----
Connection -> Received<messageDataResponse, messageContext>
// If new Remote Endpoint candidates are received from the
// peer over the signaling channel -- for example, if using
// Trickle Interactive Connectivity Establishment (ICE) --
// then add them to the Connection:
Connection.AddRemote(NewRemoteCandidates)
// On a PathChange event, resolve the Local Endpoint Identifiers to
// see if a new Local Endpoint has become available and, if
// so, send to the peer as a new candidate and add to the
// Connection:
Connection -> PathChange<>
//---- PathChange event handler begin ----
ResolvedLocal, ResolvedRemote = Preconnection.Resolve()
if ResolvedLocal has changed:
// Application-specific code goes here to send the
// ResolvedLocal list to the peer via the signaling channel
...
// Add the new Local Endpoints to the Connection:
Connection.AddLocal(ResolvedLocal)
//---- PathChange event handler end ----
// Close the Connection in a Receive event handler:
Connection.Close()
Each application using the Transport Services API declares its preferences for how the Transport Services System is to operate. This is done by using Transport Properties, as defined in [RFC9621], at each stage of the lifetime of a Connection.
Transport Services APIを使用した各アプリケーションは、トランスポートサービスシステムの動作方法に対する好みを宣言します。これは、[RFC9621]で定義されているように、接続の寿命の各段階で輸送プロパティを使用して行われます。
Transport Properties are divided into Selection, Connection, and Message Properties.
輸送プロパティは、選択、接続、およびメッセージプロパティに分けられます。
Selection Properties (see Section 6.2) can only be set during preestablishment. They are only used to specify which paths and Protocol Stacks can be used and are preferred by the application. Calling Initiate on a Preconnection creates an outbound Connection, and the Selection Properties remain readable from the Connection but become immutable. Selection Properties can be set on Preconnections, and the effect of Selection Properties can be queried on Connections and Messages.
選択プロパティ（セクション6.2を参照）は、事前設定中にのみ設定できます。これらは、どのパスとプロトコルスタックを使用できるかを指定するためにのみ使用され、アプリケーションで好まれます。前提条件での呼び出しは、アウトバウンド接続を作成し、選択プロパティは接続から読みやすいままですが、不変になります。選択プロパティは、事前接続に設定でき、選択プロパティの効果は接続とメッセージに照会できます。
Connection Properties (see Section 8.1) are used to inform decisions made during establishment and to fine-tune the established Connection. They can be set during preestablishment and can be changed later. Connection Properties can be set on Connections and Preconnections; when set on Preconnections, they act as an initial default for the resulting Connections.
接続プロパティ（セクション8.1を参照）は、設立中に行われた決定を通知し、確立された接続を微調整するために使用されます。それらは事前設定中に設定することができ、後で変更することができます。接続プロパティは、接続と事前接続に設定できます。事前接続に設定すると、結果の接続の初期デフォルトとして機能します。
Message Properties (see Section 9.1.3) control the behavior of the selected Protocol Stack(s) when sending Messages. Message Properties can be set on Messages, Connections, and Preconnections; when set on the latter two, they act as an initial default for the Messages sent over those Connections.
メッセージプロパティ（セクション9.1.3を参照）は、メッセージを送信するときに選択したプロトコルスタックの動作を制御します。メッセージプロパティは、メッセージ、接続、および事前接続に設定できます。後者の2つに設定すると、それらの接続を介して送信されたメッセージの初期デフォルトとして機能します。
Note that configuring Connection Properties and Message Properties on Preconnections is preferred over setting them later. Early specification of Connection Properties allows their use as additional input to the selection process. Protocol-specific Properties, which enable configuration of specialized features of a specific protocol (see Section 3.2 of [RFC9621]), are not used as input to the selection process; they only support configuration if the respective protocol has been selected.
プレシャネクションで接続プロパティとメッセージプロパティを構成することは、後でそれらを設定するよりも推奨されることに注意してください。接続プロパティの初期の仕様により、選択プロセスへの追加の入力として使用できます。特定のプロトコルの特殊な機能の構成を可能にするプロトコル固有のプロパティ（[RFC9621]のセクション3.2を参照）は、選択プロセスへの入力として使用されません。それらは、それぞれのプロトコルが選択されている場合にのみ構成をサポートします。
Transport Properties are referred to by names, represented as case-insensitive strings. These names serve two purposes:
輸送プロパティは、ケースに依存しない文字列として表される名前で呼ばれます。これらの名前は2つの目的を果たします。
* Allowing different components of a Transport Services Implementation to pass Transport Properties (e.g., between a language frontend and a policy manager) or to enable a Transport Services Implementation to represent Properties retrieved from a file or other storage to the application.
* トランスポートサービスの実装のさまざまなコンポーネントを許可して、トランスポートプロパティ（例：言語フロントエンドとポリシーマネージャーの間）を通過させるか、トランスポートサービスの実装がファイルまたはその他のストレージからアプリケーションに取得されたプロパティを表すことができます。
* Making the code of different Transport Services Implementations look similar. While individual programming languages might preclude strict adherence to the naming convention of representing Property names as case-insensitive strings (for instance, by prohibiting the use of hyphens in symbols), users interacting with multiple implementations will still benefit from the consistency resulting from the use of visually similar symbols.
* さまざまな輸送サービスの実装のコードを似たように見せます。個々のプログラミング言語は、プロパティ名を代表する命名条約の厳格な遵守をケースに依存しない文字列として排除する可能性がありますが（たとえば、シンボルでのハイフンの使用を禁止することにより）、複数の実装と対話するユーザーは、使用から生じる一貫性の恩恵を受けます。視覚的に類似したシンボルの。
Transport Property names are hierarchically organized in the form [<Namespace>.]<PropertyName>.
トランスポートプロパティ名は、[<Namespace>。] <propertyName>の形式で階層的に編成されています。
* The optional Namespace component and its trailing dot character (".") MUST be omitted for well-known generic Properties, i.e., for Properties that are not specific to a protocol.
* オプションの名前空間コンポーネントとその末尾のドット文字（ "。"）は、よく知られている一般的なプロパティ、つまりプロトコルに固有のプロパティに対して省略する必要があります。
* Protocol-specific Properties MUST use the protocol acronym as the Namespace (e.g., a Connection that uses TCP could support a TCP-specific Transport Property, such as the TCP User Timeout value, in a Protocol-specific Property called tcp.userTimeoutValue (see Section 8.2)).
* プロトコル固有のプロパティは、プロトコルの頭字語を名前空間として使用する必要があります（たとえば、TCPを使用するTCP固有の輸送プロパティをサポートできます。TCP.USERTIMEOUTVALUEと呼ばれるプロトコル固有のプロパティで、TCPユーザータイムアウト値などのTCP固有の輸送プロパティをサポートできます（セクションを参照8.2））。
* Vendor-specific or implementation-specific Properties MUST be placed in a Namespace starting with the underscore character ("_") and SHOULD use a string identifying the vendor or implementation.
* ベンダー固有または実装固有のプロパティは、アンダースコア文字（「_」）から始まる名前空間に配置する必要があり、ベンダーまたは実装を識別する文字列を使用する必要があります。
* For IETF protocols, the name of a Protocol-specific Property MUST be specified in an RFC from the IETF Stream (after IETF Review [RFC8126]). An IETF protocol Namespace does not start with an underscore character ("_").
* IETFプロトコルの場合、プロトコル固有のプロパティの名前は、IETFストリームのRFCで指定する必要があります（IETFレビュー[RFC8126]後）。IETFプロトコルネームスペースは、アンダースコア文字（ "_"）から始まりません。
Namespaces for each of the keywords provided in the "Protocol Numbers" registry (see <https://www.iana.org/assignments/protocol-numbers/>) are reserved for Protocol-specific Properties and MUST NOT be used for vendor-specific or implementation-specific Properties. Terms listed as keywords, as in the "Protocol Numbers" registry, SHOULD be avoided as any part of a vendor-specific or implementation-specific Property name.
「プロトコル番号」レジストリで提供される各キーワードの名前空間（<https://www.iana.org/assignments/protocol-numbers/>を参照）は、プロトコル固有の特性のために予約されており、ベンダーに使用しないでください。特定または実装固有のプロパティ。「プロトコル番号」レジストリのように、キーワードとしてリストされている用語は、ベンダー固有または実装固有のプロパティ名の一部として避ける必要があります。
Though Transport Property names are case insensitive, it is recommended to use camelCase to improve readability. Implementations may transpose Transport Property names into snake_case or PascalCase to blend into the language environment.
輸送プロパティ名はケースでは鈍感ですが、キャメルケースを使用して読みやすさを向上させることをお勧めします。実装は、トランスポートプロパティ名をsnake_caseまたはpascalcaseに転置して、言語環境に溶け込むことができます。
Each Transport Property has one of the basic types described in Section 1.1.
各輸送プロパティには、セクション1.1で説明されている基本的なタイプの1つがあります。
Most Selection Properties (see Section 6.2) are of the Enumeration type, and they use the Preference Enumeration, which takes one of five possible values (Prohibit, Avoid, No Preference, Prefer, or Require) denoting the level of preference for a given Property during protocol selection.
ほとんどの選択プロパティ（セクション6.2を参照）は列挙タイプであり、特定のプロパティの優先レベルを示す5つの可能な値のいずれか（禁止、回避、優先、好み、または要求）のいずれかを使用します。プロトコル選択中。
This document defines a language- and platform-independent API of a Transport Services System. Given the wide variety of languages and language conventions used to write applications that use the transport layer to connect to other applications over the Internet, this independence makes this API necessarily abstract.
このドキュメントでは、輸送サービスシステムの言語およびプラットフォームに依存しないAPIを定義します。インターネットを介して他のアプリケーションに接続するためにトランスポート層を使用するアプリケーションを作成するために使用されるさまざまな言語と言語規則を考えると、この独立性により、このAPIは必然的に抽象的になります。
There is no interoperability benefit in tightly defining how the API is presented to application programmers across diverse platforms. However, maintaining the "shape" of the abstract API across different platforms reduces the effort for programmers who learn to use the Transport Services API to then apply their knowledge to another platform. That said, implementations have significant freedom in presenting this API to programmers, balancing the conventions of the protocol with the shape of the API. We make the following recommendations:
APIがさまざまなプラットフォーム全体のアプリケーションプログラマーにどのように表示されるかを厳密に定義する上で、相互運用性の利点はありません。ただし、さまざまなプラットフォームで抽象的なAPIの「形状」を維持することで、Transport Services APIを使用して別のプラットフォームに知識を適用することを学ぶプログラマーの努力が減少します。とはいえ、実装には、このAPIをプログラマーに提示することに大きな自由があり、プロトコルの規則とAPIの形状のバランスを取ります。次の推奨事項を作成します。
* Actions, events, and errors in implementations of the Transport Services API SHOULD use the names assigned to them in this document, subject to capitalization, punctuation, and other typographic conventions in the language of the implementation, unless the implementation itself uses different names for substantially equivalent objects for networking by convention.
* トランスポートサービスAPIの実装におけるアクション、イベント、およびエラーは、実装自体が実質的に異なる名前を使用しない限り、実装の言語で大文字化、句読点、およびその他のタイポグラフィの規則に従って、このドキュメントで割り当てられた名前を使用する必要があります。慣習によるネットワークのための同等のオブジェクト。
* Transport Services Systems SHOULD implement each Selection Property, Connection Property, and MessageContext Property specified in this document. These features SHOULD be implemented even when, in a specific implementation, it will always result in no operation, e.g., there is no action when the API specifies a Property that is not available in a transport protocol implemented on a specific platform. For example, if TCP is the only underlying transport protocol, the Message Property msgOrdered can be implemented (trivially, as a no-op) as disabling the requirement for ordering will not have any effect on delivery order for Connections over TCP. Similarly, the msgLifetime Message Property can be implemented but ignored, as the description of this Property (Section 9.1.3.1) states that "it is not guaranteed that a Message will not be sent when its Lifetime has expired".
* トランスポートサービスシステムは、このドキュメントで指定されている各選択プロパティ、接続プロパティ、およびMESSAGECONTEXTプロパティを実装する必要があります。これらの機能は、特定の実装では常に操作がなくなる場合でも実装する必要があります。たとえば、APIが特定のプラットフォームに実装されたトランスポートプロトコルで利用できないプロパティを指定する場合でもアクションはありません。たとえば、TCPが唯一の基礎となる輸送プロトコルである場合、注文の要件を無効にすることはTCPを介した接続の配信順序に何の影響もありません。同様に、このプロパティの説明（セクション9.1.3.1）は、「寿命が経過したときにメッセージが送信されないことは保証されていない」と述べているため、MSGLIFETIMEメッセージプロパティを実装できますが無視できます。
* Implementations can use other representations for Transport Property names, e.g., by providing constants, but should provide a straightforward mapping between their representation and the Property names specified here.
* 実装は、定数を提供することにより、輸送プロパティ名に他の表現を使用できますが、ここで指定されている表現とプロパティ名の間に簡単なマッピングを提供する必要があります。
The preestablishment phase allows applications to specify Properties for the Connections that they are about to make or to query the API about potential Connections they could make.
事前設計フェーズにより、アプリケーションは、アクセスしようとしている接続のプロパティを指定したり、潜在的な接続についてAPIを照会したりすることができます。
A Preconnection object represents a potential Connection. It is a passive object (a data structure) that merely maintains the state that describes the Properties of a Connection that might exist in the future. This state comprises Local Endpoint and Remote Endpoint objects that denote the Endpoints of the potential Connection (see Section 6.1), the Selection Properties (see Section 6.2), any preconfigured Connection Properties (Section 8.1), and the Security Parameters (see Section 6.3):
事前接続オブジェクトは、潜在的な接続を表します。これは、将来存在する可能性のある接続のプロパティを記述する状態を単に維持する単に、パッシブオブジェクト（データ構造）です。この状態は、潜在的な接続のエンドポイント（セクション6.1を参照）、選択プロパティ（セクション6.2を参照）、事前に設定された接続プロパティ（セクション8.1）、およびセキュリティパラメーター（セクション6.3を参照）を示すローカルエンドポイントとリモートエンドポイントオブジェクトで構成されています。：
Preconnection := NewPreconnection([]LocalEndpoint,
[]RemoteEndpoint,
TransportProperties,
SecurityParameters)
At least one Local Endpoint MUST be specified if the Preconnection is used to Listen for incoming Connections, but the list of Local Endpoints MAY be empty if the Preconnection is used to Initiate connections. If no Local Endpoint is specified, the Transport Services System will assign an ephemeral local port to the Connection on the appropriate interface(s). At least one Remote Endpoint MUST be specified if the Preconnection is used to Initiate Connections, but the list of Remote Endpoints MAY be empty if the Preconnection is used to Listen for incoming Connections. At least one Local Endpoint and one Remote Endpoint MUST be specified if a peer-to-peer Rendezvous is to occur based on the Preconnection.
プレシャネクションを使用して着信接続をリッスンする場合は、少なくとも1つのローカルエンドポイントを指定する必要がありますが、プレシャネクションを使用して接続を開始する場合、ローカルエンドポイントのリストは空になる場合があります。ローカルエンドポイントが指定されていない場合、トランスポートサービスシステムは、適切なインターフェイス上の接続にはかなかローカルポートを割り当てます。プレシャネクションを使用して接続を開始する場合は、少なくとも1つのリモートエンドポイントを指定する必要がありますが、リモートエンドポイントのリストは、前提条件を使用して着信接続をリッスンする場合は空になる場合があります。ピアツーピアのランデブーが前接続に基づいて発生する場合、少なくとも1つのローカルエンドポイントと1つのリモートエンドポイントを指定する必要があります。
If more than one Local Endpoint is specified on a Preconnection, then the application is indicating that all of the Local Endpoints are eligible to be used for Connections. For example, their Endpoint Identifiers might correspond to different interfaces on a multihomed host or their Endpoint Identifiers might correspond to local interfaces and a STUN server that can be resolved to a server-reflexive address for a Preconnection used to make a peer-to-peer Rendezvous.
事前接続で複数のローカルエンドポイントが指定されている場合、アプリケーションは、すべてのローカルエンドポイントが接続に使用される資格があることを示しています。たとえば、それらのエンドポイント識別子は、マルチホームホストの異なるインターフェイスに対応する場合がある場合、またはエンドポイント識別子はローカルインターフェイスと、ピアツーピアを作成するために使用される事前接続のためにサーバー反射アドレスに解決できるスタンサーバーに対応する場合があります。ランデブー。
If more than one Remote Endpoint is specified on the Preconnection, the application is indicating that it expects all of the Remote Endpoints to offer an equivalent service and that the Transport Services System can choose any of them for a Connection. For example, a Remote Endpoint might represent various network interfaces of a host, or a server-reflexive address that can be used to reach a host, or a set of hosts that provide equivalent local balanced service.
プレシャネクションで複数のリモートエンドポイントが指定されている場合、アプリケーションは、すべてのリモートエンドポイントが同等のサービスを提供することを期待しており、トランスポートサービスシステムが接続用にそれらを選択できることを示しています。たとえば、リモートエンドポイントは、ホストのさまざまなネットワークインターフェイス、またはホストに到達するために使用できるサーバー反射アドレス、または同等のローカルバランスサービスを提供するホストのセットを表す場合があります。
In most cases, it is expected that a single Remote Endpoint will be specified by name, and a later call to Initiate on the Preconnection (see Section 7.1) will internally resolve that name to a list of concrete Endpoint Identifiers. Specifying multiple Remote Endpoints on a Preconnection allows applications to override this for more detailed control.
ほとんどの場合、単一のリモートエンドポイントが名前で指定されることが予想され、その後の事前接続（セクション7.1を参照）で開始する後の呼び出しは、その名前をコンクリートエンドポイント識別子のリストに内部的に解決します。事前接続で複数のリモートエンドポイントを指定すると、アプリケーションがこれをオーバーライドして、より詳細な制御を実現できます。
If Message Framers are used (see Section 9.1.2), they MUST be added to the Preconnection during preestablishment.
メッセージフレーマーを使用する場合（セクション9.1.2を参照）、それらは事前設定中に事前接続に追加する必要があります。
The Transport Services API uses the Local Endpoint and Remote Endpoint objects to refer to the Endpoints of a Connection. Endpoints can be created as either remote or local:
Transport Services APIは、ローカルエンドポイントとリモートエンドポイントオブジェクトを使用して、接続のエンドポイントを参照します。エンドポイントは、リモートまたはローカルとして作成できます。
RemoteSpecifier := NewRemoteEndpoint()
LocalSpecifier := NewLocalEndpoint()
A single Endpoint object represents the identity of a network host. That Endpoint can be more or less specific, depending on which Endpoint Identifiers are set. For example, an Endpoint that only specifies a hostname can, in fact, finally correspond to several different IP addresses on different hosts.
単一のエンドポイントオブジェクトは、ネットワークホストのIDを表します。そのエンドポイントは、どのエンドポイント識別子が設定されているかに応じて、多かれ少なかれ具体的にすることができます。たとえば、ホスト名のみを指定するエンドポイントは、実際には、最終的に異なるホストのいくつかの異なるIPアドレスに対応できます。
An Endpoint object can be configured with the following identifiers:
エンドポイントオブジェクトは、次の識別子で構成できます。
* HostName (string):
* hostname（string）：
RemoteSpecifier.WithHostName("example.com")
* Port (a 16-bit unsigned Integer):
* ポート（16ビットの署名のない整数）：
RemoteSpecifier.WithPort(443)
* Service (an identifier string that maps to a port; either a service name associated with a port number (from <https://www.iana.org/assignments/service-names-port-numbers/>) or a DNS SRV service name to be resolved):
* サービス（ポートにマップする識別子文字列;ポート番号（<https://www.iana.org/assignments/service-names-port-numbers/>）に関連付けられたサービス名のいずれかまたはDNS SRVサービス解決する名前）：
RemoteSpecifier.WithService("https")
* IP address (an IPv4 or IPv6 address type; note that the examples here show the human-readable form of the IP addresses, but the functions can take a binary encoding of the addresses):
* IPアドレス（IPv4またはIPv6アドレスタイプ。ここでの例には、IPアドレスの人間が読める形式が表示されますが、関数はアドレスのバイナリエンコードを取得できます）：
RemoteSpecifier.WithIPAddress(192.0.2.21)
RemoteSpecifier.WithIPAddress(2001:db8:4920:e29d:a420:7461:7073:a)
* Interface identifier (which can be a string name or other platform-specific identifier), e.g., to qualify link-local addresses (see Section 6.1.2 for details):
* インターフェイス識別子（文字列名またはその他のプラットフォーム固有の識別子にすることができます）、例えば、リンクローカルアドレスを修飾するため（詳細についてはセクション6.1.2を参照）：
LocalSpecifier.WithInterface("en0")
The Resolve action on a Preconnection can be used to obtain a list of available local interfaces.
事前接続での解決アクションを使用して、利用可能なローカルインターフェイスのリストを取得できます。
Note that an IPv6 address specified with a scope zone ID (e.g., fe80::2001:db8%en0) is equivalent to WithIPAddress with an unscoped address and WithInterface together.
スコープゾーンIDで指定されたIPv6アドレス（たとえば、Fe80 :: 2001：DB8％EN0）は、Unscopedアドレスを備えたWithIPADDRESSと一緒にTERTERFACE内に相当することに注意してください。
Applications creating Endpoint objects using WithHostName SHOULD provide Fully Qualified Domain Names (FQDNs). Not providing an FQDN will result in the Transport Services Implementation needing to use DNS search domains for name resolution, which might lead to inconsistent or unpredictable behavior.
WithHostNameを使用してエンドポイントオブジェクトを作成するアプリケーションは、完全に適格なドメイン名（FQDNS）を提供する必要があります。FQDNを提供しないと、DNS検索ドメインを使用する必要がある輸送サービスの実装が名前の解決につながり、一貫性のないまたは予測不可能な動作につながる可能性があります。
The design of the API MUST NOT permit an Endpoint object to be configured with multiple Endpoint Identifiers of the same type. For example, an Endpoint object cannot specify two IP addresses. Two separate IP addresses are represented as two Endpoint objects. If a Preconnection specifies a Remote Endpoint with a specific IP address set, it will only establish Connections to that IP address. If, on the other hand, a Remote Endpoint specifies a hostname but no addresses, the Transport Services Implementation can perform name resolution and attempt using any address derived from the original hostname of the Remote Endpoint. Note that multiple Remote Endpoints can be added to a Preconnection, as discussed in Section 7.5.
APIの設計により、同じタイプの複数のエンドポイント識別子でエンドポイントオブジェクトを構成することはできません。たとえば、エンドポイントオブジェクトは2つのIPアドレスを指定できません。2つの個別のIPアドレスが2つのエンドポイントオブジェクトとして表されます。プレシャネクションが特定のIPアドレスセットを備えたリモートエンドポイントを指定する場合、そのIPアドレスへの接続のみを確立します。一方、リモートエンドポイントがホスト名を指定しているがアドレスがない場合、トランスポートサービスの実装は名前の解決を実行し、リモートエンドポイントの元のホスト名から派生したアドレスを使用して試みることができます。セクション7.5で説明したように、複数のリモートエンドポイントを事前接続に追加できることに注意してください。
The Transport Services System resolves names internally, when the Initiate, Listen, or Rendezvous action is called to establish a Connection. Privacy considerations for the timing of this resolution are given in Section 13.
トランスポートサービスシステムは、接続を確立するために開始、リスニング、またはランデブーアクションが呼び出されたときに、内部的に名前を解決します。この解決策のタイミングに関するプライバシーに関する考慮事項は、セクション13に記載されています。
The Resolve action on a Preconnection can be used by the application to force early binding when required, for example, with some Network Address Translator (NAT) traversal protocols (see Section 7.3).
たとえば、必要に応じて、必要に応じて、ネットワークアドレス翻訳者（NAT）トラバーサルプロトコルを使用して、アプリケーションで解決策を使用することができます（セクション7.3を参照）。
To use multicast, a Preconnection is first created with the Local or Remote Endpoint Identifier specifying the Any-Source Multicast (ASM) or Source-Specific Multicast (SSM) group and destination port number. This is then followed by a call to either Initiate, Listen, or Rendezvous, depending on whether the resulting Connection is to be used to send Messages to the multicast group, receive Messages from the group, or both send and receive Messages (as is the case for an ASM group).
マルチキャストを使用するには、任意のソースマルチキャスト（ASM）またはソース固有のマルチキャスト（SSM）グループおよび宛先ポート番号を指定するローカルまたはリモートエンドポイント識別子で最初に作成されます。次に、結果の接続を使用してマルチキャストグループにメッセージを送信するか、グループからメッセージを受信するか、メッセージを送信および受信するかどうかに応じて、開始、聞く、またはランデブーのいずれかを呼び出します（ASMグループの場合）。
Note that the Transport Services API has separate specifier calls for multicast groups to avoid introducing filter Properties for single-source multicast and seeks to avoid confusion that can be caused by overloading the unicast specifiers.
Transport Services APIには、シングルソースマルチキャストのフィルタープロパティの導入を避けるために、マルチキャストグループの個別の仕様呼び出しがあり、ユニキャスト仕様の過負荷によって引き起こされる可能性のある混乱を避けようとすることに注意してください。
Calling Initiate on that Preconnection creates a Connection that can be used to send Messages to the multicast group. The Connection object that is created will support Send but not Receive. Any Connections created this way are send-only and do not join the multicast group. The resulting Connection will have a Local Endpoint identifying the local interface to which the Connection is bound and a Remote Endpoint identifying the multicast group.
その前提条件での呼び出しは、マルチキャストグループにメッセージを送信するために使用できる接続を作成します。作成された接続オブジェクトは、送信をサポートしますが、受信しません。この方法で作成された接続は、送信のみであり、マルチキャストグループに参加しません。結果の接続には、接続がバインドされているローカルインターフェイスを識別するローカルエンドポイントと、マルチキャストグループを識別するリモートエンドポイントがあります。
The following API calls can be used to configure a Preconnection before calling Initiate:
次のAPI呼び出しを使用して、Initiateを呼び出す前に、事前接続を構成できます。
RemoteSpecifier.WithMulticastGroupIP(GroupAddress)
RemoteSpecifier.WithPort(PortNumber)
RemoteSpecifier.WithHopLimit(HopLimit)
Calling Listen on a Preconnection with a multicast group address specified as the Remote Endpoint Identifier will trigger the Transport Services Implementation to join the multicast group to receive Messages. This Listener will create one Connection for each Remote Endpoint sending to the group, with the Local Endpoint Identifier specified as a group address. The set of Connection objects created forms a Connection Group. The receiving interface can be restricted by passing it as part of the LocalSpecifier or queried through the MessageContext on the Messages received (see Section 9.1.1 for further details).
リモートエンドポイント識別子として指定されたマルチキャストグループアドレスを使用して、リストレーションでリスニングを呼び出すと、トランスポートサービスの実装がトリガーされ、マルチキャストグループに参加してメッセージを受信します。このリスナーは、グループに送信するリモートエンドポイントごとに1つの接続を作成し、ローカルエンドポイント識別子をグループアドレスとして指定します。作成された接続オブジェクトのセットは、接続グループを形成します。受信インターフェイスは、地元の人々の一部として渡すことで制限されるか、受信したメッセージのMessageContextを介して照会することで制限できます（詳細については、セクション9.1.1を参照）。
Specifying WithHopLimit sets the Time To Live (TTL) field in the header of IPv4 packets or the Hop Count field in the header of IPv6 packets.
Withhoplimitを指定すると、IPv4パケットのヘッダーまたはIPv6パケットのヘッダーにあるホップカウントフィールドにLive（TTL）フィールドを設定します。
The following API calls can be used to configure a Preconnection before calling Listen:
次のAPI呼び出しを使用して、聴取を呼び出す前に、事前接続を構成できます。
LocalSpecifier.WithSingleSourceMulticastGroupIP(GroupAddress,
SourceAddress)
LocalSpecifier.WithAnySourceMulticastGroupIP(GroupAddress)
LocalSpecifier.WithPort(PortNumber)
Calling Rendezvous on a Preconnection with an ASM group address as the Remote Endpoint Identifier will trigger the Transport Services Implementation to join the multicast group and also indicates that the resulting Connection can be used to send Messages to the multicast group. The Rendezvous action will return both:
ASMグループアドレスをリモートエンドポイント識別子としてASMグループアドレスを使用した事前接続でrendezvousを呼び出し、トランスポートサービスの実装をトリガーしてマルチキャストグループに参加し、結果の接続を使用してマルチキャストグループにメッセージを送信できることも示します。ランデブーアクションは両方を返します。
1. a Connection that can be used to send to the group and that acts the same as a Connection returned by calling Initiate with a multicast Remote Endpoint and
1. グループに送信するために使用できる接続。マルチキャストリモートエンドポイントでretuniateを呼び出すことで返される接続と同じように機能する
2. a Listener that acts as if Listen had been called with a multicast Remote Endpoint.
2. まるで聞くように振る舞うリスナーは、マルチキャストのリモートエンドポイントで呼ばれていました。
Calling Rendezvous on a Preconnection with an SSM group address as the Local Endpoint Identifier results in an EstablishmentError.
ローカルエンドポイント識別子としてのSSMグループアドレスを使用した事前接続でRendezvousを呼び出してください。
The following API calls can be used to configure a Preconnection before calling Rendezvous:
次のAPI呼び出しを使用して、rendezvousを呼び出す前に、事前接続を構成できます。
RemoteSpecifier.WithMulticastGroupIP(GroupAddress)
RemoteSpecifier.WithPort(PortNumber)
RemoteSpecifier.WithHopLimit(HopLimit)
LocalSpecifier.WithAnySourceMulticastGroupIP(GroupAddress)
LocalSpecifier.WithPort(PortNumber)
LocalSpecifier.WithHopLimit(HopLimit)
See Section 6.1.5 for more examples.
その他の例については、セクション6.1.5を参照してください。
Note that this API has multiple ways to constrain and prioritize Endpoint candidates based on the network interface:
このAPIには、ネットワークインターフェイスに基づいてエンドポイント候補を制約および優先順位付けする方法があることに注意してください。
* Specifying an interface on a Remote Endpoint qualifies the scope zone of the Remote Endpoint, e.g., for link-local addresses.
* リモートエンドポイントでインターフェイスを指定すると、リモートエンドポイントのスコープゾーン、たとえばリンクローカルアドレスの資格があります。
* Specifying an interface on a Local Endpoint explicitly binds all candidates derived from this Endpoint to use the specified interface.
* ローカルエンドポイントでインターフェイスを指定すると、指定されたインターフェイスを使用するために、このエンドポイントから派生したすべての候補者に明示的にバインドします。
* Specifying an interface using the interface Selection Property (Section 6.2.11) or indirectly via the pvd Selection Property (Section 6.2.12) influences the selection among the available candidates.
* インターフェイス選択プロパティ（セクション6.2.11）を使用してインターフェイスを指定するか、PVD選択プロパティ（セクション6.2.12）を介して間接的に、利用可能な候補者の選択に影響します。
While specifying an interface on an Endpoint restricts the candidates available for Connection establishment in the preestablishment phase, the Selection Properties prioritize and constrain the Connection establishment.
エンドポイントでインターフェイスを指定すると、事前設定フェーズで接続確立に利用できる候補者が制限されますが、選択プロパティは接続確立を優先し、制約します。
An Endpoint can have an alternative definition when using different protocols. For example, a server that supports both TLS/TCP and QUIC could be accessible on two different port numbers, depending on which protocol is used.
エンドポイントは、異なるプロトコルを使用する場合、代替の定義を持つことができます。たとえば、TLS/TCPとQUICの両方をサポートするサーバーは、使用するプロトコルに応じて、2つの異なるポート番号でアクセスできる可能性があります。
To scope an Endpoint to apply conditionally to a specific transport protocol (such as defining an alternate port to use when QUIC is selected, as opposed to TCP), an Endpoint can be associated with a protocol identifier. Protocol identifiers are objects or Enumeration values provided by the Transport Services API that will vary based on which protocols are implemented in a particular system.
特定のトランスポートプロトコルに条件付きで適用するエンドポイントを範囲（TCPとは対照的に、QUICが選択されたときに使用する代替ポートを定義するなど）に適用するには、エンドポイントをプロトコル識別子に関連付けることができます。プロトコル識別子は、特定のシステムにどのプロトコルが実装されているかによって異なるトランスポートサービスAPIによって提供されるオブジェクトまたは列挙値です。
AlternateRemoteSpecifier.WithProtocol(QUIC)
The following example shows a case where example.com has a server running on port 443 with an alternate port of 8443 for QUIC. Both endpoints can be passed when creating a Preconnection.
次の例は、example.comがポート443で実行されているサーバーがQUICの8443の代替ポートを備えたサーバーを持っている場合を示しています。両方のエンドポイントは、前提条件を作成するときに渡すことができます。
RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithHostName("example.com")
RemoteSpecifier.WithPort(443)
QUICRemoteSpecifier := NewRemoteEndpoint()
QUICRemoteSpecifier.WithHostName("example.com")
QUICRemoteSpecifier.WithPort(8443)
QUICRemoteSpecifier.WithProtocol(QUIC)
RemoteSpecifiers := [ RemoteSpecifier, QUICRemoteSpecifier ]
The following examples of Endpoints show common usage patterns.
エンドポイントの次の例は、一般的な使用パターンを示しています。
Specify a Remote Endpoint using a hostname example.com and a service name https, which tells the system to use the default port for HTTPS (443):
HostName Example.comとサービス名HTTPSを使用してリモートエンドポイントを指定します。これは、システムにhttps（443）にデフォルトポートを使用するように指示します。
RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithHostName("example.com")
RemoteSpecifier.WithService("https")
Specify a Remote Endpoint using an IPv6 address and remote port:
IPv6アドレスとリモートポートを使用してリモートエンドポイントを指定します。
RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithIPAddress(2001:db8:4920:e29d:a420:7461:7073:a)
RemoteSpecifier.WithPort(443)
Specify a Remote Endpoint using an IPv4 address and remote port:
IPv4アドレスとリモートポートを使用してリモートエンドポイントを指定します。
RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithIPAddress(192.0.2.21)
RemoteSpecifier.WithPort(443)
Specify a Local Endpoint using a local interface name and no local port to let the system assign an ephemeral local port:
ローカルインターフェイス名とローカルポートを使用してローカルエンドポイントを指定して、システムにはかなかローカルポートを割り当てることができます。
LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithInterface("en0")
Specify a Local Endpoint using a local interface name and local port:
ローカルインターフェイス名とローカルポートを使用してローカルエンドポイントを指定します。
LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithInterface("en0")
LocalSpecifier.WithPort(443)
As an alternative to specifying an interface name for the Local Endpoint, an application can express more fine-grained preferences using the interface Selection Property; see Section 6.2.11. However, if the application specifies Selection Properties that are inconsistent with the Local Endpoint, this will result in an error once the application attempts to open a Connection.
ローカルエンドポイントのインターフェイス名を指定する代わりに、アプリケーションはインターフェイス選択プロパティを使用して、より微調整された設定を表現できます。セクション6.2.11を参照してください。ただし、アプリケーションがローカルエンドポイントと矛盾する選択プロパティを指定した場合、アプリケーションが接続を開こうとすると、これによりエラーが発生します。
Specify a Local Endpoint using a STUN server:
スタンサーバーを使用してローカルエンドポイントを指定します。
LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithStunServer(address, port, credentials)
The following examples show how multicast groups can be used.
次の例は、マルチキャストグループをどのように使用できるかを示しています。
Join an ASM group in receive-only mode, bound to a known port on a named local interface:
名前付きローカルインターフェイス上の既知のポートにバインドされた受信専用モードでASMグループに参加します。
RemoteSpecifier := NewRemoteEndpoint()
LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithAnySourceMulticastGroupIP(233.252.0.0)
LocalSpecifier.WithPort(5353)
LocalSpecifier.WithInterface("en0")
TransportProperties := ...
SecurityParameters := ...
Preconnection := NewPreconnection(LocalSpecifier,
RemoteSpecifier,
TransportProperties,
SecurityProperties)
Listener := Preconnection.Listen()
Join an SSM group in receive-only mode, bound to a known port on a named local interface:
名前付きローカルインターフェイス上の既知のポートにバインドされた受信専用モードでSSMグループに参加します。
RemoteSpecifier := NewRemoteEndpoint()
LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithSingleSourceMulticastGroupIP(233.252.0.0,
198.51.100.10)
LocalSpecifier.WithPort(5353)
LocalSpecifier.WithInterface("en0")
TransportProperties := ...
SecurityParameters := ...
Preconnection := NewPreconnection(LocalSpecifier,
RemoteSpecifier,
TransportProperties,
SecurityProperties)
Listener := Preconnection.Listen()
Create an SSM group as a sender:
送信者としてSSMグループを作成します。
RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithMulticastGroupIP(233.251.240.1)
RemoteSpecifier.WithPort(5353)
RemoteSpecifier.WithHopLimit(8)
LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithIPAddress(192.0.2.22)
LocalSpecifier.WithInterface("en0")
TransportProperties := ...
SecurityParameters := ...
Preconnection := NewPreconnection(LocalSpecifier,
RemoteSpecifier,
TransportProperties,
SecurityProperties)
Connection := Preconnection.Initiate()
Join an ASM group as both a sender and a receiver:
送信者と受信機の両方としてASMグループに参加してください。
RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithMulticastGroupIP(233.252.0.0)
RemoteSpecifier.WithPort(5353)
RemoteSpecifier.WithHopLimit(8)
LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithAnySourceMulticastGroupIP(233.252.0.0)
LocalSpecifier.WithIPAddress(192.0.2.22)
LocalSpecifier.WithPort(5353)
LocalSpecifier.WithInterface("en0")
TransportProperties := ...
SecurityParameters := ...
Preconnection := NewPreconnection(LocalSpecifier,
RemoteSpecifier,
TransportProperties,
SecurityProperties)
Connection, Listener := Preconnection.Rendezvous()
A Preconnection object holds Properties reflecting the application's requirements and preferences for the transport. These include Selection Properties for selecting Protocol Stacks and paths, as well as Connection Properties and Message Properties for configuration of the detailed operation of the selected Protocol Stacks on a per-Connection and per-Message level.
事前接続オブジェクトは、アプリケーションの要件と輸送の設定を反映したプロパティを保持します。これらには、プロトコルスタックとパスを選択するための選択プロパティ、および選択したプロトコルスタックの詳細な操作とメッセージごとのレベルでの接続プロパティとメッセージプロパティが含まれます。
The protocol(s) and path(s) selected as candidates during establishment are determined and configured using these Properties. Since there could be paths over which some transport protocols are unable to operate, or Remote Endpoints that support only specific network addresses or transports, transport protocol selection is necessarily tied to path selection. This could involve choosing between multiple local interfaces that are connected to different access networks.
確立中に候補として選択されたプロトコルとパスは、これらのプロパティを使用して決定および構成されます。一部のトランスポートプロトコルが動作できないパス、または特定のネットワークアドレスまたはトランスポートのみをサポートするリモートエンドポイントがある可能性があるため、トランスポートプロトコルの選択は必然的にパス選択に結び付けられます。これには、異なるアクセスネットワークに接続されている複数のローカルインターフェイスを選択することが含まれます。
When additional information (such as PvD information [RFC7556]) is available about the networks over which an Endpoint can operate, this can inform the selection between alternate network paths. Path information can include the Path MTU (PMTU), the set of supported Differentiated Services Code Points (DSCPs), expected usage, cost, etc. The usage of this information by the Transport Services System is generally independent of the specific mechanism or protocol used to receive the information (e.g., zero-conf, DHCP, or IPv6 Router Advertisements (RAs)).
追加情報（PVD情報[RFC7556]など）がエンドポイントが動作できるネットワークについて利用できる場合、代替ネットワークパス間の選択を通知できます。パス情報には、パスMTU（PMTU）、サポートされている差別化されたサービスコードポイント（DSCP）、予想される使用、コストなどを含めることができます。この情報の使用は、一般に使用される特定のメカニズムまたはプロトコルとは無関係です。情報を受信するには（例：ゼロ-CONF、DHCP、またはIPv6ルーター広告（RAS））。
Most Selection Properties are represented as Preferences, which can take one of five values:
ほとんどの選択プロパティは、5つの値のいずれかをとることができます。
+============+=========================================+
| Preference | Effect |
+============+=========================================+
| Require | Select only protocols/paths providing |
| | the Property; otherwise, fail |
+------------+-----------------------------------------+
| Prefer | Prefer protocols/paths providing the |
| | Property; otherwise, proceed |
+------------+-----------------------------------------+
| No | No preference |
| Preference | |
+------------+-----------------------------------------+
| Avoid | Prefer protocols/paths not providing |
| | the Property; otherwise, proceed |
+------------+-----------------------------------------+
| Prohibit | Select only protocols/paths not |
| | providing the Property; otherwise, fail |
+------------+-----------------------------------------+
Table 1: Selection Property Preference Levels
表1：選択特性レベルの選択
The implementation MUST ensure an outcome that is consistent with all application requirements expressed using Require and Prohibit. While preferences expressed using Prefer and Avoid influence protocol and path selection as well, outcomes can vary, even given the same Selection Properties, because the available protocols and paths can differ across systems and contexts. However, implementations are RECOMMENDED to seek to provide a consistent outcome to an application, when provided with the same set of Selection Properties.
実装は、要求と禁止を使用して表明されたすべてのアプリケーション要件と一致する結果を確保する必要があります。プレゼントプロトコルとパスの選択も優先して回避する設定が表現されていますが、利用可能なプロトコルとパスはシステムとコンテキスト間で異なる可能性があるため、同じ選択プロパティが与えられても、結果は異なる場合があります。ただし、同じ選択プロパティが提供された場合、アプリケーションに一貫した結果を提供しようとするために実装が推奨されます。
Note that application preferences can conflict with each other. For example, if an application indicates a preference for a specific path by specifying an interface, but also a preference for a protocol, a situation might occur in which the preferred protocol is not available on the preferred path. In such cases, applications can expect Properties that determine path selection to be prioritized over Properties that determine protocol selection. The Transport Services System SHOULD determine the preferred path first, regardless of protocol preferences. This ordering is chosen to provide consistency across implementations; this is based on the fact that it is more common for the use of a given network path to determine cost to the user (i.e., an interface type preference might be based on a user's preference to avoid being charged more for a cellular data plan).
アプリケーションの設定は互いに競合する可能性があることに注意してください。たとえば、アプリケーションがインターフェイスを指定することにより特定のパスの優先を示すだけでなく、プロトコルの好みを示す場合、優先プロトコルが優先パスで使用できない状況が発生する可能性があります。このような場合、アプリケーションは、プロトコル選択を決定するプロパティよりもパス選択が優先順位を付けることを決定するプロパティを期待できます。輸送サービスシステムは、プロトコルの好みに関係なく、最初に優先パスを決定する必要があります。この順序は、実装間で一貫性を提供するために選択されます。これは、特定のネットワークパスを使用してユーザーへのコストを決定することがより一般的であるという事実に基づいています（つまり、インターフェイスタイプの好みは、セルラーデータプランの請求を避けるためにユーザーの好みに基づいている可能性があります）。
Selection and Connection Properties, as well as defaults for Message Properties, can be added to a Preconnection to configure the selection process and to further configure the eventually selected Protocol Stack(s). They are collected into a TransportProperties object to be passed into a Preconnection object:
メッセージプロパティのデフォルトと同様に、選択プロセスのデフォルトと同様に、選択プロセスを構成し、最終的に選択したプロトコルスタックをさらに構成するための前提条件に追加できます。それらは、TransportPropertiesオブジェクトに収集され、以前のオブジェクトに渡されます。
TransportProperties := NewTransportProperties()
Individual Properties are then set on the TransportProperties object. Setting a Transport Property to a value overrides the previous value of this Transport Property.
その後、個々のプロパティがTransportPropertiesオブジェクトに設定されます。輸送プロパティを値に設定すると、この輸送プロパティの以前の値を無効にします。
TransportProperties.Set(property, value)
To aid readability, implementations MAY provide additional convenience functions to simplify the use of Selection Properties: see Appendix B.1 for examples. In addition, implementations MAY provide a mechanism to create TransportProperties objects that are preconfigured for common use cases, as outlined in Appendix B.2.
読みやすさを支援するために、実装は選択プロパティの使用を簡素化するための追加の利便性関数を提供する場合があります。例については、付録B.1を参照してください。さらに、実装は、付録B.2に概説されているように、一般的なユースケースのために事前に構成されたTransportPropertiesオブジェクトを作成するメカニズムを提供する場合があります。
Transport Properties for an established Connection can be queried via the Connection object, as outlined in Section 8.
確立された接続の輸送プロパティは、セクション8で概説されているように、接続オブジェクトを介して照会できます。
A Connection gets its Transport Properties by either being explicitly configured via a Preconnection, being configured after establishment, or inheriting them from an antecedent via cloning; see Section 7.4 for more details.
接続は、事前接続を介して明示的に構成され、設立後に構成されているか、クローニングを介して前件から継承することにより、輸送プロパティを取得します。詳細については、セクション7.4を参照してください。
Section 8.1 provides a list of Connection Properties, while Selection Properties are listed in the subsections below. Selection Properties are only considered during establishment and cannot be changed after a Connection is established. At this point, Selection Properties can only be read to check the Properties used by the Connection. Upon reading, the Preference type of a Selection Property changes into Boolean, where:
セクション8.1では、接続プロパティのリストを示し、選択プロパティは以下のサブセクションにリストされています。選択プロパティは、施設中にのみ考慮され、接続が確立された後に変更することはできません。この時点で、選択プロパティは、接続で使用されるプロパティを確認するためにのみ読み取ることができます。読むと、選択プロパティの好みのタイプがブール値に変わります。
* true means that the selected Protocol Stack supports the feature or uses the path associated with the Selection Property, and
* TRUEとは、選択したプロトコルスタックが機能をサポートするか、選択プロパティに関連付けられたパスを使用することを意味します。
* false means that the Protocol Stack does not support the feature or use the path.
* falseとは、プロトコルスタックが機能をサポートしていないか、パスを使用しないことを意味します。
Implementations of Transport Services Systems could alternatively use the Require and Prohibit Preference values to represent true and false, respectively. Other types of Selection Properties remain unchanged when they are made available for reading after a Connection is established.
トランスポートサービスシステムの実装は、それぞれ要求値を使用し、それぞれTrue and Falseを表す優先値を禁止することができます。他のタイプの選択プロパティは、接続が確立された後に読み取りできるようになった場合、変更されません。
An implementation of the Transport Services API needs to provide sensible defaults for Selection Properties. The default values for each Property below represent a configuration that can be implemented over TCP. If these default values are used and TCP is not supported by a Transport Services System, then an application using the default set of Properties might not succeed in establishing a Connection. Using the same default values for independent Transport Services Systems can be beneficial when applications are ported between different implementations/platforms, even if this default could lead to a Connection failure when TCP is not available. If default values other than those suggested below are used, it is RECOMMENDED to clearly document any differences.
Transport Services APIの実装では、選択プロパティに賢明なデフォルトを提供する必要があります。以下の各プロパティのデフォルト値は、TCPを介して実装できる構成を表します。これらのデフォルト値が使用され、TCPがトランスポートサービスシステムによってサポートされていない場合、プロパティのデフォルトセットを使用するアプリケーションは、接続の確立に成功しない場合があります。独立した輸送サービスシステムに同じデフォルト値を使用すると、アプリケーションが異なる実装/プラットフォーム間で移植される場合、このデフォルトがTCPが利用できない場合に接続障害につながる可能性がある場合でも、有益です。以下に提案されているもの以外のデフォルト値を使用する場合は、違いを明確に文書化することをお勧めします。
Name:
名前：
reliability
信頼性
Type:
タイプ：
Preference
好み
Default:
デフォルト：
Require
必要とする
This Property specifies whether the application needs to use a transport protocol that ensures that all data is received at the Remote Endpoint in order, without loss or duplication. When reliable data transfer is enabled, this also entails being notified when a Connection is closed or aborted.
このプロパティは、アプリケーションが、損失または複製なしで、すべてのデータが順に順番に受信されることを保証するトランスポートプロトコルを使用する必要があるかどうかを指定します。信頼できるデータ転送が有効になっている場合、これは接続が閉じたり中止されたときに通知されることも伴います。
Name:
名前：
preserveMsgBoundaries
Preservemsgboundaries
Type:
タイプ：
Preference
好み
Default:
デフォルト：
No Preference
好みはありません
This Property specifies whether the application needs or prefers to use a transport protocol that preserves Message boundaries.
このプロパティは、アプリケーションがメッセージの境界を保持するトランスポートプロトコルを使用する必要があるか、好まれるかを指定します。
Name:
名前：
perMsgReliability
パームグレリ性
Type:
タイプ：
Preference
好み
Default:
デフォルト：
No Preference
好みはありません
This Property specifies whether an application considers it useful to specify different reliability requirements for individual Messages in a Connection.
このプロパティは、アプリケーションが接続内の個々のメッセージの異なる信頼性要件を指定するのに役立つと見なすかどうかを指定します。
Name:
名前：
preserveOrder
PreserveOrder
Type:
タイプ：
Preference
好み
Default:
デフォルト：
Require
必要とする
This Property specifies whether the application wishes to use a transport protocol that can ensure that data is received by the application at the Remote Endpoint in the same order as it was sent.
このプロパティは、アプリケーションが、送信されたのと同じ順序でリモートエンドポイントのアプリケーションによってデータが受信されることを保証できるトランスポートプロトコルを使用したいかどうかを指定します。
Name:
名前：
zeroRttMsg
Zerorttmsg
Type:
タイプ：
Preference
好み
Default:
デフォルト：
No Preference
好みはありません
This Property specifies whether an application would like to supply a Message to the transport protocol before Connection establishment, which will then be reliably transferred to the Remote Endpoint before or during connection establishment. This Message can potentially be received multiple times (i.e., multiple copies of the Message data could be passed to the Remote Endpoint). See also Section 9.1.3.4.
このプロパティは、接続確立の前にアプリケーションが輸送プロトコルにメッセージを提供するかどうかを指定します。これは、接続確立の前または最中にリモートエンドポイントに確実に転送されます。このメッセージは複数回受信する可能性があります（つまり、メッセージデータの複数のコピーをリモートエンドポイントに渡すことができます）。セクション9.1.3.4も参照してください。
Name:
名前：
multistreaming
マルチストリーミング
Type:
タイプ：
Preference
好み
Default:
デフォルト：
Prefer
好む
This Property specifies whether the application would prefer multiple Connections within a Connection Group to be provided by streams of a single underlying transport connection, where possible.
このプロパティは、可能であれば、単一の基礎となる輸送接続のストリームによって提供される接続グループ内の複数の接続を適用するかどうかを指定します。
Name:
名前：
fullChecksumSend
fullchecksumsend
Type:
タイプ：
Preference
好み
Default:
デフォルト：
Require
必要とする
This Property specifies the application's need for protection against corruption for all data transmitted on this Connection. Disabling this Property could enable the application to influence the sender checksum coverage after Connection establishment (see Section 9.1.3.6).
このプロパティは、この接続に送信されるすべてのデータに対して、アプリケーションの汚職に対する保護の必要性を指定します。このプロパティを無効にすると、アプリケーションが接続の確立後に送信者チェックサムカバレッジに影響を与える可能性があります（セクション9.1.3.6を参照）。
Name:
名前：
fullChecksumRecv
fullchecksumrecv
Type:
タイプ：
Preference
好み
Default:
デフォルト：
Require
必要とする
This Property specifies the application's need for protection against corruption for all data received on this Connection. Disabling this Property could enable the application to influence the required minimum receiver checksum coverage after Connection establishment (see Section 8.1.1).
このプロパティは、この接続で受け取ったすべてのデータに対して、アプリケーションの汚職に対する保護の必要性を指定します。このプロパティを無効にすると、アプリケーションが接続確立後に必要な最小受信機チェックサムカバレッジに影響を与える可能性があります（セクション8.1.1を参照）。
Name:
名前：
congestionControl
混雑制御
Type:
タイプ：
Preference
好み
Default:
デフォルト：
Require
必要とする
This Property specifies whether or not the application would like the Connection to be congestion controlled. Note that if a Connection is not congestion controlled, an application using such a Connection SHOULD itself perform congestion control in accordance with [RFC2914] or use a circuit breaker in accordance with [RFC8084], whichever is appropriate. Also note that reliability is usually combined with congestion control in protocol implementations rendering "reliable but not congestion controlled", a request that is unlikely to succeed. If the Connection is congestion controlled, performing additional congestion control in the application can have negative performance implications.
このプロパティは、アプリケーションが接続を渋滞に制御することを望むかどうかを指定します。接続が混雑制御されていない場合、そのような接続を使用するアプリケーション自体が[RFC2914]に従って輻輳制御を実行するか、[RFC8084]に従って回路ブレーカーを使用する必要があることに注意してください。また、信頼性は通常、プロトコルの実装における混雑制御と組み合わされており、「信頼性がありますが、混雑が制御されていない」とレンダリングします。これは、成功する可能性が低い要求です。接続が輻輳制御されている場合、アプリケーションで追加の混雑制御を実行すると、パフォーマンスの影響がマイナスになります。
Name:
名前：
keepAlive
Keepalive
Type:
タイプ：
Preference
好み
Default:
デフォルト：
No Preference
好みはありません
This Property specifies whether or not the application would like the Connection to send keep-alive packets. Note that if a Connection determines that keep-alive packets are being sent, the application itself SHOULD avoid generating additional keep-alive Messages. Note that, when supported, the system will use the default period for generation of the keep-alive packets. (See also Section 8.1.4.)
このプロパティは、アプリケーションが接続にキープアライブパケットを送信したいかどうかを指定します。接続がキープアライブパケットが送信されていると判断した場合、アプリケーション自体は追加のキープアライブメッセージの生成を避ける必要があることに注意してください。サポートされると、システムはキープアライブパケットの生成にデフォルト期間を使用することに注意してください。（セクション8.1.4も参照してください。）
Name:
名前：
interface
インタフェース
Type:
タイプ：
Set of (Preference, Enumeration)
（好み、列挙）のセット
Default:
デフォルト：
Empty (not setting a Preference for any interface)
空（インターフェイスの好みを設定しない）
This Property allows the application to select any specific network interfaces or categories of interfaces it wants to Require, Prohibit, Prefer, or Avoid. Note that marking a specific interface as Require strictly limits path selection to that single interface, and often leads to less flexible and resilient Connection establishment.
このプロパティを使用すると、アプリケーションは、特定のネットワークインターフェイスまたは必要なインターフェイスのカテゴリを選択、禁止、好み、または避けることができます。特定のインターフェイスをマークすると、その単一のインターフェイスへのパス選択を厳密に制限し、多くの場合、柔軟で回復力のある接続確立につながることが多いことに注意してください。
In contrast to other Selection Properties, this Property is a set of tuples of (enumerated) interface identifier and Preference. It can either be implemented directly as such or be implemented to make one Preference available for each interface and interface type available on the system.
他の選択プロパティとは対照的に、このプロパティは、（列挙された）インターフェイス識別子と好みのタプルのセットです。そのように直接実装するか、システムで利用可能な各インターフェイスとインターフェイスタイプで1つの設定を使用できるように実装することができます。
The set of valid interface types is specific to the implementation or system. For example, on a mobile device, there could be Wi-Fi and Cellular interface types available; whereas, on a desktop computer, Wi-Fi and Wired Ethernet interface types might be available. An implementation should provide all types that are supported on the local system to allow applications to be written generically. For example, if a single implementation is used on both mobile devices and desktop devices, it ought to define the Cellular interface type for both systems, since an application might wish to always prohibit Cellular.
有効なインターフェイスタイプのセットは、実装またはシステムに固有です。たとえば、モバイルデバイスでは、利用可能なWi-Fiおよびセルラーインターフェイスタイプが存在する可能性があります。一方、デスクトップコンピューターでは、Wi-Fiおよび有線イーサネットインターフェイスタイプが利用可能になる可能性があります。実装は、アプリケーションを一般的に記述できるように、ローカルシステムでサポートされているすべてのタイプを提供する必要があります。たとえば、モバイルデバイスとデスクトップデバイスの両方で単一の実装が使用されている場合、アプリケーションは常にセルラーを禁止したい可能性があるため、両方のシステムのセルラーインターフェイスタイプを定義する必要があります。
The set of interface types is expected to change over time as new access technologies become available. The taxonomy of interface types on a given Transport Services System is implementation specific.
インターフェイスタイプのセットは、新しいアクセステクノロジーが利用可能になると、時間とともに変化すると予想されます。特定の輸送サービスシステム上のインターフェイスタイプの分類法は実装固有です。
Interface types SHOULD NOT be treated as a proxy for properties of interfaces, such as metered or unmetered network access. If an application needs to prohibit metered interfaces, this should be specified via Provisioning Domain attributes (see Section 6.2.12) or another specific Property.
インターフェイスタイプは、メーターまたはメーターのネットワークアクセスなど、インターフェイスのプロパティのプロキシとして扱われるべきではありません。アプリケーションでメーターインターフェイスを禁止する必要がある場合、これはプロビジョニングドメイン属性（セクション6.2.12を参照）または別の特定のプロパティを介して指定する必要があります。
Note that this Property is not used to specify an interface scope zone for a particular Endpoint. Section 6.1.2 provides details about how to qualify endpoint candidates on a per-interface basis.
このプロパティは、特定のエンドポイントのインターフェイススコープゾーンを指定するために使用されないことに注意してください。セクション6.1.2では、インターフェイスごとにエンドポイント候補を修飾する方法に関する詳細を説明します。
Name:
名前：
pvd
PVD
Type:
タイプ：
Set of (Preference, Enumeration)
（好み、列挙）のセット
Default:
デフォルト：
Empty (not setting a Preference for any PvD)
空（PVDの好みを設定しない）
Similar to interface (see Section 6.2.11), this Property allows the application to control path selection by selecting which specific PvD or categories of PvDs it wants to Require, Prohibit, Prefer, or Avoid. Provisioning Domains define consistent sets of network properties that might be more specific than network interfaces [RFC7556].
インターフェイスと同様に（セクション6.2.11を参照）、このプロパティにより、アプリケーションは、特定のPVDまたは必要なPVDのカテゴリを要求、禁止、好む、または回避することにより、パス選択を制御できます。プロビジョニングドメインは、ネットワークインターフェイスよりも具体的なネットワークプロパティの一貫したセットを定義します[RFC7556]。
As with interface, this Property is a set of tuples of (enumerated) PvD identifier and Preference. It can either be implemented directly as such or be implemented to make one Preference available for each interface and interface type available on the system.
インターフェースと同様に、このプロパティは、（列挙された）PVD識別子と好みのタプルのセットです。そのように直接実装するか、システムで利用可能な各インターフェイスとインターフェイスタイプで1つの設定を使用できるように実装することができます。
The identification of a specific PvD is specific to the implementation or system. [RFC8801] defines how to use an FQDN to identify a PvD when advertised by a network, but systems might also use other locally relevant identifiers such as string names or Integers to identify PvDs. As with requiring specific interfaces, requiring a specific PvD strictly limits the path selection.
特定のPVDの識別は、実装またはシステムに固有です。[RFC8801]は、ネットワークによって宣伝されたときにFQDNを使用してPVDを識別する方法を定義しますが、システムは文字列名や整数などの他のローカルに関連する識別子を使用してPVDを識別することもできます。特定のインターフェイスを必要とする場合と同様に、特定のPVDを必要とすると、パス選択が厳密に制限されます。
Categories or types of PvDs are also defined to be specific to the implementation or system. These can be useful to identify a service that is provided by a PvD. For example, if an application wants to use a PvD that provides a Voice-Over-IP (VoIP) service on a Cellular network, it can use the relevant PvD type to require a PvD that provides this service, without needing to look up a particular instance. While this does restrict path selection, it is broader than requiring specific PvD instances or interface instances and should be preferred over these options.
PVDのカテゴリまたはタイプは、実装またはシステムに固有のものであると定義されます。これらは、PVDによって提供されるサービスを識別するのに役立ちます。たとえば、アプリケーションがセルラーネットワークでボイスオーバーIP（VOIP）サービスを提供するPVDを使用する場合、関連するPVDタイプを使用して、このサービスを提供するPVDを必要とすることができます。特定のインスタンス。これはパスの選択を制限しますが、特定のPVDインスタンスまたはインターフェイスインスタンスを必要とするよりも広く、これらのオプションよりも優先されるはずです。
Name:
名前：
useTemporaryLocalAddress
USETEMPORARYLOCALADDRESS
Type:
タイプ：
Preference
好み
Default:
デフォルト：
Avoid for Listeners and Rendezvous Connections; Prefer for other Connections
リスナーやランデブー接続を避けてください。他の接続を好む
This Property allows the application to express a preference for the use of temporary local addresses, sometimes called "privacy" addresses [RFC8981]. Temporary addresses are generally used to prevent linking connections over time when a stable address, sometimes called a "permanent" address, is not needed. There are some caveats to note when specifying this Property. First, if an application requires the use of temporary addresses, the resulting Connection cannot use IPv4 because temporary addresses do not exist in IPv4. Second, temporary local addresses might involve trading off privacy for performance. For instance, temporary addresses (e.g., [RFC8981]) can interfere with resumption mechanisms that some protocols rely on to reduce initial latency.
このプロパティにより、アプリケーションは、「プライバシー」アドレス[RFC8981]と呼ばれることもある一時的なローカルアドレスの使用に対する好みを表すことができます。通常、一時的なアドレスは、「永続的な」アドレスと呼ばれる安定したアドレスが必要ない場合に、時間の経過とともに接続をリンクするのを防ぐために使用されます。このプロパティを指定する際に注意すべき注意事項がいくつかあります。まず、アプリケーションが一時アドレスの使用を必要とする場合、IPv4には一時アドレスが存在しないため、結果の接続はIPv4を使用できません。第二に、一時的なローカルアドレスには、パフォーマンスのためにプライバシーを取引することが含まれる場合があります。たとえば、一時的なアドレス（[RFC8981]など）は、一部のプロトコルが初期遅延を減らすために依存する再開メカニズムを妨害する可能性があります。
Name:
名前：
multipath
マルチパス
Type:
タイプ：
Enumeration
列挙
Default:
デフォルト：
Disabled for Connections created through Initiate and Rendezvous; Passive for Listeners
InitiateおよびRendezvousを通じて作成された接続に対して無効化されています。リスナーのためのパッシブ
This Property specifies whether, and how, applications want to take advantage of transferring data across multiple paths between the same end hosts. Using multiple paths allows Connections to migrate between interfaces or aggregate bandwidth as availability and performance properties change. Possible values are as follows:
このプロパティは、アプリケーションが同じエンドホスト間で複数のパスでデータを転送することを利用するかどうか、および方法を指定します。複数のパスを使用すると、接続がインターフェイスまたは集約帯域幅の間を移行し、可用性とパフォーマンスプロパティが変化するようになります。考えられる値は次のとおりです。
Disabled:
無効：
The Connection will not use multiple paths once established, even if the chosen transport supports using multiple paths.
接続は、選択されたトランスポートが複数のパスを使用してサポートしている場合でも、一度確立された複数のパスを使用しません。
Active:
アクティブ：
The Connection will negotiate the use of multiple paths if the chosen transport supports it.
接続は、選択したトランスポートがサポートしている場合、複数のパスの使用を交渉します。
Passive:
受け身：
The Connection will support the use of multiple paths if the Remote Endpoint requests it.
リモートエンドポイントが要求する場合、接続は複数のパスの使用をサポートします。
The policy for using multiple paths is specified using the separate multipathPolicy Property; see Section 8.1.7. To enable the peer Endpoint to initiate additional paths toward a local address other than the one initially used, it is necessary to set the advertisesAltaddr Property (see Section 6.2.15).
複数のパスを使用するためのポリシーは、個別のMultiPathpolicyプロパティを使用して指定されています。セクション8.1.7を参照してください。ピアエンドポイントが最初に使用されたもの以外のローカルアドレスへの追加のパスを開始できるようにするには、AdvertiseSaltaddrプロパティを設定する必要があります（セクション6.2.15を参照）。
Setting this Property to Active can have privacy implications. It enables the transport to establish connectivity using alternate paths that might result in users being linkable across the multiple paths, even if the advertisesAltaddr Property (see Section 6.2.15) is set to false.
このプロパティをアクティブに設定すると、プライバシーの影響があります。AdversiseAltaddrプロパティ（セクション6.2.15を参照）がfalseに設定されている場合でも、複数のパス全体でユーザーがリンクできるようになる可能性のある代替パスを使用して、トランスポートが接続性を確立できるようにします。
Note that this Property has no corresponding Selection Property of type "Preference". Enumeration values other than Disabled are interpreted as a preference for choosing protocols that can make use of multiple paths. The Disabled value implies a requirement not to use multiple paths in parallel but does not prevent choosing a protocol that is capable of using multiple paths, e.g., it does not prevent choosing TCP but prevents sending the MP_CAPABLE option in the TCP handshake.
このプロパティには、「設定」タイプの対応する選択プロパティがないことに注意してください。無効以外の列挙値は、複数のパスを使用できるプロトコルを選択する方が優先されるものとして解釈されます。無効値は、複数のパスを並行して使用しないことを要件であることを意味しますが、複数のパスを使用できるプロトコルの選択を妨げません。たとえば、TCPの選択を妨げず、TCPハンドシェークでMP_Capableオプションの送信を防ぎます。
Name:
名前：
advertisesAltaddr
Advertisesaltaddr
Type:
タイプ：
Boolean
ブール
Default:
デフォルト：
false
間違い
This Property specifies whether alternative addresses, e.g., of other interfaces, ought to be advertised to the peer Endpoint by the Protocol Stack. Advertising these addresses enables the peer Endpoint to establish additional connectivity, e.g., for Connection migration or using multiple paths.
このプロパティは、他のインターフェイスなどの代替アドレスが、プロトコルスタックによってピアエンドポイントに宣伝されるべきかどうかを指定します。これらのアドレスを宣伝することにより、ピアエンドポイントは、接続の移行や複数のパスを使用するための追加の接続性を確立することができます。
Note that this can have privacy implications because it might result in users being linkable across the multiple paths. Also, note that setting this to false does not prevent the local Transport Services System from _establishing_ connectivity using alternate paths (see Section 6.2.14); it only prevents _proactive advertisement_ of addresses.
これにより、プライバシーへの影響がある可能性があることに注意してください。これにより、ユーザーが複数のパスでリンク可能になる可能性があるためです。また、これをfalseに設定しても、ローカルトランスポートサービスシステムが代替パスを使用して_ESTABLISHING_接続を妨げないことに注意してください（セクション6.2.14を参照）。アドレスの_Proactive Advertisement_のみを防ぎます。
Name:
名前：
direction
方向
Type:
タイプ：
Enumeration
列挙
Default:
デフォルト：
Bidirectional
双方向
This Property specifies whether an application wants to use the Connection for sending and/or receiving data. Possible values are as follows:
このプロパティは、アプリケーションがデータの送信および/または受信に接続を使用するかどうかを指定します。考えられる値は次のとおりです。
Bidirectional:
双方向：
The Connection must support sending and receiving data.
接続は、データの送信と受信をサポートする必要があります。
Unidirectional send:
単方向の送信：
The Connection must support sending data, and the application cannot use the Connection to receive any data.
接続はデータの送信をサポートする必要があり、アプリケーションは接続を使用してデータを受信することはできません。
Unidirectional receive:
単方向受信：
The Connection must support receiving data, and the application cannot use the Connection to send any data.
接続はデータの受信をサポートする必要があり、アプリケーションは接続を使用してデータを送信できません。
Since unidirectional communication can be supported by transports offering bidirectional communication, specifying unidirectional communication might cause a Protocol Stack that supports bidirectional communication to be selected.
単方向通信は双方向通信を提供する輸送によってサポートできるため、単方向通信を指定すると、双方向通信をサポートするプロトコルスタックが選択される可能性があります。
Name:
名前：
softErrorNotify
softerRornotify
Type:
タイプ：
Preference
好み
Default:
デフォルト：
No Preference
好みはありません
This Property specifies whether an application considers it useful to be informed when an ICMP error message arrives that does not force termination of a connection. When set to true, received ICMP errors are available as SoftError events; see Section 8.3.1. Note that even if a protocol supporting this Property is selected, not all ICMP errors will necessarily be delivered, so applications cannot rely upon receiving them [RFC8085].
このプロパティは、接続の終了を強制しないICMPエラーメッセージが到着したときに、アプリケーションがそれを通知するのに役立つと見なすかどうかを指定します。Trueに設定すると、受信したICMPエラーがSofterrorイベントとして利用できます。セクション8.3.1を参照してください。このプロパティをサポートするプロトコルが選択されたとしても、すべてのICMPエラーが必ずしも配信されるわけではないため、アプリケーションがそれらを受信することに依存することはできないことに注意してください[RFC8085]。
Name:
名前：
activeReadBeforeSend
ActiverEadBeforesEnd
Type:
タイプ：
Preference
好み
Default:
デフォルト：
No Preference
好みはありません
The most common client-server communication pattern involves the client actively opening a Connection, then sending data to the server. The server listens (passive open), reads, and then answers. This Property specifies whether an application wants to diverge from this pattern by either:
最も一般的なクライアントサーバー通信パターンには、クライアントが接続を積極的に開き、サーバーにデータを送信することが含まれます。サーバーは、耳を傾け（パッシブオープン）、読み取り、および回答します。このプロパティは、アプリケーションが次のいずれかでこのパターンから分岐したいかどうかを指定します。
1. actively opening with Initiate, immediately followed by reading or
1. 初心者で積極的にオープンし、すぐに読書が続きます
2. passively opening with Listen, immediately followed by writing.
2. 聞きながら受動的に開くと、すぐに書くことができます。
This Property is ignored when establishing connections using Rendezvous. Requiring this Property limits the choice of mappings to underlying protocols, which can reduce efficiency. For example, it prevents the Transport Services System from mapping Connections to Stream Control Transmission Protocol (SCTP) streams, where the first transmitted data takes the role of an active open signal.
このプロパティは、Rendezvousを使用して接続を確立するときに無視されます。このプロパティを必要とすると、マッピングの選択が基礎となるプロトコルへの選択が制限され、効率を低下させる可能性があります。たとえば、輸送サービスシステムが接続をマッピングして、最初の送信データがアクティブなオープン信号の役割を担うストリーム制御伝送プロトコル（SCTP）ストリームにマッピングすることを防ぎます。
Most Security Parameters, e.g., TLS ciphersuites, local identity and private key, etc., can be configured statically. Others are dynamically configured during Connection establishment. Security Parameters and callbacks are partitioned based on their place in the lifetime of Connection establishment. Similar to Transport Properties, both parameters and callbacks are inherited during cloning (see Section 7.4).
ほとんどのセキュリティパラメーター、たとえば、TLS暗号、ローカルアイデンティティ、プライベートキーなどは、静的に構成できます。その他は、接続の確立中に動的に構成されます。セキュリティパラメーターとコールバックは、接続確立の生涯の位置に基づいて分割されます。輸送プロパティと同様に、クローニング中にパラメーターとコールバックの両方が継承されます（セクション7.4を参照）。
This document specifies an abstract API, which could appear to conflict with the need for Security Parameters to be unambiguous. The Transport Services System SHOULD provide reasonable, secure defaults for each enumerated Security Parameter, such that users of the system only need to specify parameters required to establish a secure connection (e.g., serverCertificate or clientCertificate). Specifying Security Parameters from enumerated values (e.g., specific ciphersuites) might constrain which transport protocols can be selected during Connection establishment.
このドキュメントは、抽象的なAPIを指定します。これは、セキュリティパラメーターが明確になる必要があると矛盾するように見える可能性があります。トランスポートサービスシステムは、列挙された各セキュリティパラメーターの合理的で安全なデフォルトを提供する必要があります。これにより、システムのユーザーは、安全な接続（ServerCertificateまたはClientCertificateなど）を確立するために必要なパラメーターを指定する必要があります。列挙された値（例：特定の暗号筋）からセキュリティパラメーターを指定すると、接続確立中にどの輸送プロトコルを選択できるかを制約する場合があります。
Security Parameters are specified in the preestablishment phase and are created as follows:
セキュリティパラメーターは、事前設定フェーズで指定され、次のように作成されます。
SecurityParameters := NewSecurityParameters()
Specific parameters are added using a call to Set on the SecurityParameters.
特定のパラメーターは、SecurityParametersに設定する呼び出しを使用して追加されます。
As with the rest of the Transport Services API, the exact names of parameters and/or values of Enumerations (e.g., ciphersuites) used in the Security Parameters are specific to the system or implementation and ought to be chosen to follow the principle of least surprise for users of the platform/language environment in question.
他のトランスポートサービスAPIと同様に、セキュリティパラメーターで使用される列挙の正確な名前および/または列挙の値（ciphersuitesなど）はシステムまたは実装に固有のものであり、最も驚きの原則に従うために選択する必要があります問題のプラットフォーム/言語環境のユーザー向け。
For Security Parameters that are Enumerations of known values, such as TLS ciphersuites, implementations are responsible for exposing the set of values they support. For Security Parameters that are not simple value types, such as certificates and keys, implementations are responsible for exposing types appropriate for the platform/ language environment.
TLS Ciphersuitesなどの既知の値の列挙であるセキュリティパラメーターの場合、実装は、サポートする値のセットを公開する責任があります。証明書やキーなどの単純な値タイプではないセキュリティパラメーターの場合、実装はプラットフォーム/言語環境に適したタイプを公開する責任があります。
Applications SHOULD use common safe defaults for values such as TLS ciphersuites whenever possible. However, as discussed in [RFC8922], many transport security protocols require specific Security Parameters and constraints from the client at the time of configuration and actively during a handshake.
アプリケーションは、可能な限りTLS ciphersuitesなどの値に対して一般的な安全なデフォルトを使用する必要があります。ただし、[RFC8922]で説明したように、多くの輸送セキュリティプロトコルには、構成時に、握手中に積極的にクライアントからの特定のセキュリティパラメーターと制約が必要です。
The set of Security Parameters defined here is not exhaustive, but illustrative. Implementations SHOULD expose an equivalent to the parameters listed below to allow for sufficient configuration of Security Parameters, but the details are expected to vary based on platform and implementation constraints. Applications MUST be able to constrain the security protocols and versions that the Transport Services System will use.
ここで定義されているセキュリティパラメーターのセットは、網羅的ではなく、実例です。実装は、セキュリティパラメーターの十分な構成を可能にするために、以下にリストされているパラメーターに相当する必要がありますが、詳細はプラットフォームと実装の制約に基づいて異なると予想されます。アプリケーションは、トランスポートサービスシステムが使用するセキュリティプロトコルとバージョンを制約できる必要があります。
Representation of Security Parameters in implementations ought to parallel that chosen for Transport Property names as suggested in Section 5.
実装におけるセキュリティパラメーターの表現は、セクション5で提案されているように、輸送プロパティ名に選択されたものと並行する必要があります。
Connections that use Transport Services SHOULD use security in general. However, for compatibility with endpoints that do not support transport security protocols (such as a TCP endpoint that does not support TLS), applications can initialize their Security Parameters to indicate that security can be disabled or opportunistic. If security is disabled, the Transport Services System will not attempt to add transport security automatically. If security is opportunistic, it will allow Connections without transport security, but it will still attempt to use unauthenticated security if available.
輸送サービスを使用する接続は、一般的にセキュリティを使用する必要があります。ただし、輸送セキュリティプロトコル（TLSをサポートしないTCPエンドポイントなど）をサポートしていないエンドポイントとの互換性の場合、アプリケーションはセキュリティパラメーターを初期化して、セキュリティが無効または日和見的であることを示すことができます。セキュリティが無効になっている場合、トランスポートサービスシステムは輸送セキュリティを自動的に追加しようとしません。セキュリティが日和見的である場合、輸送セキュリティのない接続が可能になりますが、利用可能な場合は認定されていないセキュリティを使用しようとします。
SecurityParameters := NewDisabledSecurityParameters()
SecurityParameters := NewOpportunisticSecurityParameters()
Name:
名前：
allowedSecurityProtocols
AldulseCurityProtocols
Type:
タイプ：
Implementation-specific Enumeration of security protocol names and/or versions
セキュリティプロトコル名および/またはバージョンの実装固有の列挙
Default:
デフォルト：
Implementation-specific best available security protocols
実装固有のベスト利用可能なセキュリティプロトコル
This Property allows applications to restrict which security protocols and security protocol versions can be used in the Protocol Stack. Applications MUST be able to constrain the security protocols used by this or an equivalent mechanism, in order to prevent the use of security protocols with unknown or weak security properties.
このプロパティにより、アプリケーションは、どのセキュリティプロトコルとセキュリティプロトコルバージョンをプロトコルスタックで使用できるかを制限できます。アプリケーションは、未知のセキュリティプロパティまたは弱いセキュリティプロパティを備えたセキュリティプロトコルの使用を防ぐために、これまたは同等のメカニズムで使用されるセキュリティプロトコルを制約できる必要があります。
SecurityParameters.Set(allowedSecurityProtocols, [ tls_1_2, tls_1_3 ])
Names:
名前：
serverCertificate, clientCertificate
serverCertificate、clientCertificate
Type:
タイプ：
Array of certificate objects
証明書オブジェクトの配列
Default:
デフォルト：
Empty array
空の配列
One or more certificate bundles identifying the Local Endpoint as a server certificate or a client certificate. Multiple bundles may be provided to allow selection among different Protocol Stacks that may require differently formatted bundles. The form and format of the certificate bundle are implementation specific. Note that if the private keys associated with a bundle are not available, e.g., since they are stored in Hardware Security Modules (HSMs), handshake callbacks are necessary. See below for details.
ローカルエンドポイントをサーバー証明書またはクライアント証明書として識別する1つ以上の証明書バンドル。異なるフォーマットされたバンドルを必要とする可能性のあるさまざまなプロトコルスタック間の選択を可能にするために、複数のバンドルを提供できます。証明書バンドルのフォームと形式は実装固有です。バンドルに関連付けられたプライベートキーが使用できない場合、たとえば、ハードウェアセキュリティモジュール（HSM）に保存されているため、ハンドシェイクコールバックが必要です。詳細については、以下をご覧ください。
SecurityParameters.Set(serverCertificate, myCertificateBundle[])
SecurityParameters.Set(clientCertificate, myCertificateBundle[])
Name:
名前：
pinnedServerCertificate
PinnedServerCertificate
Type:
タイプ：
Array of certificate chain objects
証明書チェーンオブジェクトの配列
Default:
デフォルト：
Empty array
空の配列
Zero or more certificate chains to use as pinned server certificates, such that connecting will fail if the presented server certificate does not match one of the supplied pinned certificates. The form and format of the certificate chain are implementation specific.
ピン留めサーバー証明書として使用するゼロ以上の証明書チェーン。これにより、提示されたサーバー証明書が提供されたピン留め証明書のいずれかと一致しない場合、接続が故障します。証明書チェーンのフォームと形式は実装固有です。
SecurityParameters.Set(pinnedServerCertificate, yourCertificateChain[])
Name:
名前：
alpn
alpn
Type:
タイプ：
Array of strings
文字列の配列
Default:
デフォルト：
Automatic selection
自動選択
Application-Layer Protocol Negotiation (ALPN) values: used to indicate which application-layer protocols are negotiated by the security protocol layer. See [ALPN] for a definition of the ALPN field. Note that the Transport Services System can provide ALPN values automatically based on the protocols being used, if not explicitly specified by the application.
アプリケーション層プロトコルネゴシエーション（ALPN）値：セキュリティプロトコルレイヤーによって交渉されるアプリケーション層プロトコルを示すために使用されます。ALPNフィールドの定義については、[ALPN]を参照してください。輸送サービスシステムは、アプリケーションによって明示的に指定されていない場合、使用されているプロトコルに基づいてALPN値を自動的に提供できることに注意してください。
SecurityParameters.Set(alpn, ["h2"])
Names:
名前：
supportedGroup, ciphersuite, signatureAlgorithm
supportedgroup、ciphersuite、signaturealgorithm
Types:
種類：
Arrays of implementation-specific Enumerations
実装固有の列挙の配列
Default:
デフォルト：
Automatic selection
自動選択
These are used to restrict what cryptographic parameters are used by underlying transport security protocols. When not specified, these algorithms should use known and safe defaults for the system.
これらは、基礎となる輸送セキュリティプロトコルによって使用される暗号化パラメーターを制限するために使用されます。指定されていない場合、これらのアルゴリズムはシステムに既知の安全なデフォルトを使用する必要があります。
SecurityParameters.Set(supportedGroup, secp256r1)
SecurityParameters.Set(ciphersuite, TLS_AES_128_GCM_SHA256)
SecurityParameters.Set(signatureAlgorithm, ecdsa_secp256r1_sha256)
Names:
名前：
maxCachedSessions, cachedSessionLifetimeSeconds
maxcachedsessions、cachedsessionlifetimeseconds
Type:
タイプ：
Integer
整数
Default:
デフォルト：
Automatic selection
自動選択
These values are used to tune session cache capacity and lifetime and can be extended to include other policies.
これらの値は、セッションのキャッシュ容量と寿命をチューニングするために使用され、他のポリシーを含めるように拡張できます。
SecurityParameters.Set(maxCachedSessions, 16)
SecurityParameters.Set(cachedSessionLifetimeSeconds, 3600)
Name:
名前：
preSharedKey
PresharedKey
Type:
タイプ：
Key and identity (platform specific)
キーとアイデンティティ（プラットフォーム固有）
Default:
デフォルト：
None
なし
Used to install pre-shared keying material established out of band. Each instance of pre-shared keying material is associated with some identity that typically identifies its use or has some protocol-specific meaning to the Remote Endpoint. Note that the use of a pre-shared key will tend to select a single security protocol and, therefore, directly select a single underlying Protocol Stack. A Transport Services API could express None in an environment-typical way, e.g., as a Union type or special value.
バンドから確立された事前に共有キーイング素材をインストールするために使用されます。事前に共有キーイング素材の各インスタンスは、通常その使用を識別するか、リモートエンドポイントにプロトコル固有の意味を持ついくつかのアイデンティティに関連付けられています。事前共有キーの使用は、単一のセキュリティプロトコルを選択する傾向があるため、単一の基礎となるプロトコルスタックを直接選択する傾向があることに注意してください。輸送サービスAPIは、環境の典型的な方法で、たとえば組合の種類または特別な価値として表現できません。
SecurityParameters.Set(preSharedKey, key, myIdentity)
Security decisions, especially pertaining to trust, are not static. Once configured, parameters can also be supplied during Connection establishment. These are best handled as client-provided callbacks. Callbacks block the progress of the Connection establishment, which distinguishes them from other events in the Transport Services System. How callbacks and events are implemented is specific to each implementation. Security handshake callbacks that could be invoked during Connection establishment include:
特に信頼に関するセキュリティの決定は静的ではありません。構成されたら、接続確立中にパラメーターを提供することもできます。これらは、クライアントが提供するコールバックとして最適に処理されます。コールバックは、輸送サービスシステムの他のイベントと区別する接続確立の進行をブロックします。コールバックとイベントの実装方法は、各実装に固有です。接続の確立中に呼び出される可能性のあるセキュリティハンドシェイクコールバックは次のとおりです。
* Trust verification callback: Invoked when a Remote Endpoint's trust must be verified before the handshake protocol can continue. For example, the application could verify an X.509 certificate as described in [RFC5280].
* 信頼検証コールバック：ハンドシェイクプロトコルが継続する前に、リモートエンドポイントの信頼を検証する必要がある場合に呼び出されます。たとえば、[RFC5280]で説明されているように、アプリケーションはX.509証明書を検証できます。
TrustCallback := NewCallback({
// Handle the trust and return the result
})
SecurityParameters.SetTrustVerificationCallback(TrustCallback)
* Identity challenge callback: Invoked when a private key operation is required, e.g., when local authentication is requested by a Remote Endpoint.
* Identity Challengeコールバック：リモートエンドポイントによってローカル認証が要求された場合、秘密キー操作が必要なときに呼び出されます。
ChallengeCallback := NewCallback({
// Handle the challenge
})
SecurityParameters.SetIdentityChallengeCallback(ChallengeCallback)
Before a Connection can be used for data transfer, it needs to be established. Establishment ends the preestablishment phase; all transport Properties and cryptographic parameter specification must be complete before establishment, as these will be used to select Candidate Paths and Protocol Stacks for the Connection. Establishment can be active, using the Initiate action; passive, using the Listen action; or simultaneous for peer-to-peer connections, using the Rendezvous action. These actions are described in the subsections below.
データ転送に接続を使用する前に、確立する必要があります。設立は、事前設定段階を終了します。これらは、接続の候補パスとプロトコルスタックを選択するために使用されるため、確立前にすべての輸送プロパティと暗号化パラメーター仕様を完了する必要があります。開始アクションを使用して、設立がアクティブになる可能性があります。パッシブ、リスニングアクションを使用します。または、ランデブーアクションを使用して、ピアツーピア接続の同時。これらのアクションは、以下のサブセクションで説明されています。
Active open is the action of establishing a Connection to a Remote Endpoint presumed to be listening for incoming Connection requests. Active open is used by clients in client-server interactions. Active open is supported by the Transport Services API through the Initiate action:
Active Openとは、着信接続要求を聞いていると推定されるリモートエンドポイントへの接続を確立するアクションです。Active Openは、クライアントとサーバーのインタラクションでクライアントによって使用されます。Active Openは、開始アクションを通じてトランスポートサービスAPIによってサポートされています。
Connection := Preconnection.Initiate(timeout?)
The timeout parameter specifies how long to wait before aborting active open. Before calling Initiate, the caller must have populated a Preconnection object with a Remote Endpoint object to identify the Endpoint, optionally a Local Endpoint object (if not specified, the system will attempt to determine a suitable Local Endpoint), as well as all Properties necessary for candidate selection.
タイムアウトパラメーターは、Active Openを中止するまでの待機時間を指定します。呼び出す前に、Callingを呼び出す前に、発信者は、オプションでローカルエンドポイントオブジェクト（指定されていない場合、システムは適切なローカルエンドポイントを決定しようとします）と必要なすべてのプロパティを識別するために、リモートエンドポイントオブジェクトをリモートエンドポイントオブジェクトに事前接続オブジェクトに入力している必要があります。候補者の選択。
The Initiate action returns a Connection object. Once Initiate has been called, any changes to the Preconnection MUST NOT have any effect on the Connection. However, the Preconnection can be reused, e.g., to Initiate another Connection.
開始アクションは接続オブジェクトを返します。開始が呼び出されると、事前接続の変更は接続に影響を与えてはなりません。ただし、別の接続を開始するために、事前接続を再利用することができます。
Once Initiate is called, the Candidate Protocol Stack(s) can cause one or more candidate transport-layer connections to be created to the specified Remote Endpoint. The caller could immediately begin sending Messages on the Connection (see Section 9.2) after calling Initiate; note that any data marked as "safely replayable" that is sent while the Connection is being established could be sent multiple times or using multiple candidates.
開始が呼び出されると、候補プロトコルスタックは、指定されたリモートエンドポイントに1つ以上の候補輸送層接続を作成する可能性があります。発信者は、initiateを呼び出した後、すぐに接続にメッセージの送信を開始できます（セクション9.2を参照）。接続が確立されている間に送信される「安全に再生可能」としてマークされたデータは、複数回送信したり、複数の候補を使用したりすることができることに注意してください。
The following events can be sent by the Connection after Initiate is called:
次のイベントは、開始後に接続によって送信できます。
Connection -> Ready<>
The Ready event occurs after Initiate has established a transport-layer connection on at least one usable Candidate Protocol Stack over at least one Candidate Path. No Receive events (see Section 9.3) will occur before the Ready event for Connections established using Initiate.
Readyイベントは、Initiateが少なくとも1つの候補パスで少なくとも1つの使用可能な候補プロトコルスタックで輸送層接続を確立した後に発生します。Initiateを使用して確立された接続の準備が整ったイベントの前に、受信イベント（セクション9.3を参照）は発生します。
Connection -> EstablishmentError<reason?>
An EstablishmentError occurs when:
確立エラーは次の場合に発生します。
* the set of transport Properties and Security Parameters cannot be fulfilled on a Connection for initiation (e.g., the set of available paths and/or Protocol Stacks meeting the constraints is empty) or reconciled with the Local and/or Remote Endpoints,
* 輸送プロパティとセキュリティパラメーターのセットは、開始の接続では履行できません（たとえば、制約を満たす利用可能なパスおよび/またはプロトコルスタックのセットは空です）またはローカルおよび/またはリモートエンドポイントと調整されます。
* a Remote Endpoint Identifier cannot be resolved, or
* リモートエンドポイント識別子を解決することはできません
* no transport-layer connection can be established to the Remote Endpoint (e.g., because the Remote Endpoint is not accepting connections, the application is prohibited from opening a Connection by the operating system, or the establishment attempt has timed out for any other reason).
* リモートエンドポイントへの輸送層接続を確立することはできません（たとえば、リモートエンドポイントが接続を受け入れていないため、アプリケーションがオペレーティングシステムによる接続を開くことは禁止されているか、その他の理由で確立の試みがタイムアウトしています）。
Connection establishment and transmission of the first Message can be combined in a single action (Section 9.2.5).
最初のメッセージの接続確立と送信は、単一のアクション（セクション9.2.5）で結合できます。
Passive open is the action of waiting for Connections from Remote Endpoints, commonly used by servers in client-server interactions. Passive open is supported by the Transport Services API through the Listen action and returns a Listener object:
パッシブオープンは、クライアントサーバーインタラクションでサーバーが一般的に使用するリモートエンドポイントからの接続を待つアクションです。パッシブオープンは、リスニングアクションを介してトランスポートサービスAPIによってサポートされ、リスナーオブジェクトを返します。
Listener := Preconnection.Listen()
Before calling Listen, the caller must have initialized the Preconnection during the preestablishment phase with a Local Endpoint object, as well as all Properties necessary for Protocol Stack selection. A Remote Endpoint can optionally be specified, to constrain what Connections are accepted.
リスを呼び出す前に、発信者は、ローカルエンドポイントオブジェクトとプロトコルスタックの選択に必要なすべてのプロパティを使用して、事前確定段階で前提条件を初期化している必要があります。リモートエンドポイントをオプションで指定して、どの接続が受け入れられているかを制約します。
The Listen action returns a Listener object. Once Listen has been called, any changes to the Preconnection MUST NOT have any effect on the Listener. The Preconnection can be disposed of or reused, e.g., to create another Listener.
リスニングアクションはリスナーオブジェクトを返します。リッスンが呼び出されると、前提条件の変更はリスナーに影響を与えてはなりません。事前接続は、別のリスナーを作成するために、廃棄または再利用できます。
Listener.Stop()
Listening continues until the global context shuts down or until the Stop action is performed on the Listener object.
リスニングは、グローバルコンテキストがシャットダウンするまで、またはリスナーオブジェクトで停止アクションが実行されるまで続きます。
Listener -> ConnectionReceived<Connection>
The ConnectionReceived event occurs when:
ConnectionReceivedイベントは、次の場合に発生します。
* a Remote Endpoint has established or cloned (e.g., by creating a new stream in a multi-stream transport; see Section 7.4) a transport-layer connection to this Listener (for connection-oriented transport protocols), or
* リモートエンドポイントが確立またはクローン化されています（たとえば、マルチストリームトランスポートに新しいストリームを作成することにより、セクション7.4を参照）このリスナーへの輸送層接続（接続指向のトランスポートプロトコル用）、または
* the first Message has been received from the Remote Endpoint (for connectionless protocols or streams of a multi-streaming transport) causing a new Connection to be created.
* 最初のメッセージは、リモートエンドポイント（マルチストリーミングトランスポートのコネクションレスプロトコルまたはストリーム用）から受信され、新しい接続が作成されます。
The resulting Connection is contained within the ConnectionReceived event and is ready to use as soon as it is passed to the application via the event.
結果の接続は、ConnectionReceedイベント内に含まれており、イベントを介してアプリケーションに渡されるとすぐに使用できます。
Listener.SetNewConnectionLimit(value)
If the caller wants to rate-limit the number of inbound Connections that will be delivered, it can set a cap using SetNewConnectionLimit. This mechanism allows a server to protect itself from being drained of resources. Each time a new Connection is delivered by the ConnectionReceived event, the value is automatically decremented. Once the value reaches zero, no further Connections will be delivered until the caller sets the limit to a higher value. By default, this value is Infinite. The caller is also able to reset the value to Infinite at any point.
発信者が配信されるインバウンド接続の数を評価したい場合、SetNewConnectionLimitを使用してキャップを設定できます。このメカニズムにより、サーバーはリソースの排出から自分自身を保護できます。Connection Receivedイベントによって新しい接続が配信されるたびに、値は自動的に減少します。値がゼロになると、発信者が制限をより高い値に設定するまで、それ以上の接続は配信されません。デフォルトでは、この値は無限です。発信者は、任意の時点で値を無限にリセットすることもできます。
Listener -> EstablishmentError<reason?>
An EstablishmentError occurs when:
確立エラーは次の場合に発生します。
* the Properties and Security Parameters of the Preconnection cannot be fulfilled for listening or cannot be reconciled with the Local Endpoint (and/or Remote Endpoint, if specified),
* 前提条件のプロパティとセキュリティパラメーターは、リスニングのために満たすことができず、ローカルエンドポイント（および/またはリモートエンドポイント、指定されている場合）と調整することはできません。
* the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or
* ローカルエンドポイント（または指定されている場合はリモートエンドポイント）を解決できない、または
* the application is prohibited from listening by policy.
* アプリケーションは、ポリシーごとにリスニングすることを禁止されています。
Listener -> Stopped<>
A Stopped event occurs after the Listener has stopped listening.
リスナーがリスニングを停止した後、停止したイベントが発生します。
Simultaneous peer-to-peer Connection establishment is supported by the Rendezvous action:
同時にピアツーピア接続確立は、ランデブーアクションによってサポートされています。
Preconnection.Rendezvous()
A Preconnection object used in a Rendezvous MUST have both the Local Endpoint candidates and the Remote Endpoint candidates specified, along with the Transport Properties and Security Parameters needed for Protocol Stack selection before the Rendezvous action is initiated.
ランデブーで使用される事前接続オブジェクトには、ローカルエンドポイント候補と指定されたリモートエンドポイント候補の両方が、ランデブーアクションが開始される前にプロトコルスタック選択に必要なトランスポートプロパティとセキュリティパラメーターを備えている必要があります。
The Rendezvous action listens on the Local Endpoint candidates for an incoming Connection from the Remote Endpoint candidates, while also simultaneously trying to establish a Connection from the Local Endpoint candidates to the Remote Endpoint candidates.
Rendezvousアクションは、リモートエンドポイント候補からの着信接続のローカルエンドポイント候補に耳を傾け、同時にローカルエンドポイント候補からリモートエンドポイント候補への接続を確立しようとします。
If there are multiple Local Endpoints or Remote Endpoints configured, then initiating a Rendezvous action will cause the Transport Services Implementation to systematically probe the reachability of those endpoint candidates following an approach such as that used in Interactive Connectivity Establishment (ICE) [RFC8445].
構成された複数のローカルエンドポイントまたはリモートエンドポイントがある場合、ランデブーアクションを開始すると、インタラクティブ接続確立（ICE）[RFC8445]で使用されるアプローチに従って、輸送サービスの実装がそれらのエンドポイント候補の到達可能性を体系的にプローブします。
If the endpoints are suspected to be behind a NAT, and the Local Endpoint supports a method of discovering NAT bindings, such as STUN [RFC8489] or Traversal Using Relays around NAT (TURN) [RFC8656], then the Resolve action on the Preconnection can be used to discover such bindings:
エンドポイントがNATの背後にあると疑われている場合、ローカルエンドポイントは、NAT（ターン）[RFC8656]の周りのリレーを使用して、スタン[RFC8489]などのNATバインディングを発見する方法をサポートしている場合、事前接続の解決作用は可能です。そのようなバインディングを発見するために使用されます：
[]LocalEndpoint, []RemoteEndpoint := Preconnection.Resolve()
The Resolve action returns lists of Local Endpoints and Remote Endpoints that represent the concrete addresses, local and server reflexive, on which a Rendezvous for the Preconnection will listen for incoming Connections and to which it will attempt to establish Connections.
Resolve Actionは、ローカルエンドポイントとコンクリートアドレスを表すリモートエンドポイントのリストを返します。ローカルおよびサーバー反射では、事前接続のランデブーが着信接続を聞き、接続を確立しようとします。
Note that the set of Local Endpoints returned by Resolve might or might not contain information about all possible local interfaces, depending on how the Preconnection is configured. The set of available local interfaces can also change over time, so care needs to be taken when using stored interface names.
Resolveによって返されるローカルエンドポイントのセットには、事前接続の構成方法に応じて、可能なすべてのローカルインターフェイスに関する情報が含まれている場合と含まない場合があります。利用可能なローカルインターフェイスのセットも時間とともに変化する可能性があるため、保存されたインターフェイス名を使用する場合は注意が必要です。
An application that uses Rendezvous to establish a peer-to-peer Connection in the presence of NATs will configure the Preconnection object with at least one Local Endpoint that supports NAT binding discovery. It will then Resolve the Preconnection and pass the resulting list of Local Endpoint candidates to the peer via a signaling protocol, for example, as part of an ICE exchange [RFC8445] within SIP [RFC3261] or WebRTC [RFC7478]. The peer will then, via the same signaling channel, return the Remote Endpoint candidates. The set of Remote Endpoint candidates is then configured on the Preconnection:
NATの存在下でRendezvousを使用してピアツーピア接続を確立するアプリケーションは、NAT結合発見をサポートする少なくとも1つのローカルエンドポイントを使用して、Preconnectionオブジェクトを構成します。その後、前序を解決し、たとえばSIP [RFC3261]またはWeBRTC [RFC7478]内の氷交換[RFC8445]の一部として、シグナリングプロトコルを介してローカルエンドポイント候補の結果をピアに渡します。ピアは、同じシグナリングチャネルを介して、リモートエンドポイント候補を返します。リモートエンドポイント候補のセットは、以下の概要で構成されます。
Preconnection.AddRemote([]RemoteEndpoint)
Once the application has added both the Local Endpoint candidates and the Remote Endpoint candidates retrieved from the peer via the signaling channel to the Preconnection, the Rendezvous action is initiated and causes the Transport Services Implementation to begin connectivity checks.
アプリケーションがローカルエンドポイント候補と、シグナリングチャネルを介してピアから取得されたリモートエンドポイント候補の両方を事前接続に追加すると、ランデブーアクションが開始され、トランスポートサービスの実装が接続チェックを開始します。
If successful, the Rendezvous action returns a Connection object via a RendezvousDone event:
成功した場合、Rendezvousアクションは、Rendezvousdoneイベントを介して接続オブジェクトを返します。
Preconnection -> RendezvousDone<Connection>
The RendezvousDone event occurs when a Connection is established with the Remote Endpoint. For connection-oriented transports, this occurs when the transport-layer connection is established; for connectionless transports, it occurs when the first Message is received from the Remote Endpoint. The resulting Connection is contained within the RendezvousDone event and is ready to use as soon as it is passed to the application via the event. Changes made to a Preconnection after Rendezvous has been called MUST NOT have any effect on existing Connections.
Rendezvousdoneイベントは、リモートエンドポイントで接続が確立されたときに発生します。接続指向の輸送の場合、これは輸送層の接続が確立されたときに発生します。Connectionless Transportsの場合、最初のメッセージがリモートエンドポイントから受信されたときに発生します。結果の接続は、Rendezvousdoneイベントに含まれており、イベントを介してアプリケーションに渡されるとすぐに使用する準備ができています。rendezvousが呼び出された後に前提条件に加えられた変更は、既存の接続に影響を与えてはなりません。
An EstablishmentError occurs when:
確立エラーは次の場合に発生します。
* the Properties and Security Parameters of the Preconnection cannot be fulfilled for rendezvous or cannot be reconciled with the Local and/or Remote Endpoints,
* 前接続のプロパティとセキュリティパラメーターは、rendezvousのために満たすことができず、ローカルおよび/またはリモートエンドポイントと調整することはできません。
* the Local Endpoint or Remote Endpoint cannot be resolved,
* ローカルエンドポイントまたはリモートエンドポイントは解決できません。
* no transport-layer connection can be established to the Remote Endpoint, or
* リモートエンドポイントに輸送層接続を確立することはできません。
* the application is prohibited from rendezvous by policy.
* このアプリケーションは、ポリシーによりRendezvousを禁止されています。
Preconnection -> EstablishmentError<reason?>
Connection Groups can be created using the Clone action:
接続グループは、クローンアクションを使用して作成できます。
Connection := Connection.Clone(framer?, connectionProperties?)
Calling Clone on a Connection yields a Connection Group containing two Connections: the parent Connection on which Clone was called and a resulting cloned Connection. The new Connection is actively opened, and it will locally send a Ready event or an EstablishmentError event. Calling Clone on any of these Connections adds another Connection to the Connection Group. Connections in a Connection Group share all Connection Properties except connPriority (see Section 8.1.2), and these Connection Properties are entangled: changing one of the Connection Properties on one Connection in the Connection Group automatically changes the Connection Property for all others. For example, changing connTimeout (see Section 8.1.3) on one Connection in a Connection Group will automatically make the same change to this Connection Property for all other Connections in the Connection Group. Like all other Properties, connPriority is copied to the new Connection when calling Clone, but, in this case, a later change to the connPriority on one Connection does not change it on the other Connections in the same Connection Group.
接続でクローンを呼び出すと、2つの接続を含む接続グループが得られます。クローンが呼び出された親接続と、結果のクローン接続です。新しい接続が積極的にオープンされ、Readyイベントまたは設立イベントがローカルで送信されます。これらの接続のいずれかでクローンを呼び出すと、接続グループに別の接続が追加されます。接続グループ内の接続は、Connpriorityを除くすべての接続プロパティを共有します（セクション8.1.2を参照）。これらの接続プロパティは次のようになります。接続グループの1つの接続の接続プロパティの1つを変更すると、他のすべての接続プロパティが自動的に変更されます。たとえば、接続グループの1つの接続でConnTimeout（セクション8.1.3を参照）を変更すると、接続グループ内の他のすべての接続に対してこの接続プロパティを自動的に変更します。他のすべてのプロパティと同様に、ConnpriorityはCloneを呼び出すときに新しい接続にコピーされますが、この場合、1つの接続のConnpriorityの後の変更は、同じ接続グループの他の接続で変更されません。
The optional connectionProperties parameter allows passing Transport Properties that control the behavior of the underlying stream or connection to be created, e.g., Protocol-specific Properties to request specific stream IDs for SCTP or QUIC.
オプションのConnectionPropertiesパラメーターにより、基礎となるストリームまたは接続の動作を制御するトランスポートプロパティ、たとえば、SCTPまたはQUICの特定のストリームIDを要求するプロトコル固有のプロパティなど。
Message Properties set on a Connection also apply only to that Connection.
接続に設定されたメッセージプロパティは、その接続にのみ適用されます。
A new Connection created by Clone can have a Message Framer assigned via the optional framer parameter of the Clone action. If this parameter is not supplied, the stack of Message Framers associated with a Connection is copied to the cloned Connection when calling Clone. Then, a cloned Connection has the same stack of Message Framers as the Connection from which they are cloned, but these Framers can internally maintain per-Connection state.
クローンによって作成された新しい接続は、クローンアクションのオプションのフレーマーパラメーターを介して割り当てられたメッセージフレーマーを持つことができます。このパラメーターが提供されていない場合、接続に関連付けられたメッセージフレーマーのスタックは、クローンを呼び出すときにクローン接続にコピーされます。次に、クローニングされた接続には、クローン化された接続と同じメッセージフレーマーのスタックがありますが、これらのフレーマーは接続ごとに内部的に維持できます。
It is also possible to check which Connections belong to the same Connection Group. Calling GroupedConnections on a specific Connection returns a set of all Connections in the same group.
同じ接続グループに属する接続を確認することもできます。特定の接続でグループ化された接続を呼び出すと、同じグループのすべての接続のセットが返されます。
[]Connection := Connection.GroupedConnections()
Connections will belong to the same group if the application previously called Clone. Passive Connections can also be added to the same group, e.g., when a Listener receives a new Connection that is just a new stream of an already-active multi-streaming protocol instance.
アプリケーションが以前にCloneと呼ばれる場合、接続は同じグループに属します。パッシブ接続は、例えば、リスナーが既に活動的なマルチストリーミングプロトコルインスタンスの新しいストリームである新しい接続を受信する場合、同じグループに追加することもできます。
If the underlying protocol supports multi-streaming, it is natural to use this functionality to implement Clone. In that case, Connections in a Connection Group are multiplexed together, giving them similar treatment not only inside Endpoints, but also across the end-to-end Internet path.
基礎となるプロトコルがマルチストリーミングをサポートしている場合、この機能を使用してクローンを実装することは自然です。その場合、接続グループ内の接続は一緒に多重化され、エンドポイント内だけでなく、エンドツーエンドのインターネットパス全体でも同様の処理が得られます。
Note that calling Clone can result in on-the-wire signaling, e.g., to open a new transport connection, depending on the underlying Protocol Stack. When Clone leads to the opening of multiple such connections, the Transport Services System will ensure consistency of Connection Properties by uniformly applying them to all underlying connections in a group. Even in such a case, it is possible for a Transport Services System to implement prioritization within a Connection Group (see [TCP-COUPLING] and [RFC8699]).
クローンを呼び出すと、基礎となるプロトコルスタックに応じて、ワイヤー上のシグナリング、たとえば新しい輸送接続を開くことができることに注意してください。クローンが複数のこのような接続を開くことにつながると、輸送サービスシステムは、グループ内のすべての基礎となる接続に均一に適用することにより、接続特性の一貫性を確保します。そのような場合でも、輸送サービスシステムが接続グループ内で優先順位付けを実装することが可能です（[TCP結合]および[RFC8699]を参照）。
Attempts to clone a Connection can result in a CloneError:
接続をクローン化しようとすると、cloneErrorが生じる可能性があります。
Connection -> CloneError<reason?>
A CloneError can also occur later, after Clone was successfully called. In this case, it informs the application that the Connection that sends the CloneError is no longer a part of any Connection Group. For example, this can occur when the Transport Services system is unable to implement entanglement (a Connection Property was changed on a different Connection in the Connection Group, but this change could not be successfully applied to the Connection that sends the CloneError).
クローンが正常に呼び出された後、クロネローも後で発生する可能性があります。この場合、CloneErrorを送信する接続が接続グループの一部ではなくなったことをアプリケーションに通知します。たとえば、これは、輸送サービスシステムがエンタングルメントを実装できない場合に発生する可能性があります（接続グループの別の接続で接続プロパティが変更されましたが、この変更はクロネローを送信する接続に正常に適用できませんでした）。
The connPriority Connection Property operates on Connections in a Connection Group using the same approach as that used in Section 9.1.3.2: when allocating available network capacity among Connections in a Connection Group, sends on Connections with numerically lower priority values will be prioritized over sends on Connections that have numerically higher priority values. Capacity will be shared among these Connections according to the connScheduler Property (Section 8.1.5). See Section 9.2.6 for more details.
Connpriority Connectionプロパティは、セクション9.1.3.2で使用されているアプローチと同じアプローチを使用して接続グループの接続で動作します。接続グループ内の接続間で利用可能なネットワーク容量を割り当てるとき、数値が低い優先度値の接続で送信されます。数値的に優先度の高い値を持つ接続。Connschedulerプロパティ（セクション8.1.5）に従って、これらの接続間で容量が共有されます。詳細については、セクション9.2.6を参照してください。
Transport protocols that are explicitly multipath-aware are expected to automatically manage the set of remote endpoints that they are communicating with and the paths to those endpoints. A PathChange event, described in Section 8.3.2, will be generated when the path changes.
明示的にマルチパス対応の輸送プロトコルは、通信しているリモートエンドポイントのセットとそれらのエンドポイントへのパスを自動的に管理することが期待されます。セクション8.3.2で説明されているPathchangeイベントは、パスが変更されると生成されます。
However, in some cases, it is necessary to explicitly indicate to a Connection that a new Remote Endpoint has become available for use or indicate that a Remote Endpoint is no longer available. This is most common in the case of peer-to-peer connections using Trickle ICE [RFC8838].
ただし、場合によっては、新しいリモートエンドポイントが使用できるようになったこと、またはリモートエンドポイントが使用できなくなったことを示すことを接続に明示的に示す必要があります。これは、トリクルアイスを使用したピアツーピア接続の場合に最も一般的です[RFC8838]。
The AddRemote action can be used to add one or more new Remote Endpoints to a Connection:
AddRemoteアクションを使用して、1つ以上の新しいリモートエンドポイントを接続に追加できます。
Connection.AddRemote([]RemoteEndpoint)
Endpoints that are already known to the Connection are ignored. A call to AddRemote makes the new Remote Endpoints available to the Connection, but whether the Connection makes use of those Endpoints will depend on the underlying transport protocol.
接続に対して既に知られているエンドポイントは無視されます。AddRemoteへの呼び出しにより、新しいリモートエンドポイントが接続で利用可能になりますが、接続がこれらのエンドポイントを使用するかどうかは、基礎となる輸送プロトコルに依存します。
Similarly, the RemoveRemote action can be used to tell a Connection to stop using one or more Remote Endpoints:
同様に、RemoverEmoteアクションを使用して、1つ以上のリモートエンドポイントの使用を停止するための接続を指示できます。
Connection.RemoveRemote([]RemoteEndpoint)
Removing all known Remote Endpoints can have the effect of aborting the connection. The effect of removing the active Remote Endpoint(s) depends on the underlying transport: multipath-aware transports might be able to switch to a new path if other reachable Remote Endpoints exist or the connection might abort.
既知のすべてのリモートエンドポイントを削除すると、接続を中止する効果があります。アクティブなリモートエンドポイントを削除する効果は、基礎となるトランスポートに依存します。マルチパスを意識したトランスポートは、他の到達可能なリモートエンドポイントが存在する場合、または接続が中断された場合に新しいパスに切り替えることができる場合があります。
Similarly, the AddLocal and RemoveLocal actions can be used to add and remove Local Endpoints to or from a Connection.
同様に、AddLocalおよびRemovelocalアクションを使用して、ローカルエンドポイントを接続または接続から削除できます。
During preestablishment and after establishment, Preconnections or Connections can be configured and queried using Connection Properties, and asynchronous information could be available about the state of the Connection via SoftError events.
事前設定中および設立後、接続プロパティを使用して事前接続または接続を構成および照会でき、Softerorイベントを介して接続の状態について非同期情報を利用できるようになります。
Connection Properties represent the configuration and state of the selected Protocol Stack(s) backing a Connection. These Connection Properties can be generic (applying regardless of transport protocol) or specific (applicable to a single implementation of a single transport Protocol Stack). Generic Connection Properties are defined in Section 8.1.
接続プロパティは、選択したプロトコルスタックの構成と状態を表し、接続をバックします。これらの接続プロパティは、汎用（輸送プロトコルに関係なく適用）または特定（単一の輸送プロトコルスタックの単一の実装に適用可能）です。一般的な接続プロパティは、セクション8.1で定義されています。
Protocol-specific Properties are defined in a way that is specific to the transport or implementation to permit more specialized protocol features to be used. Too much reliance by an application on Protocol-specific Properties can significantly reduce the flexibility of a Transport Services System to make appropriate selection and configuration choices. Therefore, it is RECOMMENDED that Generic Connection Properties be used for properties common across different protocols and that Protocol-specific Connection Properties are only used where specific protocols or properties are necessary.
プロトコル固有の特性は、より専門的なプロトコル機能を使用できるように、トランスポートまたは実装に固有の方法で定義されます。プロトコル固有のプロパティに関するアプリケーションによる依存度が大きすぎると、トランスポートサービスシステムの柔軟性を大幅に減らして、適切な選択と構成の選択を行うことができます。したがって、異なるプロトコルで一般的なプロパティに一般的な接続プロパティを使用し、特定のプロトコルまたはプロパティが必要な場合にのみプロトコル固有の接続プロパティを使用することをお勧めします。
The application can set and query Connection Properties on a per-Connection basis. Connection Properties that are not read-only can be set during preestablishment (see Section 6.2), as well as on Connections directly using the SetProperty action:
アプリケーションは、接続ごとに接続プロパティを設定および照会できます。読み取り専用ではない接続プロパティは、準備中に設定できます（セクション6.2を参照）、およびSetPropertyアクションを使用して直接接続することができます。
ErrorCode := Connection.SetProperty(property, value)
If an error is encountered in setting a Property (for example, if the application tries to set a TCP-specific Property on a Connection that is not using TCP), the application MUST be informed about this error via the ErrorCode object. Such errors MUST NOT cause the Connection to be terminated. Note that changing one of the Connection Properties on one Connection in a Connection Group will also change it for all other Connections of that group; see Section 7.4.
プロパティの設定でエラーが発生した場合（たとえば、アプリケーションがTCPを使用していない接続にTCP固有のプロパティを設定しようとする場合）、アプリケーションはエラーコードオブジェクトを介してこのエラーについて通知する必要があります。そのようなエラーは、接続を終了させてはなりません。接続グループ内の1つの接続の1つの接続プロパティの1つを変更すると、そのグループの他のすべての接続に対して変更されることに注意してください。セクション7.4を参照してください。
At any point, the application can query Connection Properties.
いつでも、アプリケーションは接続プロパティを照会できます。
ConnectionProperties := Connection.GetProperties()
value := ConnectionProperties.Get(property)
if ConnectionProperties.Has(boolean_or_preference_property) then...
Depending on the status of the Connection, the queried Connection Properties will include different information:
接続のステータスに応じて、照会された接続プロパティには異なる情報が含まれます。
* The Connection state, which can be one of the following: Establishing, Established, Closing, or Closed (see Section 8.1.11.1).
* 次のいずれかのいずれかのいずれかの接続状態：確立、確立、閉鎖、または閉鎖（セクション8.1.11.1を参照）。
* Whether the Connection can be used to send data (see Section 8.1.11.2). A Connection cannot be used for sending if the Connection was created with the Selection Property direction set to Unidirectional receive or if a Message marked as Final was sent over this Connection. See also Section 9.1.3.5.
* 接続を使用してデータを送信できるかどうか（セクション8.1.11.2を参照）。接続は、選択プロパティの方向が一方向に設定されている場合、またはこの接続にファイナルとしてマークされたメッセージが送信された場合に接続が作成された場合、送信には使用できません。セクション9.1.3.5も参照してください。
* Whether the Connection can be used to receive data (see Section 8.1.11.3). A Connection cannot be used for receiving if the Connection was created with the Selection Property direction set to Unidirectional send or if a Message marked as Final was received (see Section 9.3.3.3). The latter is only supported by certain transport protocols, e.g., by TCP as a half-closed connection.
* 接続を使用してデータを受信できるかどうか（セクション8.1.11.3を参照）。接続は、選択プロパティの方向を単方向送信に設定した場合、または最終としてマークされたメッセージが受信された場合（セクション9.3.3.3を参照）、接続を受信するために使用できません。後者は、特定の輸送プロトコル、たとえば、半分閉鎖された接続としてのTCPによってのみサポートされています。
* For Connections that are Established, Closing, or Closed: Connection Properties (Section 8.1) of the actual protocols that were selected and instantiated, and Selection Properties that the application specified on the Preconnection. Selection Properties of type "Preference" will be exposed as Boolean values indicating whether or not the Property applies to the selected transport. Note that the instantiated Protocol Stack might not match all Protocol Selection Properties that the application specified on the Preconnection.
* 確立、閉鎖、または閉じられた接続の場合：選択およびインスタンス化された実際のプロトコルの接続プロパティ（セクション8.1）、およびアプリケーションが事前接続で指定した選択プロパティ。タイプ「優先」の選択特性は、プロパティが選択した輸送に適用されるかどうかを示すブール値として公開されます。インスタンス化されたプロトコルスタックは、アプリケーションが事前接続で指定したすべてのプロトコル選択プロパティと一致しない場合があることに注意してください。
* For Connections that are Established: Transport Services Implementations ought to provide information concerning the path(s) used by the Protocol Stack. This can be derived from local PvD information, measurements by the Protocol Stack, or other sources. For example, a Transport Services System that is configured to receive and process PvD information [RFC7556] could also provide network configuration information for the chosen path(s).
* 確立された接続の場合：輸送サービスの実装は、プロトコルスタックで使用されるパスに関する情報を提供する必要があります。これは、ローカルPVD情報、プロトコルスタックによる測定値、またはその他のソースから導出できます。たとえば、PVD情報[RFC7556]を受信および処理するように構成されている輸送サービスシステムは、選択したパスのネットワーク構成情報を提供することもできます。
Generic Connection Properties are defined independently of the chosen Protocol Stack; therefore, they are available on all Connections.
一般的な接続プロパティは、選択したプロトコルスタックとは独立して定義されます。したがって、それらはすべての接続で利用可能です。
Many Connection Properties have a corresponding Selection Property that enables applications to express their preference for protocols providing a supporting transport feature.
多くの接続プロパティには、アプリケーションがサポート輸送機能を提供するプロトコルの好みを表現できるようにする対応する選択プロパティがあります。
Name:
名前：
recvChecksumLen
recvchecksumlen
Type:
タイプ：
Integer (non-negative) or Full Coverage
整数（非陰性）または完全なカバレッジ
Default:
デフォルト：
Full Coverage
完全なカバレッジ
If this Property is an Integer, it specifies the minimum number of bytes in a received Message that need to be covered by a checksum. A receiving Endpoint will not forward Messages that have less coverage to the application. The application is responsible for handling any corruption within the non-protected part of the Message [RFC8085]. A special value of 0 means that a received packet might also have a zero checksum field, and the enumerated value Full Coverage means that the entire Message needs to be protected by a checksum. An implementation is supposed to express Full Coverage in an environment-typical way, e.g., as a Union type or special value.
このプロパティが整数である場合、チェックサムでカバーする必要があるメッセージの最小バイト数を指定します。受信エンドポイントでは、アプリケーションへのカバレッジが少ないメッセージを転送しません。アプリケーションは、メッセージの非保護されていない部分内の腐敗を処理する責任があります[RFC8085]。0の特別な値は、受信したパケットにチェックサムフィールドがゼロになる可能性があることを意味し、列挙された値の完全なカバレッジは、メッセージ全体をチェックサムによって保護する必要があることを意味します。実装は、たとえば、組合の種類または特別な価値として、環境の典型的な方法で完全なカバレッジを表現することになっています。
Name:
名前：
connPriority
conconpriority
Type:
タイプ：
Integer (non-negative)
整数（非陰性）
Default:
デフォルト：
100
100
This Property is a non-negative Integer representing the priority of this Connection relative to other Connections in the same Connection Group. A numerically lower value reflects a higher priority. It has no effect on Connections not part of a Connection Group. As noted in Section 7.4, this Property is not entangled when Connections are cloned, i.e., changing the priority on one Connection in a Connection Group does not change it on the other Connections in the same Connection Group. No guarantees of a specific behavior regarding Connection Priority are given; a Transport Services System could ignore this Property. See Section 9.2.6 for more details.
このプロパティは、同じ接続グループの他の接続と比較して、この接続の優先度を表す非陰性整数です。数値的に低い値は、より高い優先度を反映しています。接続グループの一部ではなく、接続には影響しません。セクション7.4で述べたように、このプロパティは接続がクローン化されたときに絡み合っていません。つまり、接続グループの1つの接続の優先度を変更しても、同じ接続グループの他の接続では変更されません。接続の優先順位に関する特定の動作の保証はありません。輸送サービスシステムは、このプロパティを無視できます。詳細については、セクション9.2.6を参照してください。
Name:
名前：
connTimeout
conntimeout
Type:
タイプ：
Numeric (positive) or Disabled
数値（陽性）または無効
Default:
デフォルト：
Disabled
無効
If this Property is Numeric, it specifies how long to wait before deciding that an active Connection has failed when trying to reliably deliver data to the Remote Endpoint. Adjustments to this Property will only take effect if the underlying stack supports reliability. If this Property has the enumerated value Disabled, it means that no timeout is scheduled. A Transport Services API could express Disabled in an environment-typical way, e.g., as a Union type or special value.
このプロパティが数値の場合、リモートエンドポイントにデータを確実に配信しようとするときにアクティブな接続が失敗したと判断するまで、待機時間を指定します。このプロパティの調整は、基礎となるスタックが信頼性をサポートしている場合にのみ有効になります。このプロパティに列挙された値が無効になっている場合、タイムアウトがスケジュールされていないことを意味します。輸送サービスAPIは、環境の典型的な方法で、たとえば組合の種類または特別な価値として無効を表すことができます。
Name:
名前：
keepAliveTimeout
KeepAlivetimeOut
Type:
タイプ：
Numeric (positive) or Disabled
数値（陽性）または無効
Default:
デフォルト：
Disabled
無効
A Transport Services API can request a protocol that supports sending keep-alive packets (Section 6.2.10). If this Property is Numeric, it specifies the maximum length of time an idle Connection (one for which no transport packets have been sent) ought to wait before the Local Endpoint sends a keep-alive packet to the Remote Endpoint. Adjustments to this Property will only take effect if the underlying stack supports sending keep-alive packets. Guidance on setting this value for connectionless transports is provided in [RFC8085]. A value greater than the Connection timeout (Section 8.1.3) or the enumerated value Disabled will disable the sending of keep-alive packets. A Transport Services API could express Disabled in an environment-typical way, e.g., as a Union type or special value.
トランスポートサービスAPIは、キープアライブパケットの送信をサポートするプロトコルをリクエストできます（セクション6.2.10）。このプロパティが数値の場合、ローカルエンドポイントがリモートエンドポイントにキープアライブパケットを送信する前に、アイドル接続（輸送パケットが送信されていないもの）が待機する必要がある最大時間を指定します。このプロパティの調整は、基礎となるスタックがキープアライブパケットの送信をサポートしている場合にのみ有効になります。[RFC8085]に、ConnectionLess Transportsのこの値の設定に関するガイダンスが提供されています。接続タイムアウト（セクション8.1.3）または列挙された値が無効になっている値は、キープアライブパケットの送信を無効にします。輸送サービスAPIは、環境の典型的な方法で、たとえば組合の種類または特別な価値として無効を表すことができます。
Name:
名前：
connScheduler
connscheduler
Type:
タイプ：
Enumeration
列挙
Default:
デフォルト：
Weighted Fair Queueing (see Section 3.6 of [RFC8260])
加重公正キューイング（[RFC8260]のセクション3.6を参照）
This Property specifies which scheduler is used among Connections within a Connection Group to apportion the available capacity according to Connection priorities (see Sections 7.4 and 8.1.2). A set of schedulers is described in [RFC8260].
このプロパティは、接続グループ内の接続間で使用されるスケジューラが、接続の優先順位に応じて利用可能な容量を配分するために指定します（セクション7.4および8.1.2を参照）。スケジューラのセットは[RFC8260]で説明されています。
Name:
名前：
connCapacityProfile
conncapacityprofile
Type:
タイプ：
Enumeration
列挙
Default:
デフォルト：
Default Profile (Best Effort)
デフォルトプロファイル（最善の努力）
This Property specifies the desired network treatment for traffic sent by the application and the trade-offs the application is prepared to make in path and protocol selection to receive that desired treatment. When the capacity profile is set to a value other than Default, the Transport Services System SHOULD select paths and configure protocols to optimize the trade-off between delay, delay variation, and efficient use of the available capacity based on the capacity profile specified. How this is realized is implementation specific. The capacity profile MAY also be used to set markings on the wire for Protocol Stacks supporting this action. Recommendations for use with DSCPs are provided below for each profile; note that when a Connection is multiplexed, the guidelines in Section 6 of [RFC7657] apply.
このプロパティは、アプリケーションから送信されたトラフィックのための望ましいネットワーク処理と、アプリケーションがパスおよびプロトコル選択を行うために、その望ましい治療を受けるために準備されていることを指定します。容量プロファイルがデフォルト以外の値に設定されている場合、トランスポートサービスシステムはパスを選択し、プロトコルを構成して、指定された容量プロファイルに基づいて、遅延、遅延変動、および利用可能な容量の効率的な使用を最適化するためにプロトコルを構成する必要があります。これがどのように実現されるかは、実装固有です。容量プロファイルは、このアクションをサポートするプロトコルスタック用のワイヤーにマーキングを設定するためにも使用できます。DSCPで使用するための推奨事項は、各プロファイルに対して以下に提供されます。接続が多重化されている場合、[RFC7657]のセクション6のガイドラインが適用されることに注意してください。
The following values are valid for the capacity profile:
次の値は、容量プロファイルに対して有効です。
Default:
デフォルト：
The application provides no information about its expected capacity profile. Transport Services Systems that map the requested capacity profile to per-connection DSCP signaling SHOULD assign the DSCP Default Forwarding Per Hop Behavior (PHB) [RFC2474].
アプリケーションは、予想される容量プロファイルに関する情報を提供しません。要求された容量プロファイルを接続ごとにマッピングする輸送サービスシステムは、DSCPのデフォルト転送（PHB）[RFC2474]を割り当てる必要があります。
Scavenger:
スカベンジャー：
The application is not interactive. It expects to send and/or receive data without any urgency. This can, for example, be used to select Protocol Stacks with scavenger transmission control and/or to assign the traffic to a lower-effort service. Transport Services Systems that map the requested capacity profile to per-connection DSCP signaling SHOULD assign the DSCP "Less than best effort" PHB [RFC8622].
アプリケーションはインタラクティブではありません。緊急性なしにデータを送信および/または受信することを期待しています。これは、たとえば、スカベンジャー伝送制御を備えたプロトコルスタックを選択したり、トラフィックを低エフォルトサービスに割り当てるために使用できます。要求された容量プロファイルを接続ごとのDSCPシグナルにマッピングする輸送サービスシステムは、DSCPを「最適な努力よりも少ない」PHB [RFC8622]を割り当てる必要があります。
Low Latency/Interactive:
低レイテンシー/インタラクティブ：
The application is interactive and prefers loss to latency. Response time SHOULD be optimized at the expense of delay variation and efficient use of the available capacity when sending on this Connection. The Low Latency/Interactive value of the capacity profile can be used by the system to disable the coalescing of multiple small Messages into larger packets (Nagle algorithm (see Section 4.2.3.4 of [RFC1122])); to prefer immediate acknowledgement from the peer Endpoint when supported by the underlying transport; and so on. Transport Services Systems that map the requested capacity profile to per-connection DSCP signaling without multiplexing SHOULD assign a DSCP Assured Forwarding (AF41, AF42, AF43, and AF44) PHB [RFC2597]. Inelastic traffic that is expected to conform to the configured network service rate could be mapped to the DSCP Expedited Forwarding PHBs [RFC3246] or PHBs as discussed in [RFC5865].
アプリケーションはインタラクティブであり、レイテンシの損失を好みます。応答時間は、この接続を送信する際に、遅延の変動と利用可能な容量の効率的な使用を犠牲にして最適化する必要があります。容量プロファイルの低レイテンシ/インタラクティブ値は、システムが複数の小さなメッセージの合体をより大きなパケットに無効にするために使用できます（Nagleアルゴリズム（[RFC1122]のセクション4.2.3.4を参照））。基礎となる輸送でサポートされている場合、ピアエンドポイントからの即時の承認を好む。等々。要求された容量プロファイルをマルチプレックスなしで接続ごとのDSCPシグナル伝達にマッピングする輸送サービスシステムは、DSCP Assured Forwarding（AF41、AF42、AF43、およびAF44）PHB [RFC2597]を割り当てる必要があります。構成されたネットワークサービスレートに準拠すると予想される非弾性トラフィックは、[RFC5865]で説明されているように、DSCP迅速な転送PHB [RFC3246]またはPHBにマッピングできます。
Low Latency/Non-Interactive:
低レイテンシー/非対話型：
The application prefers loss to latency but is not interactive. Response time SHOULD be optimized at the expense of delay variation and efficient use of the available capacity when sending on this Connection. Transport system implementations that map the requested capacity profile to per-connection DSCP signaling without multiplexing SHOULD assign a DSCP Assured Forwarding (AF21, AF22, AF23, and AF24) PHB [RFC2597].
アプリケーションは、遅延への損失を好みますが、インタラクティブではありません。応答時間は、この接続を送信する際に、遅延の変動と利用可能な容量の効率的な使用を犠牲にして最適化する必要があります。要求された容量プロファイルをマルチプレックスなしで接続ごとのDSCPシグナル伝達にマッピングする輸送システムの実装は、DSCP保証転送（AF21、AF22、AF23、およびAF24）PHB [RFC2597]を割り当てる必要があります。
Constant-Rate Streaming:
一定のストリーミング：
The application expects to send/receive data at a constant rate after Connection establishment. Delay and delay variation SHOULD be minimized at the expense of efficient use of the available capacity. This implies that the Connection might fail if the path is unable to maintain the desired rate. A transport can interpret this capacity profile as preferring a circuit breaker [RFC8084] to a rate-adaptive congestion controller. Transport system implementations that map the requested capacity profile to per-connection DSCP signaling without multiplexing SHOULD assign a DSCP Assured Forwarding (AF31, AF32, AF33, and AF34) PHB [RFC2597].
アプリケーションは、接続確立後に一定の速度でデータを送信/受信することを期待しています。遅延および遅延の変動は、利用可能な容量を効率的に使用することを犠牲にして最小限に抑える必要があります。これは、パスが目的のレートを維持できない場合、接続が故障する可能性があることを意味します。トランスポートは、この容量プロファイルを、回路ブレーカー[RFC8084]をレート適応渋滞コントローラーよりも好むものとして解釈できます。要求された容量プロファイルをマルチプレックスなしで接続ごとのDSCPシグナル伝達にマッピングするトランスポートシステムの実装は、DSCP保証転送（AF31、AF32、AF33、およびAF34）PHB [RFC2597]を割り当てる必要があります。
Capacity-Seeking:
キャパシティシーキング：
The application expects to send/receive data at the maximum rate allowed by its congestion controller over a relatively long period of time. Transport Services Systems that map the requested capacity profile to per-connection DSCP signaling without multiplexing SHOULD assign a DSCP Assured Forwarding (AF11, AF12, AF13, and AF14) PHB [RFC2597] per Section 4.8 of [RFC4594].
このアプリケーションは、比較的長い期間にわたって混雑コントローラーによって許可されている最大レートでデータを送信/受信することを期待しています。要求された容量プロファイルをマルチプレックスなしで接続ごとのDSCPシグナル伝達にマッピングする輸送サービスシステムは、[RFC4594]のセクション4.8ごとにDSCP Assured Forwarding（AF11、AF12、AF13、およびAF14）PHB [RFC2597）を割り当てる必要があります。
The capacity profile for a selected Protocol Stack may be modified on a per-Message basis using the msgCapacityProfile Message Property; see Section 9.1.3.8.
選択したプロトコルスタックの容量プロファイルは、MSGCAPACityProfileメッセージプロパティを使用して、1人あたりベースで変更できます。セクション9.1.3.8を参照してください。
Name:
名前：
multipathPolicy
MultiPathpolicy
Type:
タイプ：
Enumeration
列挙
Default:
デフォルト：
Handover
引き渡す
This Property specifies the local policy for transferring data across multiple paths between the same end hosts if the multipath Property is not set to Disabled (see Section 6.2.14). Possible values are as follows:
このプロパティは、マルチパスプロパティが無効に設定されていない場合、同じエンドホスト間で複数のパスにわたってデータを転送するためのローカルポリシーを指定します（セクション6.2.14を参照）。考えられる値は次のとおりです。
Handover:
引き渡す：
The Connection ought only to attempt to migrate between different paths when the original path is lost or becomes unusable. The thresholds used to declare a path unusable are implementation specific.
接続は、元のパスが失われたり使用できなくなったときに、異なるパス間で移行しようとする必要があります。使用できないパスを宣言するために使用されるしきい値は、実装固有です。
Interactive:
相互の作用：
The Connection ought only to attempt to minimize the latency for interactive traffic patterns by transmitting data across multiple paths when this is beneficial. The goal of minimizing the latency will be balanced against the cost of each of these paths. Depending on the cost of the lower-latency path, the scheduling might choose to use a higher-latency path. Traffic can be scheduled such that data may be transmitted on multiple paths in parallel to achieve a lower latency. The specific scheduling algorithm is implementation specific.
接続は、これが有益な場合に複数のパスでデータを送信することにより、インタラクティブなトラフィックパターンのレイテンシを最小限に抑えようとする必要があります。レイテンシを最小限に抑えるという目標は、これらの各パスのコストとバランスが取れます。低遅延パスのコストに応じて、スケジューリングはより高い遅延パスを使用することを選択する場合があります。トラフィックをスケジュールすると、データを複数のパスに並行して送信して、低下を達成することができます。特定のスケジューリングアルゴリズムは実装固有です。
Aggregate:
集計：
The Connection ought to attempt to use multiple paths in parallel to maximize available capacity and possibly overcome the capacity limitations of the individual paths. The actual strategy is implementation specific.
接続は、利用可能な容量を最大化し、個々のパスの容量の制限を克服するために、複数のパスを並行して使用しようとする必要があります。実際の戦略は実装固有です。
Note that this is a local choice: the Remote Endpoint can choose a different policy.
これはローカルな選択であることに注意してください。リモートエンドポイントは別のポリシーを選択できます。
Name:
名前：
minSendRate / minRecvRate / maxSendRate / maxRecvRate
minsendrate / minrecvrate / maxsendrate / maxrecvrate
Type:
タイプ：
Numeric (positive) or Unlimited / Numeric (positive) or Unlimited / Numeric (positive) or Unlimited / Numeric (positive) or Unlimited
数値（正）または無制限 /数値（正）または無制限 /数値（正）または無制限 /数値（正）または無制限
Default:
デフォルト：
Unlimited / Unlimited / Unlimited / Unlimited
無制限 /無制限 /無制限 /無制限
Numeric values of these Properties specify an upper-bound rate that a transfer is not expected to exceed (even if flow control and congestion control allow higher rates) and/or a lower-bound application-layer rate below which the application does not deem it will be useful. These rate values are measured at the application layer, i.e., do not consider the header overhead from protocols used by the Transport Services System. The values are specified in bits per second and assumed to be measured over one-second time intervals. For example, specifying a maxSendRate of X bits per second means that, from the moment at which the Property value is chosen, not more than X bits will be sent in any following second. The enumerated value Unlimited indicates that no bound is specified. A Transport Services API could express Unlimited in an environment-typical way, e.g., as a Union type or special value.
これらのプロパティの数値は、転送が超えると予想されない上限速度を指定します（フロー制御と混雑制御により高い速度が可能になった場合でも）、および/またはアプリケーションがそれを考慮しない下限アプリケーション層レートを指定します役に立ちます。これらのレート値は、アプリケーションレイヤーで測定されます。つまり、輸送サービスシステムが使用するプロトコルからヘッダーオーバーヘッドを考慮しないでください。値は1秒あたりビットで指定され、1秒の時間間隔で測定されると想定されます。たとえば、Xビットの最大節酸塩を1秒あたりの指定すると、プロパティ値が選択されている瞬間から、Xビット以下が次の秒で送信されることを意味します。列挙された値無制限は、バウンドが指定されていないことを示します。輸送サービスAPIは、たとえば、組合の種類または特別な価値として、環境型の方法で無制限を表現できます。
Name:
名前：
groupConnLimit
GroupConnlimit
Type:
タイプ：
Numeric (positive) or Unlimited
数値（正）または無制限
Default:
デフォルト：
Unlimited
無制限
If this Property is Numeric, it controls the number of Connections that can be accepted from a peer as new members of the Connection's group. Similar to SetNewConnectionLimit, this limits the number of ConnectionReceived events that will occur, but constrained to the group of the Connection associated with this Property. For a multi-streaming transport, this limits the number of allowed streams. A Transport Services API could express Unlimited in an environment-typical way, e.g., as a Union type or special value.
このプロパティが数値の場合、接続グループの新しいメンバーとしてピアから受け入れることができる接続の数を制御します。setNewConnectionLimitと同様に、これにより、発生する接続再生イベントの数が制限されますが、このプロパティに関連する接続のグループに制約されます。マルチストリーミングトランスポートの場合、これにより許可されたストリームの数が制限されます。輸送サービスAPIは、たとえば、組合の種類または特別な価値として、環境型の方法で無制限を表現できます。
Name:
名前：
isolateSession
分離
Type:
タイプ：
Boolean
ブール
Default:
デフォルト：
false
間違い
When set to true, this Property will initiate new Connections using as little cached information (such as session tickets or cookies) as possible from previous Connections that are not in the same Connection Group. Any state generated by this Connection will only be shared with Connections in the same Connection Group. Cloned Connections will use saved state from within the Connection Group. This is used for separating Connection Contexts as specified in Section 4.2.3 of [RFC9621].
Trueに設定すると、このプロパティは、同じ接続グループにない以前の接続から、可能な限り少ないキャッシュ情報（セッションチケットやCookieなど）を使用して新しい接続を開始します。この接続によって生成される状態は、同じ接続グループの接続とのみ共有されます。クローン接続は、接続グループ内から保存された状態を使用します。これは、[RFC9621]のセクション4.2.3で指定されているように、接続コンテキストを分離するために使用されます。
Note that this does not guarantee that information will not leak because implementations might not be able to fully isolate all caches (e.g., RTT estimates). Note that this Property could degrade Connection performance.
実装がすべてのキャッシュを完全に分離できない可能性があるため、これは情報が漏れないことを保証しないことに注意してください（例：RTTの推定）。このプロパティは接続性能を低下させる可能性があることに注意してください。
The following generic Connection Properties are read-only, i.e., they cannot be changed by an application.
次の汎用接続プロパティは読み取り専用です。つまり、アプリケーションで変更することはできません。
Name:
名前：
connState
connstate
Type:
タイプ：
Enumeration
列挙
This Property provides information about the current state of the Connection. Possible values are Establishing, Established, Closing, or Closed. For more details on Connection state, see Section 11.
このプロパティは、接続の現在の状態に関する情報を提供します。考えられる値は、確立、確立、閉鎖、または閉鎖です。接続状態の詳細については、セクション11を参照してください。
Name:
名前：
canSend
缶詰
Type:
タイプ：
Boolean
ブール
This Property can be queried to learn whether the Connection can be used to send data.
このプロパティを照会して、接続を使用してデータを送信できるかどうかを確認できます。
Name:
名前：
canReceive
Can Receive
Type:
タイプ：
Boolean
ブール
This Property can be queried to learn whether the Connection can be used to receive data.
このプロパティを照会して、接続を使用してデータを受信できるかどうかを知ることができます。
Name:
名前：
singularTransmissionMsgMaxLen
singulartransmissionmsgmaxlen
Type:
タイプ：
Integer (non-negative) or Not applicable
整数（非陰性）または適用されない
This Property, if applicable, represents the maximum Message size that can be sent without incurring network-layer fragmentation at the sender. It is specified as a number of bytes and is less than or equal to the maximum Message Size on Send. It exposes a readable value to the application based on the Maximum Packet Size (MPS). The value of this Property can change over time (and can be updated via Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) [RFC8899]). This value allows a sending stack to avoid unwanted fragmentation at the network layer or segmentation by the transport layer before choosing the Message size and/or after a SendError occurs indicating an attempt to send a Message that is too large. A Transport Services API could express Not applicable in an environment-typical way, e.g., as a Union type or special value (e.g., 0).
このプロパティは、該当する場合は、送信者にネットワーク層の断片化を発生させずに送信できる最大メッセージサイズを表します。多数のバイトとして指定されており、送信時の最大メッセージサイズ以下です。最大パケットサイズ（MPS）に基づいて、読み取り可能な値をアプリケーションに公開します。このプロパティの値は、時間の経過とともに変更される可能性があります（Datagram Packetization Layer Path MTU Discovery（DPLPMTUD）[RFC8899]を介して更新できます）。この値により、送信スタックは、メッセージサイズを選択する前、および/またはsenderrorが発生した後に、輸送層によるネットワーク層またはセグメンテーションで不要な断片化を回避できます。トランスポートサービスAPIは、環境の典型的な方法で、たとえば組合タイプまたは特別な値として適用されないことを表現できます（例：0）。
Name:
名前：
sendMsgMaxLen
sendmsgmaxlen
Type:
タイプ：
Integer (non-negative)
整数（非陰性）
This Property represents the maximum Message size that an application can send. It is specified as the number of bytes. A value of 0 indicates that sending is not possible.
このプロパティは、アプリケーションが送信できる最大メッセージサイズを表します。バイト数として指定されています。0の値は、送信が不可能であることを示します。
Name:
名前：
recvMsgMaxLen
recvmsgmaxlen
Type:
タイプ：
Integer (non-negative)
整数（非陰性）
This Property represents the maximum Message size that an application can receive. It is specified as the number of bytes. A value of 0 indicates that receiving is not possible.
このプロパティは、アプリケーションが受信できる最大メッセージサイズを表します。バイト数として指定されています。0の値は、受信が不可能であることを示します。
These Properties specify configurations for the TCP User Timeout Option (UTO). This is a TCP-specific Property that is only used in the case that TCP becomes the chosen transport protocol. It is useful only if TCP is implemented in the Transport Services System. Protocol-specific options could also be defined for other transport protocols.
これらのプロパティは、TCPユーザータイムアウトオプション（UTO）の構成を指定します。これは、TCPが選択された輸送プロトコルになる場合にのみ使用されるTCP固有のプロパティです。TCPが輸送サービスシステムに実装されている場合にのみ役立ちます。プロトコル固有のオプションは、他の輸送プロトコルに対しても定義できます。
These Properties are included here because the feature Suggest timeout to the peer is part of the minimal set of Transport Services [RFC8923], where this feature was categorized as "functional". This means that when a Transport Services System offers this feature, the Transport Services API has to expose an interface to the application. Otherwise, the implementation might violate assumptions by the application, which could cause the application to fail.
これらのプロパティは、ピアへのタイムアウトが最小限の輸送サービスセット[RFC8923]の一部であることを示唆しているため、ここに含まれています。この機能は「機能的」に分類されています。これは、トランスポートサービスシステムがこの機能を提供する場合、トランスポートサービスAPIがアプリケーションにインターフェイスを公開する必要があることを意味します。それ以外の場合、実装はアプリケーションによる仮定に違反し、アプリケーションが失敗する可能性があります。
All of the below Properties are optional (e.g., it is possible to specify tcp.userTimeoutValue as true but not specify a tcp.userTimeoutValue value; in this case, the TCP default will be used). These Properties reflect the API extension specified in Section 3 of [RFC5482].
以下のすべてのプロパティはオプションです（たとえば、TCP.USERTIMEOUTVALUEをTRUEとして指定することは可能ですが、TCP.USERTIMEOUTVALUE値を指定しません。この場合、TCPデフォルトが使用されます）。これらの特性は、[RFC5482]のセクション3で指定されたAPI拡張を反映しています。
Name:
名前：
tcp.userTimeoutValue
TCP.USERTIMEOUTVALUE
Type:
タイプ：
Integer (positive)
整数（ポジティブ）
Default:
デフォルト：
the TCP default
TCPデフォルト
This time value is advertised via the TCP User Timeout Option (UTO) [RFC5482] to the Remote Endpoint, which can use it to adapt its own connTimeout (see Section 8.1.3) value.
この時間値は、TCPユーザータイムアウトオプション（UTO）[RFC5482]を介してリモートエンドポイントに宣伝されます。これにより、独自のConnTimeout（セクション8.1.3を参照）値を適応させることができます。
Name:
名前：
tcp.userTimeoutEnabled
TCP.USERTIMEOUTENABLED
Type:
タイプ：
Boolean
ブール
Default:
デフォルト：
false
間違い
This Property controls whether the TCP UTO is enabled for a connection. This applies to both sending and receiving.
このプロパティは、接続のためにTCP UTOが有効になっているかどうかを制御します。これは、送信と受信の両方に適用されます。
Name:
名前：
tcp.userTimeoutChangeable
TCP.USERTIMEOUTCHANGEABLE
Type:
タイプ：
Boolean
ブール
Default:
デフォルト：
true
真実
This Property controls whether the TCP connTimeout (see Section 8.1.3) can be changed based on a UTO received from the remote peer. This Boolean becomes false when connTimeout (see Section 8.1.3) is used.
このプロパティは、TCP Conntimeout（セクション8.1.3を参照）をリモートピアから受信したUTOに基づいて変更できるかどうかを制御します。Conntimeout（セクション8.1.3を参照）が使用されると、このブール値がfalseになります。
During the lifetime of a Connection there are events that can occur when configured.
接続の寿命の間に、構成されたときに発生する可能性のあるイベントがあります。
Asynchronous introspection is also possible, via the SoftError event. This event informs the application about the receipt and contents of an ICMP error message related to the Connection. This will only happen if the underlying Protocol Stack supports access to soft errors; however, even if the underlying stack supports it, there is no guarantee that a soft error will be signaled.
Softerrorイベントを介して、非同期内省も可能です。このイベントは、接続に関連するICMPエラーメッセージの領収書と内容についてアプリケーションに通知します。これは、基礎となるプロトコルスタックがソフトエラーへのアクセスをサポートする場合にのみ発生します。ただし、基礎となるスタックがサポートしていても、ソフトエラーが通知されるという保証はありません。
Connection -> SoftError<>
This event notifies the application when at least one of the paths underlying a Connection has changed. Changes occur on a single path when the PMTU changes as well as when multiple paths are used and paths are added or removed, the set of Local Endpoints changes, or a handover has been performed.
このイベントは、接続の根底にあるパスの少なくとも1つが変更されたときにアプリケーションに通知します。PMTUが変更された場合、および複数のパスが使用され、パスが追加または削除された場合、ローカルエンドポイントのセットが変更された場合、またはハンドオーバーが実行されたときの単一のパスで変更が発生します。
Connection -> PathChange<>
Data is sent and received as Messages, which allows the application to communicate the boundaries of the data being transferred.
データが送信され、メッセージとして受信されるため、アプリケーションは転送されるデータの境界を通信できます。
Each Message has an optional MessageContext, which allows adding Message Properties, to identify Send events related to a specific Message or to inspect metadata related to the Message sent. Framers can be used to extend or modify the Message data with additional information that can be processed at the receiver to detect Message boundaries.
各メッセージには、メッセージプロパティの追加を許可するオプションのMessageContextがあり、特定のメッセージに関連する送信イベントを識別するか、送信されたメッセージに関連するメタデータを検査します。フレーマーを使用して、メッセージ境界を検出するために受信機で処理できる追加情報を使用してメッセージデータを拡張または変更できます。
Using the MessageContext object, the application can set and retrieve metadata of the Message, including Message Properties (see Section 9.1.3) and framing metadata (see Section 9.1.2.2). Therefore, a MessageContext object can be passed to the Send action and is returned by each event related to Send and Receive.
MessageContextオブジェクトを使用して、メッセージのプロパティ（セクション9.1.3を参照）やメタデータのフレーミング（セクション9.1.2.2を参照）を含む、メッセージのメタデータを設定および取得できます。したがって、MessageContextオブジェクトは送信アクションに渡すことができ、送信と受信に関連する各イベントによって返されます。
Message Properties can be set and queried using the MessageContext:
メッセージプロパティは、mesageContextを使用して設定および照会できます。
MessageContext.add(property, value)
PropertyValue := MessageContext.get(property)
These Message Properties can be generic Properties or Protocol-specific Properties.
これらのメッセージプロパティは、一般的なプロパティまたはプロトコル固有のプロパティです。
For MessageContexts returned by Send events (see Section 9.2.2) and Receive events (see Section 9.3.2), the application can query information about the Local and Remote Endpoint:
送信イベント（セクション9.2.2を参照）によって返されたMESSAGECONTEXTSおよび受信イベント（セクション9.3.2を参照）の場合、アプリケーションはローカルエンドポイントとリモートエンドポイントに関する情報をクエリできます。
RemoteEndpoint := MessageContext.GetRemoteEndpoint()
LocalEndpoint := MessageContext.GetLocalEndpoint()
Although most applications communicate over a network using well-formed Messages, the boundaries and metadata of the Messages are often not directly communicated by the transport protocol itself. For example, HTTP applications send and receive HTTP Messages over a byte-stream transport, requiring that the boundaries of HTTP Messages be parsed from the stream of bytes.
ほとんどのアプリケーションは、よく形成されたメッセージを使用してネットワークを介して通信しますが、メッセージの境界とメタデータは、トランスポートプロトコル自体によって直接通信されないことがよくあります。たとえば、HTTPアプリケーションは、バイトストリームトランスポートでHTTPメッセージを送信および受信し、HTTPメッセージの境界をバイトのストリームから解析する必要があります。
Message Framers allow extending a Connection's Protocol Stack to define how to encapsulate or encode outbound Messages and how to decapsulate or decode inbound data into Messages. Message Framers allow Message boundaries to be preserved when using a Connection object, even when using byte-stream transports. This is designed based on the fact that many of the application protocols in use at the time of writing evolved over TCP, which does not provide Message boundary preservation; because many of these protocols require Message boundaries to function, each application-layer protocol has defined its own framing.
メッセージフレーマーを使用すると、接続のプロトコルスタックを拡張して、アウトバウンドメッセージをカプセル化またはエンコードする方法と、インバウンドデータをメッセージに脱カプセル化またはデコードする方法を定義できます。メッセージフレーマーにより、バイトストリームトランスポートを使用する場合でも、接続オブジェクトを使用する場合でも、メッセージの境界を保存できます。これは、執筆時点で使用されているアプリケーションプロトコルの多くがTCPを介して進化したという事実に基づいて設計されており、メッセージの境界保存を提供しません。これらのプロトコルの多くはメッセージの境界を機能させる必要があるため、各アプリケーション層プロトコルは独自のフレーミングを定義しています。
To use a Message Framer, the application adds it to its Preconnection object. Then, the Message Framer can intercept all calls to Send or Receive on a Connection to add Message semantics, in addition to interacting with the setup and teardown of the Connection. A Framer can start sending data before the application sends data if the framing protocol requires a prefix or handshake (see [RFC9329] for an example of such a framing protocol).
メッセージフレーマーを使用するために、アプリケーションはそれをその事前接続オブジェクトに追加します。次に、メッセージframerは、接続のセマンティクスを追加するために、接続で送信または受信するためにすべての呼び出しを傍受することができます。フレーミングプロトコルがプレフィックスまたはハンドシェイクを必要とする場合、アプリケーションがデータを送信する前にデータの送信を開始できます（このようなフレーミングプロトコルの例については[RFC9329]を参照）。
Initiate() Send() Receive() Close()
| | ^ |
| | | |
+----v----------v---------+----------v-----+
| Connection |
+----+----------+---------^----------+-----+
| | | |
| +-----------------+ |
| | Messages | |
| +-----------------+ |
| | | |
+----v----------v---------+----------v-----+
| Framer(s) |
+----+----------+---------^----------+-----+
| | | |
| +-----------------+ |
| | Byte-stream | |
| +-----------------+ |
| | | |
+----v----------v---------+----------v-----+
| Transport Protocol Stack |
+------------------------------------------+
Figure 1: Protocol Stack Showing a Message Framer
図1：メッセージフレーマーを示すプロトコルスタック
Note that while Message Framers add the most value when placed above a protocol that otherwise does not preserve Message boundaries, they can also be used with datagram- or message-based protocols. In these cases, they add a transformation to further encode or encapsulate and can potentially support packing multiple application-layer Messages into individual transport datagrams.
メッセージフレーマーは、それ以外の場合はメッセージの境界を保存しないプロトコルの上に配置すると最も値を追加しますが、データグラムまたはメッセージベースのプロトコルでも使用することもできます。これらの場合、それらはさらにエンコードまたはカプセル化するために変換を追加し、個々のトランスポートデータグラムへの複数のアプリケーション層メッセージの梱包をサポートする可能性があります。
The API to implement a Message Framer can vary, depending on the implementation; guidance on implementing Message Framers can be found in [RFC9623].
Framerを実装するAPIは、実装によって異なる場合があります。メッセージフレーマーの実装に関するガイダンスは、[RFC9623]に記載されています。
The Message Framer object can be added to one or more Preconnections to run on top of transport protocols. Multiple Framers can be added to a Preconnection; in this case, the Framers operate as a framing stack, i.e., the last one added runs first when framing outbound Messages, and last when parsing inbound data.
メッセージフレーマーオブジェクトは、1つ以上の前提条件に追加して、輸送プロトコルの上で実行することができます。複数のフレーマーを事前接続に追加できます。この場合、フレーマーはフレーミングスタックとして動作します。つまり、最後に追加されたものは、アウトバウンドメッセージをフレーミングするときに最初に実行され、インバウンドデータを解析するときに最後に実行されます。
The following example adds a basic HTTP Message Framer to a Preconnection:
次の例では、基本的なHTTPメッセージフレーマーを事前接続に追加します。
framer := NewHTTPMessageFramer()
Preconnection.AddFramer(framer)
Since Message Framers pass from Preconnection to Listener or Connection, addition of Framers must happen before any operation that might result in the creation of a Connection.
メッセージフレーマーは、前提条件からリスナーまたは接続に渡るため、接続の作成につながる可能性のある操作の前に、フレーマーの追加が行われなければなりません。
When sending Messages, applications can add Framer-specific Properties to a MessageContext (Section 9.1.1) with the add action. To avoid naming conflicts, the Property names SHOULD be prefixed with a Namespace referencing the Framer implementation or the protocol it implements as described in Section 4.1.
メッセージを送信するとき、アプリケーションは、ADDアクションを使用して、Framer固有のプロパティ（セクション9.1.1）に追加することができます。競合の命名を避けるために、プロパティ名に、セクション4.1で説明されているように、フレーマーの実装またはプロトコルが実装する名前空間が付いている必要があります。
This mechanism can be used, for example, to set the type of a Message for a TLV format. The Namespace of values is custom for each unique Message Framer.
このメカニズムは、たとえば、TLV形式のメッセージのタイプを設定するために使用できます。値の名前空間は、一意のメッセージフレーマーごとにカスタムです。
messageContext := NewMessageContext()
messageContext.add(framer, key, value)
Connection.Send(messageData, messageContext)
When an application receives a MessageContext in a Receive event, it can also look to see if a value was set by a specific Message Framer.
アプリケーションが受信イベントでMessageContextを受信すると、特定のメッセージフレーマーによって値が設定されているかどうかを確認することもできます。
messageContext.get(framer, key) -> value
For example, if an HTTP Message Framer is used, the values could correspond to HTTP headers:
たとえば、HTTPメッセージframerを使用する場合、値はhttpヘッダーに対応できます。
httpFramer := NewHTTPMessageFramer()
...
messageContext := NewMessageContext()
messageContext.add(httpFramer, "accept", "text/html")
Applications needing to annotate the Messages they send with extra information (for example, to control how data is scheduled and processed by the transport protocols supporting the Connection) can include this information in the MessageContext passed to the Send action. For other uses of the MessageContext, see Section 9.1.1.
追加情報で送信するメッセージに注釈を付ける必要があるアプリケーション（たとえば、接続をサポートするトランスポートプロトコルによってデータのスケジュールおよび処理方法を制御するため）は、この情報を送信アクションに渡されたMessageContextに含めることができます。MessageContextの他の使用については、セクション9.1.1を参照してください。
Message Properties are per-Message, not per-Send, if partial Messages are sent (Section 9.2.3). All data blocks associated with a single Message share Properties specified in the MessageContexts. For example, it would not make sense to have the beginning of a Message expire and then allow the end of the Message to still be sent.
部分的なメッセージが送信された場合、メッセージプロパティは、センドごとではなく、1人のメッセージごとです（セクション9.2.3）。MessageContextsで指定された単一のメッセージ共有プロパティに関連付けられているすべてのデータブロック。たとえば、メッセージの始まりを期限切れにしてから、メッセージの終了をまだ送信できるようにすることは意味がありません。
A MessageContext object contains metadata for the Messages to be sent or received.
MessageContextオブジェクトには、送信または受信されるメッセージのメタデータが含まれています。
messageData := "hello"
messageContext := NewMessageContext()
messageContext.add(parameter, value)
Connection.Send(messageData, messageContext)
The simpler form of Send, which does not take any MessageContext, is equivalent to passing a default MessageContext without adding any Message Properties.
メッセージプロパティを追加せずにデフォルトのMessageContextを渡すのと同じです。
If an application wants to override Message Properties for a specific Message, it can acquire an empty MessageContext object and add all desired Message Properties to that object. It can then reuse the same MessageContext object for sending multiple Messages with the same Properties.
アプリケーションが特定のメッセージのメッセージプロパティをオーバーライドしたい場合、空のMessageContextオブジェクトを取得し、そのオブジェクトにすべての目的のメッセージプロパティを追加できます。その後、同じプロパティで複数のメッセージを送信するために、同じMESSAGECONTEXTオブジェクトを再利用できます。
Properties can be added to a MessageContext object only before the context is used for sending. Once a MessageContext has been used with a Send action, further modifications to the MessageContext object do not have any effect on this Send action. Message Properties that are not added to a MessageContext object before using the context for sending will either take a specific default value or be configured based on Selection or Connection Properties of the Connection that is associated with the Send action. This initialization behavior is defined per Message Property below.
コンテキストが送信に使用される前にのみ、プロパティをMessageContextオブジェクトに追加できます。MessageContextが送信アクションで使用されると、MessageContextオブジェクトのさらなる変更は、この送信アクションに影響を与えません。コンテキストを使用する前にMessageContextオブジェクトに追加されないメッセージプロパティは、送信アクションに関連付けられている接続の選択または接続プロパティに基づいて、特定のデフォルト値を取得するか、構成されます。この初期化動作は、以下のメッセージプロパティごとに定義されています。
The Message Properties could be inconsistent with the properties of the Protocol Stacks underlying the Connection on which a given Message is sent. For example, a Protocol Stack must be able to provide ordering if the msgOrdered Property of a Message is enabled. Sending a Message with Message Properties inconsistent with the Selection Properties of the Connection yields an error.
メッセージプロパティは、特定のメッセージが送信される接続の根底にあるプロトコルスタックのプロパティと矛盾する可能性があります。たとえば、メッセージのMSGORDEREDプロパティが有効になっている場合、プロトコルスタックは順序付けを提供できる必要があります。接続の選択プロパティと矛盾するメッセージプロパティを使用してメッセージを送信すると、エラーが生成されます。
If a Message Property contradicts a Connection Property, and if this per-Message behavior can be supported, it overrides the Connection Property for the specific Message. For example, if reliability is set to Require and a protocol with configurable per-Message reliability is used, setting msgReliable to false for a particular Message will allow this Message to be sent without any reliability guarantees. Changing the msgReliable Message Property is only possible for Connections that were established enabling the Selection Property perMsgReliability. If the contradicting Message Property cannot be supported by the Connection (such as requiring reliability on a Connection that uses an unreliable protocol), the Send action will result in a SendError event.
メッセージプロパティが接続プロパティと矛盾し、このメッセージごとの動作をサポートできる場合、特定のメッセージの接続プロパティをオーバーライドします。たとえば、信頼性が要求されるように設定されており、設定可能なメッセージごとの信頼性を備えたプロトコルが使用される場合、特定のメッセージに対してfalseにfalseに設定すると、信頼性の保証なしにこのメッセージを送信できます。MSGReliableメッセージプロパティを変更することは、選択プロパティPermsgreliLiabilityを有効にして確立された接続に対してのみ可能です。矛盾するメッセージプロパティを接続によってサポートできない場合（信頼できないプロトコルを使用する接続で信頼性を要求するなど）、送信アクションはSendErrorイベントになります。
The Message Properties in the following subsections are supported.
次のサブセクションのメッセージプロパティがサポートされています。
Name:
名前：
msgLifetime
msglifetime
Type:
タイプ：
Numeric (positive)
数値（ポジティブ）
Default:
デフォルト：
Infinite
無限
The Lifetime specifies how long a particular Message can wait in the Transport Services System before it is sent to the Remote Endpoint. After this time, it is irrelevant and no longer needs to be (re-)transmitted. This is a hint to the Transport Services System -- it is not guaranteed that a Message will not be sent when its Lifetime has expired.
Lifetimeは、特定のメッセージがリモートエンドポイントに送信されるまで、トランスポートサービスシステムで待つことができる期間を指定しています。この時間の後、それは無関係であり、もはや（再）送信する必要はありません。これは、輸送サービスシステムのヒントです。寿命が切れたときにメッセージが送信されないことは保証されていません。
Setting a Message's Lifetime to Infinite indicates that the application does not wish to apply a time constraint on the transmission of the Message, but it does not express a need for reliable delivery; reliability is adjustable per Message via the perMsgReliability Property (see Section 9.1.3.7). The type and units of Lifetime are implementation specific.
メッセージの寿命をInfiniteに設定すると、アプリケーションがメッセージの送信に時間制約を適用することを望んでいないことを示していますが、信頼できる配信の必要性を表明していません。信頼性は、Permsgrelileabilityプロパティを介してメッセージごとに調整可能です（セクション9.1.3.7を参照）。生涯のタイプと単位は実装固有です。
Name:
名前：
msgPriority
msgpriority
Type:
タイプ：
Integer (non-negative)
整数（非陰性）
Default:
デフォルト：
100
100
This Property specifies the priority of a Message, relative to other Messages sent over the same Connection. A numerically lower value represents a higher priority.
このプロパティは、同じ接続で送信された他のメッセージと比較して、メッセージの優先度を指定します。数値的に低い値は、優先度が高いことを表します。
A Message with priority 2 will yield to a Message with priority 1, which will yield to a Message with priority 0, and so on. Priorities can be used as a sender-side scheduling construct only or be used to specify priorities on the wire for Protocol Stacks supporting prioritization.
Priority 2を備えたメッセージは、優先度1を持つメッセージに屈します。これにより、Priority 0などのメッセージが得られます。優先順位は、優先順位付けをサポートするプロトコルスタックのワイヤー上の優先順位を指定するために、送信者側のスケジューリングコンストラクトとしてのみ使用できます。
Note that this Property is not a per-Message override of connPriority; see Section 8.1.2. The priority Properties might interact, but they can be used independently and be realized by different mechanisms; see Section 9.2.6.
このプロパティは、conconpriorityの過剰な過剰ではないことに注意してください。セクション8.1.2を参照してください。優先特性は相互作用する可能性がありますが、それらは独立して使用でき、さまざまなメカニズムによって実現できます。セクション9.2.6を参照してください。
Name:
名前：
msgOrdered
msgordered
Type:
タイプ：
Boolean
ブール
Default:
デフォルト：
the queried Boolean value of the Selection Property preserveOrder (Section 6.2.4)
セレクションプロパティプレジャーのクエリされたブール値（セクション6.2.4）
The order in which Messages were submitted for transmission via the Send action will be preserved on delivery via Receive events for all Messages on a Connection that have this Message Property set to true.
送信アクションを介して送信用にメッセージが送信される順序は、このメッセージプロパティがTRUEに設定されている接続のすべてのメッセージの受信イベントを介して配信時に保存されます。
If false, the Message is delivered to the receiving application without preserving the ordering. This Property is used for protocols that support preservation of data ordering (see Section 6.2.4) but allow out-of-order delivery for certain Messages, e.g., by multiplexing independent Messages onto different streams.
falseの場合、メッセージは注文を保持せずに受信アプリケーションに配信されます。このプロパティは、データの順序の保存をサポートするプロトコルに使用されます（セクション6.2.4を参照）が、たとえば、異なるストリームに独立したメッセージを多重化することにより、特定のメッセージの注文外配信を許可します。
If it is not configured by the application before sending, this Property's default value will be based on the Selection Property preserveOrder of the Connection associated with the Send action.
送信前にアプリケーションによって構成されていない場合、このプロパティのデフォルト値は、送信アクションに関連付けられている接続の選択プロパティ順序に基づいています。
Name:
名前：
safelyReplayable
SafelyReplayable
Type:
タイプ：
Boolean
ブール
Default:
デフォルト：
false
間違い
If true, safelyReplayable specifies that a Message is safe to send to the Remote Endpoint more than once for a single Send action. It marks the data as safe for certain 0-RTT establishment techniques, where retransmission of the 0-RTT data could cause the remote application to receive the Message multiple times.
Trueの場合、SafelyReplayableは、メッセージが1回の送信アクションのためにリモートエンドポイントに複数回送信できることを指定します。データを特定の0-RTT確立技術にとって安全であるとマークします。そこでは、0-RTTデータの再送信により、リモートアプリケーションがメッセージを複数回受信する可能性があります。
For protocols that do not protect against duplicated Messages, e.g., UDP, all Messages need to be marked as "safely replayable" by enabling this Property. To enable protocol selection to choose such a protocol, safelyReplayable needs to be added to the TransportProperties passed to the Preconnection. If such a protocol was chosen, disabling safelyReplayable on individual Messages MUST result in a SendError.
重複したメッセージ、たとえばUDPから保護しないプロトコルの場合、すべてのメッセージは、このプロパティを有効にすることで「安全に再生可能」としてマークする必要があります。プロトコルの選択がこのようなプロトコルを選択できるようにするには、事前接続に渡されたTransportPropertiesに安全に課せられる必要があります。そのようなプロトコルが選択された場合、個々のメッセージで安全に課せられる安全を無効にすると、SendErrorにつながる必要があります。
Name:
名前：
final
ファイナル
Type:
タイプ：
Boolean
ブール
Default:
デフォルト：
false
間違い
If true, this indicates a Message is the last that the application will send on a Connection. This allows underlying protocols to indicate to the Remote Endpoint that the Connection has been effectively closed in the sending direction. For example, TCP-based Connections can send a FIN once a Message marked as Final has been completely sent, indicated by marking endOfMessage. Protocols that do not support signaling the end of a Connection in a given direction will ignore this Property.
Trueの場合、これはメッセージがアプリケーションが接続に送信する最後のものであることを示します。これにより、基礎となるプロトコルは、リモートエンドポイントに、接続が送信方向で効果的に閉じられていることを示すことができます。たとえば、TCPベースの接続は、最終的なものとしてマークされたメッセージが完全に送信されると、EndOfMessageをマークすることでフィンを送信できます。特定の方向に接続の終了を通知することをサポートしないプロトコルは、このプロパティを無視します。
A Final Message must always be sorted to the end of a list of Messages. The final Property overrides connPriority, msgPriority, and any other Property that would reorder Messages. If another Message is sent after a Message marked as Final has already been sent on a Connection, the Send action for the new Message will cause a SendError event.
最終メッセージは、常にメッセージのリストの最後までソートする必要があります。最終的なプロパティは、conconpriority、msgpriority、およびメッセージを再注文するその他のプロパティを無効にします。ファイナルとしてマークされたメッセージが既に接続に送信された後に別のメッセージが送信された場合、新しいメッセージの送信アクションはSendErrorイベントを引き起こします。
Name:
名前：
msgChecksumLen
msgchecksumlen
Type:
タイプ：
Integer (non-negative) or Full Coverage
整数（非陰性）または完全なカバレッジ
Default:
デフォルト：
Full Coverage
完全なカバレッジ
If this Property is an Integer, it specifies the minimum length of the section of a sent Message, starting from byte 0, that the application requires to be delivered without corruption due to lower-layer errors. It is used to specify options for simple integrity protection via checksums. A value of 0 means that no checksum needs to be calculated, and the enumerated value Full Coverage means that the entire Message needs to be protected by a checksum. Only Full Coverage is guaranteed: any other requests are advisory, which may result in Full Coverage being applied.
このプロパティが整数である場合、BYTE 0から始まる送信メッセージのセクションの最小長さを指定します。アプリケーションは、低層エラーのために腐敗なしに配信する必要があります。これは、チェックサムを介して単純な整合性保護のオプションを指定するために使用されます。0の値は、チェックサムを計算する必要がないことを意味し、列挙された値の完全なカバレッジは、メッセージ全体をチェックサムによって保護する必要があることを意味します。完全なカバレッジのみが保証されます。他のリクエストはアドバイザリーであり、その結果、完全なカバレッジが適用される可能性があります。
Name:
名前：
msgReliable
msgreliable
Type:
タイプ：
Boolean
ブール
Default:
デフォルト：
the queried Boolean value of the Selection Property reliability (Section 6.2.1)
選択プロパティの信頼性のクエリされたブール値（セクション6.2.1）
When true, this Property specifies that a Message should be sent in such a way that the transport protocol ensures that all data is received by the Remote Endpoint. Changing the msgReliable Property on Messages is only possible for Connections that were established enabling the Selection Property perMsgReliability. When this is not the case, changing msgReliable will generate an error.
Trueの場合、このプロパティは、トランスポートプロトコルがすべてのデータがリモートエンドポイントによって受信されるようにメッセージを送信する必要があることを指定します。メッセージ上のMSGRelIlaibleプロパティを変更することは、選択されたプロパティPermsgreliLiabilityを可能にする接続でのみ可能です。そうでない場合、MSGReliableを変更するとエラーが生成されます。
Disabling this Property indicates that the Transport Services System could disable retransmissions or other reliability mechanisms for this particular Message, but such disabling is not guaranteed.
このプロパティを無効にすると、輸送サービスシステムがこの特定のメッセージの再送信またはその他の信頼性メカニズムを無効にする可能性があることを示していますが、そのような無効化は保証されていません。
If it is not configured by the application before sending, this Property's default value will be based on the Selection Property reliability of the Connection associated with the Send action.
送信前にアプリケーションによって構成されていない場合、このプロパティのデフォルト値は、送信アクションに関連付けられた接続の選択プロパティの信頼性に基づいています。
Name:
名前：
msgCapacityProfile
msgcapacityprofile
Type:
タイプ：
Enumeration
列挙
Default:
デフォルト：
inherited from the Connection Property connCapacityProfile (Section 8.1.6)
接続プロパティConncapacityProfileから継承（セクション8.1.6）
This enumerated Property specifies the application's preferred trade-offs for sending this Message; it is a per-Message override of the connCapacityProfile Connection Property (see Section 8.1.6). If it is not configured by the application before sending, this Property's default value will be based on the Connection Property connCapacityProfile of the Connection associated with the Send action.
この列挙されたプロパティは、このメッセージを送信するためのアプリケーションの優先トレードオフを指定します。これは、conncapacityprofile接続プロパティの過剰なオーバーライドです（セクション8.1.6を参照）。送信前にアプリケーションによって構成されていない場合、このプロパティのデフォルト値は、送信アクションに関連付けられている接続の接続プロパティconncapacityprofileに基づいています。
Name:
名前：
noFragmentation
ノフラグメント
Type:
タイプ：
Boolean
ブール
Default:
デフォルト：
false
間違い
This Property specifies that a Message should be sent and received without network-layer fragmentation, if possible. It can be used to avoid network-layer fragmentation when transport segmentation is preferred.
このプロパティは、可能であれば、ネットワーク層の断片化なしにメッセージを送信および受信する必要があることを指定します。輸送セグメンテーションが好まれる場合、ネットワーク層の断片化を回避するために使用できます。
This only takes effect when the transport uses a network layer that supports this functionality. When it does take effect, setting this Property to true will cause the sender to avoid network-layer source fragmentation. When using IPv4, this will result in the Don't Fragment (DF) bit being set in the IP header.
これは、トランスポートがこの機能をサポートするネットワークレイヤーを使用する場合にのみ有効になります。有効になると、このプロパティをTrueに設定すると、送信者がネットワーク層のソースの断片化を避けます。IPv4を使用すると、IPヘッダーで[フラグメント（DF）ビットが設定されないようになります。
Attempts to send a Message with this Property that result in a size greater than the transport's current estimate of its maximum packet size (singularTransmissionMsgMaxLen) can result in transport segmentation when permitted or in a SendError.
このプロパティを使用してメッセージを送信しようとすると、輸送の最大パケットサイズ（SingularTransmissionMsGmaxlen）の現在の推定値よりも大きいサイズになります。
Note: noSegmentation is used when it is desired to send a Message within a single network packet.
注：単一のネットワークパケット内でメッセージを送信することが望まれる場合、ノーズグレグメントは使用されます。
Name:
名前：
noSegmentation
ノーズグラメンテーション
Type:
タイプ：
Boolean
ブール
Default:
デフォルト：
false
間違い
When set to true, this Property requests that the transport layer not provide segmentation of Messages larger than the maximum size permitted by the network layer and that it avoid network-layer source fragmentation of Messages. When running over IPv4, setting this Property to true will result in a sending Endpoint setting the Don't Fragment bit in the IPv4 header of packets generated by the transport layer.
Trueに設定すると、このプロパティは、トランスポートレイヤーがネットワークレイヤーで許可されている最大サイズよりも大きいメッセージのセグメンテーションを提供しないことを要求し、メッセージのネットワーク層ソースの断片化を回避することを要求します。IPv4を介して実行すると、このプロパティをTrueに設定すると、送信エンドポイントが輸送層によって生成されたパケットのIPv4ヘッダーにdot fragmentビットを設定します。
An attempt to send a Message that results in a size greater than the transport's current estimate of its maximum packet size (singularTransmissionMsgMaxLen) will result in a SendError. This only takes effect when the transport and network layers support this functionality.
トランスポートの最大パケットサイズ（SingularTransmissionMsGmaxlen）の現在の推定値よりも大きいサイズになるメッセージを送信しようとすると、SendErrorが生成されます。これは、トランスポートレイヤーとネットワーク層がこの機能をサポートしている場合にのみ有効になります。
Once a Connection has been established, it can be used for sending Messages. By default, Send enqueues a complete Message and takes optional per-Message Properties (see Section 9.2.1). All Send actions are asynchronous and deliver events (see Section 9.2.2). Sending partial Messages for streaming large data is also supported (see Section 9.2.3).
接続が確立されると、メッセージの送信に使用できます。デフォルトでは、Enqueuesに完全なメッセージを送信し、オプションのメッセージごとのプロパティを実行します（セクション9.2.1を参照）。すべての送信アクションは非同期であり、イベントを配信します（セクション9.2.2を参照）。大規模なデータをストリーミングするための部分的なメッセージの送信もサポートされています（セクション9.2.3を参照）。
Messages are sent on a Connection using the Send action:
メッセージは、送信アクションを使用して接続に送信されます。
Connection.Send(messageData, messageContext?, endOfMessage?)
where messageData is the data object to send and messageContext allows adding Message Properties, identifying Send events related to a specific Message or inspecting metadata related to the Message sent (see Section 9.1.1).
MESSAGEDATAは送信およびMESSAGECONTEXTを送信するデータオブジェクトであり、メッセージプロパティを追加したり、特定のメッセージに関連するイベントの送信イベントを識別したり、送信されたメッセージに関連するメタデータを検査したりします（セクション9.1.1を参照）。
The optional endOfMessage parameter supports partial sending and is described in Section 9.2.3.
オプションのEndofMessageパラメーターは部分的な送信をサポートし、セクション9.2.3で説明します。
The most basic form of sending on a Connection involves enqueuing a single Data block as a complete Message with default Message Properties.
接続を送信する最も基本的な形式では、デフォルトのメッセージプロパティを使用した完全なメッセージとして、単一のデータブロックをエンキューすることが含まれます。
messageData := "hello"
Connection.Send(messageData)
The interpretation of a Message to be sent is dependent on the implementation and on the constraints on the Protocol Stacks implied by the Connection's transport properties. For example, a Message could be the payload of a single datagram for a UDP connection. Another example would be an HTTP Request for an HTTP Connection.
送信されるメッセージの解釈は、実装と、接続の輸送プロパティによって暗示されるプロトコルスタックの制約に依存します。たとえば、メッセージは、UDP接続の単一のデータグラムのペイロードである可能性があります。別の例は、HTTP接続のHTTPリクエストです。
Some transport protocols can deliver arbitrarily sized Messages, but other protocols constrain the maximum Message size. Applications can query the Connection Property sendMsgMaxLen (Section 8.1.11.5) to determine the maximum size allowed for a single Message. If a Message is too large to fit in the Maximum Message Size for the Connection, the Send will fail with a SendError event (Section 9.2.2.3). For example, it is invalid to send a Message over a UDP connection that is larger than the available datagram sending size.
一部のトランスポートプロトコルでは、任意にサイズのメッセージを提供できますが、他のプロトコルは最大メッセージサイズを制約します。アプリケーションは、接続プロパティsendmsgmaxlen（セクション8.1.11.5）を照会して、単一のメッセージに許容される最大サイズを決定できます。メッセージが大きすぎて接続の最大メッセージサイズに収まると、送信はSendErrorイベントで失敗します（セクション9.2.2.3）。たとえば、利用可能なデータグラムの送信サイズよりも大きいUDP接続を介してメッセージを送信することは無効です。
Like all actions in the Transport Services API, the Send action is asynchronous. There are several events that can be delivered in response to sending a Message. Exactly one event (Sent, Expired, or SendError) will be delivered in response to each call to Send.
Transport Services APIのすべてのアクションと同様に、送信アクションは非同期です。メッセージの送信に応じて配信できるイベントがいくつかあります。正確に1つのイベント（送信、期限切れ、またはsenderror）は、各コールに応答して配信されます。
Note that, if partial Send calls are used (Section 9.2.3), there will still be exactly one Send event delivered for each call to Send. For example, if a Message expired while two requests to Send data for that Message are outstanding, there will be two Expired events delivered.
部分的な送信コールが使用されている場合（セクション9.2.3）、送信ごとに配信される1つの送信イベントがまだ1つあります。たとえば、そのメッセージのデータを送信する2つのリクエストが未解決の場合、メッセージの有効期限が切れた場合、2つの期限切れのイベントが配信されます。
The Transport Services API should allow the application to correlate a Send event to the particular call to Send that triggered the event. The manner in which this correlation is indicated is implementation specific.
Transport Services APIは、アプリケーションが送信イベントを特定の呼び出しに相関させることを可能にする必要があります。この相関が示される方法は、実装固有です。
Connection -> Sent<messageContext>
The Sent event occurs when a previous Send action has completed, i.e., when the data derived from the Message has been passed down or through the underlying Protocol Stack and is no longer the responsibility of the Transport Services API. The exact disposition of the Message (i.e., whether it has actually been transmitted, moved into a buffer on the network interface, moved into a kernel buffer, and so on) when the Sent event occurs is implementation specific. The Sent event contains a reference to the Message Context of the Message to which it applies.
送信イベントは、以前の送信アクションが完了したときに発生します。つまり、メッセージから派生したデータが下に渡されるか、基礎となるプロトコルスタックを介して渡され、輸送サービスAPIの責任ではなくなります。送信イベントが発生したときに、メッセージの正確な配置（つまり、実際に送信された、ネットワークインターフェイスのバッファーに移動し、カーネルバッファーに移動するなど）が実装固有です。送信されたイベントには、適用されるメッセージのメッセージコンテキストへの参照が含まれています。
Sent events allow an application to obtain an understanding of the amount of buffering it creates. That is, if an application calls the Send action multiple times without waiting for a Sent event, it has created more buffer inside the Transport Services System than an application that always waits for the Sent event before calling the next Send action.
送信されたイベントにより、アプリケーションが作成するバッファリングの量の理解を得ることができます。つまり、アプリケーションが送信イベントを待たずにセンドアクションを複数回呼び出す場合、次の送信アクションを呼び出す前に常に送信イベントを待つアプリケーションよりも、トランスポートサービスシステム内でより多くのバッファーを作成しました。
Connection -> Expired<messageContext>
The Expired event occurs when a previous Send action expired before completion, i.e., when the Message was not sent before its Lifetime (see Section 9.1.3.1) expired. This is separate from SendError, as it is an expected behavior for partially reliable transports. The Expired event contains a reference to the MessageContext of the Message to which it applies.
期限切れのイベントは、以前の送信アクションが完了前に期限切れになったときに発生します。つまり、その寿命（セクション9.1.3.1を参照）が失効する前にメッセージが送信されなかったときに発生します。これは、部分的に信頼性の高い輸送に期待される動作であるため、Senderrorとは別です。期限切れのイベントには、適用されるメッセージのMessageContextへの参照が含まれています。
Connection -> SendError<messageContext, reason?>
A SendError occurs when a Message was not sent due to an error condition: an attempt to send a Message that is too large for the system and Protocol Stack to handle, some failure of the underlying Protocol Stack, or a set of Message Properties not consistent with the Connection's transport properties. The SendError contains a reference to the MessageContext of the Message to which it applies.
エラー条件のためにメッセージが送信されないときにsenderrorが発生します。システムとプロトコルスタックが処理するには大きすぎるメッセージ、基礎となるプロトコルスタックの障害、または一貫性のないメッセージプロパティのセットを送信する試みです。接続のトランスポートプロパティ。SendErrorには、適用されるメッセージのMessageContextへの参照が含まれています。
It is not always possible for an application to send all data associated with a Message in a single Send action. The Message data might be too large for the application to hold in memory at one time or the length of the Message might be unknown or unbounded.
アプリケーションが単一の送信アクションでメッセージに関連付けられたすべてのデータを送信できるとは限りません。メッセージデータは、アプリケーションが一度にメモリに保持するには大きすぎる場合があります。または、メッセージの長さが不明または束縛されていない場合があります。
Partial Message sending is supported by passing an endOfMessage Boolean parameter to the Send action. This value is always true by default, and the simpler forms of Send are equivalent to passing true for endOfMessage.
部分的なメッセージ送信は、endofmessageブールパラメーターを送信アクションに渡すことによりサポートされます。この値はデフォルトで常に真であり、Sendのよりシンプルな形式は、EndofMessageにTrueを渡すのと同等です。
The following example sends a Message in two separate calls to Send:
次の例では、2つの個別の呼び出しでメッセージを送信します。
messageContext := NewMessageContext()
messageContext.add(parameter, value)
messageData := "hel"
endOfMessage := false
Connection.Send(messageData, messageContext, endOfMessage)
messageData := "lo"
endOfMessage := true
Connection.Send(messageData, messageContext, endOfMessage)
All data sent with the same MessageContext object will be treated as belonging to the same Message and will constitute an in-order series until the endOfMessage is marked.
同じMESSAGECONTEXTオブジェクトで送信されたすべてのデータは、同じメッセージに属するものとして扱われ、エンドオフメッジがマークされるまで次のシリーズを構成します。
To reduce the overhead of sending multiple small Messages on a Connection, the application could batch several Send actions together. This provides a hint to the system that the sending of these Messages ought to be coalesced when possible and that sending any of the batched Messages can be delayed until the last Message in the batch is enqueued.
接続に複数の小さなメッセージを送信するオーバーヘッドを減らすために、アプリケーションはいくつかのアクションを一緒に送信することができます。これにより、これらのメッセージの送信は可能な場合は合体し、バッチの最後のメッセージがenquedになるまでバッチメッセージの送信を遅らせることができるというシステムにヒントが提供されます。
The semantics for starting and ending a batch can be implementation specific but need to allow multiple Send actions to be enqueued.
バッチを開始および終了するためのセマンティクスは、実装固有の場合がありますが、複数の送信アクションを使用できるようにする必要があります。
Connection.StartBatch()
Connection.Send(messageData)
Connection.Send(messageData)
Connection.EndBatch()
For application-layer protocols where the Connection initiator also sends the first Message, the InitiateWithSend action combines Connection initiation with a first Message sent:
接続イニシエーターも最初のメッセージを送信するアプリケーション層プロトコルの場合、InitiateWithSendアクションは、接続の開始と最初のメッセージを組み合わせます。
Connection := Preconnection.InitiateWithSend(messageData,
messageContext?,
timeout?)
Whenever possible, a messageContext should be provided to declare the Message passed to InitiateWithSend as "safely replayable" using the safelyReplayable Property. This allows the Transport Services System to make use of 0-RTT establishment in case this is supported by the available Protocol Stacks. When the selected stack or stacks do not support transmitting data upon connection establishment, InitiateWithSend is identical to Initiate followed by Send.
可能な場合はいつでも、MESSAGECONTEXTを提供して、渡されたメッセージを宣言して、セーフリプレイ可能なプロパティを使用して「安全に再生可能」として開始するように開始するように宣言する必要があります。これにより、これが利用可能なプロトコルスタックによってサポートされている場合に備えて、トランスポートサービスシステムが0-RTT確立を使用できるようになります。選択したスタックまたはスタックが接続の確立時にデータの送信データをサポートしない場合、aidiatewithsendはsendを開始するのと同じです。
Neither partial sends nor send batching are supported by InitiateWithSend.
Partial SendまたはSendバッチは、IntiateWithSendによってサポートされていません。
The events that are sent after InitiateWithSend are equivalent to those that would be sent by an invocation of Initiate followed immediately by an invocation of Send, with the caveat that a send failure that occurs because the Connection could not be established will not result in a SendError separate from the EstablishmentError signaling the failure of Connection establishment.
InitiateWithSendの後に送信されるイベントは、initiateの呼び出しがすぐに送信されることによって送信されるイベントと同等です。接続確立の失敗を合図する設立エラーとは別に。
The Transport Services API provides two Properties to allow a sender to signal the relative priority of data transmission: msgPriority (see Section 9.1.3.2) and connPriority (see Section 8.1.2). These Properties are designed to allow the expression and implementation of a wide variety of approaches to transmission priority in the transport and application layers, including those that do not appear on the wire (affecting only sender-side transmission scheduling) as well as those that do (e.g., [RFC9218]). A Transport Services System gives no guarantees about how its expression of relative priorities will be realized.
Transport Services APIは、送信者がデータ送信の相対的な優先度を信号することを可能にする2つのプロパティを提供します：MSGPRIORITY（セクション9.1.3.2を参照）とconconpriority（セクション8.1.2を参照）。これらのプロパティは、ワイヤーに表示されないもの（送信者側の送信スケジューリングのみに影響を与える）を含む、トランスポートおよびアプリケーション層の伝送優先度に対するさまざまなアプローチの表現と実装を可能にするように設計されています。（例：[RFC9218]）。輸送サービスシステムは、相対的な優先順位の表現がどのように実現されるかについての保証を提供しません。
The Transport Services API does order connPriority over msgPriority. In the absence of other externalities (e.g., transport-layer flow control), a priority 1 Message on a priority 0 Connection will be sent before a priority 0 Message on a priority 1 Connection in the same group.
Transport Services APIは、MSGPRIORITYよりも順序付けを行います。他の外部性（たとえば、輸送層の流れ制御など）がない場合、優先順位0接続の優先1メッセージは、同じグループの優先度1接続の優先0メッセージの前に送信されます。
Once a Connection is established, it can be used for receiving data (unless the direction Property is set to unidirectional send). As with sending, the data is received in Messages. Receiving is an asynchronous operation in which each call to Receive enqueues a request to receive new data from the Connection. Once data has been received, or an error is encountered, an event will be delivered to complete any pending Receive requests (see Section 9.3.2). If Messages arrive at the Transport Services System before Receive requests are issued, ensuing Receive requests will first operate on these Messages before awaiting any further Messages.
接続が確立されると、データの受信に使用できます（方向プロパティが単方向送信に設定されていない限り）。送信と同様に、データはメッセージで受信されます。受信は非同期操作であり、各呼び出しがエンキューを受信するために、接続から新しいデータを受信するリクエストを受け取ります。データが受信されるか、エラーが発生したら、保留中の受信リクエストを完了するためにイベントが配信されます（セクション9.3.2を参照）。受信リクエストが発行される前にメッセージが輸送サービスシステムに到着した場合、それ以上のメッセージを待つ前に、受信リクエストがこれらのメッセージで最初に動作します。
Receive takes two parameters to specify the length of data that an application is willing to receive, both of which are optional and have default values if not specified.
受信は、アプリケーションが受信する意思のあるデータの長さを指定するために2つのパラメーターを取ります。どちらもオプションであり、指定されていない場合はデフォルト値があります。
Connection.Receive(minIncompleteLength?, maxLength?)
By default, Receive will try to deliver complete Messages in a single event (Section 9.3.2.1).
デフォルトでは、受信は1つのイベント（セクション9.3.2.1）で完全なメッセージを配信しようとします。
The application can set a minIncompleteLength value to indicate the smallest partial Message data size in bytes to be delivered in response to this Receive. By default, this value is Infinite, which means that only complete Messages should be delivered. See Sections 9.3.2.2 and 9.1.2 for more information on how this is accomplished. If this value is set to some smaller value, the associated Receive event will be triggered only:
アプリケーションは、MinincompleTeLength値を設定して、この受信に応じて配信されるバイトの最小の部分メッセージデータサイズを示すことができます。デフォルトでは、この値は無限であるため、完全なメッセージのみを配信する必要があります。これがどのように達成されるかの詳細については、セクション9.3.2.2および9.1.2を参照してください。この値がある程度の値に設定されている場合、関連する受信イベントはトリガーされます。
1. when at least that many bytes are available,
1. 少なくとも多くのバイトが利用可能な場合、
2. the Message is complete with fewer bytes, or
2. メッセージは、より少ないバイトで完了します
3. the system needs to free up memory.
3. システムはメモリを解放する必要があります。
Applications SHOULD always check the length of the data delivered to the Receive event and not assume it will be as long as minIncompleteLength in the case of shorter complete Messages or memory issues.
アプリケーションは常に受信イベントに配信されたデータの長さを確認する必要がありますが、より短い完全なメッセージまたはメモリの問題の場合、それがminincompletelengthになると想定しないでください。
The maxLength argument indicates the maximum size of a Message in bytes that the application is currently prepared to receive. The default value for maxLength is Infinite. If an incoming Message is larger than the minimum of this size and the maximum Message size on receive for the Connection's Protocol Stack, it will be delivered via ReceivedPartial events (Section 9.3.2.2).
最大長の引数は、アプリケーションが現在受信する準備ができているバイトのメッセージの最大サイズを示します。MaxLengthのデフォルト値は無限です。着信メッセージがこのサイズの最小値よりも大きい場合、接続のプロトコルスタックの受信時の最大メッセージサイズは、受信部のイベントを介して配信されます（セクション9.3.2.2）。
Note that maxLength does not guarantee that the application will receive that many bytes if they are available; the Transport Services API could return ReceivedPartial events with less data than maxLength according to implementation constraints. Note also that maxLength and minIncompleteLength are intended only to manage buffering and are not interpreted as a receiver preference for Message reordering.
MaxLengthは、アプリケーションが利用可能な場合、アプリケーションがその多くのバイトを受け取ることを保証しないことに注意してください。Transport Services APIは、実装の制約に応じて、最大長よりも少ないデータで受信部門のイベントを返すことができます。また、MaxLengthとMinincompletelengthはバッファリングの管理のみを目的としており、メッセージの再注文に対する受信者の好みとして解釈されないことに注意してください。
Each call to Receive will be paired with a single Receive event. This allows an application to provide backpressure to the Protocol Stack when it is temporarily not ready to receive Messages. For example, an application that will later be able to handle multiple Receive events at the same time can make multiple calls to Receive without waiting for, or processing, any Receive events. An application that is temporarily unable to process received events for a connection could refrain from calling Receive or could delay calling it. This would lead to a buildup of unread data, which, in turn, could result in backpressure to the sender via a transport protocol's flow control.
受信する各呼び出しは、単一の受信イベントとペアになります。これにより、アプリケーションは一時的にメッセージを受信する準備ができていない場合に、プロトコルスタックにバックプレッシャーを提供できます。たとえば、後で複数の受信イベントを同時に処理できるアプリケーションは、受信イベントを待つことや処理せずに受信するために複数の電話をかけることができます。接続のために受信したイベントを一時的に処理できないアプリケーションは、受信を呼び出すことを控えるか、それを呼び出すことを遅らせる可能性があります。これにより、未読データが蓄積され、輸送プロトコルのフロー制御を介して送信者に逆圧力をかける可能性があります。
The Transport Services API should allow the application to correlate a Receive event to the particular call to Receive that triggered the event. The manner in which this correlation is indicated is implementation specific.
Transport Services APIは、アプリケーションが受信イベントを特定の呼び出しに相関させることを可能にする必要があります。この相関が示される方法は、実装固有です。
Connection -> Received<messageData, messageContext>
A Received event indicates the delivery of a complete Message. It contains two objects: the received bytes as messageData and the metadata and Properties of the received Message as messageContext.
受け取ったイベントは、完全なメッセージの配信を示します。2つのオブジェクトが含まれています。MESSAGEDATAとして受信されたバイトと、MESSAGECONTEXTとしての受信メッセージのメタデータとプロパティです。
The messageData value provides access to the bytes that were received for this Message, along with the length of the byte array. The messageContext value is provided to enable retrieving metadata about the Message and referring to the Message. The MessageContext object is described in Section 9.1.1.
MESSAGEDATA値は、バイト配列の長さとともに、このメッセージに対して受信されたバイトへのアクセスを提供します。MessageContext値は、メッセージについてメタデータを取得し、メッセージを参照できるようにするために提供されます。MessageContextオブジェクトは、セクション9.1.1で説明されています。
See Section 9.1.2 regarding how to handle Message framing in situations where the Protocol Stack only provides a byte-stream transport.
プロトコルスタックがバイトストリームトランスポートのみを提供する状況でメッセージフレーミングを処理する方法については、セクション9.1.2を参照してください。
Connection -> ReceivedPartial<messageData, messageContext,
endOfMessage>
If a complete Message cannot be delivered in one event, one part of the Message can be delivered with a ReceivedPartial event. To continue to receive more of the same Message, the application must invoke Receive again.
1つのイベントで完全なメッセージを配信できない場合、メッセージの一部を受け取った出来事で配信できます。同じメッセージをより多く受信し続けるには、アプリケーションは再び受信を呼び出す必要があります。
Multiple invocations of ReceivedPartial deliver data for the same Message by passing the same MessageContext until the value of the endOfMessage Property is delivered or a ReceiveError occurs. All partial blocks of a single Message are delivered in order without gaps. This event does not support delivering non-contiguous partial Messages. For example, if Message A is divided into three pieces (A1, A2, and A3), Message B is divided into three pieces (B1, B2, and B3), and preserveOrder is not Require, the ReceivedPartial could deliver them in a sequence like this: A1, B1, B2, A2, A3, B3. This is because the MessageContext allows the application to identify the pieces as belonging to Message A and B, respectively. However, a sequence like A1, A3 will never occur.
EndofMessageプロパティの値が配信されるか受信エラーが発生するまで、同じメッセージのデータの受信パルチアル配信データの複数の呼び出し。単一のメッセージのすべての部分ブロックは、ギャップなしで整理されて配信されます。このイベントは、非連続的な部分メッセージの配信をサポートしていません。たとえば、メッセージAが3つのピース（A1、A2、およびA3）に分割されている場合、メッセージBは3つのピース（B1、B2、およびB3）に分割され、Preserve Orderは必要ありません。このように：A1、B1、B2、A2、A3、B3。これは、MessageContextがアプリケーションがそれぞれメッセージAとBに属するものとしてピースを識別できるためです。ただし、A1、A3のようなシーケンスは発生しません。
If the minIncompleteLength in the Receive request was set to be Infinite (indicating a request to receive only complete Messages), the ReceivedPartial event could still be delivered if one of the following conditions is true:
受信リクエストのminincompletelengthが無限に設定されている場合（完全なメッセージのみを受信するリクエストを示します）、以下の条件のいずれかが真である場合、受信部のイベントは引き続き配信される可能性があります。
* the underlying Protocol Stack supports Message boundary preservation and the size of the Message is larger than the buffers available for a single Message;
* 基礎となるプロトコルスタックはメッセージの境界保存をサポートし、メッセージのサイズは単一のメッセージで使用可能なバッファーよりも大きくなります。
* the underlying Protocol Stack does not support Message boundary preservation and the Message Framer (see Section 9.1.2) cannot determine the end of the Message using the buffer space it has available; or
* 基礎となるプロトコルスタックはメッセージの境界保存をサポートせず、メッセージフレーマー（セクション9.1.2を参照）は、使用可能なバッファースペースを使用してメッセージの終了を決定できません。または
* the underlying Protocol Stack does not support Message boundary preservation and no Message Framer was supplied by the application.
* 基礎となるプロトコルスタックは、メッセージの境界保存をサポートせず、アプリケーションによってFramerが提供されませんでした。
Note that, in the absence of Message boundary preservation or a Message Framer, all bytes received on the Connection will be represented as one large Message of indeterminate length.
メッセージの境界保存またはメッセージフレーマーがない場合、接続で受信したすべてのバイトは、不確定な長さの1つの大きなメッセージとして表されることに注意してください。
In the following example, an application only wants to receive up to 1000 bytes at a time from a Connection. If a 1500-byte Message arrives, it would receive the Message in two separate ReceivedPartial events.
次の例では、アプリケーションは、接続から一度に最大1000バイトのみを受信したいと考えています。1500バイトのメッセージが届くと、2つの別々の受信特別イベントでメッセージが受信されます。
Connection.Receive(1, 1000)
// Receive the first 1000 bytes; Message is incomplete
Connection -> ReceivedPartial<messageData(1000 bytes),
messageContext, false>
Connection.Receive(1, 1000)
// Receive the last 500 bytes; Message is now complete
Connection -> ReceivedPartial<messageData(500 bytes),
messageContext, true>
Connection -> ReceiveError<messageContext, reason?>
A ReceiveError occurs when:
受信エラーは次の場合に発生します。
* data is received by the underlying Protocol Stack that cannot be fully retrieved or parsed, and
* データは、完全に取得または解析できない基礎となるプロトコルスタックによって受信され、
* it is useful for the application to be notified of such errors.
* アプリケーションにそのようなエラーを通知するのに役立ちます。
For example, a ReceiveError can indicate that a Message (identified via the messageContext value) that was being partially received previously, but had not completed, encountered an error and will not be completed. This can be useful for an application, which might wish to use this error as a hint to remove previously received Message parts from memory. As another example, if an incoming Message does not fulfill the recvChecksumLen Property (see Section 8.1.1), an application can use this error as a hint to inform the peer application to adjust the msgChecksumLen Property (see Section 9.1.3.6).
たとえば、受信エラーは、以前に部分的に受信されていたが完了しておらず、エラーが発生し、完了しないメッセージ（MessageContext値で識別）を示すことができます。これはアプリケーションに役立つ場合があります。アプリケーションは、このエラーをヒントとして使用して、以前に受信したメッセージパーツをメモリから削除することをお勧めします。別の例として、着信メッセージがRecvChecksumlenプロパティを満たしていない場合（セクション8.1.1を参照）、アプリケーションはこのエラーをヒントとして使用してピアアプリケーションに通知してMSGChecksumlenプロパティを調整できます（セクション9.1.3.6を参照）。
In contrast, internal protocol reception errors (e.g., loss causing retransmissions in TCP) are not signaled by this event. Conditions that irrevocably lead to the termination of the Connection are signaled using ConnectionError (see Section 10).
対照的に、内部プロトコル受信エラー（たとえば、TCPの再送信を引き起こす損失）は、このイベントでは示されません。接続の終了に取り返しのつかないほど導かれる条件は、ConnectionErrorを使用してシグナル伝えられます（セクション10を参照）。
Each MessageContext could contain metadata from protocols in the Protocol Stack; which metadata is available is Protocol Stack dependent. These are exposed through additional read-only Message Properties that can be queried from the MessageContext object (see Section 9.1.1) passed by the Receive event. The metadata values in the following subsections are supported.
各MESSAGECONTEXTには、プロトコルスタックのプロトコルからメタデータを含めることができます。どのメタデータが利用可能かは、プロトコルスタック依存です。これらは、受信イベントで渡されたMessageContextオブジェクト（セクション9.1.1を参照）から照会できる追加の読み取り専用メッセージプロパティを介して公開されます。次のサブセクションのメタデータ値がサポートされています。
When available, Message metadata carries the value of the Explicit Congestion Notification (ECN) field. This information can be used for logging and debugging as well as building applications that need access to information about the transport internals for their own operation. This Property is specific to UDP and UDP-Lite, because these protocols do not implement congestion control; hence, they expose this functionality to the application (see [RFC8293], following the guidance in [RFC8085]).
利用可能な場合、メッセージメタデータは、明示的な混雑通知（ECN）フィールドの値を伝えます。この情報は、ロギングとデバッグ、および独自の操作のために輸送内部に関する情報へのアクセスが必要なアプリケーションの構築に使用できます。これらのプロトコルは混雑制御を実装していないため、このプロパティはUDPおよびUDP-Liteに固有です。したがって、彼らはこの機能をアプリケーションに公開します（[RFC8085]のガイダンスに従って、[RFC8293]を参照）。
In some cases, it can be valuable to know whether data was read as part of early data transfer (before Connection establishment has finished). This is useful if applications need to treat early data separately, e.g., if early data has different security Properties than data sent after Connection establishment. In the case of TLS 1.3, client early data can be replayed maliciously (see [RFC8446]). Thus, receivers might wish to perform additional checks for early data to ensure that it is safely replayable. If TLS 1.3 is available and the recipient Message was sent as part of early data, the corresponding metadata carries a flag indicating as such. If early data is enabled, applications should check this metadata field for Messages received during Connection establishment and respond accordingly.
場合によっては、早期データ転送の一部としてデータが読み取られたかどうかを知ることは価値があります（接続確立が終了する前）。これは、アプリケーションが初期データを個別に扱う必要がある場合に役立ちます。たとえば、初期データに接続確立後に送信されるデータとは異なるセキュリティプロパティがある場合。TLS 1.3の場合、クライアントの初期データは悪意を持って再生できます（[RFC8446]を参照）。したがって、受信機は、安全に再生可能であることを確認するために、早期データの追加チェックを実行したい場合があります。TLS 1.3が利用可能で、受信者メッセージが初期データの一部として送信された場合、対応するメタデータにはそのようなフラグがあります。初期のデータが有効になっている場合、アプリケーションは、接続確立中に受信されたメッセージがこのメタデータフィールドを確認し、それに応じて応答する必要があります。
The MessageContext can indicate whether or not this Message is the last Message on a Connection. For any Message that is marked as Final, the application can assume that there will be no more Messages received on the Connection once the Message has been completely delivered. This corresponds to the final Property that can be marked on a sent Message; see Section 9.1.3.5.
MessageContextは、このメッセージが接続の最後のメッセージであるかどうかを示すことができます。ファイナルとしてマークされているメッセージの場合、アプリケーションは、メッセージが完全に配信されると、接続にメッセージがかなっていないと想定できます。これは、送信されたメッセージにマークできる最終プロパティに対応します。セクション9.1.3.5を参照してください。
Some transport protocols and peers do not support signaling of the final Property. Therefore, applications SHOULD NOT rely on receiving a Message marked Final to know that the sending Endpoint is done sending on a Connection.
一部の輸送プロトコルとピアは、最終的なプロパティの信号をサポートしていません。したがって、アプリケーションはファイナルとマークされたメッセージの受信に依存して、送信エンドポイントが接続の送信が完了していることを知るべきではありません。
Any calls to Receive once the Final Message has been delivered will result in errors.
最終メッセージが配信されると受信するための呼び出しは、エラーになります。
A Connection can be terminated:
接続を終了することができます：
1. by the Local Endpoint (i.e., the application calls the Close, CloseGroup, Abort, or AbortGroup action),
1. ローカルエンドポイントによって（つまり、アプリケーションは、閉じる、閉じる、中絶、またはアボートグループアクションを呼び出します）、
2. by the Remote Endpoint (i.e., the remote application calls the Close, CloseGroup, Abort, or AbortGroup action), or
2. リモートエンドポイント（つまり、リモートアプリケーションが閉鎖、閉じる、中止、またはアボートグループアクションを呼び出す）、または
3. because of an error (e.g., a timeout).
3. エラーのため（例：タイムアウト）。
A local call of the Close action will cause the Connection to send either a Closed event or a ConnectionError event; a local call of the CloseGroup action will cause all of the Connections in the group to send either a Closed event or a ConnectionError event. A local call of the Abort action will cause the Connection to send a ConnectionError event, indicating local Abort as a reason; a local call of the AbortGroup action will cause all of the Connections in the group to send a ConnectionError event, indicating local Abort as a reason.
密接なアクションのローカルコールにより、接続は閉じたイベントまたはConnectionErrorイベントのいずれかを送信します。Closeグループアクションのローカルコールにより、グループ内のすべての接続が閉じたイベントまたはConnectionErrorイベントのいずれかを送信します。ローカルの中止アクションの呼び出しにより、接続がConnectionErrorイベントを送信し、ローカル中断を理由として示します。AbortGroupアクションのローカルコールにより、グループ内のすべての接続がConnectionErrorイベントを送信し、ローカル中断を理由として示します。
Remote action calls map to events similar to local calls (e.g., a remote Close causes the Connection to send either a Closed event or a ConnectionError event), but in contrast to local action calls, it is not guaranteed that such events will indeed be invoked. When an application needs to free resources associated with a Connection, it ought not rely on the invocation of such events due to termination calls from the Remote Endpoint; instead, it should use the local termination actions.
リモートアクションコールローカルコールと同様のイベントへのマップ（例えば、リモートクローズにより、接続が閉じたイベントまたはConnectionErrorイベントのいずれかを送信します）が、ローカルアクションコールとは対照的に、そのようなイベントが実際に呼び出されることは保証されていません。アプリケーションが接続に関連付けられたリソースを解放する必要がある場合、リモートエンドポイントからの終了呼び出しによるこのようなイベントの呼び出しに依存するべきではありません。代わりに、ローカル終了アクションを使用する必要があります。
Close terminates a Connection after satisfying all the requirements that were specified regarding the delivery of Messages that the application has already given to the Transport Services System. Upon successfully satisfying all these requirements, the Connection will send the Closed event. For example, if reliable delivery was requested for a Message handed over before calling Close, the Closed event will signify that this Message has indeed been delivered. This action does not affect any other Connection in the same Connection Group.
Closeは、アプリケーションが輸送サービスシステムに既に提供しているメッセージの配信に関して指定されたすべての要件を満たした後、接続を終了します。これらすべての要件を正常に満たすと、接続はクローズドイベントを送信します。たとえば、Closeを呼び出す前に伝達されたメッセージの信頼できる配信が要求された場合、クローズドイベントはこのメッセージが実際に配信されたことを示します。このアクションは、同じ接続グループの他の接続には影響しません。
An application MUST NOT assume that it can receive any further data on a Connection for which it has called Close, even if such data is already in flight.
アプリケーションは、そのようなデータがすでに飛行中であっても、Closeと呼ばれる接続に関するさらなるデータを受信できると想定してはなりません。
Connection.Close()
The Closed event informs the application that a Close action has successfully completed or that the Remote Endpoint has closed the Connection. There is no guarantee that a remote Close will be signaled.
クローズドイベントは、緊密なアクションが正常に完了したこと、またはリモートエンドポイントが接続を閉じたことをアプリケーションに通知します。リモートクローズが信号を受けるという保証はありません。
Connection -> Closed<>
Abort terminates a Connection without delivering any remaining Messages. This action does not affect any other Connection that is entangled with this one in a Connection Group. When the Abort action has finished, the Connection will send a ConnectionError event, indicating local Abort as a reason.
Abortは、残りのメッセージを配信せずに接続を終了します。このアクションは、接続グループ内のこの接続に絡み合っている他の接続には影響しません。中止アクションが終了すると、接続がConnectionErrorイベントを送信し、ローカル中断を理由として示します。
Connection.Abort()
CloseGroup gracefully terminates a Connection and any other Connections in the same Connection Group. For example, all of the Connections in a group might be streams of a single session for a multistreaming protocol; closing the entire group will close the underlying session. See also Section 7.4. All Connections in the group will send a Closed event when the CloseGroup action was successful. As with Close, any Messages remaining to be processed on a Connection will be handled prior to closing.
CloseGroupは、同じ接続グループの接続とその他の接続を優雅に終了します。たとえば、グループ内のすべての接続は、マルチストリーミングプロトコルの単一セッションのストリームである可能性があります。グループ全体を閉じると、基礎となるセッションが終了します。セクション7.4も参照してください。グループ内のすべての接続は、クローズグループアクションが成功したときにクローズドイベントを送信します。近い場合と同様に、接続で処理されるメッセージはすべて閉鎖前に処理されます。
Connection.CloseGroup()
AbortGroup terminates a Connection and any other Connections that are in the same Connection Group without delivering any remaining Messages. When the AbortGroup action has finished, all Connections in the group will send a ConnectionError event, indicating local Abort as a reason.
AbortGroupは、残りのメッセージを配信せずに、同じ接続グループにある接続とその他の接続を終了します。AbortGroupアクションが終了すると、グループ内のすべての接続がConnectionErrorイベントを送信し、ローカル中断を理由として示します。
Connection.AbortGroup()
A ConnectionError informs the application that:
ConnectionErrorはアプリケーションに次のことを通知します。
1. data could not be delivered to the peer after a timeout or
1. データをタイムアウト後、または
2. the Connection has been aborted (e.g., because the peer has called Abort).
2. 接続は中止されています（例えば、ピアがAbortと呼ばれているため）。
There is no guarantee that an Abort from the peer will be signaled.
ピアからの中絶が合図されるという保証はありません。
Connection -> ConnectionError<reason?>
This Transport Services API is designed to be independent of an implementation's concurrency model. The exact details regarding how actions are handled, and how events are dispatched, are implementation dependent.
このTransport Services APIは、実装の並行性モデルから独立するように設計されています。アクションの処理方法とイベントの派遣方法に関する正確な詳細は、実装に依存しています。
Some transitions of Connection states are associated with events:
接続状態の一部の遷移は、イベントに関連付けられています。
* A Ready event occurs when a Connection created with Initiate or InitiateWithSend transitions to Established state.
* 準備が整ったイベントは、確立された状態への遷移を開始または開始することで作成された接続が発生します。
* A ConnectionReceived event occurs when a Connection created with Listen transitions to Established state.
* ConnectionReativeedイベントは、リスニングで作成された接続が確立された状態に移行すると発生します。
* A RendezvousDone event occurs when a Connection created with Rendezvous transitions to Established state.
* ランデブスドーンイベントは、ランデブーで作成された接続が確立された状態に遷移するときに発生します。
* A Closed event occurs when a Connection transitions to Closed state without error.
* 接続がエラーなしで閉じた状態に移行すると、閉じたイベントが発生します。
* An EstablishmentError event occurs when a Connection created with Initiate transitions from Establishing state to Closed state due to an error.
* EntiventiendErrorイベントは、エラーのために状態を確立することから閉じた状態への移行を開始することで作成された接続が発生します。
* A ConnectionError event occurs when a Connection transitions to Closed state due to an error in all other circumstances.
* ConnectionErrorイベントは、他のすべての状況でエラーが発生したため、接続が閉じた状態に移行すると発生します。
The following diagram shows the possible states of a Connection and the events that occur upon a transition from one state to another.
次の図は、接続の可能な状態と、ある状態から別の状態への移行時に発生するイベントを示しています。
(*) (**)
Establishing -----> Established -----> Closing ------> Closed
| ^
| |
+---------------------------------------------------+
EstablishmentError<>
(*) Ready<>, ConnectionReceived<>, RendezvousDone<>
(**) Closed<>, ConnectionError<>
Figure 2: Connection State Diagram
図2：接続状態図
The Transport Services API provides the following guarantees about the ordering of operations:
Transport Services APIは、運用の順序付けについて次の保証を提供します。
* Sent events will occur on a Connection in the order in which the Messages were sent (i.e., delivered to the kernel or to the network interface, depending on the implementation).
* 送信されたイベントは、メッセージが送信された順序で接続で発生します（つまり、実装に応じて、カーネルまたはネットワークインターフェイスに配信されます）。
* Received events will never occur on a Connection before it is Established, i.e., before a Ready event on that Connection or a ConnectionReceived or RendezvousDone event containing that Connection.
* 受信したイベントは、接続が確立される前、つまり、その接続での準備が整ったイベントや、その接続を含む接続レシーブまたはランデブスドーンイベントの前に、接続で発生することはありません。
* No events will occur on a Connection after it is closed, i.e., after a Closed event, an EstablishmentError or ConnectionError event will not occur on that Connection. To ensure this ordering, a Closed event will not occur on a Connection while other events on the Connection are still locally outstanding (i.e., known to the Transport Services API and waiting to be dealt with by the application).
* 接続が閉じた後、つまり、閉じたイベントの後、その接続では設立エラーまたはConnectionErrorイベントが発生しないイベントは発生しません。この順序付けを確実にするために、接続で閉じたイベントは発生しませんが、接続上の他のイベントはまだ局所的に傑出しています（つまり、輸送サービスAPIに知られ、アプリケーションによって対処されるのを待っています）。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
Future works might create IANA registries for generic Transport Property names and Transport Property Namespaces (see Section 4.1).
将来の作品は、一般的な輸送プロパティ名のIANAレジストリを作成し、輸送プロパティ名空間を輸送する可能性があります（セクション4.1を参照）。
This document describes a generic API for interacting with a Transport Services System. Part of this API includes configuration details for transport security protocols, as discussed in Section 6.3. It does not recommend use (or disuse) of specific algorithms or protocols. Any API-compatible transport security protocol ought to work in a Transport Services System. Security considerations for these protocols are discussed in the respective specifications.
このドキュメントでは、輸送サービスシステムと対話するための一般的なAPIについて説明しています。このAPIの一部には、セクション6.3で説明したように、輸送セキュリティプロトコルの構成詳細が含まれています。特定のアルゴリズムまたはプロトコルの使用（または不使用）を推奨しません。API互換の輸送セキュリティプロトコルは、輸送サービスシステムで機能するはずです。これらのプロトコルのセキュリティ上の考慮事項については、それぞれの仕様で説明します。
[RFC9621] provides general security considerations and requirements for any system that implements the Transport Services Architecture. These include recommendations of relevance to the API, e.g., regarding the use of keying material.
[RFC9621]は、輸送サービスアーキテクチャを実装するシステムに、一般的なセキュリティに関する考慮事項と要件を提供します。これらには、キーイング素材の使用に関するAPIに関連する推奨事項が含まれます。
The described API is used to exchange information between an application and the Transport Services System. The same authority implementing both systems is not necessarily expected. However, there is an expectation that the Transport Services Implementation would either:
説明されているAPIは、アプリケーションと輸送サービスシステムとの間の情報を交換するために使用されます。両方のシステムを実装する同じ機関が必ずしも予想されるわけではありません。ただし、輸送サービスの実装は次のとおりであるという期待があります。
* be provided as a library that is selected by the application from a trusted party or
* 信頼できる当事者からの申請によって選択されたライブラリとして提供される、または
* be part of the operating system that the application also relies on for other tasks.
* アプリケーションが他のタスクにも依存しているオペレーティングシステムの一部であること。
In either case, the Transport Services API is an internal interface that is used to exchange information locally between two systems. However, as the Transport Services System is responsible for network communication, it is in the position to potentially share any information provided by the application with the network or another communication peer. Most of the information provided over the Transport Services API is useful to configure and select protocols and paths and is not necessarily privacy sensitive. Still, some information could be privacy sensitive because it might reveal usage characteristics and habits of the user of an application.
どちらの場合でも、Transport Services APIは、2つのシステム間で局所的に情報を交換するために使用される内部インターフェイスです。ただし、トランスポートサービスシステムはネットワーク通信を担当しているため、アプリケーションが提供する情報をネットワークまたは別の通信ピアと共有する可能性があります。Transport Services APIを介して提供される情報のほとんどは、プロトコルとパスの構成と選択に役立ち、必ずしもプライバシーに敏感ではありません。それでも、いくつかの情報は、アプリケーションのユーザーの使用特性と習慣を明らかにする可能性があるため、プライバシーに敏感になる可能性があります。
Of course, any communication over a network reveals usage characteristics, because all packets, as well as their timing and size, are part of the network-visible wire image [RFC8546]. However, the selection of a protocol and its configuration also impacts which information is visible, potentially in clear text, and which other entities can access it. How Transport Services Systems ought to choose protocols -- depending on the security Properties required -- is out of scope for this specification, as it is limited to transport protocols. The choice of a security protocol can be informed by the survey provided in [RFC8922].
もちろん、ネットワークを介した通信は、すべてのパケットとそのタイミングとサイズがネットワーク可視ワイヤ画像の一部であるため、使用法の特性を明らかにします[RFC8546]。ただし、プロトコルとその構成の選択は、どの情報が表示されるか、潜在的に明確なテキストで、他のエンティティにアクセスできるかにも影響を与えます。輸送サービスシステムがプロトコルを選択する方法 - 必要なセキュリティプロパティに応じて、輸送プロトコルに限定されているため、この仕様の範囲外です。セキュリティプロトコルの選択は、[RFC8922]に記載されている調査によって通知できます。
In most cases, information provided for protocol and path selection does not directly translate to information that can be observed by network devices on the path. However, there might be specific configuration information that is intended for path exposure, e.g., a Diffserv codepoint setting that is either provided directly by the application or indirectly configured for a traffic profile.
ほとんどの場合、プロトコルとパスの選択に提供される情報は、パス上のネットワークデバイスによって観察できる情報に直接変換されません。ただし、パスエクスポージャーを対象とした特定の構成情報がある場合があります。たとえば、アプリケーションによって直接提供されるか、トラフィックプロファイル用に間接的に構成されているDiffServ CodePoint設定です。
Applications should be aware that a single communication attempt can lead to more than one connection establishment procedure. For example, this is the case when:
アプリケーションは、単一の通信試行が複数の接続確立手順につながる可能性があることに注意する必要があります。たとえば、これは次の場合です。
* the Transport Services System also executes name resolution,
* 輸送サービスシステムは、名前の解像度も実行します。
* support mechanisms such as TURN or ICE are used to establish connectivity if protocols or paths are raced or if a path fails and fallback or re-establishment is supported in the Transport Services System.
* ターンやアイスなどのサポートメカニズムは、プロトコルまたはパスがレースされている場合、またはパスが故障し、輸送サービスシステムでフォールバックまたは再確立がサポートされている場合、接続性を確立するために使用されます。
Applications should take special care when using 0-RTT session resumption (see Section 6.2.5), as early data sent across multiple paths during Connection establishment could reveal information that can be used to correlate Endpoints on these paths.
接続の確立中に複数のパスで送信された初期のデータがこれらのパスのエンドポイントを相関させるために使用できる情報を明らかにする可能性があるため、アプリケーションは0-RTTセッションの再開を使用する場合（セクション6.2.5を参照）、特に注意する必要があります。
Applications should also take care to not assume that all data received using the Transport Services API is always complete or well-formed. Specifically, Messages that are received partially (see Section 9.3.2.2) could be a source of truncation attacks if applications do not distinguish between partial Messages and complete Messages.
また、アプリケーションは、Transport Services APIを使用して受信したすべてのデータが常に完全または整形されていると仮定しないように注意する必要があります。具体的には、部分的に受信されるメッセージ（セクション9.3.2.2を参照）は、アプリケーションが部分的なメッセージと完全なメッセージを区別しない場合、切り捨て攻撃の原因となる可能性があります。
The Transport Services API explicitly does not require the application to resolve names, though there is a trade-off between early and late binding of addresses to names. Early binding allows the Transport Services Implementation to reduce Connection setup latency. This is at the cost of potentially limited scope for alternate path discovery during Connection establishment as well as potential additional information leakage about application interest when used with a resolution method (such as DNS without TLS) that does not protect query confidentiality. Names used with the Transport Services API SHOULD be FQDNs; not providing an FQDN will result in the Transport Services Implementation needing to use DNS search domains for name resolution, which might lead to inconsistent or unpredictable behavior.
Transport Services APIは、名前を解決するためのアプリケーションを明示的に要求していませんが、アドレスの早期拘束力と遅い名前の間にはトレードオフがあります。早期バインディングにより、トランスポートサービスの実装が接続のセットアップ遅延を減らすことができます。これは、クエリの機密性を保護しない解像度方法（TLSのないDNSなど）で使用した場合、接続確立中の代替パス発見の範囲が潜在的に限られた範囲と、アプリケーションの関心に関する潜在的な追加情報漏れを犠牲にします。Transport Services APIで使用される名前はFQDNSでなければなりません。FQDNを提供しないと、DNS検索ドメインを使用する必要がある輸送サービスの実装が名前の解決につながり、一貫性のないまたは予測不可能な動作につながる可能性があります。
These communication activities are not different from what is used at the time of writing. However, the goal of a Transport Services System is to support such mechanisms as a generic service within the transport layer. This enables applications to more dynamically benefit from innovations and new protocols in the transport, although it reduces transparency of the underlying communication actions to the application itself. The Transport Services API is designed such that protocol and path selection can be limited to a small and controlled set if required by the application to perform a function or to provide security. Further, introspection on the Properties of Connection objects allows an application to determine which protocol(s) and path(s) are in use. A Transport Services System SHOULD provide a facility logging the communication events of each Connection.
これらのコミュニケーション活動は、執筆時点で使用されているものと違いはありません。ただし、輸送サービスシステムの目標は、輸送層内の一般的なサービスなどのメカニズムをサポートすることです。これにより、アプリケーションは、輸送中の革新と新しいプロトコルからより動的に利益を得ることができますが、基礎となる通信アクションの透明性をアプリケーション自体に透明にします。Transport Services APIは、プロトコルとパスの選択を、アプリケーションで必要とする場合、機能を実行したり、セキュリティを提供するために必要な場合、小規模で制御されたセットに制限できるように設計されています。さらに、接続オブジェクトのプロパティに関する内省により、アプリケーションはどのプロトコルとパスが使用されているかを決定できます。輸送サービスシステムは、各接続の通信イベントを記録する施設を提供する必要があります。
[ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9621] Pauly, T., Ed., Trammell, B., Ed., Brunstrom, A.,
Fairhurst, G., and C. S. Perkins, "Architecture and
Requirements for Transport Services", RFC 9621,
DOI 10.17487/RFC9621, January 2025,
<https://www.rfc-editor.org/info/RFC9621>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597,
DOI 10.17487/RFC2597, June 1999,
<https://www.rfc-editor.org/info/rfc2597>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/info/rfc2914>.
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<https://www.rfc-editor.org/info/rfc3246>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006,
<https://www.rfc-editor.org/info/rfc4594>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option",
RFC 5482, DOI 10.17487/RFC5482, March 2009,
<https://www.rfc-editor.org/info/rfc5482>.
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
Services Code Point (DSCP) for Capacity-Admitted Traffic",
RFC 5865, DOI 10.17487/RFC5865, May 2010,
<https://www.rfc-editor.org/info/rfc5865>.
[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use Cases and Requirements", RFC 7478,
DOI 10.17487/RFC7478, March 2015,
<https://www.rfc-editor.org/info/rfc7478>.
[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain
Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
<https://www.rfc-editor.org/info/rfc7556>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services
(Diffserv) and Real-Time Communication", RFC 7657,
DOI 10.17487/RFC7657, November 2015,
<https://www.rfc-editor.org/info/rfc7657>.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers",
BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,
<https://www.rfc-editor.org/info/rfc8084>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
Ed., "Services Provided by IETF Transport Protocols and
Congestion Control Mechanisms", RFC 8095,
DOI 10.17487/RFC8095, March 2017,
<https://www.rfc-editor.org/info/rfc8095>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
"Stream Schedulers and User Message Interleaving for the
Stream Control Transmission Protocol", RFC 8260,
DOI 10.17487/RFC8260, November 2017,
<https://www.rfc-editor.org/info/rfc8260>.
[RFC8293] Ghanwani, A., Dunbar, L., McBride, M., Bannai, V., and R.
Krishnan, "A Framework for Multicast in Network
Virtualization over Layer 3", RFC 8293,
DOI 10.17487/RFC8293, January 2018,
<https://www.rfc-editor.org/info/rfc8293>.
[RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of
Transport Features Provided by IETF Transport Protocols",
RFC 8303, DOI 10.17487/RFC8303, February 2018,
<https://www.rfc-editor.org/info/rfc8303>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8489] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing,
D., Mahy, R., and P. Matthews, "Session Traversal
Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489,
February 2020, <https://www.rfc-editor.org/info/rfc8489>.
[RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a
Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April
2019, <https://www.rfc-editor.org/info/rfc8546>.
[RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for
Differentiated Services", RFC 8622, DOI 10.17487/RFC8622,
June 2019, <https://www.rfc-editor.org/info/rfc8622>.
[RFC8656] Reddy, T., Ed., Johnston, A., Ed., Matthews, P., and J.
Rosenberg, "Traversal Using Relays around NAT (TURN):
Relay Extensions to Session Traversal Utilities for NAT
(STUN)", RFC 8656, DOI 10.17487/RFC8656, February 2020,
<https://www.rfc-editor.org/info/rfc8656>.
[RFC8699] Islam, S., Welzl, M., and S. Gjessing, "Coupled Congestion
Control for RTP Media", RFC 8699, DOI 10.17487/RFC8699,
January 2020, <https://www.rfc-editor.org/info/rfc8699>.
[RFC8801] Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W.
Shao, "Discovering Provisioning Domain Names and Data",
RFC 8801, DOI 10.17487/RFC8801, July 2020,
<https://www.rfc-editor.org/info/rfc8801>.
[RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE:
Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol", RFC 8838,
DOI 10.17487/RFC8838, January 2021,
<https://www.rfc-editor.org/info/rfc8838>.
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
Völker, "Packetization Layer Path MTU Discovery for
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/info/rfc8899>.
[RFC8922] Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C.
Wood, "A Survey of the Interaction between Security
Protocols and Transport Services", RFC 8922,
DOI 10.17487/RFC8922, October 2020,
<https://www.rfc-editor.org/info/rfc8922>.
[RFC8923] Welzl, M. and S. Gjessing, "A Minimal Set of Transport
Services for End Systems", RFC 8923, DOI 10.17487/RFC8923,
October 2020, <https://www.rfc-editor.org/info/rfc8923>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 8981,
DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/info/rfc8981>.
[RFC9218] Oku, K. and L. Pardue, "Extensible Prioritization Scheme
for HTTP", RFC 9218, DOI 10.17487/RFC9218, June 2022,
<https://www.rfc-editor.org/info/rfc9218>.
[RFC9329] Pauly, T. and V. Smyslov, "TCP Encapsulation of Internet
Key Exchange Protocol (IKE) and IPsec Packets", RFC 9329,
DOI 10.17487/RFC9329, November 2022,
<https://www.rfc-editor.org/info/rfc9329>.
[RFC9623] Brunstrom, A., Ed., Pauly, T., Ed., Enghardt, R., Tiesel,
P. S., and M. Welzl, "Implementing Interfaces to Transport
Services", RFC 9623, DOI 10.17487/RFC9623, January 2025,
<https://www.rfc-editor.org/info/rfc9623>.
[TCP-COUPLING]
Islam, S., Welzl, M., Hiorth, K., Hayes, D., Armitage, G.,
and S. Gjessing, "ctrlTCP: Reducing latency through
coupled, heterogeneous multi-flow TCP congestion control",
IEEE INFOCOM 2018 - IEEE Conference on Computer
Communications Workshops (INFOCOM WKSHPS),
DOI 10.1109/INFCOMW.2018.8406887, 2018,
<https://ieeexplore.ieee.org/document/8406887>.
The way the concepts from this abstract API map to concrete APIs in a given language on a given platform largely depends on the features and norms of the language and the platform. Actions could be implemented as either functions or method calls. For instance, actions could be implemented via event queues, handler functions or classes, communicating sequential processes, or other asynchronous calling conventions.
この抽象的なAPIから、特定のプラットフォーム上の特定の言語での具体的なAPIへの概念が、言語とプラットフォームの機能と規範に大きく依存する方法。アクションは、関数またはメソッド呼び出しのいずれかとして実装できます。たとえば、アクションは、イベントキュー、ハンドラー機能またはクラス、シーケンシャルプロセスの通信、またはその他の非同期呼び出し条約を介して実装できます。
The basic types mentioned in Section 1.1 typically have natural correspondences in practical programming languages, perhaps constrained by implementation-specific limitations. For example:
セクション1.1で言及されている基本的なタイプは、通常、実用的なプログラミング言語で自然な対応を持っています。おそらく、実装固有の制限によって制約されます。例えば：
* Typically, an Integer can be represented in C by an int or long; this is subject to the underlying platform's ranges for each.
* 通常、整数はcでintまたはlongで表すことができます。これは、それぞれの基礎となるプラットフォームの範囲の対象となります。
* In C, a Tuple may be represented as a struct with one member for each of the value types in the ordered grouping. However, in Python, a Tuple may be represented as a tuple, which is a sequence of dynamically typed elements.
* Cでは、順序付けられたグループ内の値タイプごとに1つのメンバーを持つタプルが構造体として表される場合があります。ただし、Pythonでは、動的に型付けされた要素のシーケンスであるタプルがタプルとして表される場合があります。
* A Set may be represented as a std::set in C++ or as a set in Python. In C, it may be represented as an array or as a higher-level data structure with appropriate accessors defined.
* セットは、C ++のSTD ::セットとして、またはPythonのセットとして表される場合があります。Cでは、アレイとして、または適切なアクセターが定義された高レベルのデータ構造として表される場合があります。
The objects described in Section 1.1 can also be represented in different ways, depending on which programming language is used. Objects like Preconnections, Connections, and Listeners can be long-lived and benefit from using object-oriented constructs. Note that, in C, these objects may need to provide a way to release or free their underlying memory when the application is done using them. For example, since a Preconnection can be used to initiate multiple Connections, it is the responsibility of the application to clean up the Preconnection memory if necessary.
セクション1.1で説明したオブジェクトは、どのプログラミング言語を使用するかによって異なる方法で表現できます。事前接続、接続、リスナーなどのオブジェクトは長命であり、オブジェクト指向の構造を使用することで利益を得ることができます。Cでは、これらのオブジェクトは、アプリケーションがそれらを使用して行われたときに、基礎となるメモリを解放または解放する方法を提供する必要がある場合があることに注意してください。たとえば、事前接続を使用して複数の接続を開始できるため、必要に応じて事前接続メモリをクリーンアップすることはアプリケーションの責任です。
This specification treats events and errors similarly. Errors, just as any other events, may occur asynchronously in network applications. However, implementations of this API may report errors synchronously. This is done according to the error-handling idioms of the implementation platform, where they can be immediately detected. An example of this is to generate an exception when attempting to initiate a Connection with inconsistent Transport Properties. An error can provide an optional reason to the application with further details about why the error occurred.
この仕様では、イベントとエラーも同様に扱います。エラーは、他のイベントと同様に、ネットワークアプリケーションで非同期に発生する可能性があります。ただし、このAPIの実装により、エラーが同期して報告される場合があります。これは、実装プラットフォームのエラー処理イディオムに従って行われ、すぐに検出できます。この例は、一貫性のない輸送特性との接続を開始しようとするときに例外を生成することです。エラーは、エラーが発生した理由についての詳細とともに、アプリケーションにオプションの理由を提供できます。
Time duration types are implementation specific. For instance, it could be a number of seconds, a number of milliseconds, or a struct timeval in C; in C++, it could be a user-defined Duration class.
期間タイプは実装固有です。たとえば、cの数秒、数ミリ秒、またはstruct timevalになる可能性があります。C ++では、ユーザー定義の持続時間クラスである可能性があります。
TransportProperties will frequently need to set Selection Properties of type "Preference"; therefore, implementations can provide special actions for adding each preference level, i.e., TransportProperties.Set(some_property, avoid) is equivalent to TransportProperties.Avoid(some_property):
TransportPropertiesは、型「設定」の選択プロパティを設定する必要があることがよくあります。したがって、実装は、各選好レベルを追加するための特別なアクションを提供できます。つまり、TransportProperties.set（some_property、回避）はTransportProperties.avoid（some_property）と同等です。
TransportProperties.Require(property)
TransportProperties.Prefer(property)
TransportProperties.NoPreference(property)
TransportProperties.Avoid(property)
TransportProperties.Prohibit(property)
To ease the use of the Transport Services API, implementations can provide a mechanism to create Transport Property objects (see Section 6.2) that are preconfigured with frequently used sets of Properties; the following subsections list those that are in common use in applications at the time of writing.
Transport Services APIの使用を容易にするために、実装は、頻繁に使用されるプロパティセットで事前に設定されたトランスポートプロパティオブジェクト（セクション6.2を参照）を作成するメカニズムを提供できます。次のサブセクションには、執筆時点でアプリケーションで一般的に使用されているものがリストされています。
This profile provides reliable, in-order transport service with congestion control. TCP is an example of a protocol that provides this service. It should consist of the following Properties:
このプロファイルは、混雑制御を備えた信頼性の高い秩序輸送サービスを提供します。TCPは、このサービスを提供するプロトコルの例です。次のプロパティで構成する必要があります。
+=======================+===============+
| Property | Value |
+=======================+===============+
| reliability | Require |
+-----------------------+---------------+
| preserveOrder | Require |
+-----------------------+---------------+
| congestionControl | Require |
+-----------------------+---------------+
| preserveMsgBoundaries | No Preference |
+-----------------------+---------------+
Table 2: reliable-inorder-stream Preferences
表2：信頼性の高い順序通りとストリームの好み
This profile provides Message-preserving, reliable, in-order transport service with congestion control. SCTP is an example of a protocol that provides this service. It should consist of the following Properties:
このプロファイルは、渋滞制御を備えたメッセージ圧力で信頼性の高い順序輸送サービスを提供します。SCTPは、このサービスを提供するプロトコルの例です。次のプロパティで構成する必要があります。
+=======================+=========+
| Property | Value |
+=======================+=========+
| reliability | Require |
+-----------------------+---------+
| preserveOrder | Require |
+-----------------------+---------+
| congestionControl | Require |
+-----------------------+---------+
| preserveMsgBoundaries | Require |
+-----------------------+---------+
Table 3: reliable-message Preferences
表3：信頼できるメッセージの好み
This profile provides a datagram transport service without any reliability guarantee. An example of a protocol that provides this service is UDP. It consists of the following Properties:
このプロファイルは、信頼性の保証なしでデータグラムトランスポートサービスを提供します。このサービスを提供するプロトコルの例はUDPです。次のプロパティで構成されています。
+=======================+===============+
| Property | Value |
+=======================+===============+
| reliability | Avoid |
+-----------------------+---------------+
| preserveOrder | Avoid |
+-----------------------+---------------+
| congestionControl | No Preference |
+-----------------------+---------------+
| preserveMsgBoundaries | Require |
+-----------------------+---------------+
| safelyReplayable | true |
+-----------------------+---------------+
Table 4: unreliable-datagram Preferences
表4：信頼できないダタグラムの好み
Applications that choose this Transport Property Profile would avoid the additional latency that could be introduced by retransmission or reordering in a transport protocol.
この輸送プロパティプロファイルを選択するアプリケーションは、交換または輸送プロトコルでの再注文によって導入できる追加のレイテンシを回避します。
Applications that choose this Transport Property Profile to reduce latency should also consider setting an appropriate capacity profile Property (see Section 8.1.6) and might benefit from controlling checksum coverage (see Sections 6.2.7 and 6.2.8).
この輸送プロパティプロファイルを選択してレイテンシを減らすアプリケーションは、適切な容量プロファイルプロパティの設定を検討する必要があります（セクション8.1.6を参照）、チェックサムカバレッジの制御から恩恵を受ける可能性があります（セクション6.2.7および6.2.8を参照）。
[RFC8923] identifies a minimal set of Transport Services that end systems should offer. These services make all non-security-related transport features of TCP, Multipath TCP (MPTCP), UDP, UDP-Lite, SCTP, and Low Extra Delay Background Transport (LEDBAT) available that:
[RFC8923]は、システムが提供すべき最小限の輸送サービスセットを識別します。これらのサービスは、TCP、MultiPath TCP（MPTCP）、UDP、UDP-LITE、SCTP、および低追加遅延バックグラウンドトランスポート（LEDBAT）のすべての非セキュリティ関連輸送機能を使用します。
1. require interaction with the application and
1. アプリケーションとの相互作用が必要です
2. do not get in the way of a possible implementation over TCP (or, with limitations, UDP).
2. TCP（または制限付き、UDP）を介した可能な実装の邪魔にならないでください。
The following text explains how this minimal set is reflected in the present API. For brevity, it is based on the list in Section 4.1 of [RFC8923] and updated according to the discussion in Section 5 of [RFC8923]. The present API covers all elements of this section. This list is a subset of the transport features in Appendix A of [RFC8923], which refers to the primitives in "pass 2". See Section 4 of [RFC8303] for 1) further details on the implementation with TCP, MPTCP, UDP, UDP-Lite, SCTP, and LEDBAT and 2) how to facilitate finding the specifications for implementing the services listed below with these protocols.
次のテキストは、この最小セットが現在のAPIにどのように反映されているかを説明しています。簡潔にするために、[RFC8923]のセクション4.1のリストに基づいており、[RFC8923]のセクション5の議論に従って更新されます。現在のAPIは、このセクションのすべての要素をカバーしています。このリストは、[RFC8923]の付録Aの輸送機能のサブセットであり、「Pass 2」のプリミティブを指します。1）TCP、MPTCP、UDP、UDP-LITE、SCTP、およびLEDBATを使用した実装の詳細については、[RFC8303]のセクション4を参照してください。
* Connect: Initiate action (Section 7.1).
* 接続：アクションを開始します（セクション7.1）。
* Listen: Listen action (Section 7.2).
* 聞く：聞くアクション（セクション7.2）。
* Specify number of attempts and/or timeout for the first establishment Message: timeout parameter of Initiate (Section 7.1) or InitiateWithSend action (Section 9.2.5).
* 最初の確立メッセージの試行回数および/またはタイムアウトを指定します：開始のタイムアウトパラメーター（セクション7.1）または開始装置アクション（セクション9.2.5）。
* Disable MPTCP: multipath Property (Section 6.2.14).
* MPTCP：MultiPathプロパティ（セクション6.2.14）を無効にします。
* Hand over a Message to reliably transfer (possibly multiple times) before Connection establishment: InitiateWithSend action (Section 9.2.5).
* 接続確立の前に（おそらく複数回）メッセージを渡して、[おそらく複数回）。
* Change timeout for aborting connection (using retransmit limit or time value): connTimeout Property, using a time value (Section 8.1.3).
* 接続を中止するためのタイムアウトを変更します（再送信制限または時間値を使用）：ConnTimeAutプロパティ、時間値（セクション8.1.3）を使用します。
* Timeout event when data could not be delivered for too long: ConnectionError event (Section 10).
* データを長時間配信できなかったタイムアウトイベント：ConnectionErrorイベント（セクション10）。
* Suggest timeout to the peer: See "TCP-Specific Properties: User Timeout Option (UTO)" (Section 8.2).
* ピアへのタイムアウトを提案：「TCP固有のプロパティ：ユーザータイムアウトオプション（UTO）」（セクション8.2）を参照してください。
* Notification of ICMP error message arrival: softErrorNotify (Section 6.2.17) and SoftError event (Section 8.3.1).
* ICMPエラーメッセージの通知到着：SofterRornotify（セクション6.2.17）およびSofterrorイベント（セクション8.3.1）。
* Choose a scheduler to operate between streams of an association: connScheduler Property (Section 8.1.5).
* アソシエーションのストリーム間で動作するスケジューラを選択します：Connschedulerプロパティ（セクション8.1.5）。
* Configure priority or weight for a scheduler: connPriority Property (Section 8.1.2).
* スケジューラの優先度または重量を構成：connpriorityプロパティ（セクション8.1.2）。
* "Specify checksum coverage used by the sender" and "Disable checksum when sending": msgChecksumLen Property (Section 9.1.3.6) and fullChecksumSend Property (Section 6.2.7).
* 「送信者が使用するチェックサムカバレッジの指定」および「送信時にチェックサムを無効にする」：MSGCHECKSUMLENプロパティ（セクション9.1.3.6）およびFullChecksumsendプロパティ（セクション6.2.7）。
* "Specify minimum checksum coverage required by receiver" and "Disable checksum requirement when receiving": recvChecksumLen Property (Section 8.1.1) and fullChecksumRecv Property (Section 6.2.8).
* 「受信者が必要とする最小チェックサムカバレッジを指定」および「受信時にチェックサム要件を無効にする」：RecvChecksumlenプロパティ（セクション8.1.1）およびFullChecksumRecvプロパティ（セクション6.2.8）。
* Specify DF field: noFragmentation Property (Section 9.1.3.9).
* DFフィールドを指定：ノフラグメント化プロパティ（セクション9.1.3.9）。
* Get maximum transport-message size that may be sent using a non-fragmented IP packet from the configured interface: singularTransmissionMsgMaxLen Property (Section 8.1.11.4).
* 構成されたインターフェイスからの非フラグメント化されたIPパケットを使用して送信できる最大トランスポートメサージサイズを取得します：SingularTransmissionMsGmaxlenプロパティ（セクション8.1.11.4）。
* Get maximum transport-message size that may be received from the configured interface: recvMsgMaxLen Property (Section 8.1.11.6).
* 構成されたインターフェイス：recvmsgmaxlenプロパティ（セクション8.1.11.6）から受信できる最大輸送メサージサイズを取得します。
* Obtain ECN field: This is a read-only Message Property of the MessageContext object (see "Property Specific to UDP and UDP-Lite: ECN" (Section 9.3.3.1)).
* ECNフィールドを取得：これは、MessageContextオブジェクトの読み取り専用メッセージプロパティです（「UDPおよびUDP-Lite：ECNに固有のプロパティ」（セクション9.3.3.1）を参照）。
* "Specify DSCP field", "Disable Nagle algorithm", and "Enable and configure a Low Extra Delay Background Transfer": as suggested in Section 5.5 of [RFC8923], these transport features are collectively offered via the connCapacityProfile Property (Section 8.1.6). Per-Message control ("Request not to bundle messages") is offered via the msgCapacityProfile Property (Section 9.1.3.8).
* 「DSCPフィールドの指定」、「ナグルアルゴリズムを無効にし、「低い余分な遅延バックグラウンド転送を有効にして構成する」：[RFC8923]のセクション5.5で提案されているように、これらの輸送機能はconncapacityprofileプロパティを介して集合的に提供されます（セクション8.1.6.6）。Message Control（「メッセージをバンドルするリクエスト」）は、msgcapacityprofileプロパティ（セクション9.1.3.8）を介して提供されます。
* Close after reliably delivering all remaining data, causing an event informing the application on the other side: this is offered by the Close action with slightly changed semantics in line with the discussion in Section 5.2 of [RFC8923] (see also Section 10).
* 残りのすべてのデータを確実に配信して終了し、反対側のアプリケーションを通知するイベントを引き起こします。これは、[RFC8923]のセクション5.2の議論に沿ったわずかに変更されたセマンティクスを備えた緊密なアクションによって提供されます（セクション10も参照）。
* "Abort without delivering remaining data, causing an event informing the application on the other side" and "Abort without delivering remaining data, not causing an event informing the application on the other side": these are offered by the Abort action without promising that these are signaled to the other side. If they are, a ConnectionError event will be invoked at the peer (Section 10).
* 「残りのデータを配信せずに中止し、反対側のアプリケーションを通知するイベントを引き起こします」と「残りのデータを配信せずに中止します。反対側に通知されます。もしそうなら、ConnectionErrorイベントはピアで呼び出されます（セクション10）。
* "Reliably transfer data, with congestion control", "Reliably transfer a message, with congestion control", and "Unreliably transfer a message": data is transferred via the Send action (Section 9.2). Reliability is controlled via the reliability (Section 6.2.1) Property and the msgReliable Message Property (Section 9.1.3.7). Transmitting data as a Message or without delimiters is controlled via Message Framers (Section 9.1.2). The choice of congestion control is provided via the congestionControl Property (Section 6.2.9).
* 「混雑制御を使用してデータを確実に転送する」、「渋滞制御を使用してメッセージを確実に転送する」、および「信頼できないメッセージの転送」：データは送信アクションを介して転送されます（セクション9.2）。信頼性は、信頼性（セクション6.2.1）プロパティとMSGRelilaibleメッセージプロパティ（セクション9.1.3.7）を介して制御されます。データをメッセージとして、または区切り文字なしで送信することは、メッセージフレーマーを介して制御されます（セクション9.1.2）。輻輳制御の選択は、混雑コントロールプロパティ（セクション6.2.9）を介して提供されます。
* Configurable Message Reliability: the msgLifetime Message Property implements a time-based way to configure Message reliability (Section 9.1.3.1).
* 構成可能なメッセージ信頼性：MSGLIFETIMEメッセージプロパティは、メッセージの信頼性を構成するための時間ベースの方法を実装します（セクション9.1.3.1）。
* "Ordered message delivery (potentially slower than unordered)" and "Unordered message delivery (potentially faster than ordered)": these two transport features are controlled via the Message Property msgOrdered (Section 9.1.3.3).
* 「順序付けられたメッセージ配信（順序付けられていない潜在的に）」および「順序付けられていないメッセージ配信（注文よりも速い可能性があります）」：これら2つのトランスポート機能は、メッセージプロパティMSGORDERED（セクション9.1.3.3）を介して制御されます。
* Request not to delay the acknowledgement (SACK) of a message: should the protocol support it, this is one of the transport features the Transport Services System can apply when an application uses the connCapacityProfile Property (Section 8.1.6) or the msgCapacityProfile Message Property (Section 9.1.3.8) with value Low Latency/Interactive.
* メッセージの承認（袋）を遅らせないようにリクエスト：プロトコルがサポートしている場合、これはアプリケーションがconncapacityprofileプロパティ（セクション8.1.6）またはmsgcapacityprofileメッセージプロパティを使用する場合にトランスポートサービスシステムが適用できる輸送機能の1つです。（セクション9.1.3.8）値低下/インタラクティブで。
* Receive data (with no message delimiting): Receive action (Section 9.3.1) and Received event (Section 9.3.2.1).
* データを受信します（メッセージが区切りません）：アクション（セクション9.3.1）および受信イベント（セクション9.3.2.1）を受信します。
* Receive a message: Receive action (Section 9.3.1) and Received event (Section 9.3.2.1) using Message Framers (Section 9.1.2).
* メッセージの受信：アクション（セクション9.3.1）を受信し、メッセージフレーマー（セクション9.1.2）を使用してイベント（セクション9.3.2.1）を受信します（セクション9.3.2.1）。
* Information about partial message arrival: Receive action (Section 9.3.1) and ReceivedPartial event (Section 9.3.2.2).
* 部分的なメッセージの到着に関する情報：受信アクション（セクション9.3.1）および受信特有のイベント（セクション9.3.2.2）。
* Notification of send failures: Expired event (Section 9.2.2.2) and SendError event (Section 9.2.2.3).
* 送信障害の通知：期限切れイベント（セクション9.2.2.2）およびSendErrorイベント（セクション9.2.2.3）。
* Notification that the stack has no more user data to send: applications can obtain this information via the Sent event (Section 9.2.2.1).
* Stackに送信するユーザーデータがこれ以上ないことを通知します。アプリケーションは、送信イベント（セクション9.2.2.1）を介してこの情報を取得できます。
* Notification to a receiver that a partial message delivery has been aborted: ReceiveError event (Section 9.3.2.3).
* 部分的なメッセージ配信が中止されたことを受信者に通知：受信イベント（セクション9.3.2.3）。
* Notification of Excessive Retransmissions (early warning below abortion threshold): SoftError event (Section 8.3.1).
* 過剰な再送信の通知（中絶のしきい値以下の早期警告）：柔軟なイベント（セクション8.3.1）。
This work has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreements No. 644334 (NEAT) and No. 688421 (MAMI).
この作業は、欧州連合の地平線2020年の研究およびイノベーションプログラムから、助成金契約No. 644334（NEAT）およびNo. 688421（MAMI）に基づいて資金提供を受けています。
This work has been supported by:
この作業は次のようにサポートされています。
* Leibniz Prize project funds from the DFG - German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ FE 570/4-1).
* DFGからのLeibniz賞プロジェクト資金 - ドイツの研究財団：Gottfried Wilhelm Leibniz-Preis 2011（FKZ FE 570/4-1）。
* the UK Engineering and Physical Sciences Research Council under grant EP/R04144X/1.
* Grant EP/R04144X/1の下での英国工学および物理科学研究評議会。
* the Research Council of Norway under its "Toppforsk" programme through the "OCARINA" project.
* ノルウェーの研究評議会は、「オカリナ」プロジェクトを通じて「Toppforsk」プログラムに基づいています。
Thanks to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric Kinnear for their implementation and design efforts, including Happy Eyeballs, that heavily influenced this work. Thanks to Laurent Chuat and Jason Lee for initial work on the Post Sockets interface, from which this work has evolved. Thanks to Maximilian Franke for asking good questions based on implementation experience and for contributing text, e.g., on multicast.
この作品に大きな影響を与えたハッピーアイボールを含む実装とデザインの取り組みに、スチュアートチェシャー、ジョシュグレスリー、デビッドシナジ、エリックキニアに感謝します。Post Socketsインターフェースでの最初の作業をしてくれたLaurent ChuatとJason Leeに感謝します。この作業は進化しました。実装の経験に基づいて良い質問をしてくれたMaximilian Frankeに感謝し、例えばマルチキャストでテキストを提供してくれたことに感謝します。
Brian Trammell (editor)
Google Switzerland GmbH
Gustav-Gull-Platz 1
CH-8004 Zurich
Switzerland
Email: ietf@trammell.ch
Michael Welzl (editor)
University of Oslo
PO Box 1080 Blindern
0316 Oslo
Norway
Email: michawe@ifi.uio.no
Reese Enghardt
Netflix
121 Albright Way
Los Gatos, CA 95032
United States of America
Email: ietf@tenghardt.net
Godred Fairhurst
University of Aberdeen
Fraser Noble Building
Aberdeen, AB24 3UE
United Kingdom
Email: gorry@erg.abdn.ac.uk
URI: https://erg.abdn.ac.uk/
Mirja Kühlewind
Ericsson
Ericsson-Allee 1
Herzogenrath
Germany
Email: mirja.kuehlewind@ericsson.com
Colin S. Perkins
University of Glasgow
School of Computing Science
Glasgow
G12 8QQ
United Kingdom
Email: csp@csperkins.org
Philipp S. Tiesel
SAP SE
George-Stephenson-Straße 7-13
10557 Berlin
Germany
Email: philipp@tiesel.net
Tommy Pauly
Apple Inc.
One Apple Park Way
Cupertino, CA 95014
United States of America
Email: tpauly@apple.com