RFC1026 日本語訳

Network Working Group                                          S.E. Kille
Request for Comments 1026                       University College London
                                                           September 1987

ネットワークワーキンググループ東南Killeは1987年9月にコメント1026のためにユニバーシティ・カレッジロンドンを要求します。

                         Addendum to RFC 987

RFC987への付加物

                 (Mapping between X.400 and RFC-822)

(X.400とRFC-822の間のマッピング)

Status of this Memo

このMemoの状態

   This RFC suggest a proposed protocol for the Internet community, and
   requests discussion and suggestions for improvements.  Distribution
   of this memo is unlimited.

このRFCは改良のためにインターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。 このメモの分配は無制限です。

   This document specifies a number of additions and corrections to
   RFC-987, aka Mailgroup Note 19.

このドキュメントはRFC-987、通称Mailgroup Note19に多くの追加と修正を指定します。

   The addendum carries equal weight to the original specification,
   which must be used when this mapping is performed on the Internet or
   in the UK Academic Community.  This mapping may also be used within
   the RARE community in Europe.  This specification may be modified in
   the light of implementation experience, but no substantial changes
   are expected.

付加物は同量を正式仕様書に載せます。(このマッピングがインターネットの上、または、イギリスのAcademic Communityで実行されるとき、それを使用しなければなりません)。 また、このマッピングはヨーロッパのRARE共同体の中で使用されるかもしれません。 この仕様は実現経験の見地から変更されるかもしれませんが、大きな変化は全く予想されません。

1.  Errata

1. 誤字

   -    In section 4.6.4, replace ".." with ".".

- 「セクション4.6.4で取り替え、」、」、」、」

   -    In section 4.2.4, replace three references to 4.3.1 by
        4.2.1, and one reference to 4.2.2 by 4.1.2.

- セクション4.2.4では、4.3の3つの参照箇所を取り替えてください、.1、4.2、.1、1つが4.2に.2に参照をつける、4.1、.2

   -    In section 5.2, replace "1  mailbox" with "1#mailbox",
        "1 msg-id" with "1#msg-id" and "1 encoded-type" with
        "1#encoded-type".

- セクション5.2では、「1#メールボックス」がある「1個のメールボックス」、「1つの#msg-イド」がある「1つのmsg-イド」、および「1つの#コード化されたタイプ」がある「1つのコード化されたタイプ」を取り替えてください。

2.  Component Ordering

2. コンポーネント注文

   In most cases, ordering of O/R name components is not significant for
   the mappings specified by this document.  However, Organisational
   Units and Domain Defined Attributes are specified as SEQUENCE, in
   P1.ORName, and so their order may be significant.  This specification
   needs to take account of this in two ways:

多くの場合、このドキュメントによって指定されたマッピングには、O/R名前コンポーネントの注文は重要ではありません。 しかしながら、Organisational UnitsとDomain Defined AttributesがSEQUENCEとしてP1.ORNameで指定されるので、彼らのオーダーは重要であるかもしれません。 この仕様は、2つの方法でこれを考慮に入れる必要があります:

   1)   To allow consistent mapping into the domain hierarchy

1) ドメイン階層構造に一貫したマッピングを許容するために

   2)   To ensure preservation of order over multiple mappings.

2) 複数のマッピングの上の秩序の維持を確実にするために。

Kille                                                           [Page 1]

RFC 1026                                                  September 1987

Kille[1ページ]RFC1026 1987年9月

There are three places where an order must be specified:

3つの場所がオーダーを指定しなければならないところにあります:

   1)   On the text encoding (std-orname) of P1.ORName as used in the
        local-part of an RFC-822 address, the most significant component
        must be on the RHS.  This applies only to those components which
        may have multiple values (Organisational Unit, and Domain
        Defined Attributes).  Other attributes may be presented in any
        order. Note that in dmn-orname specified in Appendix F, this
        ordering is already implied by the current ordering
        requirements.

