3.1. TCP Packet Format

3.1. TCPパケットフォーマット

The DTH flag uses the fourth bit in the Control bits field in TCP header as depicted in Figure 1 [RFC9293]. The fourth bit was intentionally selected because "four" in Chinese is Sì; it has a similar sound to Sǐ, which means "die".

DTHフラグは、図1[RFC9293] に示すように、TCPヘッダーのControl bitsフィールドの4番目のビットを使用します。4番目のビットが選択されたのは意図的なものです。なぜなら、中国語で「4」は「Sì」であり、「死」という意味の「Sǐ」と似た音を持つためです。

A TCP session peer SHOULD transmit a DTH segment when the TCP session will likely be terminated soon. It can be sent from both the server and client. The application or TCP stack MAY elect not to send DTH segments, even if it knows that the session will be terminated. This results in a dramatic surprise for the peer; however, the end users may perceive the end too convenient or overly simplistic. Use of the DTH segment that is not associated with the session termination is not encouraged but it is permitted. (This is often referred to as "teasing" or a false-positive DTH flag.)

TCPセッションのピアは、TCPセッションがまもなく終了する可能性がある場合、DTHセグメントを送信すべきです（SHOULD）。これはサーバー側、クライアント側の両方から送信されることができます。アプリケーションまたはTCPスタックは、セッションが終了することを知っていても、DTHセグメントを送信しないことを選択してもよいです（MAY）。これにより、ピアにとっては劇的な驚きが生じますが、エンドユーザーにとっては終了があまりに便利または過度に単純化されたものに感じられるかもしれません。セッション終了と関連付けられていないDTHセグメントの使用は推奨されていませんが、許可されています。（これはしばしば「からかい」または偽陽性のDTHフラグと呼ばれます）。

The DTH flag is informational. TCP software that does not implement this feature can safely ignore this flag. However, to fully appreciate the session, users should be aware of the subtle signs of the session narratives.

DTHフラグは情報提供のためのものです。この機能を実装していないTCPソフトウェアは、安全にこのフラグを無視できます。ただし、セッションの全体像を把握するためには、ユーザーはセッションのストーリーの微妙な兆候に気を配る必要があります。

The DTH flag itself does not change the sequence or acknowledgment number. It does not require any acknowledgement.

DTHフラグ自体はシーケンス番号や確認応答番号を変更しません。また、確認応答を必要としません。

The recipient of the flag is not required to act differently upon reception; however, it is RECOMMENDED that information be conveyed to the application layer, so the end user can be notified of the incident. The recipient of a DTH segment SHOULD NOT close the socket immediately upon reception; it SHOULD wait for a RST or FIN segment.

フラグの受信側は受信時に異なる操作を行うことは必須ではありません。ただし、エンドユーザーに通知するためにアプリケーション層に情報が伝えられることが推奨されます（RECOMMENDED）。DTH セグメントの受信者は、受信後すぐにソケットをクローズすべきではありません（SHOULD NOT）。RSTまたはFINセグメントを待機すべきです（SHOULD）

This specification does not stipulate the maximum number of DTH segments permitted in one TCP session; however, limiting them to a few is RECOMMENDED to maximize the dramatic effect.

この仕様書は、1つのTCPセッションで許容されるDTHセグメントの最大数を定めていません。ただし、劇的効果を最大限に引き出すためには、数を制限することが推奨されます（RECOMMENDED）

3.2. When to Send

3.2. 送信するタイミング

DTH can be used any time the sender considers it important to signal its inevitable end to the TCP peer. The example scenarios below illustrate when to send DTH segments.

DTHは、送信者がTCPピアに必然的な終了を知らせることが重要だと考える場合に、いつでも使用できます。以下のシナリオ例では、DTH セグメントを送信するタイミングを説明しています。

A malicious actor can send the flag when it suddenly repents; for example, when a sender suddenly regrets their part in a DDoS attack and unexpectedly ceases the attack. The archvillain generally terminates the sender cruelly and mercilessly soon after the change in behavior (or they are killed for protecting the hero). The timing of DTH transmission is implementation dependent. It can be sent anytime from the early signs of betrayal to just prior to the behavioral change.

悪意のある攻撃者は、たとえばDDoS攻撃に参加したことを後悔し、攻撃を思いがけず中止する場合に、DTHフラグを送信できます。大悪党は一般に、行動の変化の直後に送信者を残酷かつ無慈悲に終了させます（または、ヒーローを保護したために殺されます）。DTHの送信タイミングは実装に依存します。DTHの送信タイミングは、実装に依存します。裏切りの初期の兆候から行動の変化直前まで、いつでも送信できます。

The flag can be sent when the sender stops using cryptographic protections and reveals its plain-text content, for example, a mysterious character with a mask that often dies after they expose their face. In this example, the DTH segment would be sent just before sending the redirect (30x) from HTTPS to HTTP [RFC9110]. Similarly, the flag can be set when the forged User-Agent or Server HTTP header field is changed to the actual value, when their true identity would be revealed (for example, "I am your long-lost twin", "I am a spy", etc.). This occasionally leads to the death of the character.

