RFC1218 日本語訳

1218 Naming scheme for c=US. North American Directory Forum. April 1 1991. (Format: TXT=42698 bytes) (Obsoleted by RFC1255, RFC1417) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                 The North American Directory Forum
Request for Comments: 1218                                    April 1991

コメントを求める作業部会の北米のディレクトリフォーラム要求をネットワークでつないでください: 1218 1991年4月

                        A Naming Scheme for c=US

cの命名計画は米国と等しいです。

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

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

Summary

概要

   This RFC is a near-verbatim copy of a document, known as NADF-123,
   which has been produced by the North American Directory Forum (NADF).
   The NADF is a collection of organizations which offer, or plan to
   offer, public Directory services in North America, based on the CCITT
   X.500 Recommendations.  As a part of its charter, the NADF must reach
   agreement as to how entries are named in the public portions of the
   North American Directory.  NADF-123 is a scheme proposed for this
   purpose.  The NADF is circulating NADF-123 widely, expressly for the
   purpose of gathering comments.  The next meeting of the NADF is in
   mid-July, and it is important for comments to be received prior to
   the meeting, so that the scheme may receive adequate review.

このRFCは北米のディレクトリForum(NADF)によって製作されたNADF-123として知られているドキュメントの近く逐語的なコピーです。 NADFは申し出に提供するか、または計画されている組織の収集です、北アメリカでの公共のディレクトリサービス、CCITT X.500 Recommendationsに基づいて。 特許の一部として、エントリーが北米のディレクトリの公共の部分でどう命名されるかに関してNADFは合意に達しなければなりません。 NADF-123はこのために提案された計画です。 NADFは集会コメントの目的のためにNADF-123を広さに、明白に循環させています。 7月中旬に、NADFの次のミーティングはあります、そして、ミーティングの前にコメントを受けるのは重要です、計画が適切なレビューを受け取ることができるように。

                         A Naming Scheme for c=US
                    The North American Directory Forum
                                 NADF-123
                       Supercedes: NADF-103, NADF-71
                              March 21, 1991

cの命名計画は米国の北米のディレクトリフォーラムNADF-123 Supercedesと等しいです: NADF-103、1991年3月21日のNADF-71

ABSTRACT

要約

   This is one of a series of documents produced for discussion within
   the North American Directory Forum.  Distribution, with attribution,
   is unlimited.  This document is being circulated for comment.  The
   deadline for comments is July 1, 1991.  Comments should be directed
   to the contact given on page 16.

これは議論のために北米のディレクトリForumの中で製作された一連のドキュメントの1つです。 属性で、分配は無制限です。 このドキュメントはコメントのために循環しています。 コメントのための締め切りは1991年7月1日です。 コメントは16ページで与えられた接触に向けられるべきです。

1.  Introduction

1. 序論

   Computer networks form the infrastructure between the users they
   interconnect.  For example, the electronic mail service offered by
   computer networks provides a means for users to collaborate towards
   some common goal.  In the simplest cases, this collaboration may be
   solely for the dissemination of information.  In other cases, two

コンピュータネットワークは彼らがインタコネクトするユーザの間でインフラストラクチャを形成します。 例えば、コンピュータネットワークによって提供された電子メールサービスはユーザが何らかの一般的な目標に向かって共同する手段を提供します。 最も簡単な場合には、この共同が唯一情報の普及のためにあるかもしれません。 他のケース、2で

NADF                                                            [Page 1]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[1ページ]RFC1218は1991年4月に米国と等しいです。

   users may work on a joint research project, using electronic mail as
   their primary means of communication.

彼らのコミュニケーションの第一の手段として電子メールを使用して、ユーザは共同研究プロジェクトに取り組むかもしれません。

   However, networks themselves are built on an underlying naming and
   numbering infrastructure, usually in the form of names and addresses.
   For example, some authority must exist to assign network addresses to
   ensure that numbering collisions do not occur.  This is of paramount
   importance for an environment which consists of multiple service
   providers.

しかしながら、ネットワーク自体は通常名前とアドレスの形に基本的な命名と付番インフラストラクチャに造られます。 例えば、何らかの権威が、付番衝突が起こらないのを保証するためにネットワーク・アドレスを割り当てるために存在しなければなりません。 これは複数のサービスプロバイダーから成る環境のために最高のに重要です。

2.  Approach

2. アプローチ

   It should be observed that there are several different naming
   universes that can be realized in the Directory Information Tree
   (DIT).  For example, geographical naming, community naming, political
   naming, organizational naming, and so on.  The choice of naming
   universe largely determines the difficulty in mapping a user's query
   into a series of Directory operations.  Although it is possible to
   simultaneously support multiple naming universes with the DIT, this
   is likely to be unnatural.  As such, this proposal focuses on a
   single naming universe.

ディレクトリ情報Tree(DIT)で実感できるいくつかの異なった命名宇宙があるのが観測されるべきです。 例えば、地理的な命名、共同体命名、政治上の命名、組織的な命名など。 宇宙を命名することの選択は一連のディレクトリ操作にユーザの質問を写像することにおける苦労を主に決定します。 同時にDITと共に複数の命名宇宙を支持するのが可能ですが、これは不自然である傾向があります。 そういうものとして、この提案は単一の命名宇宙に焦点を合わせます。

   The naming universe in this proposal is based on civil authority.
   That is, it uses the existing civil naming infrastructure and
   suggests a (nearly) straight-forward mapping on the DIT.  There are
   four components to the naming architecture:

この提案における命名宇宙は民間権威に基づいています。 すなわち、それは、既存の民間命名インフラストラクチャを使用して、DITに関する(ほとんど)簡単なマッピングを示します。 命名構造への4つのコンポーネントがあります:

   (1)  civil naming and optimized civil naming, which reflects
        names assigned by civil authority;

(1)の民間命名と最適化された民間命名(それは、民間権威によって割り当てられた名前を反映します)。

   (2)  organizational naming, which reflects names assigned
        within organizations;

(2) 組織的な命名(それは、組織の中で割り当てられた名前を反映します)。

   (3)  ADDMD naming, which reflects names assigned to public
        providers within the Directory service; and,

(3) ADDMD命名(それは、ディレクトリサービスの中で公共のプロバイダーに割り当てられた名前を反映します)。 そして

   (4)  application naming, which reflects names assigned to OSI
        entities.

(4) アプリケーション命名。(その命名はOSI実体に割り当てられた名前を反映します)。

   An important characteristic is that entries should be listed wherever
   searches for them are likely to occur.  This implies that a single
   object may be listed under several entries.

重要な特性はエントリーがどこでも、それらの検索が起こりそうであるところに記載されているべきであるということです。 これは、単一の物がいくつかのエントリーで記載されているかもしれないのを含意します。

2.1.  Names and User-Friendliness

2.1. 名前とユーザーフレンドリー

   It must be emphasized that there are three distinct concepts which
   are often confused when discussing a naming scheme:

命名計画について議論するときしばしば混乱する3つの異なった概念があると強調しなければなりません:

NADF                                                            [Page 2]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[2ページ]RFC1218は1991年4月に米国と等しいです。

   (1)  user-friendly naming: a property of a Directory which
        allows users to easily identity objects;

(1) ユーザフレンドリーな命名: 容易にアイデンティティ物にユーザを許容するディレクトリの特性。

   (2)  user-friendly name: a technique for naming an object
        which exhibits "friendliness" according to an arbitrary
        set of user-criteria; and,

(2) ユーザフレンドリーな名前: 任意のセットのユーザ評価基準に従って「友情」を示す物を命名するためのテクニック。 そして

   (3)  Distinguished Name: the administratively assigned name
        for an entry in the OSI Directory.

(3)分類名: OSIディレクトリにおけるエントリーへの行政上割り当てられた名前。

   It must be emphasized that Distinguished Names are not necessarily
   user-friendly names, and further, that user-friendly naming in the
   Directory is a property of the Directory Service, not of
   Distinguished Names.

