RFC1649 日本語訳

Network Working Group                                          R. Hagens
Request for Comments: 1649             Advanced Network & Services, Inc.
Category: Informational                                        A. Hansen
                                                                 UNINETT
                                                               July 1994

Hagensがコメントのために要求するワーキンググループR.をネットワークでつないでください: 1649年の高度なネットワークとサービスInc.カテゴリ: 情報のA.ハンセンUNINETT1994年7月

         Operational Requirements for X.400 Management Domains
                        in the GO-MHS Community

碁-MHS共同体のX.400管理ドメインのための操作上の要件

Status of this Memo

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

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

1.  Introduction

1. 序論

   There are several large, operational X.400 services currently
   deployed. Many of the organizations in these services are connected
   to the Internet.  A number of other Internet-connected organizations
   are beginning to operate internal X.400 services (for example, U.S.
   government organizations following U.S. GOSIP).  The motivation for
   this document is to foster a Global Open Message Handling System
   (GO-MHS) Community that has full interoperability with the existing
   E-mail service based on RFC-822 (STD-11).

現在配備されているいくつかの大きくて、操作上のX.400サービスがあります。 これらのサービスにおける組織の多くがインターネットに接続されます。 他の多くのインターネットで接続された組織が内部のX.400サービス(例えば、U.S. GOSIPに続く米国の政府機関)を操作し始めています。 このドキュメントに関する動機は存在がある最大限のインターオペラビリティにRFC-822(STD-11)に基づくサービスをメールさせるGlobalオープンMessage Handling System(GO-MHS)共同体を伸ばすことです。

   The goal of this document is to unite regionally operated X.400
   services on the various continents into one GO-MHS Community (as seen
   from an end-user's point of view).  Examples of such regional
   services are the COSINE MHS Service in Europe and the XNREN service
   in the U.S.

このドキュメントの目標は様々な大陸で地方的に運転されたX.400サービスを1GO-MHS Communityと結合させる(エンドユーザの観点から見られるように)ことです。 そのような地方のサービスに関する例は、ヨーロッパのCOSINE MHS Serviceと米国でのXNRENサービスです。

   A successful GO-MHS Community is dependent on decisions at both the
   national and international level. National X.400 service providers
   are responsible for the implementation of the minimum requirements
   defined in this document. In addition to these minimum requirements,
   national requirements may be defined by each national service
   provider.

うまくいっているGO-MHS Communityは国家的、そして、国際的なレベルで決定に依存しています。 国家のX.400サービスプロバイダーは本書では定義された必要最小限の実現に責任があります。 これらの必要最小限に加えて、国家の要件はそれぞれの徴兵プロバイダーによって定義されるかもしれません。

   This document refers to other documents which are published as RFCs.
   These documents are [1], [2], [3], [4], [6] and [7] in the reference
   list.

このドキュメントはRFCsとして発表される他のドキュメントを示します。 これらのドキュメントは、参考文献一覧表の[1]と、[2]と、[3]と、[4]と、[6]と[7]です。

   This document handles issues concerning X.400 1984 and X.400 1988 to
   1984 downgrading. Issues concerning pure X.400 1988 are left for
   further study.

このドキュメントはX.400 1984とX.400 1988年から1984格下げに関して問題を扱います。 純粋なX.400 1988に関する問題はさらなる研究に発たれます。

Hagens & Hansen                                                 [Page 1]

RFC 1649               X.400 Management in GO-MHS              July 1994

碁-MHS7月1994のHagensとハンセン[1ページ]RFC1649X.400管理

   We are grateful to Allan Cargille and Lawrence Landweber for their
   input and guidance on this paper. This paper is also a product of
   discussions in the IETF X.400 Operations WG and the RARE WG-MSG
   (former RARE WG1 (on MHS)).

私たちはこの紙でアランCargilleとローレンスLandweberに彼らの入力と指導に感謝しています。 また、この紙はIETF X.400 Operations WGとRARE WG-MSG(元RARE WG1(MHSの))での議論の成果です。

1.1.  Terminology

1.1. 用語

   This document defines requirements, recommendations and conventions.
   Throughout the document, the following definitions apply: a
   requirement is specified with the word shall.  A recommendation is
   specified with the word should.  A convention is specified with the
   word might.  Conventions are intended to make life easier for RFC-822
   systems that don't follow the host requirements.

このドキュメントは要件、推薦、およびコンベンションを定義します。 ドキュメント中では、以下の定義は適用されます: 要件で指定されます。単語はそうするでしょう。 推薦で指定されます。単語はそうするべきです。 コンベンションは力という単語で指定されます。 コンベンションがホスト要件に続かないRFC-822システムのために暮らしにゆとりを持たせることを意図します。

1.2.  Profiles

1.2. プロフィール

   Different communities have different profile requirements.  The
   following is a list of such profiles.

異なった共同体には、異なったプロフィール要件があります。 ↓これはそのようなプロフィールのリストです。

    o U.S. GOSIP - unspecified version
    o ENV - 41201
    o UK GOSIP for X.400(88)

o X.400のためのU.S. GOSIP--不特定のバージョンo ENV--41201○UK GOSIP(88)

   In the case when mail traffic is going from the RFC-822 mail service
   to the GO-MHS Community, the automatic return of contents when mail
   is non-delivered should be requested by RFC 1327 gateways and should
   be supported at the MTA that generates the non-delivery report.
   However, it should be noted that this practice maximizes the cost
   associated with delivery reports.

郵便運送がGO-MHS Communityに対するRFC-822メールサービスから行くことであるときの場合では、メールが非述べられるとき、コンテンツの自動復帰は、RFC1327ゲートウェイによって要求されるべきであり、非配送レポートを作るMTAで支持されるべきです。 しかしながら、この習慣が配送レポートに関連している費用を最大にすることに注意されるべきです。

2.  Architecture of the GO-MHS Community

2. 碁-MHS共同体の構造

   In order to facilitate a coherent deployment of X.400 in the GO-MHS
   Community it is necessary to define, in general terms, the overall
   structure and organization of the X.400 service.  This section is
   broken into several parts which discuss management domains, lower
   layer connectivity issues, and overall routing issues.

GO-MHS CommunityでのX.400の一貫性を持っている展開を容易にするために、あいまいな言葉でX.400サービスの全体的な構造と組織を定義するのが必要です。 管理ドメイン、下層接続性問題、および総合的なルーティング問題について議論する数個の部品がこのセクションに細かく分けられます。

   The GO-MHS Community will operate as a single MHS community, as
   defined in reference [1].

GO-MHS Communityは単一のMHS共同体参照[1]で定義されるように作動するでしょう。

2.1.  Management Domains

2.1. 管理ドメイン

   The X.400 model supports connectivity between communities with
   different service requirements; the architectural vehicle for this is
   a Management Domain. Management domains are needed when different
   administrations have different specific requirements.  Two types of
   management domains are defined by the X.400 model: an Administration

X.400モデルは異なったサービス要件で共同体の間の接続性を支持します。 これのための建築乗り物はManagement Domainです。 異なった政権に異なった決められた一定の要求があると、管理ドメインが必要です。 2つのタイプの管理ドメインはX.400モデルによって定義されます: 政権

Hagens & Hansen                                                 [Page 2]

RFC 1649               X.400 Management in GO-MHS              July 1994

碁-MHS7月1994のHagensとハンセン[2ページ]RFC1649X.400管理

   Management Domain (ADMD) and a Private Management Domain (PRMD).

管理ドメイン(ADMD)と自営業ドメイン(PRMD)。

   Throughout the world in various countries there are different
   organizational policies for MDs.  All of these policies are legal
   according to the X.400 standard.  Currently, X.400 service providers
   in a country (inside or outside the GO-MHS Community), are organized
   as:

様々な国の世界中に、MDsのための異なった組織的な方針があります。 X.400規格に従って、これらの方針のすべてが法的です。 現在の、国(GO-MHS CommunityかGO-MHS Communityの外の)のX.400サービスプロバイダーは以下として組織化されます。

    a) One or several ADMDs.
    b) One or several PRMDs and with no ADMDs present in
       the country, or that are not connected to any ADMD.
    c) One or several PRMDs connected to one or several ADMDs.

