[Joke-RFC] RFC4824 手旗信号システム(SFSS)によるIPデータグラムの伝送

# はじめに

* この文書は [RFC4824](https://tools.ietf.org/html/rfc4824) を勉強と好奇心のため適当に訳したものです。
* 翻訳の正確さは全く保証しません。
* 誤字誤訳等の指摘はいつでも大歓迎です。

# The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS)
手旗信号システム(SFSS)によるIPデータグラムの伝送

* Network Working Group
* Request for Comments: 4824
* Category: Informational

- J. Hofmueller, Ed.
- A. Bachmann, Ed.
- I. Zmoelnig, Ed.
- 1 April 2007

## Status of This Memo(このメモの位置付け)

>   This memo provides information for the Internet community.  It does   not specify an Internet standard of any kind.  Distribution of this   memo is unlimited.

このメモでは,インターネットコミュニティのための情報を提供する.
このメモはなんらインターネット標準を定めない.
このメモの配布に制限は設けない.

## Copyright Notice(著作権について)

> Copyright (C) The IETF Trust (2007).

## Abstract(概要)
>
>   This document specifies a method for encapsulating and transmitting
>   IPv4/IPv6 packets over the Semaphore Flag Signal System (SFSS).

  この文書は,手旗信号システム(SFSS)を用いて,IPv4/IPv6のパケットを
  カプセル化および伝送する方法を定義する.

## Table of Contents(目次)
>
```
1. Introduction ....................................................2
2. Definitions .....................................................2
3. Protocol Discussion .............................................3
   3.1. IP-SFS Frame Description ...................................3
   3.2. SFS Coding .................................................4
   3.3. IP-SFS Data Signals ........................................5
   3.4. IP-SFS Control Signals .....................................6
   3.5. Protocol Limitations .......................................7
   3.6. Implementation Limitations .................................7
4. Interface Discussion ............................................7
   4.1. Data Link Control ..........................................8
   4.2. Establishing a Connection ..................................8
   4.3. State Idle .................................................8
   4.4. Session Initiation .........................................8
   4.5. State Transmitting .........................................9
   4.6. State Receiving ...........................................10
   4.7. Terminating a Connection ..................................11
   4.8. Further Remarks ...........................................11
5. Security Considerations ........................................11
6. Acknowledgements ...............................................11
7. References .....................................................12
```

## 1.  Introduction(導入)

>   This document specifies IP-SFS, a method for the encapsulation and   transmission of IPv4/IPv6 packets over the Semaphore Flag Signaling   System (SFSS).  The SFSS is an internationally recognized alphabetic   communication system based upon the waving of a pair of hand-held   flags [JCroft, Wikipedia].  Under the SFSS, each alphabetic character   or control signal is indicated by a particular flag pattern, called a   Semaphore Flag Signal (SFS).

この文書は,手旗信号システム(SFSS)を用いて,IPv4/IPv6のパケットをカプセル化および伝送する方法である,IP-SFS を定義する.
SFSS は1組の手旗を振る事により伝達される,英文による国際的な通信手段である [JCroft, Wikipedia].
SFSS では,それぞれの英字や制御信号は,手旗信号(SFS)と呼ばれる特定の旗のパターンによって示される.

>   IP-SFS provides reliable transmission of IP datagrams over a half-duplex channel between two interfaces.  At the physical layer, SFSS   uses optical transmission, normally through the atmosphere using   solar illumination and line-of-sight photonics.  A control protocol   (Section 4) allows each interface to contend for transmission on the   common channel.

IP-SFS は2つのインタフェースの間(訳注:顔と顔の間?)での半二重チャンネル上でIPデータグラムの伝送を提供する.
物理層として,通常 SFSS は太陽光と見通し距離の光通信による,光学的な伝送を用いる.
制御プロトコル(4章参照)では,各インタフェースは共通のチャンネルで伝送を行う.

>   This specification defines only unicast transmission.  Broadcast is   theoretically possible, but there are some physical restrictions on   channel direction dispersion.  This is a topic for future study.

本仕様では,単一送信(ユニキャスト)のみを定義する.
同報送信も理論的には可能だが,チャンネル指示分散に関していくつかの物理的な制限がある.
この件に関しては,今後の検討課題である.

>   The diagram in Figure 1 illustrates the place of the SFSS in the   Internet protocol hierarchy.

インターネットプロトコル階層における SFSS の位置を図1に示す.

>             +-----+     +-----+       +-----+
>             | TCP |     | UDP |  ...  |     |  Host Layer
>             +-----+     +-----+       +-----+
>                |           |             |
>             +-------------------------------+
>             |    Internet Protocol & ICMP   |  Internet Layer
>             +-------------------------------+
>                            |
>             +-------------------------------+
>             |             SFSS              |  Link Layer
>             +-------------------------------+
>
>                     Figure 1: Protocol Relationships

図1:プロトコル関連図

## 2.  Definitions(定義)

>   Link:    A link consists of two (2) interfaces that share a common            subnet.

リンク:リンクは,共通のサブネットを共有する2つのインタフェースから成る.

>   Link Partner:            The opposite interface.

リンクパートナー:インタフェースの相手側.

>   Session: The transmission of an entire IP datagram.

セッション:IPデータグラムの伝送が終わるまで.

>   SFS:     One Semaphore Flag Signal, i.e., one flag pattern (Section            3.2).

SFS:ひとつの手旗信号.すなわち,1つの旗のパターン(3.2章参照)

>   SFSS:    The Semaphore Flag Signaling System.

SFSS:手旗信号システム

>   IP-SFS:  IP over Semaphore Flag Signaling System.

IP-SFS:手旗信号システムで IP 伝送をすること.

## 3.  Protocol Discussion(プロトコルについて)

>   IP-SFS adapts the standard SFSS to encode an alphabet of 16 signals   (flag patterns) to represent data values 0-15 (Section 3.2.1) and 9   signals to represent control functions (Section 3.2.2).  With 16 data   signals, IP-SFS transmission is based upon 4-bit nibbles, two per   octet.  Each of the signal patterns defined in Section 3.2 is called   an SFS.

IP-SFSでは,標準的なSFSSの英字の16種類の信号(旗のパターン)を0～15のデータ値(3.2.1章参照)を表すために,また9種類の信号を制御機能(3.2.2章参照)を表すことに使用する.
16種類のデータ信号のため,IP-SFS は4ビットニブル単位の伝送であり,2つのペアでオクテットを表す.
各々の信号パターンは SFS と呼ばれ,3.2章で定義する.

### 3.1.  IP-SFS Frame(IP-SFSフレーム)

>   IP datagrams are formatted into IP-SFS frames by adding IP-SFS   headers and trailers.  Figure 2 shows the format of one IP-SFS frame.   The frame is delimited by a control SFS called FST (Frame Start) and   a control SFS called FEN (Frame End).  It is composed of a series of   4-bit nibbles, one per SFS.

IPデータグラムは,IP-SFS フレームの中に含まれIP-SFSのヘッダとトレーラが前後に付与される.
図2に,IP-SFS フレームを示す.
このフレームは,FST(フレームスタート)と呼ばれる制御 SFS とFEN(フレームエンド)と呼ばれる制御 SFS で区切られる.
これらは,一連の4ビットのニブル(SFS)から成る.

>   An IP datagram will be fragmented into multiple successive IP-SFS   frames if necessary.  When an IP datagram is fragmented into N   frames, the first frame will be sent with frame number N-1, the   second with frame number N-2, ..., and the last with frame number 0.

IP データグラムは,必要に応じて複数の連続した IP-SFS フレームに分割される.
IP データグラムがN個のフレームに分割される場合,先頭のフレームはフレーム番号N-1で送信され,2番目のフレームがフレーム番号N-2で送信され,…,そして最後がフレーム番号0になる.

>              0        1        2        3
>          +--------+--------+--------+--------+--------+
>          |   FST  |Protocol|CksumTyp|Frame No|Frame No|
>          +--------+--------+--------+--------+--------+
>                   |                                   |
>                   //       DATA  Payload              //
>                   |                                   |
>                   +--------+--------+--------+--------+---------+
>                   |  CRC   |  CRC   |  CRC   |  CRC   |   FEN   |
>                   +--------+--------+--------+--------+---------+
>
>            Note that each field represents one SFS or 4 bits.
>
>                       Figure 2: IP-SFS Frame Format

注:各フィールドは,1つの SFS あるいは4ビットを表す.
図2:IP-SFS フレームフォーマット

>   FST:       Frame Start control SFS

FST:       フレームの開始を示す制御SFS

>   Protocol:  4 bits -- Internetwork-layer protocol code
>
>       0      None.
>       1      For IPv4.
>       2      For IPv6.
>       3      For IPv4 frame gzip-compressed.
>       4      For IPv6 frame gzip-compressed.
>       5...15 Reserved for future use.

Protocol:  4ビット -- インターネットレイヤープロトコルコード

* 0      無し
* 1      IPv4
* 2      IPv6.
* 3      gzip圧縮されたIPv4
* 4      gzip圧縮されたIPv6
* 5...15 将来使用のための予備

>   CksumTyp:  4 bits (one data SFS) -- Checksum Type
>
>       0      none.
>
>       1      CCITT CRC 16 (polynomial: x^16 + x^12 + x^5+1).
>
>       2...15 Reserved for future use.

CksumTyp:  4ビット -- チェックサムタイプ

* 0      なし
* 1      CCITT CRC 16 (多項式: x^16 + x^12 + x^5+1).
* 2...15 将来使用のための予備


>   Frame No:  8 bits (2 data SFSs):
>              Frame number for fragmented IP datagram.

Frame No:  8ビット(2つの SFS):分割されたIPデータグラムのフレーム番号

>   DATA:      0 to 510 data SFSs (Section 3.2.1) representing 0 to 255
>              octets of payload.

DATA:      0～510 個のデータSFS(3.2.1章参照)であり0～255オクテットのIPデータグラム本体.

>   CRC:       16 bits as four data SFSs.
>              CRC checksum.  Preset to 0xFFFF.  One's complement of checksum is transmitted.

   CRC:       16ビット(4つのSFS).CRC チェックサム.プリセットは 0xFFFF.

>   FEN:       Frame ENd control SFS.

FEN:       フレームの終了を示す制御SFS

>   The number of transmitted SFSs per minute (Spm) depends on the   experience of participating interfaces.  Resulting link speed in bits   per second for IP-SFS is (Spm/60)*4, not counting framing overhead.

1分間のSFS伝送速度(Spm)は,インタフェースの経験に依存する.
IP-SFS のデータ速度(ビット/秒)は,フレーム化のオーバーヘッドを考慮せず(Spm/60)*4 となる.

### 3.2.  SFS Coding(SFSコード化)

>   Data signals and control signals are based upon standard SFS   encoding, as described by [JCroft], [Wikipedia], and other sources on   the Internet.  The 16 data signals are interpreted as 4-bit nibbles,   while the 9 control signals are used for data link control.

データ信号と制御信号は,標準 SFS エンコードを使用する.
16種類のデータ信号は4バイトのニブルに,9種類の制御信号はデータリンクコントロールに使われる.

>   IP-SFS defines the 16 data signals by the original SFSS encodings for   letters A to P and the 9 control signals represented by SFSS   encodings Q to X.

IP-SFS で定義した16種類のデータ信号は,元の SFSS でAからPの文字に制御信号は,元の SFSS でQからXの文字に当たる.

## 3.2.1.  IP-SFS Data Signals(IP-SFSデータ信号)

>   Figure 3 illustrates the 16 SFSs used to transmit data frames over
>   the link.  The illustrations show each SFS as seen from the receiving
>   side.

図3に16種類のデータ伝送に使われる SFS を示す.
示された図は受信者側から見た SFS である.

>                   SFS        0     __0      \0      |0
>                             /||      ||      ||      ||
>                             / \     / \     / \     / \
>                              A       B       C       D
>                   IP-SFS    0x00    0x01    0x02    0x03
>
>                   -----------------------------------------
>
>                   SFS        0/      0__     0     __0
>                             ||      ||      ||\     /|
>                             / \     / \     / \     / \
>                              E       F       G       H
>                   IP-SFS    0x04    0x05    0x06    0x07
>
>                   -----------------------------------------
>
>                   SFS       \0      |0__     0|      0/
>                             /|       |      /|      /|
>                             / \     / \     / \     / \
>                              I       J       K       L
>                   IP-SFS    0x08    0x09    0x0A    0x0B
>
>                   -----------------------------------------
>
>                   SFS        0__     0     _\0     __0|
>                             /|      /|\      |       |
>                             / \     / \     / \     / \
>                              M       N       O       P
>                   IP-SFS    0x0C    0x0D    0x0E    0x0F
>
>                      Figure 3: IP-SFS Data Signals.

図3:IP-SFS データ信号

## 3.2.2.  IP-SFS Control Signals(IP-SFS制御信号)

>   Nine control signals are used to signal special IP-SFS conditions.
>   Their meanings are listed in Figure 4.  The illustrations show each
>   SFS as seen from the receiving side.

9種類の制御信号は,IP-SFS の特別な状況を示す.
それらの意味を,図4に挙げる.
示された図は受信者側から見た SFS である.

>                   SFS      __0/    __0__   __0      \0|
>                              |       |       |\      |
>                             / \     / \     / \     / \
>                              Q       R       S       T
>                   IP-SFS    FST     FEN     SUN     FUN
>
>                   -----------------------------------------
>
>                   SFS       \0/     \0__     0/_     0/
>                              |       |       |       |\
>                             / \     / \     / \     / \
>                              U       V       W       X
>                   IP-SFS    ACK     KAL     NAK     RTR
>
>                   -----------------------------------------
>
>                   SFS        0__     0__
>                             /|       |\
>                             / \     / \
>                              Y       Z
>                   IP-SFS    RTT    unused
>
>                   -----------------------------------------
>
>                   SFS      _\0/_
>                             /|\
>                             / \
>                            Error
>                   IP-SFS   unused
>
>                     Figure 4: IP-SFS Control Signals.

図4:IP-SFS 制御信号

>   FST: Frame STart.  Signals the start of a new frame.

FST: Frame STart. 新しいフレームの開始.

>   FEN: Frame ENd.  Signals the end of one frame.

  FEN: Frame ENd. 1つのフレームの終了.

>   SUN: Signal UNdo.  Cancels the transmission of one or more individual
>        SFSs within the current frame.  This signal will be
>        unacknowledged by the receiver.

SUN: Signal UNdo.  現在のフレーム内で一つ以上の個々の SFS の伝送をキャンセルする.受信者はこの信号を無視する.

>   FUN: Frame UNdo.  As long as Frame ENd is not sent, the transmitter
>        or the receiver may send a FUN to restart the transmission of
>        the current frame.  This signal will be unacknowledged and may
>        be ignored by the receiver.

FUN: Frame UNdo.  FEN が送られない限り,送信者または受信者は現在のフレーム伝送を最初から送りなおすために FUN を送ることができる.受信者はこの信号を無視する.

>   ACK: Frame ACK.  Acknowledges reception of one frame.

ACK: Frame ACK.  1つのフレームの受信を認める.

>   KAL: KeepALive.  Keep a connection alive.  Is to be transmitted in
>        State Idle at a frequency of at least KAL_FREQ (see
>        Section 4.2).  This signal will be unacknowledged.

KAL: 接続を保持する.少なくとも KAL_FREQ (4.2章参照)の頻度で,待機状態を送る必要がある.この信号は無視される.

>   NAK: Frame No AcK.  The frame received is incorrect.

NAK: Frame No AcK.  受信フレームは誤っている.

>   RTR: Ready To Receive.  Receiver acknowledges it is ready to receive.

RTR: Ready To Receive.  受信者は受信準備が出来ている.

>   RTT: Ready To Transmit.  Sender requests permission to initiate        transmission.

RTT: Ready To Transmit.  送信者は伝送開始の許可を求める.

### 3.3.  Protocol Limitations(プロトコルの制限)

>   Due to the physical characteristics of the transfer channel, bit   error rates are expected to be in the range of 1e-3 (boy scout) to   1e-4 (professional sailor), and also depend a number of physical   factors.  Poor visibility due to weather conditions or lack of   illumination (e.g., night time) can drastically increase the error   rate.

転送チャンネルの物理的な特徴によりビット誤り率の範囲は1e-3(ボーイスカウト)から1e-4(プロの水夫)程度が予想され,さらに,いくつかの物理的な要因にも依存する.
気象状況や,照明不足(例えば夜間など)による低可視性によりエラーレートが大幅に増えることがありえる.

>   IP-SFS provides no means to handle frame reordering or dual   (multiple) frame reception.  Thus, the protocol is not suitable in   environments where interfaces are moving fast and/or when the path of   light is long.

IP-SFS は,フレームの再整理や重複受信を取り扱う方法を規定しない.
したがって,インターフェースが高速移動している場合,および/あるいは光の通り道が長い(訳注:両者の距離が離れている)などの環境ではこのプロトコルの適用は向いていない.

### 3.4.  Implementation Limitations(実装上の制限)

>   Maximum payload per frame: 510 SFS (0...510) nibbles (0 to 255   octets)

1フレーム当たりの最大ペイロード:510 SFS (0～510) ニブル                                  (0～255オクテット)

>   Maximum SFS per frame: 518

1フレーム当たりの最大 SFS :518

>   Maximum frames per session: 255 (0...254)

セッション当たりの最大フレーム数: 255 (0～254)

## 4.  Interface Discussion(インタフェースについて)

>   An interface is constructed through the participation of one or more   humans.  A knowledge of the SFSS is recommended, but its absence can   be compensated by a well-designed GUI.

インターフェースは,一人以上の人間が関与することによって構成される.
SFSS についての知識を持っていることを推奨するが,もし不足している場合であっても,うまく設計された GUI によって補うことが可能である.

### 4.1.  Data Link Control(データリンク制御)
>
>   This section describes the control protocol used to allocate the   half-duplex data link to either interface.

このセクションでは,半二重データリンクのどちらのインタフェースに対して制御権を割り当てるのかについて述べる.

>   Interfaces know three States: Idle, Transmitting (TX), and Receiving   (RX).

インタフェースには,3つのステータスがある:待機,送信中(TX),受信中(RX).

### 4.2.  Establishing a Connection(接続の確立)

>   IP-SFS is strictly point-to-point.  Unless interface members are   acquainted with each other, a brief introduction of both sides is   suggested prior to setting up a link to reduce the likelihood of   interface-spoofing attacks.

IP-SFS は,厳密に1対1の通信である.
インタフェースの構成員が互いを知らない限りインタフェースのなりすまし攻撃の可能性を減らすために通信前に簡単に両者の紹介をすることを提案する.

>   Interfaces must agree on two different IP addresses on the same   subnet.

インタフェースは,同じサブネットの上の2つの異なるIPアドレスについて同意しなければならない.

>   Interfaces are free to negotiate any period of time as TIMEOUT.   Possible values for TIMEOUT are the time it takes to smoke a   cigarette or the time it takes to drink a glass of water.  If   negotiation fails, TIMEOUT defaults to 60 seconds.

インタフェースは,タイムアウト間隔(TIMEOUT)について自由に交渉することができる.
TIMEOUT の有効な値は,一服するのに,あるいは水を一杯飲むのに必要な時間である.
交渉が失敗した場合には,TIMEOUTはデフォルトの60秒となる.

>   The same procedure may be applied for the KeepALive FReQuency   (KAL_FRQ).  The period of KAL_FRQ (1/KAL_FRQ) should be at least   5*TIMEOUT.

  同じ手順は,KeepALive FReQuency(KAL_FRQ)にも適用することができる.
  KAL_FRQ(1/KAL_FRQ)の期間は,少なくとも5*TIMEOUTでなければならない.

### 4.3.   State Idle(待機状態)

>   Interfaces in State Idle must be ready to send an IP datagram   provided by a local higher-level protocol or to receive a datagram   from the link-partner.  Interfaces in State Idle must send keep-alive   signals KAL at a frequency of at least KAL_FRQ.

待機状態にあるインタフェースは,ローカルの「より上位のプロトコル」によって提供される IP データグラムを送るか,リンクパートナーからデータグラムを受信する準備ができていなければならない.
待機状態のインターフェースは,少なくとも KAL_FRQ の頻度で,回線保持のための信号 KAL を送らなければならない.

>   There are no further definitions for State Idle, but we recommend   staying away from alcoholic beverages or other types of drugs that   could lead to an increased number of FUN and/or SUN signals, a   decrease in bandwidth, or an increase of line latency.

待機状態については,これ以上の定義はないがFUN や SUN の増加や,帯域の減少,回線待ち時間の増加などを避けるためにアルコール飲料やその他の薬物の摂取は我慢しておくことを勧める.

>   If the number of IP datagrams in the transmission queue is >0, the   interface may try to initiate a session by sending an RTT to the link   partner.  If the link partner ready to receive, it returns an RTR   signal.

送信キューに IP データグラムがある場合にはインタフェースはリンクパートナーに RTT を送ることによってセッションを始めようとするだろう.
リンクパートナーの受信準備ができている場合には,RTR 信号を返す.

### 4.4.  Session Initiation(セッションの開始)

>   An interface receiving a datagram from an Internet layer protocol   level may start signaling RTT.

インターネットレイヤープロトコルレベルからデータグラムを受信したインタフェースは,RTT を送るだろう.

>   If the link partner does not respond with RTR within TIMEOUT, or the   link partner responds with RTT, the interface switches to State Idle   for a random period of time between 2 seconds and TIMEOUT, before   resending the RTT.

リンクパートナーが TIMEOUT の間に RTR で応えない,あるいは RTT を応えた場合にはインタフェースは,RTT を送信する前に,2秒～TIMEOUT の間に待機状態に切り換える.

>   If the link partner transmits RTR, the interface transmits the number   of IP-SFS frames to be transmitted in this session as two SFSs   followed by another RTT.  If the link partner does not transmit the   same number of IP-SFS frames followed by RTR within 3*TIMEOUT, the   interface switches to State Idle.

リンクパートナーが RTR を送ってきた場合には,インタフェースは,もうひとつの RTT に続いてこのセッションで送る IP-SFS フレーム数を2つの SFS で送信する.
リンクパートナーが 3*TIMEOUT 以内に,RTR に続いて同じIP-SFSフレーム数を送らなかった場合にはインタフェースは待機状態に切り替わる.

>   If the link partner transmits the same number of IP-SFS frames   followed by RTR, the interface switches to State Transmitting.

リンクパートナーが RTR に続いて同じIP-SFSフレーム数を送った場合にはインターフェースは送信中状態に切り替わる.

>   Unless obstructed through environmental noise or great distance,   hollering can be used to request line discipline from the link   partner in State Idle.  The use of cellphones is also an option,   whereas throwing objects or using guns is not recommended, since it   could result in interface damage or destruction.  This would be   counterproductive.

環境雑音または大きな距離によって妨げられない限り,待機状態のリンクパートナーに対して叫ぶことで回線の秩序を守ることを要請することができます.
携帯電話の使用は自由に選択することができるがインタフェースに損害を与え,または破壊することがあるため,物を投げたり銃を使うことは推薦できない.
これは逆効果である.

### 4.5.  State Transmitting(送信状態)

>   Transmission of one IP-SFS frame starts with FST.  After FST and   before FEN have been transmitted, the interface may acknowledge a   received FUN and restart the transmission of the active frame or   discard the signal and continue transmission of the active IP-SFS   frame.

IP-SFS フレームの伝送は,FST から始める.
FST の後で,FEN が伝送されるまでの間,インタフェースは受信した FUN を受け入れ,実行中のフレームの伝送を再開始したり信号を破棄して実行中の IP-SFS フレームの伝送を続ける.

>   If an error occurs by transmitting a wrong data SFS, the interface   may invalidate the last data SFS by transmitting SUN followed by the   correct signal.  A series of incorrectly transmitted data SFSs may be   invalidated by sending a SUN for each invalid SFS, effectively back-spacing the sequence.

もし間違ったデータを伝送してしまった場合,インタフェースは SUN と正しい信号を送ることによって最後のデータ SFS を無効にすることができる.
一連の誤ったデータ SFS を送った場合には,誤った SFS 毎に SUN を送ることによって無効にすることができる,
つまり,事実上のシーケンスのバックスペースをすることである.

>   Control SFSs cannot be invalidated.

制御 SFS は無効にすることは出来ない.

>   If an error occurs, the interface may also transmit FUN and restart   transmission of the active IP-SFS frame.

エラーが発生した場合,インタフェースは FUN を送り,実行中の IP-SFS フレームの伝送を最初から送りなおすこともできる.

>   Whether the interfaces choose SUN or FUN for error correction is up   to the interface, but it is suggested to use SUN for a single invalid   SFS, and FUN whenever the interface failed to transmit several SFSs   in a row.

誤り訂正のために SUN と FUN のどちらを選ぶかはインタフェースが自由に選択することができるが,1つの SFS を訂正する場合には SUN を,いくつかの誤りをしてしまったときに FUN を使うことを提案する.

>   After FEN has been transmitted, the transmitting interface waits for   the link partner to transmit ACK or NAK.

FENを送った後,送信者はリンクパートナーが ACK あるいは NAK を送ってくるのを待つ.

>   If ACK has been received, the transmitting interface removes the   active frame and starts transmitting the next IP-SFS frame.  If no   frames are left, the interface switches to State Idle.

ACK を受信したならば,送信者は実行中のフレームを取り除き,次の IP-SFS フレームの転送を始める.
もしフレームが残っていないならば,待機状態に切り替わる.

>   If NAK has been received, the transmission failed, and the interface   must start transmitting the active frame again.

NAK を受信したならば,伝送は失敗したため,インタフェースは再び実行中のフレームを送る必要がある.

>   If the link partner does not transmit ACK or NAK within TIMEOUT, the   transmission failed, and the interface must start retransmitting the   active IP-SFS frame.

リンクパートナーが TIMEOUT までに ACK も NAK を送らなかった場合には伝送は失敗したため,インタフェースは実行中の IP-SFS フレームを再度送信しなければならない.

>   If transmission of the same IP-SFS frame fails 5 times, the interface   leaves the IP datagram in the transmission queue and switches to   State Idle.

同じ IP-SFS フレームの伝送が5回失敗するならば,インタフェースは IP データグラムをキューに残したまま待機状態に切り替わる.

### 4.6.  State Receiving(受信状態)

>   In State Receiving, the interface stores each SFS received from the   link partner in the receiving queue in the order of appearance.

受信中状態の場合,インタフェースはリンクパートナーから受け取った各 SFS を受信した順に受信キューに格納する.

>   After FST and before FEN have been received, the interface may   transmit FUN at any time to request a retransmission of the entire   IP-SFS frame.

FST の後で,FEN が受信されるまでの間であればいつでもインタフェースは FUN を送ることによりIP-SFS フレームを最初から送りなおすことを要求することができる.

>   If the time between two received SFSs exceeds TIMEOUT, the receiving   interface must discard all data from the active IP-SFS frame and may   additionally transmit FUN.  If the link partner does not continue   transmitting within a second TIMEOUT period, the interface must clear   the receiving queue and switch to State Idle.

2つの SFS の間の時間が TIMEOUT を上回るならば受信側インタフェースは実行中の IP-SFS フレームのすべてのデータを削除しなければならず,更に FUN を送ることができる.
リンクパートナーが第2の TIMEOUT 期間以内に伝送が続かない場合にはインターフェースは受信キューを削除し,待機状態に切り替わらなくてはならない.

>   If the interface receives SUN from the link partner, it must discard   the last received data SFS (if any).  If N SUNs are received in a   row, then the last N data SFS must be discarded, unless there are no   more data SFS in the frame.  If there are no more data SFS in the   frame to be discarded, the SUN signal must be ignored by the   interface.

インタフェースがリンクパートナーから SUN を受信した場合,最後に受信したデータ SFS(もしあるなら)を捨てなければならない.
N個の SUN を続けて受信した場合には,フレームにある最後のN個のデータ SFS を捨てなければならない.
フレームに,捨てるデータ SFS がない場合には,SUN 信号は無視されなければならない.

>   If the receiving interface receives FUN from the link partner, it is   free to discard the frame received thus far.  We suggest honoring FUN   since discarding the signal will decrease bandwidth.

受信側インタフェースがリンクパートナーから FUN を受信した場合にはそれまで受信していたフレームを破棄することができる.
FUNを守り信号を放棄することにより,帯域幅を減らすことを提案する.

>   After FEN has been received, the receiving interface evaluates the   checksum.  If the checksum is good, the interface transmits ACK.  If   the Frame Number of the active frame is 0, the interface passes the   entire data from the receiving queue to the higher level protocol,   clears the receiving queue, and switches to State Idle.

FEN を受信した場合,受信側インタフェースはチェックサムを評価する.
チェックサムが正しいならば,インタフェースは ACK を送る.
実行中のフレームのフレーム番号が0であるならば,インタフェースは受信キューから取り出した全データを「より上位のプロトコル」に渡し,受信キューをクリアして待機状態に切り替わる.

>   If the checksum is incorrect, the interface transmits NAK.

もしチェックサムが無効な場合には,インタフェースは NAK を送る.

>4.7.  Terminating a Connection
>
>   If the interface is in State Idle and the link partner did not
>   transmit any kind of SFS for at least five times 1/KAL_FRQ, the
>   connection is terminated and the interfaces are free to disband.

インタフェースが待機状態であり,リンクパートナーが少なくとも5回,1/KAL_FRQ の間にいかなる SFS も送らないならば,コネクションは切断され,インターフェースは解散することになる.

### 4.8.  Further Remarks(その他)

>   Interfaces are connected to computer hardware by means of a suitable   input device (RX) and a suitable output device (TX).  Possible   devices include keyboard, mouse, and monitor.  Other means of   connection are subject to availability and budget.

インタフェースは,適当な入力装置(RX)と適当な出力装置(TX)によってコンピュータハードウェアに接続している.
ふさわしい装置は,キーボード,マウスとモニタを含む.
その他の機器は,有効性と予算の影響を受ける.

>   Although it is theoretically possible to combine the TX and RX parts   of an interface in one human being, we suggest dividing the   operations among at least two people per interface.  For longer   transmissions (multimedia streaming, video conferencing, etc.),   consider rotating and providing substitutes.

TX や RX のインタフェースを1人の人間で実現することも理論的に可能だがインタフェース毎に少なくとも2人で作業することを提案する.
より長い伝送(マルチメディアのストリーミング,テレビ会議,等)のために,交替して,代わりの人を立てるなどの考慮をしてください.

>   Bandwidth tends to vary.  Typically TX starts at about 2-4 bits/s and   will decrease over time due to exhaustion and lack of concentration.   When an interface in TX State signals at a rate higher than the RX   interface is able to receive, signal loss occurs.

帯域幅は,変動する傾向がある.
一般的に TX は 2-4 ビット/sくらいで始まり,集中力の減退と欠如のために,時間とともに減少する.
送信中状態のインタフェースが RX インターフェースが受けることができるより高い率で信号を送るとき,信号の損失が起こる.

## 5.  Security Considerations(セキュリティに関する考察)

>   By its nature of line-of-sight signaling, IP-SFS is considered   insecure.  The transmission of sensitive data over IP-SFS is strongly   discouraged unless security is provided by higher level protocols.

自然な見通し距離での通信によるため,IP-SFS は安全ではないと思われる.
セキュリティが「より高位のプロトコル」によって提供されない限り,IP-SFS上での機密データの伝送は,非常に危険である.

>   Interfaces tend to keep data in their memory.  There is no way to   determine the lifetime of data in memory.  As a side effect, data   might show up in unwanted locations at undesired times.

インタフェースは,データを自らの記憶に憶えてしまう傾向がある.
記憶内のデータの有効期間を決定する方法はない.
副作用として,データは望まれていない時に不必要な場所で現れる可能性がある.

>   We are currently not aware of a technique to reliably delete data   from interfaces' memory without permanent interface destruction.

インタフェースを恒久的破壊するという方法以外に,現在,確実にインタフェースの記憶を削除する方法は知られていない.

## 6.  Acknowledgements

>   We thank Eva Ursprung and Doris Jauk-Hinz from Womyn's Art Support
>   (WAS), Anita Hofer, Reni Hofmueller, Ulla Klopf, Nicole Pruckermayr,
>   Manfred Rittler, Martin Schitter, and Bob Braden for all their
>   contributions and support of this project.

## 7.  References

>   [JCroft]     Croft, J., "Semaphore Flag Signalling System",
>                <http://www.anbg.gov.au/flags/semaphore.html>.
>
>   [Wikipedia]  Wikipedia, "Modern semaphore", <http://
>                en.wikipedia.org/wiki/Semaphore#Modern_semaphore>.

## Authors' Addresses

>   Jogi Hofmueller (editor)
>   Brockmanngasse 65
>   Graz  8010
>   AT
>
>   EMail: ip-sfs@mur.at
>
>
>   Aaron Bachmann (editor)
>   Ulmgasse 14 C
>   Graz  8053
>   AT
>
>   EMail: ip-sfs@mur.at
>
>
>   Iohannes Zmoelnig (editor)
>   Goethestrasse 9
>   Graz  8010
>   AT
>
>   EMail: ip-sfs@mur.at

## Full Copyright Statement

>   Copyright (C) The IETF Trust (2007).
>
>   This document is subject to the rights, licenses and restrictions
>   contained in BCP 78, and except as set forth therein, the authors
>   retain all their rights.
>
>   This document and the information contained herein are provided on an
>   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
>   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
>   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
>   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
>   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
>   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

## Intellectual Property

>   The IETF takes no position regarding the validity or scope of any
>   Intellectual Property Rights or other rights that might be claimed to
>   pertain to the implementation or use of the technology described in
>   this document or the extent to which any license under such rights
>   might or might not be available; nor does it represent that it has
>   made any independent effort to identify any such rights.  Information
>   on the procedures with respect to rights in RFC documents can be
>   found in BCP 78 and BCP 79.
>
>   Copies of IPR disclosures made to the IETF Secretariat and any
>   assurances of licenses to be made available, or the result of an
>   attempt made to obtain a general license or permission for the use of
>   such proprietary rights by implementers or users of this
>   specification can be obtained from the IETF on-line IPR repository at
>   http://www.ietf.org/ipr.
>
>   The IETF invites any interested party to bring to its attention any
>   copyrights, patents or patent applications, or other proprietary
>   rights that may cover technology that may be required to implement
>   this standard.  Please address the information to the IETF at
>   ietf-ipr@ietf.org.

## Acknowledgement

>   Funding for the RFC Editor function is currently provided by the
>   Internet Society.