Distinguished Namesが必ずユーザフレンドリーな名前であるというわけではないと強調しなければならなくて、さらに、ディレクトリにおけるそのユーザフレンドリーな命名はDistinguished Namesではなく、ディレクトリサービスの特性です。

2.2.  Choice of RDN Names

2.2. RDN名の選択

   The key aspect to appreciate for choice of RDNs is that they should
   provide a large name space to avoid collisions: the naming strategy
   must provide enough "real estate" to accommodate a large demand for
   entries.  This is the primary requirement for RDNs.  A secondary
   requirement is that RDNs should be meaningful (friendly to people)
   and should not impede searching.

RDNsの選択のために感謝する特徴は彼らが衝突を避けるために大きい名前スペースを提供するべきであるということです: 命名戦略はエントリーを求める大口需要を収容できるくらいの「不動産」を提供しなければなりません。 これはRDNsのための第一の要件です。 二次要件はRDNsが重要であるはずであり(人々にとって、好意的な)、探すことを妨害するはずがないということです。

   However, it is important to understand that this second requirement
   can be achieved by using additional (non-distinguished) attribute
   values.  For example, if the RDN of an entry is

しかしながら、追加している(非顕著な)属性値を使用することによってこの2番目の要件を達成できるのを理解しているのは重要です。 例えば、エントリーのRDNはそうです。

                organizationName is Performance Systems International

organizationNameは国際パフォーマンスSystemsです。

   then it is perfectly acceptable (and indeed desirable) to have other
   values for the organizationName attribute, e.g.,

次に、organizationName属性のための他の値を持っているのは、例えば完全に許容できるのと(本当に望ましい)です。

                organizationName is PSI

organizationNameはPSIです。

   The use of these abbreviated names greatly aids searching whilst
   avoiding unnecessary Distinguished Name conflicts.

これらの略称の使用は、不要なDistinguished Name闘争を避けている間、探しながら、大いに支援されます。

   In order to appreciate the naming scheme which follows, it is
   important to understand that it leverages, wherever possible,
   existing naming infrastructure.  That is, it relies heavily on non-
   OSI naming authorities which already exist.  Note that inasmuch as it
   relies on existing naming authorities, there is little chance that
   any "final" national decision could obsolete it.  [Footnote: Any
   naming scheme may be subject to the jurisdiction of certain national
   agencies.  For example, the US State Department is concerned with any
   impact on US telecommunications treaty obligations.] (To do so would
   require a national decision that disregards existing national and

続く命名計画に感謝するために、それが力を入れるのを理解しているのはどこでも、可能であるところで重要です、インフラストラクチャを命名しながら存在していて。 すなわち、それは大いに当局を任命する非OSIを当てにします(既に存在しています)。 当局を任命しながら存在するのを当てにする限り、どんな「最終的な」国家的な決定もそれを時代遅れにするかもしれないという見込みがほとんどないことに注意してください。 [以下に脚注をつけてください。 どんな命名計画もある国家の政府機関の管轄を受けることがあるかもしれません。 例えば、米国国務省は米国テレコミュニケーション条約義務へのどんな影響にも関係があります。] そして(そうするのが既存の同胞を無視する国家的な決定が必要であるだろう。

NADF                                                            [Page 3]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[3ページ]RFC1218は1991年4月に米国と等しいです。

   regional infrastructure, and establishes some entirely new and
   different national naming infrastructure.)

地方のインフラストラクチャ、何らかの完全に新しくて異なった国家の命名インフラストラクチャを確立する、)。

3.  Civil Naming

3. 民間命名

   Civil naming occurs at three levels:

民間命名は3つのレベルで起こります:

   (1)  the national level, which contains objects that are
        recognized throughout a country;

(1) 全国レベル(それは、国中で認識される物を含みます)。

   (2)  the regional level, which contains objects that are
        recognized throughout a state or state-equivalent; and,

(2) 局在レベル(それは、状態か州同等物中で認識される物を含みます)。 そして

   (3)  the local level, which contains objects that are
        recognized within a populated place.

(3) 地方レベル。(その地方レベルは居住された場所の中で認識される物を含みます)。

3.1.  Naming at the National Level

3.1. 全国レベルにおける命名

   At the national-level (at least) three kinds of names may be listed:

全国レベルでは、(少なくとも)の3種類の名前は記載されているかもしれません:

   (1)  The States and State-Equivalents

(1) 州と州同等物

   (2)  Organizations with National Standing

(2) 国家の地位との組織

   (3)  ADDMD Operators

(3) ADDMDオペレータ

3.1.1.  The States and State-Equivalents

3.1.1. 州と州同等物

   For each state or state-equivalent (the District of Columbia and the
   eight outlying areas [Footnote: i.e., American Samoa, Federated
   States of Micronesia, Guam, Marshall Islands, Northern Mariana
   Islands, Palau, Puerto Rico, and Virgin Islands of the US.]), an
   instance of an

各状態か州同等物(コロンビア特別区と8つの辺ぴな領域[脚注: 米国のすなわち、アメリカ領サモア、ミクロネシア連邦、グアム、マーシャル諸島共和国、北マリアナ諸島、パラオ、プエルトリコ、およびヴァージン諸島。])、例

               usStateOrEquivalent

usStateOrEquivalent

          object is used.  The RDN is formed as

物は使用されています。 RDNとして、形成されます。

               localityName is <FIPS 5 name>

localityNameは<FIPS5名前>です。

          e.g.,

例えば

               localityName is California

localityNameはカリフォルニアです。

   provides the RDN for the State of California.  In addition, this
   entry would contain attributes identifying both the FIPS 5 alpha and
   numeric code for the State, e.g.,

RDNをカリフォルニア州に提供します。 さらに、このエントリーは州のために例えばFIPS5アルファと数字コードの両方を特定する属性を含んでいるでしょう。

NADF                                                            [Page 4]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[4ページ]RFC1218は1991年4月に米国と等しいです。

                fipsStateNumericCode is 06
                fipsStateAlphaCode is CA

fipsStateNumericCodeによる06fipsStateAlphaCodeがカリフォルニアであるということです。

   Of course, this entry could contain many other attributes such as

もちろん、このエントリーは他がそのようなものを結果と考える多くを含むかもしれません。

                stateOrProvinceName is State of California

stateOrProvinceNameはカリフォルニア州です。

3.1.2.  Organizations with National Standing

3.1.2. 国家の地位との組織

   There is no authority in the United States which unambiguously
   registers the alphanumeric names of organizations with national
   standing.  It is proposed that ANSI provide this registry and that
   the ANSI alphanumeric name form be used as the basis for RDNs.

権威が全く明白に組織の英数字の名前を国家の地位に登録する合衆国にありません。 ANSIがこの登録を提供して、形成というANSIの英数字の名がRDNsの基礎として使用されるよう提案されます。

   For each organization with national standing, an instance of an

国家の地位、例がある各組織

               usOrganization

usOrganization

          object is used.  The RDN is formed as

物は使用されています。 RDNとして、形成されます。

               organizationName is <ANSI alphanumeric name form>

organizationNameは<のANSIの英数字の名前フォーム>です。

          e.g.,

例えば

               organizationName is Performance Systems International

organizationNameは国際パフォーマンスSystemsです。

   In addition, this entry would contain attributes identifying the ANSI
   Alphanumeric name form, e.g.,

さらに、このエントリーは例えば形成というANSI Alphanumeric名を特定する属性を含んでいるでしょう。

                ansiOrgNumericCode is 177777

ansiOrgNumericCodeは177777です。

   Of course, this entry would contain many other attributes such as

もちろん、このエントリーは他がそのようなものを結果と考える多くを含んでいるでしょう。

                organizationName is PSI

organizationNameはPSIです。

   For the National Government, an instance of an

National政府、例

                organization

組織

   object is also used, and the RDN is taken from the ANSI alphanumeric
   name form registry.

また、物を使用します、そして、ANSIの英数字の名前フォーム登録からRDNを取ります。

3.1.3.  ADDMD Operators