a) 1か数個ADMDs. b) 1つか数個のPRMDsとどんなADMD. cへの国、またはつなげられなかったそれの現在のADMDs、も) 1か数個のPRMDsが1か数個のADMDsに接続しました。

   Or in combinations of a), b) and c).  At this stage it is not
   possible to say which model is the most effective.  Thus, the GO-MHS
   Community shall allow every model.

または、a)、b)、およびc)の組み合わせで。 現在のところ、どのモデルが最も有能であるかを言うのは可能ではありません。 したがって、GO-MHS Communityはすべてのモデルを許容するものとします。

2.2.  The RELAY-MTA

2.2. MTAをリレーします。

   The X.400 message routing decision process takes as input the
   destination O/R address and produces as output the name (and perhaps
   connection information) of the MTA who will take responsibility of
   delivering the message to the recipient. The X.400 store and forward
   model permits a message to pass through multiple MTAs.  However, it
   is generally accepted that the most efficient path for a message to
   take is one where a direct connection is made from the originator to
   the recipient's MTA.

過程が取るX.400メッセージルーティング決定は、目的地O/Rアドレスを入力して、メッセージを受取人に送るのについて責任を取るMTAという名前(そして、恐らく接続情報)を出力するとき、生産されます。 X.400店と前進のモデルは複数のMTAsを通り抜けるメッセージを可能にします。 しかしながら、一般に、取るメッセージのための最も効率的な経路がダイレクト接続が創始者から受取人のMTAまで作られているものであると受け入れます。

   Large scale deployment of X.400 in the GO-MHS Community will require
   a well deployed directory infrastructure to support routing. In the
   GO-MHS Community X.500 is considered to be the best protocol for such
   an infrastructure.  In this environment, a routing decision can be
   made by searching the directory with a destination O/R address in
   order to obtain the name of the next hop MTA. This MTA may be a
   central entry point into an MD, or it may be the destination MTA
   within an MD.

GO-MHS CommunityでのX.400の大規模展開は、掘るのを支持するためによく配備されたディレクトリインフラストラクチャを必要とするでしょう。 GO-MHS Community X.500では、そのようなインフラストラクチャのための最も良いプロトコルであると考えられます。 この環境で、次のホップMTAという名前を得るために目的地O/Rアドレスでディレクトリを捜すことによって、ルーティング決定をすることができます。 このMTAはMDへの主要なエントリー・ポイントであるかもしれませんかそれがMDの中の目的地MTAであるかもしれません。

   Deployment of X.400 without a well deployed Directory infrastructure,
   will require the use of static tables to store routing information.
   These tables (keyed on O/R addresses), will be used to map a
   destination O/R address to a next hop MTA.  In order to facilitate
   efficient routing, one could build a table that contains information
   about every MTA in every MD.  However, this table would be enormous
   and very dynamic, so this is not feasible in practice.  Therefore, it
   is necessary to use the concept of a RELAY-MTA.

井戸のないX.400の展開はディレクトリインフラストラクチャを配備して、ルーティング情報を格納するために静的なテーブルの使用を必要とするでしょう。 これらのテーブル(O/Rアドレスでは、合わせられる)が目的地O/Rアドレスを次のホップMTAに写像するのにおいて使用するでしょう。 効率的なルーティングを容易にするために、1つはあらゆるMDにあらゆるMTAの情報を保管しているテーブルを組立てるかもしれません。 しかしながら、このテーブルは、巨大であって、非常にダイナミックでしょう、したがって、これは実際には可能ではありません。 したがって、RELAY-MTAの概念を使用するのが必要です。

   The purpose of a RELAY-MTA is to act as a default entry point into an
   MD. The MTA that acts as a RELAY MTA for an MD shall be capable of

RELAY-MTAの目的はデフォルトエントリー・ポイントとしてMDに機能することです。 MDへのRELAY MTAとしての行為はできるMTA

Hagens & Hansen                                                 [Page 3]

RFC 1649               X.400 Management in GO-MHS              July 1994

碁-MHS7月1994のHagensとハンセン[3ページ]RFC1649X.400管理

   accepting responsibility for all messages that it receives that are
   destined for well-defined recipients in that MD.

受信するというそのMDの明確な受取人のために運命づけられているすべてのメッセージへの責任を引き受けます。

   The use of a RELAY-MTA for routing is defined by reference [1].
   RELAY-MTAs in the GO-MHS Community shall route according to reference
   [1].

RELAY-MTAのルーティングの使用は参照[1]で定義されます。 参照に応じて、GO-MHS CommunityのRELAY-MTAsは[1]を発送するものとします。

2.3.  Lower Layer Stack Incompatibilities

2.3. 下層スタック両立し難いこと

   A requirement for successful operation of the GO-MHS Community is
   that all users can exchange messages. The GO-MHS Community is not
   dependent on the traditional TCP/IP lower layer protocol suite.  A
   variety of lower layer suites are used as carriers of X.400 messages.