送信者が暗号による保護をやめて平文のコンテンツを公開したときこのフラグが送信される場合があります。たとえば、謎めいたマスクのキャラクターは顔を晒した後にしばしば死にます。この例では、DTHセグメントは、HTTPSからHTTPへのリダイレクト（30x）を送信する直前に送信されます[RFC9110] 。同様に、偽造されたUser-AgentまたはServer HTTPヘッダーフィールドが実際の値に変更され、その真の正体が明らかになる（たとえば、「私は長い間行方不明だったあなたの双子です」「私はスパイです」等）ときに、このフラグを設定できます。これにより、キャラクターが死亡する場合があります。

The TCP peer is RECOMMENDED to send the flag when it notices resource issues, e.g., diminishing memory space or bandwidth. An AI bot, cyborg, sorcerer application with forbidden protocols, etc., SHOULD consider sending the flag when it starts to heavily cough error messages.

TCPのピアは、リソースの問題が発生した場合、たとえばメモリスペースや帯域幅が減少した場合、フラグを送信することが推奨されます（RECOMMENDED）。AIボット、サイボーグ、禁断のプロトコルを持つ魔術師アプリケーションなどは、エラーメッセージを大量に吐くようになったら、フラグの送信を検討すべきです（SHOULD）。

An application less capable of performing its task MAY send the flag from time to time. It will be killed by the OS (the archvillain) or CTRL-C (the end user) sooner or later due to its inefficiency. The same is likely to occur with a memory-hogging application, for example, an unscrupulous character that attempts to take all the treasure often dies accidentally (e.g., falls from a cliff).

タスクを実行できないほど能力が低いアプリケーションは、時折フラグを送信してもよいです（MAY）。それは、その非効率性により、遅かれ早かれOS（大悪党）またはCTRL-C（エンドユーザー）によって殺されるでしょう。メモリを大量に消費するアプリケーションでも同様のことが起こります。たとえば、すべての財宝を手に入れようとする不正なキャラクターは、偶然死亡することがあります（たとえば、崖から落ちるなど）。

An application SHOULD really think twice before accessing a "honeypot" or haunted server. If your choices are limited (e.g., your favorite server breaks down in the middle of nowhere and the dark server that is not on the DNS is the only place you can shelter), sending the flag periodically is a good idea. The session is most likely cursed.

アプリケーションは、「ハニーポット」やお化けサーバーにアクセスする前に、本当によく熟考すべきです（SHOULD）。選択肢が限られている場合(たとえば、お気に入りのサーバが人里離れた場所で故障し、DNSにないダークサーバが唯一の避難場所である場合など)、定期的にフラグを送信するのは良い考えです。セッションが呪われている可能性が高いです。

3.3. When Not to Send

3.3. 送信しないタイミング

The DTH flag SHOULD NOT be piggybacked on the FIN flag. If present, the recipient SHOULD silently ignore DTH flag. The only exception is when the recipient is an expert at Hokuto-Shinken ("Big Dipper Divine Fist") [WIKI-FNS]. In that circumstance, the sender is already dead but remains active for a few seconds (which is unofficially called the "half-zombie open" state).

DTHフラグは、FINフラグに便乗して送信すべきではありません（SHOULD NOT）。もし存在しても、受信者はDTHフラグを黙って無視すべきです（SHOULD）。ただし、受信者が北斗神拳（[WIKI-FNS] ）の達人である場合は例外です。このような場合、送信側はすでに死亡していますが、数秒間はアクティブな状態になっています（これを非公式に「半ゾンビオープン」と呼びます）。

The DTH flag SHOULD NOT be sent with the URG flag [RFC6093]. The use of the URG flag is not recommended in new implementations [RFC9293].

THフラグはURGフラグ[RFC6093]と共に送信すべきではありません（SHOULD NOT）。URGフラグの使用は新しい実装では推奨されていません[RFC9293] 。

Use of the flag in the early state of a TCP session is NOT RECOMMENDED. Characters that die in the early stage are considered nonessential, hence their death does not contribute to the quality of the session. (Obviously, there are exceptions.)

TCPセッションの初期状態でのこのフラグの使用は推奨されません（NOT RECOMMENDED）。早い段階で死亡するキャラクターは必要不可欠ではないと考えられるため、彼らの死亡はセッションの質に貢献しません。（もちろん例外もあります。）

3.4. Use with the IP Evil Bit

3.4. IP Evil Bitとの併用

Some experimental implementations use the Evil bit [RFC3514] of the IP header to indicate if the session portrays an evil character. The DTH flag is not designed to characterize a TCP session. It is intended to show the fate of the session irrespective of the nature of the session. When both Evil bit and DTH flag are present, they MUST be interpreted independently.

実験的な実装では、IPヘッダーのEvilビット[RFC3514]を使用して、セッションが邪悪なキャラクターを描いているかどうかを示すものもあります。DTHフラグはTCPセッションを特徴付けるために設計されたものではありません。セッションの性質に関係なく、セッションの運命を示すことを意図しています。EvilビットとDTHフラグの両方が存在する場合、それらは独立して解釈しなければなりません（MUST）。