3.1.3. ADDMDオペレータ

   There is no authority in the United States which unambiguously
   registers the names of ADDMD operators.  It is expected that the
   North American Directory Forum will coordinate with the US CCITT
   National Committee Study Group D to provide this registry.  (At

権威が全く明白にADDMDオペレータの名前を登録する合衆国にありません。 北米のディレクトリForumがこの登録を提供するために米国CCITT National Committee Study Group Dと共に調整すると予想されます。 (

NADF                                                            [Page 5]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[5ページ]RFC1218は1991年4月に米国と等しいです。

   worst, the ADDMDs can use ANSI alphanumeric name forms for their RDN
   attribute values.)

最もひどく、ADDMDsはそれらのRDN属性値にANSIの英数字の名前フォームを使用できます。)

          For each ADDMD operator, an instance of a

それぞれのADDMDオペレータ、aの例のために

               nadfADDMD

nadfADDMD

          object is used.  The RDN is formed as

物は使用されています。 RDNとして、形成されます。

               addmdName is <NADF registered name>

addmdNameは<NADF登録名>です。

          e.g.,

例えば

               addmdName is PSINet

addmdNameはPSINetです。

3.2.  Naming within a State or State-Equivalent

3.2. 状態か州同等物の中の命名

   At the regional level (at least) two kinds of names may be listed:

局在レベルでは、(少なくとも)の2種類の名前は記載されているかもしれません:

   (1)  Populated Places

(1) 居住された場所

   (2)  Organizations with Regional Standing

(2) 地方の地位との組織

3.2.1.  Populated Places

3.2.1. 居住された場所

   For each populated place within a state or state-equivalent,
   an instance of an

それぞれが状態か州同等物の中の場所、例に居住しました。

               usPlace

usPlace

          object is used.  The RDN is formed as

物は使用されています。 RDNとして、形成されます。

               localityName is <FIPS 55 name>

localityNameは<FIPS55名前>です。

          e.g.,

例えば

               localityName is Hartford

localityNameはハートフォードです。

   provides the RDN for the Hartford entry immediately subordinate to
   the usStateOrEquivalent entry for the State of Connecticut.  In
   addition, this entry would contain attributes identifying the FIPS 55
   place code, e.g.,

すぐに、ハートフォードエントリーにRDNをコネチカット州においてusStateOrEquivalentエントリーに下位で提供します。 さらに、このエントリーは例えばFIPS55場所コードを特定する属性を含んでいるでしょう。

                usPlaceCode is 37000

usPlaceCodeは37000です。

NADF                                                            [Page 6]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[6ページ]RFC1218は1991年4月に米国と等しいです。

3.2.2.  Organizations with Regional Standing

3.2.2. 地方の地位との組織

   An organization is said to have regional standing if it is registered
   with the "Secretary of State" or similar entity within that region,
   as an entity doing business in the region.

それがその領域の中の「国務長官」か同様の実体に登録されるなら、組織は地方の地位を持っていると言われます、その領域の実体する企業として。

   For each organization with regional standing, an instance of an

地方の地位、例がある各組織

               organization

組織

          object is used.  The RDN is formed as

物は使用されています。 RDNとして、形成されます。

               organizationName is <registered name of organization>

organizationNameは組織>の<登録名です。

          e.g.,

例えば

               organizationName is Network Management Associates

organizationNameはNetwork Management Associatesです。

   might provide the RDN for a business entity registered with the State
   of California.  In this case, the entry thus named would be
   immediately subordinate to the usStateOrEquivalent entry for the
   State of California.

カリフォルニア州に示された企業体にRDNを提供するかもしれません。 この場合、カリフォルニア州において、このようにして指定されたエントリーはすぐに、usStateOrEquivalentエントリーに下位でしょう。

   Note that other non-distinguished attributes, such as an ANSI numeric
   name form value, may be included in such an entry --- the
   organization object might actually be a usOrganization object.

ANSIの数値名前フォーム価値などの他の非顕著な属性がそのようなエントリーに含まれるかもしれないことに注意してください。--- 組織物は実際にusOrganization物であるかもしれません。

   For the Regional Government, an instance of an

Regional政府、例

               organization

組織

          object is also used.  The RDN is formed as:

また、物は使用されます。 RDNは以下として形成されます。

               organizationName is Government

organizationNameは政府です。

3.3.  Naming within a Populated Place

3.3. 居住された場所の中の命名

   At the local level (at least) three kinds of names may be listed:

地方レベルで(少なくとも)の3種類の名前は記載されているかもしれません:

   (1)  Persons

(1) 人々

   (2)  Organizations with Local Standing

(2) ローカルの地位との組織

   (3)  MHS Distribution Lists

(3) MHS発送先リスト

NADF                                                            [Page 7]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[7ページ]RFC1218は1991年4月に米国と等しいです。

3.3.1.  Naming of Persons

3.3.1. 人々の命名

   Within a populated place, there is no centralized naming entity which
   registers residential persons.  It is proposed that entries for
   persons be immediately subordinate to the usPlace object which most
   accurately reflects their place of residence.

居住された場所の中では、住宅の人々を登録する実体を命名するのは集結されません。 人々のためのエントリーがすぐに最も正確に彼らの居住地を反映するusPlace物に下位であるよう提案されます。

   For each person (wishing to have an entry in the Directory), an
   instance of a residentialperson

各人(ディレクトリにおけるエントリーを持っていることを願っている)、residentialpersonの例のために

               residentialPerson

residentialPerson

          object is used.  The RDN is usually multi-valued, formed with

物は使用されています。 通常、RDNはマルチ形成される状態で評価されています。

               commonName is <person's full name>

commonNameは<人のフルネームの>です。

   and some other attribute, such as postalCode, streetAddress, etc.
   However, because streetAddress is often considered private
   information, based on agreement with the entity managing the DMD and
   the listed person, some other, distinguishing attribute may be used,
   including a "serial number" (having no other purpose).  It should be
   noted however that this is non-helpful in regards to searching,
   unless other attribute values containing meaningful information are
   added to the entry and made available for public access.

そして、postalCode、streetAddressなどのある他の属性 しかしながら、streetAddressが個人情報であるとしばしば考えられるのでDMDと記載された人を管理する実体との協定に基づく、ある他の属性を区別して、中古の、そして、含んでいるa「通し番号」(他の目的を全く持っていない)はそうです。 しかしながら、これが探すのに関して非役立っていることに注意されるべきです、有意義な情報を含む他の属性値をエントリーに加えて、パブリックアクセスのために利用可能にしない場合。

3.3.2.  Organizations with Local Standing

3.3.2. ローカルの地位との組織

   An organization is said to have local standing if it is registered
   with the County or City Clerk or similar entity within that locality
   as an entity "doing business" in that place.

それがその場所で「ビジネスをし」ながら実体としてその場所の中にカウンティー、市のClerkまたは同様の実体に登録されるなら、組織はローカルの地位を持っていると言われます。

   For each organization with local standing, an instance of an

ローカルの地位、例がある各組織

               organization

組織

          object is used.  The RDN is formed as

物は使用されています。 RDNとして、形成されます。

               organizationName is <registered name of organization>

organizationNameは組織>の<登録名です。

          e.g.,

例えば

               organizationName is The Tied House

organizationNameはTied家です。

   might provide the RDN for a business entity registered with the City
   of Mountain View.  In this case, the entry thus named would be
   immediately subordinate to the usPlace entry for the City of Mountain
   View.

マウンテンビュー市に示された企業体にRDNを提供するかもしれません。 この場合、マウンテンビュー市において、このようにして指定されたエントリーはすぐに、usPlaceエントリーに下位でしょう。

NADF                                                            [Page 8]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[8ページ]RFC1218は1991年4月に米国と等しいです。

   Note that other non-distinguished attributes, such as an ANSI numeric
   name form value, may be included in an entry.  (That is, the
   organization object might actually be a usOrganization object.)

ANSIの数値名前フォーム価値などの他の非顕著な属性がエントリーに含まれるかもしれないことに注意してください。 (すなわち、組織物は実際にusOrganization物であるかもしれません。)

          For the Local Government, if any, an instance of an