GO-MHS Communityのうまくいっている操作のための要件はすべてのユーザがメッセージを交換できるということです。 GO-MHS Communityは伝統的なTCP/IP下層プロトコル群に依存していません。 さまざまな下層スイートがX.400メッセージのキャリヤーとして使用されます。

   For example, consider Figure 1.

例えば、図1を考えてください。

     -----------------------------------------------------
     !                                                   !
     !            PRMD A                                 !
     !        --------------------                       !
     !        !   o       x      !                       !
     !        !                  !                       !
     !        !     o        w   !                       !
     !        !          z       !                       !
     !        --------------------                       !
     !                                PRMD B             !
     !                            ------------------     !
     !                            !      o     o   !     !
     !    PRMD C                  !  o             !     !
     !  ------------------        !      o     z   !     !
     !  !       o        !        !                !     !
     !  !  o        x    !        ------------------     !
     !  !     o        w !                               !
     !  !        o       !                               !
     !  ------------------                               !
     !                                                   !
     !               Key: Each character the in          !
     !                    the boxes illustrates an MTA.  !
     !                                                   !
     !                    x: TP0/RFC1006/TCP RELAY-MTA   !
     !                    w: TP4/CLNP RELAY-MTA          !
     !                    z: TP0/CONS/X.25 RELAY-MTA     !
     !                    o: MTA                         !
     -----------------------------------------------------

----------------------------------------------------- ! ! ! PRMD A!-------------------- ! ! ! o x!o w!z!-------------------- ! ! PRMD B!------------------ ! ! ! o o ! ! ! PRMD C o!------------------ ! o z!o!o x!------------------ ! ! ! o w!o!------------------ ! ! ! ! キー: 各キャラクタ、コネ!箱はMTAを例証します。 ! ! ! ! x: TP0/RFC1006/TCP RELAY-MTA!w: TP4/CLNP RELAY-MTA z!: TP0/コンズ/X.25 RELAY-MTA!o: MTA!-----------------------------------------------------

                 Figure 1: A Deployment Scenario

図1: 展開シナリオ

Hagens & Hansen                                                 [Page 4]

RFC 1649               X.400 Management in GO-MHS              July 1994

碁-MHS7月1994のHagensとハンセン[4ページ]RFC1649X.400管理

   PRMD A has three RELAY-MTAs which collectively provide support for
   the TP0/CONS/X.25, TP0/RFC1006, and TP4/CLNS stacks.  (Note: it is
   acceptable for a single RELAY-MTA to support more than one stack.
   Three RELAY-MTAs are shown in this figure for clarity.)  Thus, PRMD A
   is reachable via these stacks.  However, since PRMD B only supports
   the TP0/CONS/X.25 stack, it is not reachable from the TP0/RFC 1006 or
   the TP4/CLNS stack. PRMD C supports TP0/RFC1006 and TP4/CLNS. Since
   PRMD B and PRMD C do not share a common stack, how is a message from
   PRMD C to reach a recipient in PRMD B?

PRMD Aには、TP0/コンズ/X.25、TP0/RFC1006、およびTP4/CLNSスタックのサポートをまとめて提供する3RELAY-MTAsがあります。 (以下に注意してください。 独身のRELAY-MTAが1つ以上のスタックを支えるのは、許容できます。 3RELAY-MTAsが明快ためにこの図に示されます。) したがって、PRMD Aはこれらのスタックを通して届いています。 しかしながら、PRMD BがTP0/コンズ/X.25スタックを支えるだけであるので、それはTP0/RFC1006かTP4/CLNSスタックから届いていません。 PRMD CはTP0/RFC1006とTP4/CLNSを支持します。 PRMD BとPRMD Cが一般的なスタックを共有しないので、PRMD CからのメッセージはPRMD Bでどのように受取人に届くことになっていますか?

   One solution to this problem is to require that PRMD B implement a
   stack in common with PRMD C. However this may not be a politically
   acceptable answer to PRMD B.

この問題の1つの解決はこれがPRMD BがPRMD C.Howeverと共用してスタックを実行するのが必要であるためには、PRMD Bの政治的に許容できる答えでないかもしれないということです。

   Another solution is to implement a transport service bridge (TSB)
   between TP0/RFC 1006 in PRMD C to TP0/CONS in PRMD B.  This will
   solve the problem for PRMD C and B.  However, the lack of coordinated
   deployment of TSB technology makes this answer alone unacceptable on
   an international scale.

他の解決法はPRMD B.でPRMD CでTP0/RFC1006の間の輸送サービス(TSB)橋をTP0/コンズに実行することです。ThisはPRMD CとB.Howeverのための問題を解決して、TSB技術の連携展開の不足でこの答えだけが国際的な規模で容認できなくなります。

   The solution to this problem is to define a coordinated mechanism
   that allows PRMD B to advertise to the world that it has made a
   bilateral agreement with PRMD A to support reachability to PRMD B
   from the TP0/RFC 1006 stack.

この問題の解決はPRMD BがTP0/RFC1006スタックからPRMD Bに可到達性を支持するためにPRMD Aと共に二国間条約を作ったのは世界に広告を出すことができる連携メカニズムを定義することです。

   This solution does not require that every MTA or MD directly support
   all stacks. However, it is a requirement that if a particular stack
   is not directly supported by an MD, the MD will need to make
   bilateral agreements with other MD(s) in order to assure that
   connectivity from that stack is available.

この解決策は、あらゆるMTAかMDが直接すべてのスタックを支えるのを必要としません。 しかしながら、それは特定のスタックがMDによって直接支えられないと、MDが、そのスタックからの接続性が利用可能であることを保証するために他のMDがある二国間条約を(s)にする必要があるという要件です。

   Thus, in the case of Figure 1, PRMD B can make a bilateral agreement
   with PRMD A which provides for PRMD A to relay messages which arrive
   on either the TP4/CLNP stack or the TP0/RFC 1006 stack to PRMD B
   using the TP0/CONS stack.

したがって、図1の場合では、PRMD Bは、TP4/CLNPスタックか1006年のTP0/RFCスタックのどちらかの上でTP0/コンズスタックを使用することでPRMD Bに到着するメッセージをリレーするためにPRMD AとのPRMDに備える二国間条約をAにすることができます。

   The policies described in reference [1] define this general purpose
   solution.  It is a requirement that all MDs follow the rules and
   policies defined by reference [1].

