この文書は rfc4824 を私(yotti@imasy.or.jp)が勉強と好奇心のため適当に
訳したものです．
翻訳の正確さは全く保証しません．
誤字誤訳等の指摘はいつでも大歓迎です．

この文書（原文）は，いわゆるジョーク RFC と呼ばれる物です（たぶん）．
ジョーク RFC については，私のページにてまとめています．
興味があったらどうぞご覧ください．
  http://www.imasy.or.jp/~yotti/rfc-joke.html

--
|Network Working Group                                 J. Hofmueller, Ed.
|Request for Comments: 4824                              A. Bachmann, Ed.
|Category: Informational                                 I. Zmoelnig, Ed.
|                                                            1 April 2007
|
|                   The Transmission of IP Datagrams
|            over the Semaphore Flag Signaling System (SFSS)

             手旗信号システム(SFSS)によるIPデータグラムの伝送

|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 は１組の手旗を振る事により伝達される、
  英文による国際的な通信手段である [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 は２つのインタフェースの間(訳注:顔と顔の間?)での
  半二重チャンネル上でIPデータグラムの伝送を提供する。
  物理層として、通常 SFSS は太陽光と見通し距離の光通信による、
  光学的な伝送を用いる。
  制御プロトコル(４章参照)では、各インタフェースは
  共通のチャンネルで伝送を行う。

|   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 の位置を図１に示す。

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

                      図１：プロトコル関連図

|2.  Definitions
|
|   Link:    A link consists of two (2) interfaces that share a common
|            subnet.
|
|   Link Partner:
|            The opposite interface.
|
|   Session: The transmission of an entire IP datagram.
|
|   SFS:     One Semaphore Flag Signal, i.e., one flag pattern (Section
|            3.2).
|
|   SFSS:    The Semaphore Flag Signaling System.
|
|   IP-SFS:  IP over Semaphore Flag Signaling System.

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

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

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

    SFS：ひとつの手旗信号。すなわち、１つの旗のパターン(3.2章参照)

    SFSS：手旗信号システム

    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章参照)を表すために、
  また９種類の信号を制御機能(3.2.2章参照)を表すことに使用する。。
  16種類のデータ信号のため、IP-SFS は４ビットニブル単位の伝送であり、
  ２つのペアでオクテットを表す。
  各々の信号パターンは SFS と呼ばれ、3.2章で定義する。

|3.1.  IP-SFS Frame
|
|   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のヘッダとトレーラが前後に付与される。
  図２に、IP-SFS フレームを示す。
  このフレームは、FST(フレームスタート)と呼ばれる制御 SFS と
  FEN(フレームエンド)と呼ばれる制御 SFS で区切られる。
  これらは、一連の４ビットのニブル(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-1で送信され、
  ２番目のフレームがフレーム番号N-2で送信され、
  …、そして最後がフレーム番号０になる。

|              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

             注：各フィールドは、１つの SFS あるいは４ビットを表す。

                        図２：IP-SFS フレームフォーマット

|   FST:       Frame Start control 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.
|
|   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.
|
|   Frame No:  8 bits (2 data SFSs):
|              Frame number for fragmented IP datagram.
|
|   DATA:      0 to 510 data SFSs (Section 3.2.1) representing 0 to 255
|              octets of payload.
|
|   CRC:       16 bits as four data SFSs.
|              CRC checksum.  Preset to 0xFFFF.  One's complement of
|              checksum is transmitted.
|
|   FEN:       Frame ENd control SFS.

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

   Protocol:  ４ビット -- インターネットレイヤープロトコルコード
       0      無し
       1      IPv4
       2      IPv6.
       3      gzip圧縮されたIPv4
       4      gzip圧縮されたIPv6
       5...15 将来使用のための予備

   CksumTyp:  ４ビット -- チェックサムタイプ
       0      なし
       1      CCITT CRC 16 (多項式: x^16 + x^12 + x^5+1).
       2...15 将来使用のための予備

   Frame No:  ８ビット（２つの SFS）
              分割されたIPデータグラムのフレーム番号

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

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

   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.

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

|3.2.  SFS Coding
|
|   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種類のデータ信号は４バイトのニブルに
  ９種類の制御信号はデータリンクコントロールに使われる。

|   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 でＡからＰの文字に
  制御信号は、元の SFSS でＱからＸの文字に当たる。

|3.2.1.  IP-SFS Data Signals
|
|   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.

  図３に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.

                       図３：IP-SFS データ信号

|3.2.2.  IP-SFS Control Signals
|
|   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.

  ９種類の制御信号は、IP-SFS の特別な状況を示す。
  それらの意味を、図４に挙げる。
  示された図は受信者側から見た 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.

                      図４：IP-SFS 制御信号

|   FST: Frame STart.  Signals the start of a new frame.
|
|   FEN: Frame ENd.  Signals the end of one frame.
|
|   SUN: Signal UNdo.  Cancels the transmission of one or more individual
|        SFSs within the current frame.  This signal will be
|        unacknowledged by the receiver.
|
|   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.
|
|   ACK: Frame ACK.  Acknowledges reception of one frame.
|
|   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.
|
|   NAK: Frame No AcK.  The frame received is incorrect.
|
|   RTR: Ready To Receive.  Receiver acknowledges it is ready to receive.
|
|   RTT: Ready To Transmit.  Sender requests permission to initiate
|        transmission.

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

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

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

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

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

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

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

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

  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)
|
|   Maximum SFS per frame: 518
|
|   Maximum frames per session: 255 (0...254)

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

  １フレーム当たりの最大 SFS ：518

  セッション当たりの最大フレーム数： 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).

  インタフェースには、３つのステータスがある：待機、送信中（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 は、厳密に１対１の通信である。
  インタフェースの構成員が互いを知らない限り
  インタフェースのなりすまし攻撃の可能性を減らすために
  通信前に簡単に両者の紹介をすることを提案する。

|   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 を送信する前に、２秒〜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 フレーム数を２つの 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 のどちらを選ぶかは
  インタフェースが自由に選択することができるが、
  １つの 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.

  ２つの SFS の間の時間が TIMEOUT を上回るならば
  受信側インタフェースは実行中の IP-SFS フレームのすべてのデータを
  削除しなければならず、更に FUN を送ることができる。
  リンクパートナーが第２の 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（もしあるなら）を捨てなければならない。
  Ｎ個の SUN を続けて受信した場合には、
  フレームにある最後のＮ個のデータ 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 を送る。
  実行中のフレームのフレーム番号が０であるならば、
  インタフェースは受信キューから取り出した全データを
  「より上位のプロトコル」に渡し、受信キューをクリアして
  待機状態に切り替わる。

|   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.

  インタフェースが待機状態であり、リンクパートナーが
  少なくとも５回、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 のインタフェースを１人の人間で実現することも理論的に可能だが
  インタフェース毎に少なくとも２人で作業することを提案する。
  より長い伝送(マルチメディアのストリーミング、テレビ会議、等）のために、
  交替して、代わりの人を立てるなどの考慮をしてください…。

|   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.