Local政府、どんな、例です。

               organization

組織

          object is also used.  The RDN is formed as:

また、物は使用されます。 RDNは以下として形成されます。

               organizationName is Government

organizationNameは政府です。

3.4.  Naming of MHS Distribution Lists

3.4. MHS発送先リストの命名

   Naming of MHS distribution lists remains with the scoping DMD.

MHS発送先リストの命名は見ているDMDと共に残っています。

4.  Optimized Civil Naming

4. 最適化された民間命名

   The structure of the civil component of the architecture can be
   concisely described as:

構造の民間成分の構造を簡潔に以下と説明できます。

----------------------------------------------------------------------
Level   Element   objectClass             Superior    RDN
----------------------------------------------------------------------
root    0
----------------------------------------------------------------------
intl.   1         country                 0           countryName
----------------------------------------------------------------------
natl.   2         usStateOrEquivalent     1           localityName
        3         usOganization           1           organizationName
        4         nadfADDMD               1           addmdName
----------------------------------------------------------------------
reg.    5         usPlace                 2           localityName
        6         organization            2           organizationName
----------------------------------------------------------------------
local   7         residentialPerson       5           commonName,
                                                      other
        8         organization            5           organizationName
        9         mhsDistributionList     5           commonName
----------------------------------------------------------------------

---------------------------------------------------------------------- レベルの要素のobjectClassの優れたRDN---------------------------------------------------------------------- 根0---------------------------------------------------------------------- intl。 1 国0のcountryName---------------------------------------------------------------------- natl。 2 usStateOrEquivalent1localityName3usOganization1organizationName4nadfADDMD1addmdName---------------------------------------------------------------------- reg5usPlace2localityName6組織2organizationName---------------------------------------------------------------------- 地方の7residentialPerson5commonName、他の8組織5organizationName9mhsDistributionList5commonName----------------------------------------------------------------------

   Consider how an interrogation algorithm might locate a residential
   person, given:

考えて、査問アルゴリズムがどのように住宅の人の居場所を見つけるかもしれないか考えてください:

   (1)  a string denoting the person's real-world name;

(1) 人の本当の世界名を指示するストリング。

   (2)  a string denoting the real-world name of the populated
        place in which the person lives; and,

(2) 人が住んでいる居住された場所の本当の世界名を指示するストリング。 そして

NADF                                                            [Page 9]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[9ページ]RFC1218は1991年4月に米国と等しいです。

   (3)  the Distinguished Name of the state or state-equivalent.

(3) 状態か州同等物のDistinguished Name。

   A straight-forward approach is to initiate a single-level search to
   locate the desired populated place.  The search results in zero or
   more Distinguished Names being returned which correspond to the
   string provided by the user.  Then, for each populated place, a
   subtree search might be initiated to locate the desired residential
   person.  If the number of populated places returned by the first
   search is large, then this strategy is inefficient.

簡単なアプローチは必要な居住された場所の場所を見つけるようにただ一つのレベル検索を開始することです。 ゼロにおける検索結果かストリングに対応する返されるより多くのDistinguished Namesがユーザで提供しました。 そして、それぞれの居住された場所に関して、下位木検索は、必要な住宅の人の居場所を見つけるように開始されるかもしれません。 最初の検索で返された居住された場所の数が大きいなら、この戦略は効率が悪いです。

   A better approach would be to initiate a single search, with a filter
   combining the strings for both the person's real-world name and the
   place's real-world name.  Unfortunately, such a search would have to
   involve the whole-subtree anchored at the Distinguished Name for the
   state or state-equivalent, which would be inefficient.

より良いアプローチはただ一つの検索を開始するだろうことです、フィルタが人の本当の世界名と場所の本当の世界名の両方のためにストリングを結合していて。 残念ながら、そのような検索は効率が悪いだろうという状態か州同等物のためにDistinguished Nameに据えつけられた全体の下位木にかかわらなければならないでしょう。

   As such, it may be desirable to optimize the civil naming component
   by listing some entries at a higher level.  This is accomplished by
   using a multi-valued RDN formed by combining the RDNs of the entry
   and its superior.

そういうものとして、より高いレベルでいくつかのエントリーを記載することによって民間命名コンポーネントを最適化するのは望ましいかもしれません。 これは、エントリーとその上司のRDNsを結合することによって形成されたマルチ評価されたRDNを使用することによって、達成されます。

   There are three cases in civil naming:

民間命名における3つのケースがあります:

   (1)  listing an organization with regional standing at the
        national level;

(1) 全国レベルにおける地方の地位で組織を記載します。

   (2)  listing an organization with local standing at the
        regional level; and,

(2) 局在レベルにおけるローカルの地位で組織を記載します。 そして

   (3)  listing a person with local standing at the regional
        level.

(3) 局在レベルにおけるローカルの地位で人を記載すること。

   Hence, under the optimized civil naming component, a single-level
   search, anchored at the Distinguished Name for the state or state-
   equivalent, could be used.  Further, the implementation of a DSA
   supporting this optimization would highly-index the attributes used
   for searching, in order to achieve high-performance.

したがって、最適化された民間命名コンポーネントの下に、州か州の同等物のためにDistinguished Nameに据えつけられたただ一つのレベル検索は使用できました。 さらに、この最適化を支持するDSAの実現は探索に使用される属性に非常に索引をつけるでしょう、高性能を達成するために。

   In order to clearly indicate that optimized civil naming is in
   effect, a new attribute type, nadfSearchGuide, is introduced.  An
   attribute value of this type is placed in an entry to indicate which
   optimizations are in effect.  Using the residential example above,
   the entry for the state or state-equivalent would contain an
   nadfSearchGuide value indicating that when searching for entries of
   type residentialPerson, a single-level search should be performed
   with a filter containing the logical-and of two terms, one involving
   the commonName attribute, and the other involving the localityName
   attribute.  The nadfSearchGuide is a refinement of the X.500

最適化された民間命名が有効であることを明確に示すために、新しい属性タイプ(nadfSearchGuide)を導入します。 このタイプの属性値は、どの最適化が有効であるかを示すためにエントリーに置かれます。 そして、上記の住宅の例を使用して、状態か州同等物のためのエントリーがタイプresidentialPersonのエントリーを捜し求めるとき、フィルタが含んでいてただ一つのレベル検索が実行されるべきであるのを示すnadfSearchGuide値を含んでいるだろう、論理的である、-、2つの用語、commonName属性にかかわる1つ、localityNameが結果と考える他のおよびかかわるのについて。 nadfSearchGuideはX.500の気品です。

NADF                                                           [Page 10]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[10ページ]RFC1218は1991年4月に米国と等しいです。

   searchGuide in that it indicates the depth of the search which should
   be performed, and always contains an indication of the object class
   for which the optimization exists.

そうするべきである検索の深さを示すので、searchGuideは実行されて、いつも最適化が存在する物のクラスのしるしを含んでいます。

   Finally, note that for naming within organizations, this technique
   might also be used.

最終的に、また、組織の中の命名に、このテクニックが使用されるかもしれないことに注意してください。

4.1.  Naming at the National Level

4.1. 全国レベルにおける命名

4.1.1.  Organizations with Regional Standing

4.1.1. 地方の地位との組織

   An organization with standing within a state or state-equivalent may
   be listed directly under c=US.

状態か州同等物の中に立つ組織はc=米国の直接下に記載されているかもしれません。

   For an organization with regional standing, an instance of an

地方の地位、例がある組織

               organization

組織

          object is used.  The RDN is multi-valued, formed as

物は使用されています。 マルチ評価されていて、形成されたRDN

               organizationName is <registered name of organization>
               localityName is <FIPS 5 name>

organizationNameによる組織>localityNameの<登録名が<FIPS5名前>であるということです。

          e.g.,

例えば

               organizationName is Network Management Associates
               localityName is California

organizationNameによるNetwork Management Associates localityNameがカリフォルニアであるということです。

   It must be emphasized that uniqueness within the RDN comes from using
   the a regional localityName (state or state-Equivalent) in
   association with the correspondent organizationName in that region.