参照[1]で説明された方針はこの汎用の解決策を定義します。 それはすべてのMDsが参照[1]で定義された規則と方針に従うという要件です。

3.  Description of GO-MHS Community Policies

3. 碁-MHS共同体方針の記述

   A GO-MD is a Management Domain in the GO-MHS Community.

GO-MDはGO-MHS CommunityのManagement Domainです。

   The policies described in this section constitute a minimum set of
   common policies for GO-MDs. They are specified to ensure
   interoperability between:

このセクションで説明された方針はGO-MDsのために最小の共通政策を構成します。 それらは、以下の間で相互運用性を確実にするために指定されます。

Hagens & Hansen                                                 [Page 5]

RFC 1649               X.400 Management in GO-MHS              July 1994

碁-MHS7月1994のHagensとハンセン[5ページ]RFC1649X.400管理

    - all GO-MDs.
    - all GO-MDs and the RFC-822 mail service (SMTP).
    - all GO-MDs and other X.400 service providers.

- すべてのGO-MDs。 - すべてのGO-MDsとRFC-822はサービス(SMTP)を郵送します。 - すべてのGO-MDsと他のX.400サービスプロバイダー。

3.1.  X.400 Address Registration

3.1. X.400アドレス登録

   An O/R address is a descriptive name for a UA that has certain
   characteristics that help the Service Providers to locate the UA.
   Every O/R address is an O/R name, but not every O/R name is an O/R
   address.  This is explained in reference [5], chapter 3.1.

O/RアドレスはService ProvidersがUAの場所を見つけるのを助けるある特性を持っているUAに、描写的である名前です。 あらゆるO/RアドレスがO/R名ですが、あらゆるO/R名もどんなO/Rアドレスであるというわけではありません。 これは参照[5]、第3.1章で説明されます。

   Uniqueness of X.400 addresses shall be used to ensure end-user
   connectivity.

X.400アドレスのユニークさは、エンドユーザの接続性を確実にするのに使用されるものとします。

   Mailboxes shall be addressed according to the description of O/R
   names, Form 1, Variant 1 (see reference [5], chapter 3.3.2). The
   attributes shall be regarded as a hierarchy of:

Variant1、O/R名、Form1の記述によると、メールボックスは記述されるものとします(参照[5]、第3.3章.2を見てください)。 属性は以下の階層構造と見なされるものとします。

    Country name (C)
    Administration domain name (ADMD)
    [Private domain name] (PRMD)
    [Organization name] (O)
    [Organizational Unit Names] (OUs)
    [Personal name] (PN)
    [Domain-defined attributes] (DDAs)

国の名前(C)管理ドメイン名(ADMD)[個人的なドメイン名](PRMD)[組織名]の(O)[組織的なUnit Names](OUs)[個人名](PN)[ドメインで定義された属性](DDAs)

   Attributes enclosed in square brackets are optional.  At least one of
   PRMD, O, OU and PN names shall be present in an O/R address. At least
   one of PN and DDA shall be present.

角括弧で同封された属性は任意です。 少なくともPRMD、O、OU、およびPN名の1つはO/Rアドレスに存在するでしょう。 少なくともPNとDDAの1つは存在するでしょう。

   In general a subordinate address element shall be unique within the
   scope of its immediately superior element. An exception is PRMD, see
   section 3.1.3.  There shall exist registration authorities for each
   level, or mechanisms shall be available to ensure such uniqueness.

一般に、下位のアドレス要素はすぐに優れた要素の範囲の中でユニークになるでしょう。 セクション3.1.3は、例外がPRMDであると考えます。 メカニズムは、そのようなユニークさを確実にするために各レベルのための登録局が存在するだろうか、または利用可能になるでしょう。

3.1.1.  Country (C)

3.1.1. 国(C)

   The values of the top level element, Country, shall be defined by the
   set of two letter country codes, or numeric country codes in ISO
   3166.

最高平らな要素の値(Country)は2つの手紙国名略号のセット、またはISO3166の数値国名略号によって定義されるものとします。

3.1.2.  Administration Management Domain (ADMD)

3.1.2. 政権管理ドメイン(ADMD)

   The values of the ADMD field are decided on a national basis.  Every
   national decision made within the GO-MHS community shall be supported
   by a GO-MD.

ADMD分野の値は全国的に見て決められます。 GO-MHS共同体の中でされたあらゆる国家的な決定がGO-MDによって支持されるものとします。

Hagens & Hansen                                                 [Page 6]

RFC 1649               X.400 Management in GO-MHS              July 1994

碁-MHS7月1994のHagensとハンセン[6ページ]RFC1649X.400管理

3.1.3.  Private Management Domain (PRMD)

3.1.3. 自営業ドメイン(PRMD)

   The PRMD values should be unique within a country.

PRMD値は国の中でユニークであるべきです。

3.1.4.  Organization (O)

3.1.4. 組織(o)

   Organization values shall be unique within the context of the
   subscribed PRMD or ADMD if there is no PRMD.  For clarification, the
   following situation is legal:

PRMDが全くなければ、組織価値は申し込まれたPRMDかADMDの文脈の中でユニークになるでしょう。 明確化において、以下の状況は法的です:

    1) C=FI; ADMD=FUMAIL; O=FUNET.
    2) C=FI; ADMD=FUMAIL; PRMD=NOKIA; O=FUNET.

1) CはFIと等しいです。 ADMD=FUMAIL。 O=FUNET。 2) CはFIと等しいです。 ADMD=FUMAIL。 PRMDはノキアと等しいです。 O=FUNET。

   In this case 1) and 2) are different addreses. (Note that 2) at this
   point is a hypotethical address). O=FUNET is a subscriber both at
   ADMD=FUMAIL, 1), and at PRMD=NOKIA, 2).

この場合、1と)2は)異なったaddresesです。 (その2に注意します) ここにhypotethicalがアドレスである、) O=FUNETはADMD=FUMAIL、1)においてPRMD=ノキア、2)において加入者です。

3.1.5.  Organizational Units (OUs)

3.1.5. 組織的なユニット(OUs)

   If used, a unique hierarchy of OUs shall be implemented. The top
   level OU is unique within the scope of the immediately superior
   address element (i.e., Organization, PRMD or ADMD).  Use of multiple
   OUs may be confusing.

使用されるなら、OUsのユニークな階層構造は実行されるものとします。 最高平らなOUはすぐに優れたアドレス要素(すなわち、Organization、PRMDまたはADMD)の範囲の中でユニークです。 複数のOUsの使用は混乱させられているかもしれません。

3.1.6.  Given Name, Initials, Surname (G I S)

