この文書はRFC2219の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


Network Working Group                                        M. Hamilton
Request for Comments: 2219                       Loughborough University
BCP: 17                                                        R. Wright
Category: Best Current Practice             Lawrence Berkeley Laboratory
                                                            October 1997


                Use of DNS Aliases for Network Services
                ネットワークサービスへのDNS別名の利用

Status of this Memo
この文書の状態


   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.
   このドキュメントはインターネット共同体にインターネットの現在の最良の
   実践を指定して、そして改良のために議論と提案を求めます。このメモの配
   布は無制限です。

Abstract
概要

   It has become a common practice to use symbolic names (usually
   CNAMEs) in the Domain Name Service (DNS - [RFC-1034, RFC-1035]) to
   refer to network services such as anonymous FTP [RFC-959] servers,
   Gopher [RFC-1436] servers, and most notably World-Wide Web HTTP
   [RFC-1945] servers.  This is desirable for a number of reasons.  It
   provides a way of moving services from one machine to another
   transparently, and a mechanism by which people or agents may
   programmatically discover that an organization runs, say, a World-
   Wide Web server.
   それはドメインネームサービス(DNS−[RFC-1034, RFC-1035])で、匿名
   のFTP[RFC-959]サーバーや、 Gopher[RFC-1436]サーバーや、最も顕著
   にWorld Wide Web HTTP[RFC-1945]サーバーのようなネットワークサービス
   を参照するのに、シンボル名(通常CNAME)を使うために普通の行動になった。
   これは多くの理由で望ましいです。それはサービスを他のマシンに動かす際
   に透過的になし、人間やエージェントが機械的に組織の動かす、例えばWorld
   Wide Webサービスを発見するよいメカニズムを供給します。

   Although this approach has been almost universally adopted, there is
   no standards document or similar specification for these commonly
   used names.  This document seeks to rectify this situation by
   gathering together the extant 'folklore' on naming conventions, and
   proposes a mechanism for accommodating new protocols.
   このアプローチが広く一般に採用されたが、これらの一般に使われた名前の
   標準文書や類似の仕様書がありません。この文書は命名規定に現存する「風
   習」を集めこの状態の改善を努め、新しいプロトコルを受け入れる機構を提
   案します。

   It is important to note that these naming conventions do not provide
   a complete long term solution to the problem of finding a particular
   network service for a site.  There are efforts in other IETF working
   groups to address the long term solution to this problem, such as the
   Server Location Resource Records (DNS SRV) [RFC-2052] work.
   これらの命名規定はあるサイトのネットワークサービスを見つける問題の完
   全な長期的な解決を提供しないことを指摘することは重要です。他のIET
   Fワークグループでの、サーバー位置資源レコード(DNS SRV)[RFC-2052]
   の仕事のようなに、問題に対する長期の解を扱う努力があります。