RDNの中のユニークさがその領域の通信員organizationNameと関連してa地方のlocalityName(状態か州同等物)を使用するのから来ると強調しなければなりません。

4.2.  Naming within a State or State-Equivalent

4.2. 状態か州同等物の中の命名

4.2.1.  Organizations with Local Standing

4.2.1. ローカルの地位との組織

   An organization with standing within a populated place may be listed
   directly under its state or state-equivalent.

居住された場所の中に立つ組織はその状態か州同等物の直接下で記載されているかもしれません。

   For an organization with local standing, an instance of an

ローカルの地位、例がある組織

               organization

組織

          object is used.  The RDN is multi-valued, formed as

物は使用されています。 マルチ評価されていて、形成されたRDN

               organizationName is <registered name of organization>
               localityName is <FIPS 55 name>

organizationNameによる組織>localityNameの<登録名が<FIPS55名前>であるということです。

NADF                                                           [Page 11]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[11ページ]RFC1218は1991年4月に米国と等しいです。

          e.g.,

例えば

               organizationName is The Tied House
               localityName is City of Mountain View

organizationNameによるTied下院localityNameがマウンテンビュー市であるということです。

   It must be emphasized that uniqueness within the RDN comes from using
   the a local localityName (populated place) in association with the
   correspondent organizationName in that place.

RDNの中のユニークさがその場所の通信員organizationNameと関連してa地方のlocalityName(場所に居住する)を使用するのから来ると強調しなければなりません。

4.2.2.  Persons

4.2.2. 人

   An person may be listed directly under its state or state-equivalent.

人はその状態か州同等物の直接下で記載されているかもしれません。

   For such a person, an instance of a

そのような人、aの例のために

                residentialPerson

residentialPerson

   object is used.  The RDN is multi-valued, formed by taking the RDN of
   the person and adding the RDN of the populated place containing the
   person.

物は使用されています。 RDNはマルチ評価されています、人のRDNを取って、人を含む居住された場所のRDNを加えることによって形成されて。

                commonName is the Marshall T. Rose
                postalCode is 94043-2112
                localityName is City of Mountain View

commonNameによるマーシャルT.ローズpostalCodeによる94043-2112 localityNameがマウンテンビュー市であるということであるということです。

   Note that for optimization to occur, the RDN of the person must not
   contain a localityName attribute value.

最適化が起こるように、人のRDNがlocalityName属性値を含んではいけないことに注意してください。

5.  Organizational Naming

5. 組織的な命名

   The internal structure of each usOrganization or organization object
   is a matter for that organization to establish.

それぞれのusOrganizationか組織物の内部の構造はその組織が確立する問題です。

   It is strongly recommended that organizationalUnit objects be used
   for structuring.  (If an organization uses a locality-based
   organizational hierarchy, this information can still be represented
   using the

organizationalUnit物が構造に使用されることが強く勧められます。 (組織が場所ベースの組織階層を使用するなら、この情報はまだ表された使用であることができます。

               organizationalUnit

organizationalUnit

          object.)

反対してください。)

6.  ADDMD Naming

6. ADDMD命名

   The internal structure of each nadfADDMD object is a matter for that
   service-provider to establish.

それぞれのnadfADDMD物の内部の構造はそのサービスプロバイダーが確立する問題です。

NADF                                                           [Page 12]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[12ページ]RFC1218は1991年4月に米国と等しいです。

7.  Application Naming

7. アプリケーション命名

   There are (at least) four kinds of OSI entities which may be listed:

記載されているかもしれない(少なくとも)の4種類のOSI実体があります:

   (1)  Application Processes and Entities

(1) アプリケーション・プロセスと実体

   (2)  MHS Distribution Lists

(2) MHS発送先リスト

   (3)  EDI Users

(3) EDIユーザ

   (4)  Devices

(4) 装置

7.1.  Naming of Application Processes and Entities

7.1. アプリケーション・プロセスと実体の命名

   Naming of OSI application processes and entities remains with the
   scoping DMD.  However, in order to foster interoperability, two
   requirements are made: first, application entity objects must be
   immediately subordinate to application process objects; and, second,
   application entities are represented by the nadfApplicationEntity
   object, which is identical to the applicationEntity object except
   that the presence of an attribute value of
   supportedApplicationContext is mandatory.

OSIアプリケーション・プロセスと実体の命名は見ているDMDと共に残っています。 しかしながら、相互運用性を伸ばすために、2つの要件が作られています: まず最初に、アプリケーション実体物はすぐに、アプリケーション・プロセス物に下位であるに違いありません。 そして、2番目に、アプリケーション実体はnadfApplicationEntity物によって表されます。(supportedApplicationContextの属性値の存在が義務的であるのを除いて、それは、applicationEntity物と同じです)。

7.2.  Naming of MHS Distribution Lists

7.2. MHS発送先リストの命名

   Naming of MHS distribution lists remains with the scoping DMD.

MHS発送先リストの命名は見ているDMDと共に残っています。

7.3.  Naming of EDI Users

7.3. EDIユーザの命名

   Naming of EDI users remains with the scoping DMD.

EDIユーザの命名は見ているDMDと共に残っています。

7.4.  Naming of Devices

7.4. 装置の命名

   Naming of OSI devices remains with the scoping DMD.

OSI装置の命名は見ているDMDと共に残っています。

8.  Usage Examples

8. 使用例

   Consider the following examples, expressed in a concise format (read
   left-to-right):

簡潔な形式で言い表された以下の例を考えてください(左から右を読んでください):

          Federal Government:

連邦政府:

               { c=US, o=Government }

cは米国と等しく、oは政府と等しいです。

          The State of California:

カリフォルニア州:

               { c=US, l=California }

cは米国、l=カリフォルニアと等しいです。

NADF                                                           [Page 13]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[13ページ]RFC1218は1991年4月に米国と等しいです。

          The District of Columbia:

コロンビア特別区:

               { c=US, l=District of Columbia }

cは米国、l=コロンビア特別区と等しいです。

          An organization with national standing:

国家の地位がある組織:

               { c=US, o=Performance Systems International }

cは米国と等しく、oは国際言語運用機構と等しいです。

          An ADDMD:

ADDMD:

               { c=US, addmdName=PSINet }

cは米国、addmdName=PSINetと等しいです。

          The Government of the State of California:

カリフォルニア州政府:

               { c=US, l=California, o=Government }

cは米国、l=カリフォルニアと等しく、oは政府と等しいです。

          The Government of the District of Columbia:

コロンビア特別区政府:

               { c=US, l=District of Columbia, o=Government }

cは米国、l=コロンビア特別区と等しく、oは政府と等しいです。

          A city within the State of California:

カリフォルニア州の中の都市:

               { c=US, l=California, l=City of Mountain View }

cは米国、l=カリフォルニア、マウンテンビューl=市と等しいです。

          An organization licensed to operate within the State of
          California:

カリフォルニア州の中で作動するために認可された組織:

               { c=US,
                 l=California,
                 o=Network Management Associates, Inc. }

cは米国、l=カリフォルニアと等しく、o=ネットワークマネージメントはInc.を関連づけます。

          An optimized listing for a organization with regional
          standing:

地方の地位がある組織のための最適化されたリスト:

               { c=US,
                 { l=California,
                   o=Network Management Associates }}

cは米国と等しく、lはカリフォルニアと等しく、oはネットワークマネージメント関連と等しいです。

NADF                                                           [Page 14]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[14ページ]RFC1218は1991年4月に米国と等しいです。

          A city government:

市庁:

               { c=US,
                 l=California,
                 l=City of Mountain View,
                 o=Government }

c=米国、l=カリフォルニア、マウンテンビューl=市oは政府と等しいです。

          A residential person:

住宅の人:

               { c=US,
                 l=California,
                 l=City of Mountain View,
                 { cn=Marshall T. Rose, postalCode=94043-2112 }}