3.1.6. 名、イニシャル、姓(G I S)

   Each Organization can define its own Given-names, Initials, and
   Surnames to be used within the Organization. In the cases when
   Surnames are not unique within an O or OU, the Given-name and/or
   Initial shall be used to identify the Originator/Recipient. In the
   rare cases when more than one user would have the same combination of
   G, I, S under the same O and/or OUs, each organization is free to
   find a practical solution, and provide the users with unique O/R
   addresses.

各Organizationは、Organizationの中で使用されるためにそれ自身のGiven-名前、Initials、およびSurnamesを定義できます。 SurnamesがOかOUの中でユニークでないときに場合では、Given-名前、そして/または、Initialは、Originator/受取人を特定するのに使用されるものとします。 1人以上のユーザにGの同じ組み合わせがあるだろうというときのまれなケースでは、私、同じOの下のS、そして/または、OUs、各組織は、実際的な解決を見つけて、自由にユニークなO/Rアドレスをユーザに提供できます。

   Either one of Given-name or Initials should be used, not both.
   Periods shall not be used in Initials.

Given-名前かInitialsのどちらかがともにない使用されるべきです。 Initialsで期間を費やさないものとします。

   To avoid problems with the mapping of the X.400 addresses to RFC-822
   addresses, the following rules might be used. ADMD, PRMD, O, and OU
   values should consist of characters drawn from the alphabet (A-Z),
   digits (0-9), and minus.  Blank or Space characters should be
   avoided.  No distinction is made between upper and lower case. The
   last character shall not be a minus sign or period.  The first
   character should be either a letter or a digit (see reference [6] and
   [7]).

X.400アドレスのマッピングに関する問題をRFC-822アドレスとして避けるために、以下の規則は使用されるかもしれません。 ADMD、PRMD、O、およびOU値はアルファベット(A-Z)、ケタ(0-9)、およびマイナスから得られたキャラクタから成るべきです。 空白かSpaceキャラクタが避けられるべきです。 上側の、そして、より低いケースの間で区別を全くしません。 最後のキャラクタは、マイナス記号か期間でなくなるでしょう。 最初のキャラクタは、手紙かケタのどちらかであるべきです。(参照[6]と[7])を見てください。

Hagens & Hansen                                                 [Page 7]

RFC 1649               X.400 Management in GO-MHS              July 1994

碁-MHS7月1994のHagensとハンセン[7ページ]RFC1649X.400管理

3.1.7.  Domain Defined Attributes (DDAs)

3.1.7. ドメインの定義された属性(DDAs)

   The GO-MHS Community shall allow the use of domain defined
   attributes.  Note: Support for DDAs is mandatory in the functional
   profiles, and all software must upgrade to support DDAs.  The
   following DDAs shall be supported by a GO-MD:

GO-MHS Communityはドメインの定義された属性の使用を許すものとします。 以下に注意してください。 DDAsのサポートは機能的なプロフィールで義務的です、そして、すべてのソフトウェアが、DDAsを支持するためにアップグレードしなければなりません。 以下のDDAsはGO-MDによって支持されるものとします:

    "RFC-822" - defined in reference [3].

"RFC-822"--参照[3]では、定義されます。

   The following DDAs should be supported by a GO-MD:

以下のDDAsはGO-MDによって支持されるべきです:

    "COMMON" - defined in reference [2].

"COMMON"--参照[2]では、定義されます。

3.2.  X.400 88 -> 84 Downgrading

3.2. X.400 88->84格下げ

   The requirements in reference [2] should be implemented in GO-MDs

参照[2]における要件はGO-MDsで実行されるべきです。

3.3.  X.400 / RFC-822 address mapping

3.3. X.400 / RFC-822アドレス・マッピング

   All GO-MHS Community end-users shall be reachable from all end-users
   in the RFC-822 mail service in the Internet (SMTP), and vice versa.

すべてのGO-MHS Communityエンドユーザがすべてのエンドユーザからインターネット(SMTP)でのRFC-822メールサービスで届くでしょう、逆もまた同様に。

   The address mapping issue is split into two parts:

アドレス・マッピング問題は2つの部品に分けられます:

    1) Specification of RFC-822 addresses seen from the X.400 world.
    2) Specification of X.400 addresses seen from the RFC-822 world.

1) X.400世界から見られたRFC-822アドレスの仕様。 2) RFC-822世界から見られたX.400アドレスの仕様。

   The mapping of X.400 and RFC-822 addresses shall be performed
   according to reference [3].

参照[3]に従って、X.400とRFC-822アドレスに関するマッピングは実行されるものとします。

3.3.1.  Specification of RFC-822 Addresses seen from the X.400 World

3.3.1. X.400 Worldから見られたRFC-822 Addressesの仕様

   Two scenarios are described:

2つのシナリオが説明されます:

    A. The RFC-822 end-user belongs to an organization with no defined
       X.400 standard attribute address space.
    B. The RFC-822 end-user belongs to an organization with a defined
       X.400 standard attribute address space.

A. RFC-822エンドユーザは定義されたX.400標準の属性アドレス空間なしで組織に属します。 B。 RFC-822エンドユーザは定義されたX.400標準の属性アドレス空間がある組織に属します。

   Organizations belong to scenario B if their X.400 addresses are
   registered according to the requirements in section 3.1.

要件に従ってそれらのX.400アドレスがセクション3.1に登録されるなら、組織はシナリオBに属します。

3.3.1.1.  An Organization with a defined X.400 Address Space

3.3.1.1. 定義されたX.400 Address SpaceとOrganization

   An RFC-822 address for an RFC-822 mail user in such an organization
   shall be in the same address space as a normal X.400 address for
   X.400 users in the same organization.  RFC-822 addresses and X.400
   addresses are thus sharing the same address space.  Example:

そのような組織のRFC-822メールユーザのためのRFC-822アドレスは同じ組織X.400ユーザにとって、正常なX.400アドレスと同じアドレス空間で中であるものとします。 その結果、RFC-822アドレスとX.400アドレスは同じアドレス空間を共有しています。 例:

Hagens & Hansen                                                 [Page 8]

RFC 1649               X.400 Management in GO-MHS              July 1994

碁-MHS7月1994のHagensとハンセン[8ページ]RFC1649X.400管理

   University of Wisconsin-Madison is registered under C=US;
   ADMD=Internet; PRMD=XNREN; with O=UW-Madison and they are using OU=cs
   to address end-users in the CS-department.  The RFC-822 address for
   RFC-822 mail users in the same department is: user@cs.wisc.edu.