1. Rationale
1. 原理

   In order to locate the network services offered at a particular
   Internet domain one is faced with the choice of selecting from a
   growing number of centralized databases - typically Web or Usenet
   News "wanderers", or attempting to infer the existence of network
   services from whatever DNS information may be available.  The former
   approach is not practical in some cases, notably when the entity
   seeking service information is a program.
   あるインターネットドメインの特定の提供するネットワークサービスの場所
   を突き止めるために、典型的にウェブやネットニュース「放浪者」、あるい
   はDNS情報が使ってネットワークサービスを探す試みなど、増加し続ける
   中央集権化データベースから選択する場面に直面しています。前の方法はあ
   る場合、明らかにサービス情報を探しているのがプログラムである場合、に
   は実際的でありません。

   Perhaps the most visible example of the latter approach at work is in
   the case of World-Wide Web HTTP servers.  It is common practice to
   try prefixing the domain name of an organization with "http://www."
   in order to reach its World-Wide Web site, e.g. taking "hivnet.fr"
   and arriving at "http://www.hivnet.fr."  Some popular World-Wide Web
   browsers have gone so far as to provide automatic support for this
   domain name expansion.
   多分後の方法の最も目に見える例はWorld Wide Web HTTPサーバーの場合です。
   普通の人は組織のドメイン名の前に"http://www."を付けてそのWorld Wide
   Webサイトに到達します、例えば"hivnet.fr"を得て"http://www.hivnet.fr."
   に到着するなどです。ある人気が高いWorld Wide Webブラウザがこのドメイ
   ン名拡大の自動的なサポートを供給しました。

   Ideally, the DNS or some complementary directory service would
   provide a means for programs to determine automatically the network
   services which are offered at a particular Internet domain, the
   protocols which are used to deliver them, and other technical
   information.  Unfortunately, although much work has been done to
   develop said directory service technologies and to define new types
   of DNS resource record to provide this type of information, there is
   no widely agreed upon or widely deployed solution to the problem -
   except in a small number of cases.
   理想的には、DNSやいくつかの補足的なディレクトリサービスが自動的に、
   特定のインターネットドメインと転送プロトコルと他の技術情報から、提供
   するネットワークサービスを決定するプログラムを供給するでしょう。こう
   いったディレクトリサービスを開発し、この種の情報を供給する新しいタイ
   プの資源レコードを定義するたくさんの仕事がされましたが、不幸にも、広
   く合意されないか、少数の場合以外の広い問題を解決できませんでした。

   The first case is where the DNS already provides a lookup capability
   for the type of information being sought after.  For example: Mail
   Exchanger (MX) records specify how mail to a particular domain should
   be routed [RFC-974], the Start of Authority (SOA) records make it
   possible to determine who is responsible for a given domain, and Name
   Server (NS) records indicate which hosts provide DNS name service for
   a given domain.
   最初の事例はDNSがすでに検索を供給する情報のタイプを探す能力です。
   例えば:メール交換(MX)レコードは特定のドメインへのメールが経路を明
   示的に決め[RFC-974]、権威の開始(SOA)レコードはあるドメインに関して責
   任があるか決定可能にし、ネームサーバ(NS)レコードがどのホストが所定
   のドメインのDNSネームサービスを提供するか示します。

   The second case is where the DNS does not provide an appropriate
   lookup capability, but there is some widely accepted convention for
   finding this information.  Some use has been made of Text (TXT)
   [RFC-1035] records in this scenario, but in the vast majority of
   cases a Canonical Name (CNAME) or Address (A) record pointer is used
   to indicate the host or hosts which provide the service.  This
   document proposes a slight formalization of this well-known alias
   approach.
   2番目の事例は情報発見にDNSが適切な検索能力を供給しないが、ある広
   く受け入れられた習慣がある所です。ある使用のためテキスト(TXT)
   [RFC-1035]レコードから作られていました、しかし多数の場合標準名
   (CNAME)やアドレス(A)レコードポインタがホストやサービスを供給する
   ホストを示すために使われます。この文書はこのよく知られている別名方法
   の簡単な形式化を提案します。

   It should be noted that the DNS provides a Well Known Services (WKS)
   [RFC-1035] lookup capability, which makes it possible to determine
   the network services offered at a given domain name.  In practice
   this is not widely used, perhaps because of the absence of a suitable
   programming interface.  Use of WKS for mail routing was deprecated in
   the Host Requirements specification [RFC-1123] in favour of the MX
   record, and in the long term it is conceivable that SRV records will
   supersede both WKS and MX.
   DNSがあるドメインのネットワークサービスの決定を可能にする既知サー
   ビス(WKS)[RFC-1035]検索を供給することを指摘します。多分適当なプロ
   グラムインタフェースの欠如のため、実際にはこれは広く使われません。ホ
   スト要求仕様書[RFC-1123]でメールルーティングでMXレコードを支持しWKSの
   使用が廃止され、そして長期的にSRVレコードがWKSとMXの両方の代わりにな
   ると想像可能です。