{ cは米国、l=カリフォルニア、マウンテンビューl=市と等しいです。{ postalCode=94043-2112、cn=マーシャルT.は上昇しました。}

          An organization licensed to operate within a city:

都市の中で作動するために認可された組織:

               { c=US,
                 l=California,
                 l=City of Mountain View,
                 o=The Tied House }

c=米国、l=カリフォルニア、マウンテンビューl=市oはタイドハウスと等しいです。

          An entity within the Federal Government:

連邦政府の中の実体:

               { c=US, o=Government, ou=Department of the Air Force }

cは米国と等しく、oは政府と等しく、ouは空軍省と等しいです。

          An entity within an organization with national standing:

国家の地位がある組織の中の実体:

               { c=US,
                 o=Performance Systems International,
                 ou=Marketing }

cは米国と等しく、oは国際言語運用機構と等しく、ouはマーケティングと等しいです。

9.  Acknowledgements

9. 承認

   This document is based on many sources, including, but not limited
   to:

このドキュメントは多くのソース、包含、他に基づいています:

   - Listing Services Database Generic Requirements, Bellcore
     TA-TSY-000985;

- サービスデータベースジェネリック要件、Bellcoreを記載する、バイバイ、-、TSY-000985、。

   - Common Directory Use ED 013 (Q/511) (EWOS/EGDIR/90/156);
     and,

- 一般のディレクトリ使用教育013(Q/511)(EWOS/EGDIR/90/156)。 そして

   - The THORN X.500 Naming Architecture (UCL-45 revision 6.1).

- THORN X.500 Naming Architecture(UCL-45改正6.1)。

NADF                                                           [Page 15]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[15ページ]RFC1218は1991年4月に米国と等しいです。

10.  Bibliography

10. 図書目録

   X.500: The Directory --- Overview of Concepts, Models, and
        Service, CCITT Recommendation X.500, December, 1988.

X.500: ディレクトリ--- 概念、モデルとサービス、CCITT推薦X.500、1988年12月の概観。

   US FIPS 5: Codes for the Identification of the States, The
        District of Columbia and Outlying Areas of the United
        States, and Associated Areas, US Department of Commerce
        FIPS 5--2, May 28, 1987.

米国FIPS5: 合衆国、および関連領域、米国商務省FIPSの米国、コロンビア特別区、および辺ぴな領域の識別のために、5--2と、1987年5月28日にコード化します。

   US FIPS 6: Counties and Equivalent Entities of the United
        States, its Possessions, and Associated Areas, US
        Department of Commerce FIPS 6--4, August 31, 1990.

米国FIPS6: カウンティーとEquivalent Entities、1990年8月31日の合衆国、PossessionsとAssociated Areas、米国商務省FIPS6--4。

   US FIPS 55: Guideline: Codes for Named Populated Places,
        Primary County Divisions, and other Locational Entities
        of the United States and Outlying Areas, US Department of
        Commerce FIPS 55--2, February 3, 1987.

米国FIPS55: ガイドライン: 1987年2月3日の合衆国のNamed Populated Places、Primaryカウンティーの事業部と、他のLocational EntitiesとOutlying Areas、米国商務省FIPS55--2へのコード。

   The NADF is soliticting comments on this naming scheme.  Comments
   should be directed to:

NADFはこの命名計画のコメントをsolitictingしています。 コメントによる以下のことよう指示されるべきです。

               Postal:         Dr. Marshall T. Rose
                               Performance Systems International
                               5201 Great American Parkway
                               Suite 3106
                               Santa Clara, CA  95054
                               US
               Telephone:      +1 408 562 6222
               Fax:            +1 408 562 6223
               Internet:       mrose@psi.com
               X.500:          rose, psi, us

郵便: すばらしいアメリカの公園道路スイート3106マーシャルT.ローズ博士の言語運用機構国際5201カリフォルニア95054サンタクララ(米国)に電話をします: +1 408 562、6222Fax: +1 408 562、6223年のインターネット: mrose@psi.com X.500: バラ、psi、私たち

   Comments should be received prior to July 1, 1991.

1991年7月1日以前、コメントを受けるべきです。

Appendix A:  Naming Architecture

付録A: 構造を命名します。

   There are two aspects to the naming architecture: a DIT structure and
   a set of related Schema definitions.  These are shown on pages 17 and
   18, respectively.

命名構造への2つの局面があります: DIT構造と関連するSchema定義のセット。 これらは17と18ページにそれぞれ示されます。

NADF                                                           [Page 16]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[16ページ]RFC1218は1991年4月に米国と等しいです。

DIT Structure

デイット構造

----------------------------------------------------------------------
Level   Element   objectClass             Superior    RDN
----------------------------------------------------------------------
root    0
----------------------------------------------------------------------
intl.   1         country                 0           countryName
----------------------------------------------------------------------
natl.   2         usStateOrEquivalent     1           localityName
        3         usOganization           1           organizationName
        4         nadfADDMD               1           addmdName
----------------------------------------------------------------------
reg.    5         usPlace                 2           localityName
        6         organization            2           organizationName
----------------------------------------------------------------------
local   7         residentialPerson       5           commonName,
                                                      other
        8         organization            5           organizationName
        9         mhsDistributionList     5           commonName
----------------------------------------------------------------------
----------------------------------------------------------------------
opt.    6*        organization            1          organizationName,
                                                     localityName
        7*        residentialPerson       2          commonName,
                                                     other,
                                                     localityName
        8*        organization            2          organizationName,
                                                     localityName
----------------------------------------------------------------------
----------------------------------------------------------------------
org.    10**      organizationalUnit      3,6,8,10,11 orgUnitName
        11**      locality                3,6,8,10,11 localityName
        12**      organizationalRole      3,6,8,10,11 commonName
        13**      organizationalPerson    3,6,8,10,11 commonName
----------------------------------------------------------------------
----------------------------------------------------------------------
appl.   14        applicationProcess      3,6,8,10,11 commonName
        15        nadfApplicationEntity   14          commonName
        16        mhsDistributionList     3,6,8,10,11 commonName
        17        ediUser                 3,6,8,10,11 ediName
        18        device                  3,6,8,10,11 commonName
----------------------------------------------------------------------

---------------------------------------------------------------------- レベルの要素のobjectClassの優れたRDN---------------------------------------------------------------------- 根0---------------------------------------------------------------------- intl。 1 国0のcountryName---------------------------------------------------------------------- natl。 2 usStateOrEquivalent1localityName3usOganization1organizationName4nadfADDMD1addmdName---------------------------------------------------------------------- reg5usPlace2localityName6組織2organizationName---------------------------------------------------------------------- 地方の7residentialPerson5commonName、他の8組織5organizationName9mhsDistributionList5commonName---------------------------------------------------------------------- ---------------------------------------------------------------------- 選んでください。 6*組織、1organizationName、localityName7*residentialPerson2commonName、他のlocalityName8*組織、2organizationName、localityName---------------------------------------------------------------------- ---------------------------------------------------------------------- org。 10**organizationalUnit3、6、8、10、11orgUnitName11**場所3、6、8、10、11localityName12**organizationalRole3、6、8、10、11commonName13**organizationalPerson3、6、8、10、11commonName---------------------------------------------------------------------- ---------------------------------------------------------------------- appl。 14 applicationProcess3、6、8、10、11commonName15nadfApplicationEntity14commonName16mhsDistributionList3、6、8、10、11commonName17ediUser3、6、8、10、11ediName18装置3、6、8、10、11commonName----------------------------------------------------------------------

   * = These are the optimized form of the corresponding element in the
   civil component.

* = これらは民間コンポーネントの対応する要素の最適化されたフォームです。

   ** = This scheme makes no requirements on the DIT structure within an

** = この計画は中でDIT構造の上で要件を全く作りません。

NADF                                                           [Page 17]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[17ページ]RFC1218は1991年4月に米国と等しいです。

   organization.  The organizational structure shown here is only for
   exposition.  For example, MHS objects are not listed beneath the
   organizational level, though they are likely to occur within an
   organization.

組織。 ここに示された組織体制は博覧会のためだけのものです。 例えば、それらは組織の中に起こりそうですが、MHS物は組織的なレベルの下に記載されていません。

Schema Definitions

図式定義

         NADF-SCHEMA { joint-iso-ccitt mhs(6) group(6) al-grimstad(5)
                       nadf(1) schema(1) }

NADF-図式共同iso-ccitt mhs(6)グループ(6)アル-grimstad(5) nadf(1)図式(1)

         DEFINITIONS ::= BEGIN

定義:、:= 始まってください。

         IMPORTS
             OBJECT-CLASS, ATTRIBUTE
                 FROM InformationFramework
                     { joint-iso-ccitt ds(5) module(1)
                           informationFramework(1) }
             caseIgnoreStringSyntax, Criteria
                 FROM SelectedAttributeTypes
                     { joint-iso-ccitt ds(5) module(1)
                           selectedAttributeTypes(5) }
             locality, organization, applicationEntity, top
                 FROM SelectedObjectClasses
                     { joint-iso-ccitt ds(5) module(1)
                           selectedObjectClasses(6) }
                 ;

IMPORTS OBJECT-CLASS、ATTRIBUTE FROM InformationFramework共同iso-ccitt ds(5)モジュール(1)informationFramework(1)、caseIgnoreStringSyntax、Criteria FROM SelectedAttributeTypes共同iso-ccitt ds(5)モジュール(1)selectedAttributeTypes(5)、場所、組織(applicationEntity)はFROM SelectedObjectClasses共同iso-ccitt ds(5)モジュール(1)selectedObjectClasses(6)を上回っています。

         nadf OBJECT IDENTIFIER ::= { joint-iso-ccitt mhs(6) group (6)
                                      al-grimstad(5) 1 }

nadf OBJECT IDENTIFIER:、:= 共同iso-ccitt mhs(6)グループ(6)アル-grimstad(5)1

         nadfModule          OBJECT IDENTIFIER ::= { nadf 1 }
         nadfAttributeType   OBJECT IDENTIFIER ::= { nadf 4 }
         nadfObjectClass     OBJECT IDENTIFIER ::= { nadf 6 }

nadfModule物の識別子:、:= nadf1nadfAttributeType OBJECT IDENTIFIER:、:= nadf4nadfObjectClass OBJECT IDENTIFIER:、:= nadf6

         -- object classes

-- 物のクラス

         usStateOrEquivalent OBJECT-CLASS
             -- localityName is used for RDN
             -- values come from US FIPS PUB 5
             SUBCLASS OF locality
             MUST CONTAIN { fipsStateNumericCode,
                            fipsStateAlphaCode,
                            stateOrProvinceName }
             MAY CONTAIN  { nadfSearchGuide }
             ::= { nadfObjectClass 1 }

localityNameがRDNに使用されるという値がUS FIPS PUB5SUBCLASS OF場所MUST CONTAINから来させるusStateOrEquivalent OBJECT-CLASS、fipsStateNumericCode、fipsStateAlphaCode、stateOrProvinceName、MAY CONTAIN nadfSearchGuide:、:= nadfObjectClass1

NADF                                                           [Page 18]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[18ページ]RFC1218は1991年4月に米国と等しいです。

         usPlace OBJECT-CLASS
             -- localityName is used for RDN
             -- values come from US FIPS PUB 55
             SUBCLASS OF locality
             MUST CONTAIN { fipsPlaceNumericCode,
                            localityName }
             MAY CONTAIN  { nadfSearchGuide }
             ::= { nadfObjectClass 2 }

localityNameがRDNに使用されるという値がUS FIPS PUB55SUBCLASS OF場所MUST CONTAINから来させるusPlace OBJECT-CLASS、fipsPlaceNumericCode、localityName、MAY CONTAIN nadfSearchGuide:、:= nadfObjectClass2

          usCounty OBJECT-CLASS
             SUBCLASS OF usPlace
             MUST CONTAIN { fipsCountyNumericCode }
             ::= { nadfObjectClass 3 }

usPlaceのusCounty物クラスサブクラスはfipsCountyNumericCodeを含まなければなりません:、:= nadfObjectClass3

         usOrganization OBJECT-CLASS
             -- organizationName is used for RDN
             -- values come from ANSI Alphanumeric Registry
             SUBCLASS OF organization
             MUST CONTAIN { ansiOrgNumericCode }
             MAY CONTAIN  { nadfSearchGuide }
             ::= { nadfObjectClass 4 }

organizationNameがRDNに使用されるという値がANSI Alphanumeric Registry SUBCLASS OF組織MUST CONTAIN ansiOrgNumericCodeから来させるusOrganization OBJECT-CLASS、MAY CONTAIN nadfSearchGuide:、:= nadfObjectClass4

         nadfApplicationEntity OBJECT-CLASS
             SUBCLASS OF applicationEntity
             MUST CONTAIN { supportedApplicationContext }
             ::= { nadfObjectClass 5 }

applicationEntityのnadfApplicationEntity物クラスサブクラスはsupportedApplicationContextを含まなければなりません:、:= nadfObjectClass5

         nadfADDMD OBJECT-CLASS
             -- addmdName is used for RDN
             -- values come from NADF Registry (tbd)
             SUBCLASS OF top
             MUST CONTAIN { addmdName }
             MAY CONTAIN  { nadfSearchGuide }
             ::= { nadfObjectClass 6 }

nadfADDMD OBJECT-CLASS--addmdNameはRDNに使用されます--値はNADF Registry(tbd)SUBCLASS OFの最高MUST CONTAIN addmdName MAY CONTAIN nadfSearchGuideから来ます:、:= nadfObjectClass6

         -- auxiliary classes

-- 補助のクラス

         nadfObject OBJECT-CLASS
             SUBCLASS OF top
             MAY CONTAIN { supplementaryInformation }
             ::= { nadfObjectClass 7 }

nadfObject OBJECT-CLASS SUBCLASS OFはMAY CONTAIN supplementaryInformationを上回っています:、:= nadfObjectClass7

NADF                                                           [Page 19]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[19ページ]RFC1218は1991年4月に米国と等しいです。

         -- attribute types

-- 属性タイプ

         fipsStateNumericCode ATTRIBUTE

fipsStateNumericCode属性

                 -- semantics and values defined in US FIPS PUB 5
             WITH ATTRIBUTE-SYNTAX
                             -- leading zero is significant
                 NumericString (SIZE (2))
                 MATCHES FOR EQUALITY
             ::= { nadfAttributeType 1 }

-- 意味論と値はUS FIPS PUB5でWITH ATTRIBUTE-SYNTAXを定義しました--先行ゼロが重要なNumericStringである、(SIZE(2))MATCHES FOR EQUALITY:、:= nadfAttributeType1

         fipsStateAlphaCode ATTRIBUTE
                 -- semantics and values defined in US FIPS PUB 5
             WITH ATTRIBUTE-SYNTAX
                 PrintableString (SIZE (2))
                 MATCHES FOR EQUALITY      -- case-insensitive
             ::= { nadfAttributeType 2 }

fipsStateAlphaCode ATTRIBUTE、--、意味論と値がUS FIPS PUB5でWITH ATTRIBUTE-SYNTAX PrintableStringを定義した(SIZE(2))MATCHES FOR EQUALITY--大文字と小文字を区別しない:、:= nadfAttributeType2

         fipsCountyNumericCode ATTRIBUTE
                 -- semantics and values defined in US FIPS PUB 6
             WITH ATTRIBUTE-SYNTAX
                             -- leading zeros are significant
                 NumericString (SIZE (3))
                 MATCHES FOR EQUALITY
             ::= { nadfAttributeType 3 }

fipsCountyNumericCode ATTRIBUTE--US FIPS PUB6WITH ATTRIBUTE-SYNTAXで定義された意味論と値--先行ゼロが重要なNumericStringである、(SIZE(3))MATCHES FOR EQUALITY:、:= nadfAttributeType3

         fipsPlaceNumericCode ATTRIBUTE
                 -- semantics and values defined in US FIPS PUB 55
             WITH ATTRIBUTE-SYNTAX
                             -- leading zeros are significant
                 NumericString (SIZE (5))
                 MATCHES FOR EQUALITY
             ::= { nadfAttributeType 4 }

fipsPlaceNumericCode ATTRIBUTE--US FIPS PUB55WITH ATTRIBUTE-SYNTAXで定義された意味論と値--先行ゼロが重要なNumericStringである、(SIZE(5))MATCHES FOR EQUALITY:、:= nadfAttributeType4

         ansiOrgNumericCode ATTRIBUTE
                 -- semantics and values defined in ANSI registry
             WITH ATTRIBUTE-SYNTAX
                 INTEGER
                 MATCHES FOR EQUALITY
             ::= { nadfAttributeType 5 }

ansiOrgNumericCode ATTRIBUTE--意味論と値はANSI登録でWITH ATTRIBUTE-SYNTAX INTEGER MATCHES FOR EQUALITYを定義しました:、:= nadfAttributeType5

         addmdName ATTRIBUTE
                 -- semantics and values defined in NADF registry
             WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
             ::= { nadfAttributeType 6 }

addmdName ATTRIBUTE--意味論と値はNADF登録でWITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntaxを定義しました:、:= nadfAttributeType6

NADF                                                           [Page 20]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[20ページ]RFC1218は1991年4月に米国と等しいです。

         nadfSearchGuide ATTRIBUTE
             WITH ATTRIBUTE-SYNTAX NadfGuide
             ::= { nadfAttributeType 7 }

nadfSearchGuideは属性構文NadfGuideと共に以下を結果と考えます:= nadfAttributeType7

         NadfGuide ::=
             SET {
                 objectClass[0]
                     OBJECT-CLASS,
                 criteria[1]
                     Criteria,
                 subset[2]
                     INTEGER {
                         baseObject(0), oneLevel(1), wholeSubtree(2)
                     } DEFAULT oneLevel
             }

NadfGuide:、:= セットします。objectClass[0] OBJECT-CLASS、評価基準[1]評価基準、部分集合[2]INTEGER、baseObject(0)、oneLevel(1)、wholeSubtree(2)、DEFAULT oneLevel

         supplementaryInformation ATTRIBUTE
             WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..76))
             ::= { nadfAttributeType 8 }