ウィスコンシン-マディソンの大学はC=米国の下に登録されます。 ADMDはインターネットと等しいです。 PRMD=XNREN。 O=UW-マディソンと彼らは、CS-部でエンドユーザに演説するのにOU=Csを使用しています。 同じ部のRFC-822メールユーザのためのRFC-822アドレスは以下の通りです。 user@cs.wisc.edu 。

   An X.400 user in the GO-MHS Community will address the RFC-822 mail
   user at the CS-department with the X.400 address:

GO-MHS CommunityのX.400ユーザはCS-部でX.400アドレスでRFC-822メールユーザに演説するでしょう:

    C=US; ADMD=Internet; PRMD=xnren; O=UW-Madison; OU=cs; S=user;

Cは米国と等しいです。 ADMDはインターネットと等しいです。 PRMD=xnren。 O=UW-マディソン。 OUはCsと等しいです。 Sはユーザと等しいです。

   This is the same address space as is used for X.400 end-users in the
   same department.

これはX.400エンドユーザに同じ部で使用される同じアドレス空間です。

3.3.1.2.  An Organization with no defined X.400 Address Space

3.3.1.2. 定義されたX.400 Address SpaceのないOrganization

   RFC-822 addresses shall be expressed using X.400 domain defined
   attributes.  The mechanism used to define the RFC-822 recipient will
   vary on a per-country basis.

RFC-822アドレスは言い表された使用しているX.400ドメインが属性を定義したということでしょう。 RFC-822受取人を定義するのに使用されるメカニズムは1国あたり1個のベースで異なるでしょう。

   For example, in the U.S., a special PRMD named "Internet" is defined
   to facilitate the specification of RFC-822 addresses.  An X.400 user
   can address an RFC-822 recipient in the U.S. by constructing an X.400
   address such as:

例えば、米国では、「インターネット」という特別なPRMDが、RFC-822アドレスの仕様を容易にするために定義されます。 以下などのX.400アドレスを構成することによって、X.400ユーザは米国でRFC-822受取人に演説できます。

    C=us; ADMD=Internet; PRMD=Internet; DD.RFC-822=user(a)some.place.edu;

Cは私たちと等しいです。 ADMDはインターネットと等しいです。 PRMDはインターネットと等しいです。 DD.RFC-822=user(a)some.place.edu。

   The first part of this address:

このアドレスの最初の部分:

    C=us; ADMD=Internet; PRMD=Internet;

Cは私たちと等しいです。 ADMDはインターネットと等しいです。 PRMDはインターネットと等しいです。

   denotes the U.S. portion of the Internet community and not a specific
   "gateway". The 2nd part:

特定の「ゲートウェイ」ではなくインターネットコミュニティの米国の部分を指示します。 2番目の部分:

    DD.RFC-822=user(a)some.place.edu

DD.RFC-822=user(a)some.place.edu

   is the RFC-822 address of the RFC-822 mail user after substitution of
   non-printable characters according to reference [3]. The RFC-822
   address is placed in an X.400 Domain Defined Attribute of type RFC-
   822 (DD.RFC-822).

参照[3]に従って、非印刷可能なキャラクタの代替の後のRFC-822メールユーザのRFC-822アドレスがありますか? RFC-822アドレスはタイプRFC822(DD.RFC-822)のX.400 Domain Defined Attributeに置かれます。

   Each country is free to choose its own method of defining the RFC-822
   community.  For example in Italy, an X.400 user would refer to an
   RFC-822 user as:

各国は自由にそれ自身のRFC-822共同体を定義する方法を選ぶことができます。 例えば、イタリアでは、X.400ユーザがRFC-822ユーザを以下に差し向けるでしょう。

    C=IT; ADMD=MASTER400; DD.RFC-822=user(a)some.place.it

Cはそれと等しいです。 ADMD=MASTER400。 DD.RFC-822=user(a)some.place.it

   In the UK, an X.400 user would refer to an RFC-822 user as:

イギリスでは、X.400ユーザがRFC-822ユーザを以下に差し向けるでしょう。

Hagens & Hansen                                                 [Page 9]

RFC 1649               X.400 Management in GO-MHS              July 1994

碁-MHS7月1994のHagensとハンセン[9ページ]RFC1649X.400管理

    C=GB; ADMD= ; PRMD=UK.AC; O=MHS-relay; DD.RFC-822=user(a)some.place.uk

CはGBと等しいです。 ADMD=。 PRMD=UK.AC。 O=MHS-リレー。 DD.RFC-822=user(a)some.place.uk

3.3.2.  Specification of X.400 Addresses seen from the RFC-822 World

3.3.2. RFC-822 Worldから見られたX.400 Addressesの仕様

   If an X.400 organization has a defined RFC-822 address space, RFC-822
   users will be able to address X.400 recipients in RFC-822/Internet
   terms.  This means that the address of the X.400 user, seen from an
   RFC-822 user, will generally be of the form:

X.400組織に定義されたRFC-822アドレス空間があると、RFC-822/インターネット用語でRFC-822ユーザはX.400受取人に演説できるでしょう。これは、一般に、RFC-822ユーザから見られたX.400ユーザのアドレスがフォームのものになることを意味します:

    Firstname.Lastname@some.place.edu

Firstname.Lastname@some.place.edu

   where the some.place.edu is a registered Internet domain.

some.place.eduが登録されたインターネットドメインであるところ。

   This implies the necessity of maintaining and distributing address
   mapping tables to all participating RFC-1327 gateways. The mapping
   tables shall be globally consistent.  Effective mapping table
   coordination procedures are needed.

これはすべて参加しているRFC-1327ゲートウェイにアドレス変換テーブルを維持して、分配するという必要性を含意します。 マッピングテーブルはグローバルに一貫するでしょう。 効果的なマッピングテーブル協力手順が必要です。

   If an organization does not have a defined RFC-822 address space, an
   escape mapping (defined in reference [3]) shall be used. In this
   case, the address of the X.400 user, seen from an RFC-822 user, will
   be of the form:

組織がそうしないなら定義されたRFC-822アドレス空間、エスケープを写像するようにしてください。(参照で定義されて、[3])は使用されるものとします。 この場合、RFC-822ユーザから見られたX.400ユーザのアドレスはフォームのものになるでしょう:

    "/G=Firstname/S=Lastname/O=org name/PRMD=foo/ADMD=bar/C=us/"@
                                    some.gateway.edu

