この文書はRFC1958の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group B. Carpenter, Editor
Request for Comments: 1958 IAB
Category: Informational June 1996
Architectural Principles of the Internet
インターネット構築の原則
Status of This Memo
この文書の状態
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
このメモはインターネット共同体のための情報を供給します。これはインター
ネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
The Internet and its architecture have grown in evolutionary fashion
from modest beginnings, rather than from a Grand Plan. While this
process of evolution is one of the main reasons for the technology's
success, it nevertheless seems useful to record a snapshot of the
current principles of the Internet architecture. This is intended for
general guidance and general interest, and is in no way intended to
be a formal or invariant reference model.
インターネットとその構築は、雄大な計画から始まったのではなく、謙虚に
始まり、成長しました。この成長プロセスは技術の成功が主な理由の１つで
すが、インターネット構築の現在の原則のスナップショットを記録すること
は有用に思われます。これは一般的開度ラインと一般的な興味を意図し、決
して正式あるいは不変の参照モデルを意図しません。
Table of Contents
目次
1. Constant Change
1. 常に変化
2. Is there an Internet Architecture?
2. インターネット構築体系がありますか？
3. General Design Issues
3. 一般的設計問題
4. Name and address issues
4. 名前とアドレス問題
5. External Issues
5. 外部問題
6. Related to Confidentiality and Authentication
6. 機密性と認証関連
Acknowledgements
謝辞
References
参考文献
Security Considerations
セキュリティの考察
Editor's Address
編集者アドレス
1. Constant Change
1. 常に変化
In searching for Internet architectural principles, we must remember
that technical change is continuous in the information technology
industry. The Internet reflects this. Over the 25 years since the
ARPANET started, various measures of the size of the Internet have
increased by factors between 1000 (backbone speed) and 1000000
(number of hosts). In this environment, some architectural principles
inevitably change. Principles that seemed inviolable a few years ago
are deprecated today. Principles that seem sacred today will be
deprecated tomorrow. The principle of constant change is perhaps the
only principle of the Internet that should survive indefinitely.
インターネット構築の原則を探索する際に、我々は情報工学産業で技術変化
が絶え間がないことを覚えていなくてはなりません。インターネットはこれ
を反映します。ＡＲＰＡＮＥＴが始まってから２５年にわたり、インターネッ
ト様々な種類の大きさが、１０００（バックボーン速度）から１００００００
（ホスト数）の範囲で増加しました。この環境で、ある構築の原則が必然的
に変化します。数年前に神聖に思われた原則が今日望ましくありません。今
日神聖に思われる原則が明日望ましくなくなるでしょう。常に変化の原則は
多分いつまでも生き残るべき唯一のインターネットの原則です。
The purpose of this document is not, therefore, to lay down dogma
about how Internet protocols should be designed, or even about how
they should fit together. Rather, it is to convey various guidelines
that have been found useful in the past, and that may be useful to
those designing new protocols or evaluating such designs.
従って、この文書の目的は、どのようにインターネット・プロトコルが設計
されるべきであるか、あるいはどのように適合すべきかの、教義を定めるこ
とではありません。どちらかと言うと、これは過去に有用とみなされたガイ
ドラインと、新しいプロトコルを設計するかこのような設計を評価する人た
ちに有用かもしれないガイドラインを伝えるはずです。
A good analogy for the development of the Internet is that of
constantly renewing the individual streets and buildings of a city,
rather than razing the city and rebuilding it. The architectural
principles therefore aim to provide a framework for creating
cooperation and standards, as a small "spanning set" of rules that
generates a large, varied and evolving space of technology.
インターネット開発の良い類似例は、都市を破壊して再建するよりも、都市
の個別の道路と建物を更新することです。従って構築の原則は、大きく多様
で広い範囲の技術を作る、小さい範囲の規則として、協調と標準を作るフレー
ムワークを供給することを目指します。
Some current technical triggers for change include the limits to the
scaling of IPv4, the fact that gigabit/second networks and multimedia
present fundamentally new challenges, and the need for quality of
service and security guarantees in the commercial Internet.
現在の技術的な変化の要因は、ＩＰｖ４のスケール限界と、ギガビット／秒
ネットワークとマルチメディアがもたらす基本的な新しい挑戦と、商業イン
ターネットでのサービス品質とセキュリティ保証の要求からなります。
As Lord Kelvin stated in 1895, "Heavier-than-air flying machines are
impossible." We would be foolish to imagine that the principles
listed below are more than a snapshot of our current understanding.
Lord Kelvinは１８９５年に「空気より重い飛行機は不可能」と述べました。
下にリストアップされた原則が現在の理解のスナップショット以上のものと
考えるのは愚かであるでしょう。
2. Is there an Internet Architecture?
2. インターネット構築体系がありますか？
2.1 Many members of the Internet community would argue that there is
no architecture, but only a tradition, which was not written down for
the first 25 years (or at least not by the IAB). However, in very
general terms, the community believes that the goal is connectivity,
the tool is the Internet Protocol, and the intelligence is end to end
rather than hidden in the network.
2.1 インターネット共同体の多くのメンバが、最初の２５年間に（少なくと
もＩＡＢの周辺で）記述されなかった伝統以外に、構築体系はないと論ずる
でしょう。しかし、一般的な言葉で、共同体が、目的は接続性で、道具はイ
ンターネット・プロトコルで、知性はネットワークに隠されるのではなくエ
ンドエンドだと信じています。
The current exponential growth of the network seems to show that
connectivity is its own reward, and is more valuable than any
individual application such as mail or the World-Wide Web. This
connectivity requires technical cooperation between service
providers, and flourishes in the increasingly liberal and competitive
commercial telecommunications environment.
ネットワークの現在の指数関数的な成長は接続性自身が結果で、メールやウェ
ブのような個別アプリケーションより貴重であることを示すように思われま
す。この接続性は自由競争の商況通信環境でますますサービスプロバイダ間
の技術的な協調を必要とします。
The key to global connectivity is the inter-networking layer. The
key to exploiting this layer over diverse hardware providing global
connectivity is the "end to end argument".
グローバル接続性への鍵はネットワーキング間のレイヤです。グローバル接
続性を供給している多様なハードウェア上でこのレイヤを利用することへの
鍵は「エンドエンド議論」です。
2.2 It is generally felt that in an ideal situation there should be
one, and only one, protocol at the Internet level. This allows for
uniform and relatively seamless operations in a competitive, multi-
vendor, multi-provider public network. There can of course be
multiple protocols to satisfy different requirements at other levels,
and there are many successful examples of large private networks with
multiple network layer protocols in use.
2.2 理想的状態はインターネット層で唯一のプロトコルだけがあるべきであ
ると一般に感じられます。これは競争的、多ベンダ、多プロバイダの公共の
ネットワークで、一様で比較的スムーズな運用を考慮します。他の層に異な
る条件を満たすための多数のプロトコルがもちろんあり得て、そして多数の
ネットワーク層プロトコルを使用した大きなプライベートネットワークの多
くの成功例があります。
In practice, there are at least two reasons why more than one network
layer protocol might be in use on the public Internet. Firstly, there
can be a need for gradual transition from one version of IP to
another. Secondly, fundamentally new requirements might lead to a
fundamentally new protocol.
実際は、公共のインターネットでなぜ１つ以上のネットワーク層プロトコル
が使用されないかの少なくとも２つの理由があります。第一に、ＩＰの１つ
の版から他の版までゆるやかな移行の必要があり得ます。第二に、基本的に
新しい必要条件が基本的に新しいプロトコルに導くかもしれません。
The Internet level protocol must be independent of the hardware
medium and hardware addressing. This approach allows the Internet to
exploit any new digital transmission technology of any kind, and to
decouple its addressing mechanisms from the hardware. It allows the
Internet to be the easy way to interconect fundamentally different
transmission media, and to offer a single platform for a wide variety
of Information Infrastructure applications and services. There is a
good exposition of this model, and other important fundemental
issues, in [Clark].
インターネット層プロトコルはハードウェアメディアとハードウェアアドレ
スから独立でなければなりません。この方法はインターネットがどんなどん
な種類でもの新しいデジタル送信技術でも採用することを許し、そしてハー
ドウェアからアドレスメカニズムを切り離します。れはインターネットで基
本的に異なった送信媒体を接続する容易な方法であり、そして多種多様な情
報基盤アプリケーションとサービスのための単一のプラットホームの供給を
許します。このモデルと他の重要な基本事項の良い説明が[Clark]にあります。
2.3 It is also generally felt that end-to-end functions can best be
realised by end-to-end protocols.
2.3 エンドエンド機能はエンドエンドプロトコルでが最も良く実現できると
一般に感じられます。
The end-to-end argument is discussed in depth in [Saltzer]. The
basic argument is that, as a first principle, certain required end-
to-end functions can only be performed correctly by the end-systems
themselves. A specific case is that any network, however carefully
designed, will be subject to failures of transmission at some
statistically determined rate. The best way to cope with this is to
accept it, and give responsibility for the integrity of communication
to the end systems. Another specific case is end-to-end security.
エンドエンド議論は[Saltzer]で深く論じられます。基本的な議論は、最初の
原則として、ある特定の必要とされるエンドエンド機能がただ末端システム
自身によってだけ正確に実行できるということです。特別な事例は、慎重に
設計されたどんなネットワークでも、ある統計的に決定された割合で伝達の
失敗の適用があるあろうということです。これにうまく対処する最も良い方
法は、これを受け入れて、そして末端システムに通信の完全性に対する責任
を与えることです。もう１つの特別な事例はエンドエンドセキュリティです。
To quote from [Saltzer], "The function in question can completely and
correctly be implemented only with the knowledge and help of the
application standing at the endpoints of the communication system.
Therefore, providing that questioned function as a feature of the
communication system itself is not possible. (Sometimes an incomplete
version of the function provided by the communication system may be
useful as a performance enhancement.")
[Saltzer]からの引用で、「問題の機能は、通信の終端に立つアプリケーショ
ンの知識と助けがあるときだけ、完全にそして正確に実行できます。それ故
に、その問題にされた機能を、通信システム自身の機能として提供すること
は可能ではありません。（時には通信システムによって供給された不完全な
機能が性能向上には有用であるかもしれません。）」
This principle has important consequences if we require applications
to survive partial network failures. An end-to-end protocol design
should not rely on the maintenance of state (i.e. information about
the state of the end-to-end communication) inside the network. Such
state should be maintained only in the endpoints, in such a way that
the state can only be destroyed when the endpoint itself breaks
(known as fate-sharing). An immediate consequence of this is that
datagrams are better than classical virtual circuits. The network's
job is to transmit datagrams as efficiently and flexibly as possible.
Everything else should be done at the fringes.
この原則は、もしアプリケーションが部分的なネットワーク障害から生き残
る必要があるなら、重要な帰結です。エンドエンドプロトコル設計はネット
ワーク内の状態（すなわちエンドエンド通信状態の情報）の維持管理に依存
するべきではありません。このような状態は終端でだけ維持され、エンド自
身が壊れるときだけに破壊される方法で維持されるべきです（運命共有とい
われます）。これの直接的結論はデータグラムが古典的仮想回路より良いと
いうことです。ネットワークの仕事は効率的に柔軟にデータグラムを伝達す
ることです。他のすべてが周辺でされるべきです。
To perform its services, the network maintains some state
information: routes, QoS guarantees that it makes, session
information where that is used in header compression, compression
histories for data compression, and the like. This state must be
self-healing; adaptive procedures or protocols must exist to derive
and maintain that state, and change it when the topology or activity
of the network changes. The volume of this state must be minimized,
and the loss of the state must not result in more than a temporary
denial of service given that connectivity exists. Manually
configured state must be kept to an absolute minimum.
サービスを行うために、ネットワークはある状態情報を維持します：経路、
ＱｏＳ保証、ヘッダ圧縮に使うセッション情報、データ圧縮のための圧縮履
歴、など。この状態は自己修復できなければなりません；状態を得て維持す
る適応手順やプロトコルがなければならず、そしてネットワークトポロジや
活動が変化する時、変更しなければなりません。この状態の量は最小である
に違いなく、そして状態の損失は、接続性が存在する間に一時的なサービス
停止以上の結果をもたらしてはなりません。手作業で配置された状態は絶対
最小限に留めなければなりません。
2.4 Fortunately, nobody owns the Internet, there is no centralized
control, and nobody can turn it off. Its evolution depends on rough
consensus about technical proposals, and on running code.
Engineering feed-back from real implementations is more important
than any architectural principles.
2.4 幸いに、誰もインターネットを所有せず、中央集権化された管理がなく、
そして誰も止めることができません。この進展は技術提案のラフな総意と、
実行できるコードに依存します。真の実装からの技術的フィードバックは、
構築原則より重要です。
3. General Design Issues
3. 一般的設計問題
3.1 Heterogeneity is inevitable and must be supported by design.
Multiple types of hardware must be allowed for, e.g. transmission
speeds differing by at least 7 orders of magnitude, various computer
word lengths, and hosts ranging from memory-starved microprocessors
up to massively parallel supercomputers. Multiple types of
application protocol must be allowed for, ranging from the simplest
such as remote login up to the most complex such as distributed
databases.
3.1 不均一は避けられず、計画的にサポートしなければなりません。多種の
ハードウェア、例えば、７桁以上の速さの違う転送速度と、様々なワード長
のコンピュータと、メモリの少ないマイクロプロセッサから大規模並列スー
パーコンピュータまでの広い範囲、が利用できなければなりません。リモー
トログインのような最も単純なものから、分散データベースのような最も複
雑なものまで、多数のタイプのアプリケーションプロトコルが考慮されなく
てはなりません。
3.2 If there are several ways of doing the same thing, choose one.
If a previous design, in the Internet context or elsewhere, has
successfully solved the same problem, choose the same solution unless
there is a good technical reason not to. Duplication of the same
protocol functionality should be avoided as far as possible, without
of course using this argument to reject improvements.
3.2 もし同じことをするいくつかの方法があるなら、１つを選択してくださ
い。もし前の設計が、インターネットあるいは他で、同じ問題を解くのに成
功したら、そうしない技術的な理由がないなら、同じ解決策を選択してくだ
さい。同じプロトコル機能の複製可能な限り遠くに避けられるべきです、も
ちろんこの議論を改良を拒絶に使わないでください。
3.3 All designs must scale readily to very many nodes per site and to
many millions of sites.
3.3 全ての設計はサイト毎毎の多数のノードと、何百万のサイトに対応しな
けばなりません。
3.4 Performance and cost must be considered as well as functionality.
3.4 性能とコストと機能が考慮されなくてはなりません。
3.5 Keep it simple. When in doubt during design, choose the simplest
solution.
3.5 単純にすべきです。設計に疑いがあるなら、最も単純な解決策を選択し
てください。
3.6 Modularity is good. If you can keep things separate, do so.
3.6 モジュール性は良いです。もしあなたが別にできるなら、そうしてくだ
さい。
3.7 In many cases it is better to adopt an almost complete solution
now, rather than to wait until a perfect solution can be found.
3.7 多くの場合、完ぺきな解決策が見つかるまで待つより、現在もっともよ
い解決策を採用することが良いです。
3.8 Avoid options and parameters whenever possible. Any options and
parameters should be configured or negotiated dynamically rather than
manually.
3.8 可能なら、オプションとパラメータを避けてください。オプションとパ
ラメータは手作業で設定されるより、動的に交渉されるべきです。
3.9 Be strict when sending and tolerant when receiving.
Implementations must follow specifications precisely when sending to
the network, and tolerate faulty input from the network. When in
doubt, discard faulty input silently, without returning an error
message unless this is required by the specification.
3.9 送信時には厳格で、受信時には寛大であるべきです。実装はネットワー
クに送信する時に正確に仕様書に従い、ネットワークからの欠陥がある入力
を大目に見なくてはなりません。疑いがあれば、仕様書に要求されない限り、
エラーメッセージを返さないで問題のある入力を静かに捨ててください。
3.10 Be parsimonious with unsolicited packets, especially multicasts
and broadcasts.
3.10. 要求されていないパケット、特にマルチキャストやブロードキャスト
は出し惜しみすべきです。
3.11 Circular dependencies must be avoided.
3.11 依存性のループが避けられなくてはなりません。
For example, routing must not depend on look-ups in the Domain
Name System (DNS), since the updating of DNS servers depends on
successful routing.
例えば、ＤＮＳサーバの更新はルーティングの成功に依存するので、
ルーティングはドメインネームシステム（ＤＮＳ）の検索に依存して
はなりません。
3.12 Objects should be self decribing (include type and size), within
reasonable limits. Only type codes and other magic numbers assigned
by the Internet Assigned Numbers Authority (IANA) may be used.
3.12 オブジェクトが合理的な限界の内で自己記述（種別と大きさを含む）で
あるべきです。インターネット番号割当当局（ＩＡＮＡ）によって割り当て
られたタイプコードと他のマジック番号だけが使われるかもしれません。
3.13 All specifications should use the same terminology and notation,
and the same bit- and byte-order convention.
3.13 すべての仕様書は同じ用語と表記とビット順とバイト順の会話を使うべ
きです。
3.14 And perhaps most important: Nothing gets standardised until
there are multiple instances of running code.
3.14 そして多分最も重要なのは：実行可能な多数のコード例が標準化しない
ことです。
4. Name and address issues
4. 名前とアドレス問題
4.1 Avoid any design that requires addresses to be hard coded or
stored on non-volatile storage (except of course where this is an
essential requirement as in a name server or configuration server).
In general, user applications should use names rather than addresses.
4.1 ハードウェアに組込みや不発揮性メモリに記憶するようなアドレス構想
は避けてください（もちろんこれがネームサーバや設定サーバのように不可
欠な要求条件である場合以外に）。一般に、ユーザーアプリケーションがア
ドレスより名前を使うべきです。
4.2 A single naming structure should be used.
4.2 単一の命名構造が使われるべきです。
4.3 Public (i.e. widely visible) names should be in case-independent
ASCII. Specifically, this refers to DNS names, and to protocol
elements that are transmitted in text format.
4.3 公共（すなわち広く見えます）名前はＡＳＣＩＩの大文字小文字に依存
しないべきです。特に、これはＤＮＳ名とテキストフォーマットで伝達され
るプロトコル要素でです。
4.4 Addresses must be unambiguous (unique within any scope where they
may appear).
4.4 アドレスが（現れるかもしれない範囲内で一意で）明確でなくてはなり
ません。
4.5 Upper layer protocols must be able to identify end-points
unambiguously. In practice today, this means that addresses must be
the same at start and finish of transmission.
4.5 上位レイヤプロトコルは明瞭に終端点を識別できなければなりません。
実際は今日、これはアドレスが伝達の開始と終了で同じであるに違いないこ
とを意味します。
5. External Issues
5. 外部問題
5.1 Prefer unpatented technology, but if the best technology is
patented and is available to all at reasonable terms, then
incorporation of patented technology is acceptable.
5.1 特許権を与えられていない技術の方を優先してください、しかし最良技
術が特許を取られているが、合理的な条件で入手可能であるなら、特許を取
られた技術の編入は許容できます。
5.2 The existence of export controls on some aspects of Internet
technology is only of secondary importance in choosing which
technology to adopt into the standards. All of the technology
required to implement Internet standards can be fabricated in each
country, so world wide deployment of Internet technology does not
depend on its exportability from any particular country or countries.
5.2 インターネット技術のある面での輸出規制の存在は、標準にどの技術を
採用するか決める際に、副次的な優先性だけをもちます。インターネット標
準を実行するのに必要な技術はすべてがそれぞれの国で造りあげることがで
き、そしてインターネット技術の世界中への実装は特定の国や輸出性に依存
しません。
5.3 Any implementation which does not include all of the required
components cannot claim conformance with the standard.
5.3 必要な要素のすべてを含むわけではない実装は、標準への準拠を要求す
ることができません。
5.4 Designs should be fully international, with support for
localisation (adaptation to local character sets). In particular,
there should be a uniform approach to character set tagging for
information content.
5.4 設計は完全に国際的で、ローカル化（ローカル文字セットへの改作）を
サポートするべきです。特に、情報内容に文字セットのタグを付ける一様な
方法があるべきです。
6. Related to Confidentiality and Authentication
6. 機密性と認証関連
6.1 All designs must fit into the IP security architecture.
6.1 すべてのデザインはＩＰセキュリティ体系に適合しなくてはなりません。
6.2 It is highly desirable that Internet carriers protect the privacy
and authenticity of all traffic, but this is not a requirement of the
architecture. Confidentiality and authentication are the
responsibility of end users and must be implemented in the protocols
used by the end users. Endpoints should not depend on the
confidentiality or integrity of the carriers. Carriers may choose to
provide some level of protection, but this is secondary to the
primary responsibility of the end users to protect themselves.
6.2 インターネットキャリアががすべてのトラフィックのプライバシと認証
性を守ることは大いに望ましいですが、これは構築の必要条件ではありませ
ん。機密性と認証はエンドユーザの責任であり、そしてエンドユーザの使う
プロトコルに実装されなくてはなりません。エンドがキャリアの機密性や完
全性に依存するべきではありません。キャリアがいくらかの保護のレベルを
供給すると決めてもよいですが、しかしこれはエンドが自身を守る主たる責
任に対して二の次です。
6.3 Wherever a cryptographic algorithm is called for in a protocol,
the protocol should be designed to permit alternative algorithms to
be used and the specific algorithm employed in a particular
implementation should be explicitly labeled. Official labels for
algorithms are to be recorded by the IANA.
6.3 暗号アルゴリズムがプロトコルで必要とされるなら、プロトコルは代わ
りのアルゴリズムが使えるように設計されるべきです、そして特定の実装で
使用された特定のアルゴリズムは明確にラベルを付けるべきです。アルゴリ
ズムの公式のラベルはＩＡＮＡによって記録されるはずです。
(It can be argued that this principle could be generalised beyond the
security area.)
（この原則がセキュリティエリアを越えて一般化できると論じることができ
ます。）
6.4 In choosing algorithms, the algorithm should be one which is
widely regarded as strong enough to serve the purpose. Among
alternatives all of which are strong enough, preference should be
given to algorithms which have stood the test of time and which are
not unnecessarily inefficient.
6.4 アルゴリズムの選択において、広く目的を満たすのに、アルゴリズムは
十分強いと見なされるものであるべきです。その十分に強い選択の中から、
時間テストを満足し不必要に非能率的ではないアルゴリズムに優先が与えら
れるべきです。
6.5 To ensure interoperation between endpoints making use of security
services, one algorithm (or suite of algorithms) should be mandated
to ensure the ability to negotiate a secure context between
implementations. Without this, implementations might otherwise not
have an algorithm in common and not be able to communicate securely.
6.5 セキュリティサービスを利用してエンドエンド間の相互運用を保証する
ために、が、実装間のセキュリティコンテキスト交渉の成功を保証するため
に、１つのアルゴリズム（あるいはアルゴリズム群）が義務化されるべきで
す。これがなければ、実装間に共通アルゴリズムがなく、安全な通信ができ
ないかもしれません。
Acknowledgements
謝辞
This document is a collective work of the Internet community,
published by the Internet Architecture Board. Special thanks to Fred
Baker, Noel Chiappa, Donald Eastlake, Frank Kastenholz, Neal
McBurnett, Masataka Ohta, Jeff Schiller and Lansing Sloan.
この文書は、インターネット体系委員会によって出版されて、インターネッ
ト共同体の共同仕事です。Fred BakerとNoel ChiappaとDonald Eastlakeと
Frank KastenholzとNeal McBurnettとMasataka OhtaとJeff Schillerと
Lansing Sloanに特に感謝します。
References
参考文献
Note that the references have been deliberately limited to two
fundamental papers on the Internet architecture.
参考文献が故意にインターネット構築についての２つの基本的な文書に限定
されていたことを注意を払ってください。
[Clark] The Design Philosophy of the DARPA Internet Protocols,
D.D.Clark, Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, August 1988,
pages 106-114 (reprinted in ACM CCR Vol 25, Number 1, January 1995,
pages 102-111).
[Saltzer] End-To-End Arguments in System Design, J.H. Saltzer,
D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November 1984, pp
277-288.
Security Considerations
セキュリティの考察
Security issues are discussed throughout this memo.
セキュリティ問題がこの文書で論じられます。
Editor's Address
編集者アドレス
Brian E. Carpenter
Group Leader, Communications Systems
Computing and Networks Division
CERN
European Laboratory for Particle Physics
1211 Geneva 23, Switzerland
Phone: +41 22 767-4967
Fax: +41 22 767-7155
EMail: brian@dxcoms.cern.ch