supplementaryInformationは属性構文caseIgnoreStringSyntax(サイズ(1 .76))と共に以下を結果と考えます:= nadfAttributeType8

         END

終わり

Appendix B:  Revision History of this Scheme

付録B: このSchemeの改正歴史

   The first version of this scheme (NADF-71) was contributed to the
   North American Directory Forum at its November 27--30, 1990 meeting.
   The (mis)features were:

1990年11月27日〜30日のミーティングでこの計画(NADF-71)の最初のバージョンを北米のディレクトリForumに寄付しました。 (誤、)、特徴は以下の通りでした。

   (1)  Because of the lack of confidence in ANSI registration
        procedures, it was proposed that the US trademarks be
        used as the basis for RDNs of organizations with
        national-standing.

(1) ANSI登録手順における信用の不足のために、米国商標が組織のRDNsの基礎として国家の地位で使用されるよう提案されました。

        This proved unworkable since the same trademark may be
        issued to different organizations in different
        industries.

これは、異なった産業で異なった組織に同じ商標を発行するかもしれないので、「非-実行可能」であると判明しました。

   (2)  There was no pre-existing registry used for populated
        places.

(2) 居住された場所に使用される先在の登録が全くありませんでした。

        This proved unworkable since the effort to define a new
        registry is problematic.