@「/G=Firstname/S=Lastname/O=orgは/PRMD=foo/ADMD=バー/C=私たちを/と命名する」some.gateway.edu

   Note that reference [7] specifies that quoted left-hand side
   addresses must be supported and that these addresses may be greater
   than 80 characters long.

参照[7]が引用された左側アドレスをサポートしなければならなくて、これらのアドレスが長い間80以上のキャラクタであるかもしれないと指定することに注意してください。

   This escape mapping shall also be used for X.400 addresses which do
   not map cleanly to RFC-822 addresses.

また、このエスケープマッピングは清潔にアドレスをRFC-822に写像しないX.400アドレスに使用されるものとします。

   It is recommended that an organization with no defined RFC-822
   address space, should register RFC-822 domains at the appropriate
   registration entity for such registrations. This will minimize the
   number of addresses which must use the escape mapping.

それは定義されたRFC-822アドレス空間のない組織、そのような登録証明書のために適切な登録実体でRFC-822ドメインを登録するべきであることが勧められます。 これはエスケープマッピングを使用しなければならないアドレスの数を最小にするでしょう。

   If the escape mapping is not used, RFC-822 users will not see the
   difference between an Internet RFC-822 address and an address in the
   GO-MHS Community.  For example:

エスケープマッピングが使用されていないと、RFC-822ユーザはGO-MHS CommunityのインターネットRFC-822アドレスとアドレスの違いを見ないでしょう。 例えば:

   The X.400 address:

X.400アドレス:

    C=us; ADMD=ATTMail; PRMD=CDC; O=CPG; S=Lastname; G=Firstname;

Cは私たちと等しいです。 ADMD=ATTMail。 PRMDはCDCと等しいです。 O=CPG。 S=Lastname。 G=Firstname。

   will from an RFC-822 user look like:

RFC-822ユーザから、似るでしょう:

Hagens & Hansen                                                [Page 10]

RFC 1649               X.400 Management in GO-MHS              July 1994

碁-MHS7月1994のHagensとハンセン[10ページ]RFC1649X.400管理

       Firstname.Lastname@cpg.cdc.com

Firstname.Lastname@cpg.cdc.com

3.4.  Routing Policy

3.4. ルート設定方針

   To facilitate routing in the GO-MHS Community before an X.500
   infrastructure is deployed, the following two documents, a RELAY-MTA
   document and a Domain document, are defined.  These documents are
   formally defined in reference [1]. The use of these documents is
   necessary to solve the routing crisis that is present today. However,
   this is a temporary solution that will eventually be replaced by the
   use of X.500.

X.500インフラストラクチャが配備される前にGO-MHS Communityで掘るのを容易にするために、以下の2通のドキュメント(RELAY-MTAドキュメントとDomainドキュメント)が、定義されます。 これらのドキュメントは参照[1]で正式に定義されます。 これらのドキュメントの使用が、今日存在しているルーティング危機を解決するのに必要です。 しかしながら、これは結局X.500の使用に取り替えられる一時的な解決です。

   The RELAY-MTA document will define the names of RELAY-MTAs and their
   associated connection data including selector values, NSAP addresses,
   supported protocol stacks, and supported X.400 protocol version(s).

RELAY-MTAドキュメントはセレクタ値、NSAPアドレス、支持されたプロトコル・スタック、および支持されたX.400プロトコルバージョンを含むRELAY-MTAsという名前と彼らの関連接続データを定義するでしょう。

   Each entry in the Domain document consists of a sub-tree hierarchy of
   an X.400 address, followed by a list of MTAs which are willing to
   accept mail for the address or provide a relay service for it. Each
   MTA name will be associated with a priority value. Collectively, the
   list of MTA names in the Domain document make the given address
   reachable from all protocol stacks. In addition, the list of MTAs may
   provide redundant paths to the address, so in this case, the priority
   value indicates the preferred path, or the preferred order in which
   alternative routes should be tried.

Domainドキュメントにおける各エントリーはアドレスのためにメールを受け入れる、またはリレーサービスをそれに提供しても構わないと思っているMTAsのリストがあとに続いたX.400アドレスの下位木階層構造から成ります。 それぞれのMTA名は優先順位の値に関連するでしょう。 Domainドキュメントの名前がすべてのプロトコルから届いている与えられたアドレスをするMTAのリストはまとめて、積み重ねられます。 さらに、MTAsのリストが冗長パスをアドレスに提供するかもしれないので、この場合、優先順位の値は都合のよい経路、または代替のルートが試みられるべきである都合のよいオーダーを示します。

   The RELAY-MTA and Domain documents are coordinated by the group
   specified in the Community document.  The procedures for document
   information gathering and distribution, are for further study.

RELAY-MTAとDomainドキュメントはCommunityドキュメントで指定されたグループによって調整されます。 文書情報集会と分配のための手順はさらなる研究へのそうです。

3.5.  Minimum Statistics/Accounting

3.5. 最小の統計/会計

   The following are not required for all MTAs. The information is
   provided as guidelines for MTA managers.  This is helpful for
   observing service use and evaluating service performance.

以下はすべてのMTAsに必要ではありません。 MTAマネージャへのガイドラインとして情報を提供します。 サービス利用を観測して、サービス性能を評価するのにおいて、これは役立っています。

   This section defines the data which should be kept by each MTA.
   There are no constraints on the encoding used to store the data
   (i.e., format).

このセクションは各MTAによって保たれるはずであるデータを定義します。 データ(すなわち、形式)を格納するのに使用されるコード化には規制が全くありません。

   For each message/report passing the MTA, the following information
   should be collected.

MTAを渡す各メッセージ/レポートに関しては、以下の情報は集められるべきです。

Hagens & Hansen                                                [Page 11]

RFC 1649               X.400 Management in GO-MHS              July 1994

碁-MHS7月1994のHagensとハンセン[11ページ]RFC1649X.400管理

   The following fields should be collected.

以下の分野は集められるべきです。

    Date
    Time
    Priority
    Local MTA Name
    Size

日付の時間の優先権の地方のMTAはサイズを命名します。

   The following fields are conditionally collected.

以下の分野は条件付きに集められます。

    From MTA Name (fm)
    To MTA Name (tm)
    Delta Time (dt)
    Message-id (id)

MTA名(fm)からMTA名(tm)のデルタ時間(dt)メッセージイドまで(イド)

   At least one of 'fm' and 'tm' should be present.  If one of 'fm' and
   'tm' is not present, 'id' should be present. If both 'fm' and 'tm'
   are present, then 'dt' indicates the number of minutes that the
   message was delayed in the MTA.  If 'id' cannot be mapped locally
   because of log file formats, 'id' is not present and every message
   creates two lines: one with 'fm' empty and one with 'tm' empty. In
   this case, 'date' and 'time' in the first line represent the date and
   time the message entered the MTA.  In the second line, they represent
   the date and time the message left the MTA.