1) RFC-822アドレスの地方の部分で使用されるようにP1.ORNameの(std-orname)をコード化するテキストに、最も重要なコンポーネントがRHSにあるに違いありません。 これは複数の値(Organisational Unit、およびDomain Defined Attributes)を持っているかもしれないそれらのコンポーネントだけに適用されます。 他の属性は順不同に提示されるかもしれません。 Appendix Fで指定されたdmn-ornameではこの注文が要件を命令する電流によって既に含意されることに注意してください。

   2)   For the Organisational Units (OU) in P1.ORName, the first OU in
        the SEQUENCE is the most signicicant.  This follows the
        "natural" hierarchy of the specification of P1.ORName, where the
        most significant components are defined first.

2) P1.ORNameのOrganisational Units(OU)に関しては、SEQUENCEにおける最初のOUは最も多くのsignicicantです。 これは最初に定義される中でコンポーネント最も重要であるP1.ORNameの仕様の「自然な」階層構造に従います。

   3)   For the Domain Defined Attributes in P1.ORName, the First Domain
        Defined Attribute in the SEQUENCE is the most significant.

3) P1.ORNameのDomain Defined Attributesに関しては、SEQUENCEのFirst Domain Defined Attributeは最も重要です。

   Note that although the ordering defined in 2) and 3) is mandatory for
   this mapping, there are NO implications on ordering significance
   within X.400.

2と)3で)定義された注文がこのマッピングに義務的ですが、X.400の中で意味を注文するとき、含意が全くないことに注意してください。

   3.  Extensions To Deal with Omitted Components

3. 対処する拡大はコンポーネントを省略しました。

   Implementation of RFC-987 has proved to be a little inflexible for
   some naming strategies.  In particular, there are some difficulties
   where Organisation or PRMD is omitted:

RFC-987の実現はいくつかの命名戦略には少し融通がきかないと判明しました。 特に、困難がOrganisationかPRMDが省略されるところにあります:

   The following sentence of RFC-987 should be removed: 4.2.1 (Page 27):
   "If one of the hierarchical components is omitted ....  tuple).".

RFC-987に関する以下の文は取り除かれるべきです: 4.2.1 (27ページ): 「1であるなら、階層的では、コンポーネントは省略されます… tuple)、」

   The strategy proposed is to introduce the concept of explicit missing
   components to the symmetrical mapping described in 4.2.1.
   Essentially, a domain may be associated with an omitted attribute in
   conjuction with several present ones.  When performing the
   algorithmic insertion of components lower in the hierarchy, the
   omitted value should be skipped.  For example, if "GMD.DFN" is
   associated with "C=DE", "ADMD=DBP", "PRMD=GMD", and omitted
   organisation, then "ZI.GMD.DFN" is mapped with "C=DE", "ADMD=DBP",
   "PRMD=GMD", "OU=ZI".  It should be noted that attributes may have
   null values, and that this is treated separately from omitted
   attributes (whilst it would be bad practice to treat these two cases
   differently, they must be allowed for in practice).

提案された戦略が中で説明された対称のマッピングに明白ななくなったコンポーネントの概念を紹介することである、4.2、.1 本質的には、ドメインはいくつかの現在のものでconjuctionの省略された属性に関連しているかもしれません。 階層構造で、より低くコンポーネントのアルゴリズムの挿入を実行するとき、省略された値はスキップされるべきです。 例えば、"GMD.DFN"が「CはDEと等しい」、"ADMD=DBP"、"PRMD=GMD"、および省略された機構に関連しているなら、"ZI.GMD.DFN"は「CはDEと等しい」"ADMD=DBP"、"PRMD=GMD""OU=ZI"と共に写像されます。 ヌル値が属性にあるかもしれなくて、これが別々に省略された属性から扱われることに(実際にはそれらを異なって、許容しなければならないこれらの2つのケースを扱うのが、悪い習慣でしょうが)注意されるべきです。

Kille                                                           [Page 2]

RFC 1026                                                  September 1987

Kille[2ページ]RFC1026 1987年9月

   To allow the mapping of null organisations to be represented in the
   specification of Appendix F, the dmn-orname syntax is extended, so
   that values may be given the symbol "@" (not a printable string
   character). This corresponds to an omitted attribute. The new
   definition is:

ヌル機構に関するマッピングがAppendix Fの仕様に表されるのを許容するために、dmn-orname構文は拡張されています、"@"(印刷可能なストリングキャラクタでない)というシンボルを値に与えることができるように。 これは省略された属性に対応しています。 新しい定義は以下の通りです。

           dmn-orname      = dmn-part *( "." dmn-part )
           dmn-part        = attribute "$" value
           attribute       = standard-type
                           / "~" dmn-printablestring
           value           = dmn-printablestring
                           / "@"
           dmn-printablestring
                           = *( dmn-char / dmn-pair )
           dmn-char        = <ps-delim, and any ps-char except ".">
           dmn-pair        = "."

「dmn-printablestring/"@"dmn-printablestring属性「$」値属性=標準体型/「~」dmn-printablestring dmn-orname=dmn-部分*(「.」 dmn-部分)dmn-部分=価値==*<(dmn dmn-炭/対にします)のdmn-炭=ps-delim、および」 . 「>dmn-組=」を除いたどんなps-炭も。」

   Appendix F - Format of address mapping tables

付録F--アドレス変換テーブルの形式

   A new Appendix F is defined as follows:

新しいAppendix Fは以下の通り定義されます:

   There is a need to specify the association between the domain and
   X.400 namespaces described in 4.2.1.  This is defined as a table
   syntax, but the syntax is defined in a manner which makes it suitable
   for use with domain nameservices (such as the Internet Domain
   nameservers or the UK NRS).  The mapping is not symmetric, and so a
   separate table is specified for each direction.  If multiple matches
   are possible, the longest possible match should be used.

4.2で.1に説明されたドメインとX.400名前空間との協会を指定する必要があります。 これはテーブルシンタックスと定義されますが、構文はそれをドメインnameservices(インターネットDomainネームサーバかUK NRSなどの)との使用に適するようにする方法で定義されます。 マッピングが左右対称でないので、別々のテーブルは各方向に指定されます。 複数のマッチが可能であるなら、可能な限り長いマッチは使用されるべきです。

   Various restrictions are placed on the usage of dmn-orname:

様々な制限はdmn-ornameの使用法に関して課されます:

   1)   Only C, ADMD, PRMD, O, and OU may be used.

1) C、ADMD、PRMD、O、およびOUだけを使用してもよいです。

   2)   There must be a strict ordering of all components, with the most
        significant components on the RHS.

2) RHSで最も重要なコンポーネントによるすべてのコンポーネントの厳しい注文があるに違いありません。

   3)   No components may be omitted from the hierarchy, although the
        hierarchy may terminate at any level.  If the mapping is to an
        omitted component, the "@" syntax is used.

3) 階層構造はどんなレベルでも終わるかもしれませんが、コンポーネントは全く階層構造から省略されないかもしれません。 省略されたコンポーネントにマッピングがあるなら、"@"構文は使用されています。

   For domain -> X.400:

ドメイン->X.400に:

           domain-syntax "#" dmn-orname "#"

ドメイン構文「#」dmn-orname「#」

   Note that the trailing "#" is used for clarity, as the dmn-orname
   syntax can lead to values with trailing blanks.

dmn-orname構文が引きずっている空白がある値につながることができて、引きずっている「#」が明快に使用されることに注意してください。

           For example:

例えば:

           AC.UK#PRMD$DES.ADMD$BT.C$UK#
           XEROX.COM#O$Xerox.ADMD$ATT.C$US#

AC.UK#PRMD$DES.ADMD$BT.C$イギリス#XEROX.COM#O$Xerox.ADMD$ATT.C$U.S.#

Kille                                                           [Page 3]

RFC 1026                                                  September 1987

Kille[3ページ]RFC1026 1987年9月

           HMI.DBP.DFN#O$@.PRMD$HMI.ADMD.DBP.C$DE#

HMI.DBP.DFN# O$@.PRMD$HMI.ADMD.DBP.C$DE #

   For X.400 -> domain:

X.400->ドメインに:

           dmn-orname "#" domain-syntax "#"

dmn-orname「#」ドメイン構文「#」

Kille                                                           [Page 4]

Kille[4ページ]