新しい登録を定義するための努力が問題が多いので、これは「非-実行可能」であると判明しました。

   The second version of this scheme was contributed to the ANSI
   Registration Authority Committee at its January 30, 1991 meeting, and
   the IETF OSI Directory Services Working Group at its February 12--13,
   1991 meeting.  The (mis)features were:

1991年2月12日〜13日のミーティングで1991年1月30日ミーティング、およびIETF OSIディレクトリサービス作業部会でこの計画の第2バージョンをANSI Registration Authority Committeeに寄付しました。 (誤、)、特徴は以下の通りでした。

NADF                                                           [Page 21]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[21ページ]RFC1218は1991年4月に米国と等しいです。

   (1)  The ANSI numeric name form registry was used as the basis
        for RDNs of organizations with national standings.

(1) ANSIの数値名前フォーム登録は組織のRDNsの基礎として国家の順位表で使用されました。

   (2)  The FIPS 5 state numeric code was used as the basis for
        RDNs of states and state-equivalents.

(2) FIPS5州の数字コードは州のRDNsの基礎と州同等物として使用されました。

   (3)  The FIPS 55 place numeric code was used as the basis for
        RDNs of populated places.

(3) FIPS55場所数字コードは居住された場所のRDNsの基礎として使用されました。

   The choice of numeric rather than alphanumeric name forms was
   unpopular, but was motivated by the desire to avoid using the ANSI
   alphanumeric name form registry, which was perceived as unstable.

英数字であるというよりむしろ数値の名前フォームの選択は、不人気でしたが、ANSIの英数字の名前フォーム登録を使用するのを避ける願望によって動機づけられました。登録は不安定であるとして知覚されました。

   The third version of this scheme was contributed to US State
   Department Study Group D's MHS-MD subcommittee at its March 7--8 1991
   meeting.  That version used alphanumeric name forms for all objects,
   under the perception that the ANSI alphanumeric name form registry
   will prove stable.  If the ANSI alphanumeric name form registry
   proves unstable, then two alternatives are possible:

1991年3月7日〜8日のミーティングで米国国務省Study Group DのMHS-MD小委員会にこの計画の第3バージョンを寄付しました。 そのバージョンはすべての物に英数字の名前フォームを使用しました、ANSIの英数字の名前フォーム登録が安定していると立証する知覚で。 ANSIの英数字の名前フォーム登録が不安定であると判明するなら、2つの選択肢が可能です:

   (1)  disallow organizations with national-standing in the US
        portion of the DIT; or,

(1) 国家の地位がDITの米国の部分にある状態で、組織を禁じてください。 または

   (2)  use the ANSI numeric name form registry instead.

(2) 代わりにANSIの数値名前フォーム登録を使用してください。

   Hopefully neither of these two undesirable alternatives will prove
   necessary.

うまくいけば、これらの2つの望ましくない選択肢のどちらも必要であると判明しないでしょう。

   The fourth version of this scheme (NADF-103) was contributed to the
   North American Directory Forum at its March 18--22, 1990 meeting.
   This version introduced the notion of organizations with regional
   standing being listed at the national level through the use of alias
   names and multi-valued RDNs.

1990年3月18日〜22日のミーティングでこの計画(NADF-103)の第4バージョンを北米のディレクトリForumに寄付しました。 地方の地位が全国レベルで別名とマルチ評価されたRDNsの使用で記載されている状態で、このバージョンは組織の概念を紹介しました。

   The current (fifth) version of this scheme (NADF-123) generalized the
   listing concept by introducing the notion of optimized civil naming.
   Further, the document was edited to clearly note the different naming
   components and the relation between them.

この計画(NADF-123)の(5番目)の現在のバージョンは、最適化された民間命名の概念を紹介することによって、リスト概念を広めました。 さらに、ドキュメントは、明確に異なった命名コンポーネントとそれらの関係に注意するために編集されました。

NADF                                                           [Page 22]

RFC 1218                A Naming Scheme for c=US              April 1991

cのための命名計画あたりNADF[22ページ]RFC1218は1991年4月に米国と等しいです。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

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

Author's Address

作者のアドレス

   North American Directory Forum
   c/o Theodore H. Myer
   Rapport Communication, Inc.
   3055 Q Street NW
   Washington, DC  20007

セオドアH.マイヤー関係コミュニケーションInc.3055Q通りNWワシントン、北米のディレクトリフォーラム気付DC 20007

   Tel: +1 202-342-2727

Tel: +1 202-342-2727

NADF                                                           [Page 23]

NADF[23ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

暗号化・複合化を行う ブロック暗号

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る