少なくとも'fm'と'tm'の1つは存在しているべきです。 'fm'と'tm'の1つが存在していないなら、'イド'は存在しているべきです。 両方であるなら、'fm'と'tm'は存在しています、とメッセージが数分の数でしたが、MTAで遅らせられて、当時の'dt'は示します。 ログファイル形式のために局所的に'イド'を写像できないなら、'イド'は存在していません、そして、あらゆるメッセージが2つの線を作成します: 'fm'が空の1と'tm'がある1つは空になります。 この場合、'日付'と'時間'は最初の線でメッセージがMTAに入った日時を表します。 セカンドラインでは、彼らがメッセージがMTAを残した日時を表します。

   The following fields are optionally collected.

以下の分野は任意に集められます。

    From Domain (fd)
    To Domain (td)

ドメイン(fd)からドメインまで(td)

   For route tracing, 'fd' and 'td' are useful. They represent X.400
   OU's, O, PRMD, ADMD and C and may be supplied up to any level of
   detail.

ルートのたどるのに、'fd'と'td'は役に立ちます。 それらをX.400 OU、O、PRMD、ADMD、およびCを表して、どんなレベルの詳細までも供給するかもしれません。

4.  Community Document

4. 共同体ドキュメント

   For the GO-MHS community there will exist one single COMMUNITY
   document containing basic information as defined in reference [1].
   First the contact information for the central coordination point can
   be found together with the addresses for the file server where all
   the documents are stored.  It also lists network names and stacks to
   be used in the RELAY-MTA and DOMAIN documents. The GO-MHS community
   must agree on its own set of mandatory and optional networks and
   stacks.

GO-MHS共同体に、参照[1]で定義されるように基本情報を含む1通のただ一つのCOMMUNITYドキュメントが存在するでしょう。 まず最初に、ファイルサーバーのためのすべてのドキュメントが格納されるアドレスと共に主要なコーディネートポイント単位で問い合わせ先を見つけることができます。 それは、また、ネットワーク名を記載して、RELAY-MTAとDOMAINドキュメントで使用されるために積み重ねられます。 GO-MHS共同体はそれ自身の義務的で任意のネットワークとスタックのセットに同意しなければなりません。

Hagens & Hansen                                                [Page 12]

RFC 1649               X.400 Management in GO-MHS              July 1994

碁-MHS7月1994のHagensとハンセン[12ページ]RFC1649X.400管理

5.  Security Considerations

5. セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

6.  Authors' Addresses

6. 作者のアドレス

   Robert Hagens
   Advanced Network & Services, Inc.
   1875 Campus Commons Drive
   Suite 220
   Reston, VA 22091
   U.S.A.

ロバートHagensはネットワークを唱えて、Inc.1875キャンパス共有ドライブSuite220ヴァージニア22091レストン(米国)にサービスを提供します。

   Phone: +1 703 758 7700
   Fax:   +1 703 758 7717
   EMail: hagens@ans.net
   DDA.RFC-822=hagens(a)ans.net; P=INTERNET; C=US

以下に電話をしてください。 +1 703 758、7700Fax: +1 7717年の703 758メール: hagens@ans.net DDA.RFC-822=hagens(a)ans.net。 Pはインターネットと等しいです。 Cは米国と等しいです。

   Alf Hansen
   UNINETT
   Elgesetergt. 10
   Postbox 6883, Elgeseter
   N-7002 Trondheim
   Norway

アルフハンセンUNINETT Elgesetergt。 10 ポスト6883、Elgeseter N-7002トロンヘイムノルウェー

   Phone: +47 7359 2982
   Fax:   +47 7359 6450
   EMail: Alf.Hansen@uninett.no
   G=Alf; S=Hansen; O=uninett; P=uninett; C=no

以下に電話をしてください。 +47 7359 2982、Fax: +47 7359 6450はメールされます: Alf.Hansen@uninett.no Gはアルフと等しいです。 Sはハンセンと等しいです。 O=uninett。 P=uninett。 Cはいいえと等しいです。

Hagens & Hansen                                                [Page 13]

RFC 1649               X.400 Management in GO-MHS              July 1994

碁-MHS7月1994のHagensとハンセン[13ページ]RFC1649X.400管理

References

参照

   [1] Eppenberger, U., Routing Coordination for X.400 MHS-Services
       Within a Multi Protocol / Multi Network Environment, RFC 1465,
       SWITCH, May 1993.

[1] Eppenberger(U.、マルチプロトコル/マルチネットワーク環境、RFC1465の中のX.400 MHS-サービスのためのルート設定コーディネート)は切り替わります、1993年5月。

   [2] Hardcastle-Kille, S., "X.400 1988 to 1984 downgrading, RFC 1328,
       University College London, May 1992.

[2]Hardcastle-Kille、S.、「X.400 1988年から1984格下げ、RFC1328、ユニバーシティ・カレッジロンドン1992年5月。」

   [3] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
       and RFC 822, RFC 1327, May 1992.

[3]Hardcastle-Kille、S.、「X.400(1988)/ISO10021とRFC822、RFC1327、1992年5月の間のマッピング。」

   [4] Cargille, A., "Postmaster Convention for X.400 Operations", RFC
       1648, University of Wisconsin, July 1994.

[4]Cargille、A.、「X.400操作のための郵便局長コンベンション」、RFC1648、ウィスコンシン大学、1994年7月。

   [5] International Telecommunications Union, CCITT.  Data
       Communications Networks, Volume VIII, Message Handling Systems,
       ITU: Geneva 1985.

[5] 国際電気通信組合、CCITT。 データ通信網、巻VIII、メッセージハンドリングシステム、ITU: ジュネーブ1985。

   [6] Harrenstien, K., Stahl, M., and E. Feinler, "DOD Internet Host
       Table Specification", RFC 952, SRI, October 1985.

[6]HarrenstienとK.とスタール、M.とE.Feinler、「DODインターネットホストテーブル仕様」、RFC952、様、1985年10月。

   [7] Braden, R., "Requirements for Internet Hosts -- Application and
       Support", STD 3,  RFC 1123, USC/Information Sciences Institute,
       October 1989.

[7] ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、科学が設けるUSC/情報、10月1989日

Hagens & Hansen                                                [Page 14]

Hagensとハンセン[14ページ]