2. A generic framework
2. 一般的な骨組み

   Our approach to dealing with aliases for protocols is
   straightforward. We define a standard set of DNS aliases for the most
   popular network services that currently exist (see the "Special
   Cases" section below). For protocols that are not explicitly listed
   in this document, the protocol specification must propose a name.
   我々の、プロトコルに別名を使う方法は簡単です。我々は現在存在する(下
   記の「特別なケース」章を参照)最も人気が高いネットワークサービスのD
   NS別名の標準セットを定義します。この文書で明示的にリストアップされ
   ないプロトコルのについては、プロトコル仕様書で名前を提案しなくてはな
   りません。

3. Special cases
3. 特別な場合

   Special Cases:
   特別な場合
        -----------------------------------------------------------
        Alias     Service
        別名      サービス
        -----------------------------------------------------------
        archie    archie [ARCHIE]
        finger    Finger [RFC-1288]
        ftp       File Transfer Protocol [RFC-959]
        gopher    Internet Gopher Protocol [RFC-1436]
        ldap      Lightweight Directory Access Protocol [RFC-1777]
        mail      SMTP mail [RFC-821]
        news      Usenet News via NNTP [RFC-977]
        ntp       Network Time Protocol [RFC-1305]
        ph        CCSO nameserver [PH]
        pop       Post Office Protocol [RFC-1939]
        rwhois    Referral WHOIS [RFC-1714]
        wais      Wide Area Information Server [RFC-1625]
        whois     NICNAME/WHOIS [RFC-954]
        www       World-Wide Web HTTP [RFC-1945]
        -----------------------------------------------------------

4. (Ab)Use of the DNS as a directory service
4. ディレクトリサービスとしてのDNSの使用

   The widespread use of these common aliases effectively means that it
   is sometimes possible to "guess" the domain names associated with an
   organization's network services, though this is becoming more
   difficult as the number of organizations registered in the DNS
   increases.
   これらの共通の別名の広範囲にわたる使用は、DNSで登録された組織の数
   が増加するにつれてより難しくなっるが、効率的に組織のネットワークサー
   ビスと結び付けられたドメイン名を「推測する」ことが可能であることを意
   味します。

   It should be understood by implementors that the existence of a DNS
   entry such as
   例えば次のようなDNS項目は、World Wide Webサービスの登録になるので
   はないと実装者は理解するべきです

        www.hivnet.fr

   does not constitute a registration of a World-Wide Web service.
   There is no requirement that the domain name resolve to an IP address
   or addresses.  There is no requirement that a host be listening for
   HTTP connections, or if it is, that the HTTP server be running on
   port 80.  Finally, even if all of these things are true, there can be
   no guarantee that the World-Wide Web server will be prepared to honor
   requests from arbitrary clients.
   ドメイン名がIPアドレスを解決するという必要条件がありません。ホスト
   はHTTPサーバ接続を待っていなければならないという要求条件はないし、
   HTTPサーバーが動いていてもポート80上で動かなければならないという必
   要条件がありません。最終的に、HTTPがポート80で動いていても、
   World Wide Webサーバーが任意のクライアントからリクエストに回答を与え
   る保証があり得ません。

   Having said this, the aliases do provide useful "hints" about the
   services offered.  We propose that they be taken in this spirit.
   はっきり言って、別名は提供サービスに関する有用な「助言」を供給します。
   我々はこの精神で行われることを提案します。

   The conventions described in this document are, essentially, only
   useful when the organization's domain name can be determined - e.g.
   from some external database.  A number of groups, including the IETF,
   have been working on ways of finding domain names given a set of
   information such as organization name, location, and business type.
   It is hoped that one or more of these will eventually make it
   possible to augment the basic lookup service which the DNS provides
   with a more generalized search and retrieval capability.
   この文書で記述された議論は本質的に、例えば何かの外部のデータベースで
   組織のドメイン名が決定されることができる時だけ、有効です。IETFを
   含む多くのグループが、組織名や場所とビジネスタイプのような情報からド
   メイン名を見つける方法の仕事をしていましす。これら仕事の多くが結局は
   DNSの探索と検索能力をより一般化して提供する基本的な検索サービスに
   なる可能性が希望されます。

5. DNS server configuration
5. DNSサーバ設定

   In the short term, whilst directory service technology and further
   types of DNS resource record are being developed, domain name
   administrators are encouraged to use these common names for the
   network services they run.  They will make it easier for outsiders to
   find information about your organization, and also make it easier for
   you to move services from one machine to another.
   短期に、ディレクトリサービス技術と新しいタイプのDNS資源レコードが
   開発されている間、ドメイン名管理者がネットワークサービスのために上記
   名称を使うよう奨励されます。これらは部外者に組織の情報を見つけやすく
   し、サービスを他の機械に動かしやすくもするでしょう。

   There are two conventional approaches to creating these DNS entries.
   One is to add a single CNAME record to your DNS server's
   configuration, e.g.
   これらのDNS項目を作ることへの2つ便利な方法があります。1つはDN
   Sサーバ設定にひとつのCNAMEレコードを加える事です、例えば。

        ph.hivnet.fr. IN CNAME baby.hivnet.fr.

   Note that in this scenario no information about ph.hivnet.fr should
   exist in the DNS other than the CNAME record. For example,
   ph.hivnet.fr could not contain a MX record.
   このシナリオでph.hivnet.frの情報がCNAMEレコード以外のDNSに存在する
   べきではないことに注意してください。例えば、ph.hivnet.frにMXレコード
   を含める事ができません。

   An alternative approach would be to create an A record for each of
   the IP addresses associated with ph.hivnet.fr, e.g.
   他の方法が以下の様にph.hivnet.frと関連するIPアドレスのそれぞれのA
   レコードを作る事です。

        ph.hivnet.fr. IN A 194.167.157.2

   It isn't a simple matter of recommending CNAMEs over A records. Each
   site has it's own set of requirements that may make one approach
   better than the other. RFC 1912 [RFC-1912]  discusses some of the
   configuration issues involved in using CNAMEs.
   AレコードよりCNAMEを推薦することは単純な問題ではありません。各サイト
   にはそれぞれの要求条件があり、どちらかの方法が他よりよいでしょう。
   RFC1912[RFC-1912]がCNAMEを使う際の複雑な設定の問題を論じます。

   Recent DNS server implementations provide a "round-robin" feature
   which causes the host's IP addresses to be returned in a different
   order each time the address is looked up.
   最近のDNSサーバー実装がホストのIPアドレスを、アドレスが検索され
   るたびに、異なった順序で返す「ラウンドロビン」機能を供給します。

   Network clients are starting to appear which, when they encounter a
   host with multiple addresses, use heuristics to determine the address
   to contact - e.g. picking the one which has the shortest round-trip-
   time.  Thus, if a server is mirrored (replicated) at a number of
   locations, it may be desirable to list the IP addresses of the mirror
   servers as A records of the primary server.  This is only likely to
   be appropriate if the mirror servers are exact copies of the original
   server.
   ネットワーククライアントはホストに複数のアドレスがあるのを見つけると、
   例えば往復遅延時間の見積もりに基づいて、どのアドレスを使うべきか決め
   ます。もし多くの場所にサーバーのミラー(複製)があるなら、主サーバー
   のAレコードにミラーサーバーのIPアドレスを記録するのが望ましいかも
   しれません。これは、もしミラーサーバーがオリジナルサーバーの正確なコ
   ピーである場合だけ、適切な可能性が高いだけです。

6. Limitations of this approach
6. この方法の限界

   Some services require that a client have more information than the
   server's domain name.  For example, an LDAP client needs to know a
   starting search base within the Directory Information Tree in order
   to have a meaningful dialogue with the server.  This document does
   not attempt to address this problem.
   あるサービスはクライアントにサーバードメイン名より多くの情報を持つこ
   とを要求します。例えば、LDAPクライアントがサーバと有意義に通信をする
   ためにはディレクトリインフォメーションツリー内で探索をはじめるベース
   を知る必要があります。この文書はこの問題を扱おうと試みません。

7. CCSO service name
7. CCSOサービス名

   There are currently at least three different aliases in common use
   for the CCSO nameserver - e.g. "ph", "cso" and "ns".  It would appear
   to be in everyone's interest to narrow the choice of alias down to a
   single name.  "ns" would seem to be the best choice since it is the
   most commonly used name.  However, "ns" is also being used by DNS to
   point to the DNS server.  In fact, the most prevalent use of "ns" is
   to name DNS servers.  For this reason, we suggest the use of "ph" as
   the best name to use for CCSO nameservers.
   CCSOネームサーバの一般的な用途に現在少なくとも3つの異なった別名があ
   ります− 例えば"ph"と"cso"と"ns"です。どうやって別名を1つに絞るかに
   皆の興味があるように思われるでしょう。"ns"が最も一般に使われる名前な
   ので、最も良い選択と思われるでしょう。しかし"ns"がDNSサーバを示す
   ためにDNSで使われています。実際"ns"は最も流行っている用途はDNS
   サーバ名です。このために、我々はCCSOネームサーバに使うべき最も良い名
   前として"ph"の使用を提案します。

   Sites with existing CCSO servers using some of these aliases may find
   it desirable to use all three.  This increases the likelihood of the
   service being found.
   これらの別名のどれかを使っている既存のCCSOサーバーを持つサイトが3つ
   すべてを使うのが望ましいと考えるかもしれません。これはサービスの発見
   可能性を増やします。

   As noted earlier, implementations should be resilient in the event
   that the name does not point to the expected service.
   前に述べた通り、名前が予想されるサービスを指し示さない場合に、問題を
   起こさないように実装すべきです。

8. Security Considerations
8. セキュリティの考察

   The DNS is open to many kinds of "spoofing" attacks, and it cannot be
   guaranteed that the result returned by a DNS lookup is indeed the
   genuine information.  Spoofing may take the form of denial of
   service, such as directing of the client to a non-existent address,
   or a passive attack such as an intruder's server which masquerades as
   the legitimate one.
   DNSは多くの種類の「スプーフ(だまし)」攻撃に弱いです、そしてDN
   S検索によって返された結果が本当に本物の情報であることを保証できませ
   ん。スプーフは、クライアントを指揮して、存在しないアドレスでのサービ
   ス拒否や、合法的なふりをする侵入者のサーバーのような受動的な攻撃に導
   くかもしれません。

   Work is ongoing to remedy this situation insofar as the DNS is
   concerned [RFC-2065].  In the meantime it should be noted that
   stronger authentication mechanisms such as public key cryptography
   with large key sizes are a pre-requisite if the DNS is being used in
   any sensitive situations.  Examples of these would be on-line
   financial transactions, and any situation where privacy is a concern
   - such as the querying of medical records over the network.  Strong
   encryption of the network traffic may also be advisable, to protect
   against TCP connection "hijacking" and packet sniffing.
   仕事が、 DNSに関する限りで、この状態を修復する仕事が進行中です
   [RFC-2065]。その間、もしDNSが機密性が高い状態で使われているなら、
   大きい鍵サイズの公開鍵暗号のようなより強い認証メカニズムが必要条件で
   あることを指摘するべきです。これらの例はオンラインの金融の取引やプラ
   イバシーが心配される状況、例えばネットワーク上に医学レコードなどであ
   りえるでしょう。ネットワークトラフィックの難解な暗号がTCP接続「ハ
   イジャック」とパケット探知から保護するのに賢明であるかもしれません。

9. Conclusions
9. 結論

   The service names listed in this document provide a sensible set of
   defaults which may be used as an aid in determining the hosts which
   offer particular services for a given domain name.
   この文書でリストアップされたサービス名は所定のドメイン名に特定のサー
   ビスを提供するホストを決定する手助けに用いられるかもしれないデフォル
   ト設定を提供します。

   This document has noted some exceptions which are either inherently
   unsuitable for this treatment, or already have a substantial
   installed base using alternative aliases.
   この文書は、この方法が本質的に不適当なある例外と、別の別名をすでに使っ
   ていることを指摘しました。

10. Acknowledgements
10. 謝辞

   Thanks to Jeff Allen, Tom Gillman, Renato Iannella, Thomas
   Lenggenhager, Bill Manning, Andy Powell, Sri Sataluri, Patrik
   Faltstrom, Paul Vixie and Greg Woods for their comments on draft
   versions of this document.
   このドラフトバージョンのコメントに対してJeff Allen, Tom Gillman,
   Renato Iannella, Thomas Lenggenhager, Bill Manning, Andy Powell,
   Sri Sataluri, Patrik Faltstrom, Paul Vixie and Greg Woods に感謝し
   ます。

   This work was supported by UK Electronic Libraries Programme (eLib)
   grant 12/39/01, the European Commission's Telematics for Research
   Programme grant RE 1004, and U. S. Department of Energy Contract
   Number DE-AC03-76SF00098.
   この仕事はUK電子図書館プログラム(eLib)認可12/39/01、欧州共同
   体Telematicsは研究プログラム交付金RE 1004とU.S.エネルギー省契約番
   号DE-AC03-76SF00098によって支援されました。

11. References
11. 参考文献

   Request For Comments (RFC) documents are available from
   <URL:ftp://ftp.internic.net/rfc> and numerous mirror sites.
   リクエストフォーコメント(RFC)文書は<URL:ftp://ftp.internic.net/rfc>
   と多数のミラーサイトで利用可能です。

   [ARCHIE]    A. Emtage, P. Deutsch. "archie - An Electronic
               Directory Service for the Internet", Winter Usenix
               Conference Proceedings 1992.  Pages 93-110.

   [PH]        R. Hedberg, S. Dorner, P. Pomes.  "The CCSO
               Nameserver (Ph) Architecture", Work in Progress.

   [RFC-768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
               August 1980.

   [RFC-793]   Postel, J., "Transmission Control Protocol", STD 7,
               RFC 793, September 1981.

   [RFC-821]   Postel, J., "Simple Mail Transfer Protocol", STD 10,
               RFC 821, August 1982.

   [RFC-954]   Harrenstien, K., Stahl, M., and E. Feinler,
               "NICNAME/WHOIS", RFC 954, October 1985.

   [RFC-959]   Postel, J., and J.K. Reynolds, "File Transfer
               Protocol", STD 9, RFC 959, October 1985.

   [RFC-974]   Partridge, C., "Mail routing and the domain
               System", STD 14, RFC 974,  January 1986.

   [RFC-977]   Kantor, B., and P. Lapsley, "Network News Transfer
               Protocol", RFC 977, February 1986.

   [RFC-1034]  Mockapetris, P., "Domain names - concepts and
               facilities", STD 13, RFC 1034, November 1987.

   [RFC-1035]  Mockapetris, P., "Domain names - implementation
               and specification", STD 13, RFC 1035, November 1987.

   [RFC-1123]  Braden, R., "Requirements for Internet hosts -
               application and support", STD 3, RFC 1123, October 1989.

   [RFC-1288]  Zimmerman, D., "The Finger User Information
               Protocol", RFC 1288, December 1992.

   [RFC-1305]  Mills, D., "Network Time Protocol (Version 3)
               Specification, Implementation", RFC 1305,  March  1992.

   [RFC-1436]  Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
               Torrey, D., and B. Albert, "The Internet Gopher Protocol
               (a distributed document search and retrieval protocol)",
               RFC 1436, March 1993.

   [RFC-1590]  Postel, J., "Media Type Registration Procedure",
               RFC 1590, March 1994.

   [RFC-1625]  St. Pierre, M., Fullton, J., Gamiel, K., Goldman, J.,
               Kahle, B., Kunze, J., Morris, H., and F. Schiettecatte,
               "WAIS over Z39.50-1988", RFC 1625, June 1994.

   [RFC-1700]  Reynolds, J.K., and J. Postel,  "ASSIGNED NUMBERS",
               STD 2, RFC 1700, October 1994.

   [RFC-1714]  Williamson, S., and M. Kosters, "Referral Whois
               Protocol (RWhois)", RFC 1714, November 1994.

   [RFC-1777]  Yeong, W., Howes, T., and S. Kille, "Lightweight
               Directory Access Protocol", RFC 1777, March 1995.

   [RFC-1912]  Barr, D., "Common DNS Operational and Configuration
               Errors", RFC 1912, Feburary 1996.

   [RFC-1939]  Myers, J., and M. Rose, "Post Office Protocol - Version
               3", STD 53, RFC 1939, May 1996.

   [RFC-1945]  Berners-Lee, T., Fielding, R., and H. Nielsen,
               "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May
               1996.

   [RFC-2052]  Gulbrandsen, A., and P. Vixie, "A DNS RR for specifying
               the location of services (DNS SRV)", RFC 2052, October
               1996.

   [RFC-2065]  Eastlake, D., and C. Kaufman, "Domain Name System
               Security Extensions", RFC 2065, January 1997.

12. Authors' Addresses
12. 著者のアドレス

   Martin Hamilton
   Department of Computer Studies
   Loughborough University of Technology
   Leics. LE11 3TU, UK

   EMail: m.t.hamilton@lut.ac.uk


   Russ Wright
   Information & Computing Sciences Division
   Lawrence Berkeley National Laboratory
   1 Cyclotron Road, Berkeley
   Mail-Stop: 50A-3111
   CA 94720, USA

   EMail: wright@lbl.gov

[]Japanese translation by Ishida So