RFC1384 日本語訳
1384 Naming Guidelines for Directory Pilots. P. Barker, S.E.Hardcastle-Kille. January 1993. (Format: TXT=25870, PS=175044, PDF=134487 bytes) (Obsoleted by RFC1617, RTR0011) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Barker
Requests for Comments 1384 University College London
S.E. Hardcastle-Kille
ISODE Consortium
January 1993
バーカーがユニバーシティ・カレッジロンドン東南Hardcastle-Kille ISODE共同体1993年1月にコメント1384のために要求するネットワークワーキンググループP.
Naming Guidelines for Directory Pilots
ガイドラインをディレクトリのパイロットにちなんで命名します。
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.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Abstract
要約
Deployment of a Directory will benefit from following certain guidelines. This document defines a number of naming guidelines. Alignment to these guidelines is recommended for directory pilots.
ディレクトリの展開は次のあるガイドラインの利益を得るでしょう。 このドキュメントは多くの命名ガイドラインを定義します。 これらのガイドラインへの整列はディレクトリのパイロットのために推薦されます。
1 Introduction
1つの序論
As a pre-requisite to this document, it is assumed that the COSINE and Internet X.500 Schema is followed [1].
このドキュメントへの前提条件として、COSINEとインターネットX.500 Schemaが続かれていると思われます。[1]。
2 DIT structure
2 DIT構造
The majority of this document is concerned with DIT structure and naming for organisations, organisational units and personal entries. This section briefly notes three other key issues.
このドキュメントの大部分が機構、organisationalユニット、および個人的なエントリーのためのDIT構造と命名に関係があります。 このセクションは簡潔に他の主要な3冊に注意します。
2.1 The top level of the DIT
2.1 DITのトップレベル
The following information will be present at the top level of the DIT:
以下の情報はDITのトップレベルで存在するでしょう:
Participating Countries
The entries should contain suitable values of the "Friendly
Country" attribute.
エントリーがそうするべきである参加Countriesは「友好国」属性の適当な値を含んでいます。
International Organisations
An international organisation is an organisation, such as the
United Nations, which inherently has a brief and scope covering
many nations. Such organisations might be considered to be
supra-national and this, indeed, is the raison-d'etre of such
organisations. Such organisations will almost all be governmental
or quasi-governmental. A multi-national organisation is an
国際Organisations An国際機関は機構です、国連などのように。(本来、要約と範囲はそれで、多くの国を含みます)。 そのような機構が上国家であると考えられるかもしれなくて、本当に、これはそのような機構の存在理由です。 そのような機構はほとんどすべてを望んでいます。政府である、または準政府になってください。 多国籍の機構はそうです。
Barker & Hardcastle-Kille [Page 1] RFC 1384 Naming Guidelines January 1993
1993年1月とガイドラインを命名するバーカーとHardcastle-Kille[1ページ]RFC1384
organisation which operates in more than one country, but is not
supra-national. This classification includes the large commercial
organisations whose production and sales are spread throughout a
large number of countries.
1つ以上の国で作動していますが、上国家でない機構。 この分類は生産販売が多くの国中で広げられる大きい営利団体を含んでいます。
International organisations, may be registered at the top level.
This will not be done for multi-national organisations. The only
international organisation registered so far is: Internet. This
is not a formal registration, but is adopted for the Internet
Directory Service.
国際機関は登録されているかもしれません。最高レベルで。 多国籍の機構のためにこれをしないでしょう。 今までのところ登録されている唯一の国際機関は以下の通りです。 インターネット。 これは、正式な登録ではありませんが、インターネットディレクトリサービスのために採用されます。
Localities
A few localities will be registered under the root. The chief
purpose of these locality entries is to provide a "natural" parent
node for organisations which are supra-national, and yet which do
not have global authority in their particular field. Such
organisations will usually be governmental or quasi-governmental.
Example localities might include: Europe, Africa, West Indies.
Example organisations within Europe might include: European Court
of Justice, European Space Agency, European Commission.
場所Aわずかな場所しか根の下で示されないでしょう。 これらの場所エントリーの最大の目標は上国家ですが、それらの特定の分野にグローバルな権威を持っていない機構のための「自然な」親ノードを提供することです。 通常、そのような機構は、政府である、または準政府になるでしょう。 例の場所は以下を含むかもしれません。 ヨーロッパ、アフリカ、西インド諸島。 ヨーロッパの中の例の機構は以下を含むかもしれません。 欧州司法裁判所、欧州宇宙機関、欧州委員会。
DSA Information
Some information on DSAs may be needed at the top level. This
should be kept to a minimum.
DSAsのDSA情報Some情報がトップレベルで必要であるかもしれません。 これは最小限に保たれるべきです。
The only directory information for which there is a recognised top level registration authority is countries. Registration of other information at the top level may potentially cause problems. At this stage, it is argued that the benefits of additional top level registration outweighs these problems. However, this potential problem should be noted by anyone making use of such a registration.
認識された最高平らな登録局がある唯一のディレクトリ情報が国です。 トップレベルにおける他の情報の登録は潜在的に問題を起こすかもしれません。現在のところ、追加最高平らな登録の恩恵がこれらの問題より重いと主張されます。しかしながら、そのような登録を利用することでこの潜在的な問題はだれによっても注意されるべきです。
2.2 The DNS within the DIT
2.2 デイットの中のDNS
The rules for the DNS parts of the DIT are defined in [3]. One modification to this is that the DNS tree will be rooted under "O=Internet", rather than at the root of the DIT.
DITのDNS部分への規則は[3]で定義されます。 これへの1つの変更はDNS木がDITの根でというよりむしろ「Oはインターネットと等しい」下に根づくということです。
2.3 Access control
2.3 アクセス管理
An entry's object class attribute, and any attribute(s) used for naming an entry are of special significance and may be considered to be "structural". Any inability to access these attributes will often militate against successful querying of the Directory. For example, user interfaces typically limit the scope of their searches by searching for entries of a particular type, where the type of entry is indicated by its object class. Thus, unless the intention is to bar public access to an entry or set of entries, the object class and
エントリーの物のクラス属性、およびエントリーを命名するのが「構造的に」特別な意味があって、考えられるかもしれないので使用されるどんな属性。 これらの属性にアクセスできないどんなこともしばしばディレクトリのうまくいっている質問に影響するでしょう。 例えば、ユーザインタフェースは、エントリーのタイプが物のクラスによって示される特定のタイプのエントリーを捜し求めることによって、彼らの検索の範囲を通常制限します。 そしてその結果、物のクラスでない、意志がエントリーのエントリーかセットにパブリックアクセスを禁じないことであるなら。
Barker & Hardcastle-Kille [Page 2] RFC 1384 Naming Guidelines January 1993
1993年1月とガイドラインを命名するバーカーとHardcastle-Kille[2ページ]RFC1384
naming attributes should be publicly readable.
属性を命名するのは公的に読み込み可能であるべきです。
3 Naming Style
3 様式を命名すること。
The first goal of naming is to provide unique identifiers for entries. Once this is achieve, the next major goal in naming entries should be to facilitate querying of the Directory. In particular, support for a naming structure which facilitates use of user friendly naming is desirable. Other considerations, such as accurately reflecting the organisational structure of an organisation, should be disregarded if this has an adverse effect on normal querying. Early experience in the pilot has shown that a consistent approach to structure and naming is an aid to querying using a wide range of user interfaces, as interfaces are often optimised for DIT structures which appear prevalent.
命名の初ゴールはエントリーのためのユニークな識別子を提供することです。 一度、これがそうである、達成、エントリーを命名することにおける次の主要な目標はディレクトリが質問されるのを容易にすることであるべきです。 ユーザフレンドリーな命名の使用を容易にする命名構造のサポートは特に、望ましいです。 これが正常な質問に悪影響を及ぼすなら、正確に機構のorganisational構造を反映などなどの他の問題は無視されるべきです。 パイロットの早めの経験は、構造と命名への一貫したアプローチがさまざまなユーザインタフェースを使用する質問への援助であることを示しました、インタフェースがしばしば一般的に見えるDIT構造に最適化されるとき。
Naming is dependent on a number of factors and these are now considered in turn.
命名は多くの要因に依存しています、そして、これらは現在、順番に考えられます。
3.1 National Guidelines
3.1 国家のガイドライン
Where naming is being done in a country which has established guidelines for naming, these guidelines should in general be followed. These guidelines might be based on an established registration authority, or may make use use of an existing registration mechanism (e.g., company name registration).
一般に、命名が命名のためのガイドラインを確立した国で行われているところに、これらのガイドラインは従われるべきです。 これらのガイドラインは、設立された登録局に基づいているか、または使用を既存の登録メカニズム(例えば、会社名登録)の使用にするかもしれません。
Where an organisation has a name which is nationally registered in an existing registry, this name is likely to be appropriate for use in the Directory, even in cases where there are no national guidelines.
機構には既存の登録に全国的に登録される名前があるところでは、この名前はディレクトリにおける使用に適切である傾向があります、どんな国家のガイドラインもない場合でさえ。
3.2 Structure Rules
3.2 構造規則
A DIT structure is suggested in Annex B of X.521, and it is recommended that Directory Pilots should follow a slightly modified form of these guidelines. The rules should be extended for handling DNS [3]. Some simple restrictions should be applied, as described below.
DIT構造はX.521のAnnex Bで提案されます、そして、ディレクトリPilotsがこれらのガイドラインのわずかに変更されたフォームに続くはずであるのは、お勧めです。 規則は取り扱いDNS[3]のために広げられるべきです。 いくつかの簡単な制限が以下で説明されるように適用されるべきです。
For most countries pilots, the following simple structure should suffice. The country entry will appear immediately beneath the root of the tree. Organisations which have national significance should have entries immediately beneath their respective country entries. Smaller organisations which are only known in a particular locality should be placed underneath locality entries representing states or similar geographical divisions. Large organisations will probably need to be sub-divided by organisational units to help in the disambiguation of entries for people with common names. Entries for
ほとんどの国のパイロットのために、以下の単純構造は十分であるべきです。 国のエントリーは木の根のすぐ下に現れるでしょう。 国家の意味を持っている機構は彼らのそれぞれの国のエントリーのすぐ下にエントリーを持つべきです。 特定の場所で知られているだけであるより小さい機構は、州か同様の地理的な部門を代表しながら、場所エントリーの下に置かれるべきです。 大きな組織はたぶんorganisationalユニットによって細分されて、人々のために一般名でエントリーの曖昧さの解消で助ける必要があるでしょう。 エントリー
Barker & Hardcastle-Kille [Page 3] RFC 1384 Naming Guidelines January 1993
1993年1月とガイドラインを命名するバーカーとHardcastle-Kille[3ページ]RFC1384
people and roles will be stored beneath organisations or organisational units. An example plan evolving for the US is the work of the North American Directory Forum [2].
人々と役割は機構かorganisationalユニットの下に格納されるでしょう。 米国に発展する例のプランは北米のディレクトリForum[2]の仕事です。
As noted above, there will be a few exceptions to this basic structure. International organisations will be stored immediately under the root of the tree. Multi-national organisations will be stored within the framework outlined, but with some use of aliases and attributes such as seeAlso to help bind together the constituent parts of these organisations. This is discussed in more detail later.
上で述べたように、この基本構造へのいくつかの例外があるでしょう。 国際機関は木の根のすぐ下で格納されるでしょう。 多国籍の機構は、これらの機構の構成している部分を一緒にくくるのを助けるために概説されているのにもかかわらずの、seeAlsoなどの別名と属性の何らかの使用がある枠組みの中に格納されるでしょう。 さらに詳細に後でこれについて議論します。
3.3 Depth of tree
3.3 木の深さ
The broad recommendation is that the DIT should be as flat as possible. A flat tree means that Directory names will be relatively short, and probably somewhat similar in length and component structure to paper mail addresses. A deep DIT would imply long Directory names, with somewhat arbitrary component parts, with a result which it is argued seems less natural. Any artificiality in the choice of names militates against successful querying.
広い推薦はDITができるだけ平坦であるべきであるということです。 平坦な木は、ディレクトリ名がたぶん長さとコンポーネント構造で比較的不足していて、紙の郵便の宛先といくらか同様になることを意味します。 深いDITは、長さが論争されて、ディレクトリがいくらか任意のコンポーネントの部品、それがそうである結果で命名するより自然でなく見えるのを含意するでしょう。 名前の選択におけるどんな不自然さもうまくいっている質問に影響します。
A presumption behind this style of naming is that most querying will be supported by the user specifying convenient strings of characters which will be mapped onto powerful search operations. The alternative approach of the user browsing their way down the tree and selecting names from large numbers of possibilities may be more appropriate in some cases, and a deeper tree facilitates this. However, these guidelines recommend a shallow tree, and implicitly a search oriented approach.
このスタイルの命名の後ろの推定はほとんどの質問が強力な索敵行動に写像されるキャラクタの便利なストリングを指定するユーザによって支持されるということです。 いくつかの場合、木の下側にそれらの道をブラウズして、多くの可能性から名前を選択するユーザの代替的アプローチは、より適切であるかもしれません、そして、より深い木はこれを容易にします。 しかしながら、これらのガイドラインは浅い木を推薦します、そして、それとなく、検索はアプローチを適応させました。
It may be considered that there are two determinants of DIT depth: first, how far down the DIT an organisation is placed; second, the structure of the DIT within organisations.
DITの深さの2つの決定因があると考えられるかもしれません: まず最初に、どれくらい遠くにDITの下側に、機構は置かれるか。 2番目、機構の中のDITの構造。
The structure of the upper levels of the tree will be determined in due course by various registration authorities, and the pilot will have to work within the given structure. However, it is important that the various pilots are cognisant of what the structures are likely to be, and move early to adopt these structures.
木の上側のレベルの構造は様々な登録局でやがて決定するでしょう、そして、パイロットは与えられた構造の中で働かなければならないでしょう。 しかしながら、様々なパイロットは構造がおそらくであることになっているこれらの構造を採用するために早く動かすものにおいて認識力があるのは、重要です。
The other principal determinant of DIT depth is whether an organisation splits its entries over a number of organisational units, and if so, the number of levels. The recommendation here is that this sub-division of organisations is kept to a minimum. A maximum of two levels of organisational unit should suffice even for large organisations. Organisations with only a few tens or hundreds of employees should strongly consider not using organisational units
そして、DITの深さのもう片方の主行列式が機構が多くのorganisationalユニットの上にエントリーを分けるかどうかということである、そうだとすれば、レベルの数。 機構のこの下位区分が最小限に保たれるという推薦がここにあります。 最大2つのレベルのorganisational単位は大きな組織にさえ十分であるはずです。 ほんのいくつかによる10か何百人もの従業員が強くそうするべきである機構は、organisationalユニットを使用すると考えません。
Barker & Hardcastle-Kille [Page 4] RFC 1384 Naming Guidelines January 1993
1993年1月とガイドラインを命名するバーカーとHardcastle-Kille[4ページ]RFC1384
at all. It is noted that there may be some problems with choice of unique RDNs when using a flat DIT structure. Multiple value RDNs can alleviate this problem. The standard recommends that an organizationalUnitName attribute can also be used as a naming attribute to disambiguate entries. Further disambiguation may be achieved by the use of a personalTitle attribute in the RDN.
全く。 平坦なDIT構造を使用するとき、ユニークなRDNsの選択に関するいくつかの問題があるかもしれないことに注意されます。 複数の値のRDNsがこの問題を軽減できます。 規格は、また、エントリーのあいまいさを除くのに命名属性としてorganizationalUnitName属性を使用できることを勧めます。 さらなる曖昧さの解消はRDNにおけるpersonalTitle属性の使用で達成されるかもしれません。
3.4 Organisation and Organisational Unit Names
3.4 機構とOrganisationalユニット名
The naming of organisations in the Directory will ultimately come under the jurisdiction of official naming authorities. In the interim, it is recommended that pilots and organisations follow these guidelines. An organisation's RDN should usually be the full name of the organisation, rather than just a set of initials. This means that University College London should be preferred over UCL. An example of the problems which a short name might cause is given by the proposed registration of AA for the Automobile Association. This seems reasonable at first glance, as the Automobile Association is well known by this acronym. However, it seems less reasonable in a broader perspective when you consider organisations such as Alcoholics Anonymous and American Airlines which use the same acronym. Just as initials should usually be avoided for organisational RDNs, so should formal names which, for example, exist only on official charters and are not generally well known. There are two reasons for this approach:
ディレクトリにおける、機構の命名は結局、公式の命名当局の管轄に該当するでしょう。 その間、パイロットと機構がこれらのガイドラインに従うのは、お勧めです。 通常、機構のRDNはちょうど1セットのイニシャルよりむしろ機構のフルネームであるべきです。 これは、ユニバーシティ・カレッジロンドンがUCLより好まれるべきであることを意味します。 省略名が引き起こすかもしれない問題に関する例は自動車協会のためにAAの提案された登録で出されます。 自動車協会がよく知られているとき、これはこの頭文字語で一見したところでは妥当に思えます。 しかしながら、あなたが同じ頭文字語を使用するアルコール中毒者自主治療協会やアメリカン航空などの機構を考えるとき、それは大局的見地で、より妥当でなく思えます。 ちょうど通常、イニシャルがorganisational RDNsのために避けられるべきであるように、例えば、公式の特許だけで存在していて、一般に、よく知られていない正式名もそうするべきです。 このアプローチの2つの理由があります:
1. The names should be meaningful.
1. 名前は重要であるはずです。
2. The names should uniquely identify the organisation, and be a
name which is unlikely to be challenged in an open registration
process. For example, UCL might well be challenged by United
Carriers Ltd.
2. 名前は、唯一機構を特定して、開いている登録手続で挑戦されそうにない名前であるべきです。 例えば、UCLはたぶんUnited Carriers Ltd.によって挑戦されるでしょう。
The same arguments on naming style can be applied with even greater force to the choice of RDNs for organisational units. While abbreviated names will be in common parlance within an organisation, they will almost always be meaningless outside of that organisation. While many people in academic computing habitually refer to CS when thinking of Computer Science, CS may be given several different interpretations. It could equally be interpreted as Computing Services, Cognitive Science, Clinical Science or even Counselling Services.
さらに大きい力と共にスタイルを命名するときの同じ議論をRDNsの選択にorganisationalユニット適用できます。 普通の言い方で機構の中に略称があるでしょうが、それらは外でその機構で無意味にほとんどいつもなるでしょう。 コンピュータScienceを考えるとき、アカデミックなコンピューティングにおける多くの人々が習慣的にCSについて言及している間、いくつかの異なった解釈をCSにするかもしれません。 コンピューターサービス、Cognitive Science、Clinical ScienceまたはCounselling Servicesとしてさえ等しくそれを解釈できました。
For both organisations and organisational units, extra naming information should be stored in the directory as alternative values of the naming attribute. Thus, for University College London, UCL should be stored as an alternative organizationName attribute value. Similarly CS could be stored as an alternative organizationalUnitName
機構とorganisationalユニットの両方に関しては、余分な命名情報は命名属性の代替の値としてディレクトリに格納されるべきです。 したがって、ユニバーシティ・カレッジロンドンに関して、UCLは代替のorganizationName属性値として格納されるべきです。 同様に、代替のorganizationalUnitNameとしてCSを格納できました。
Barker & Hardcastle-Kille [Page 5] RFC 1384 Naming Guidelines January 1993
1993年1月とガイドラインを命名するバーカーとHardcastle-Kille[5ページ]RFC1384
value for Computer Science and any of the other departments cited earlier. In general, entries will be located by searching, and so it is not essential to have names which are either memorable or guessable. Minimising of typing may be achieved by use of carefully selected alternate values.
コンピュータには、Scienceと、より早く引用された他の部のいずれも評価してください。 一般に、エントリーが探すことによって見つけられるので、忘れられないか、または推測可能な名前を持っているのは不可欠ではありません。 タイプについて最小となることは慎重に選択された交互の値の使用で達成されるかもしれません。
3.5 Naming human users
3.5 人間のユーザを命名すること。
A reasonably consistent approach to naming people is particularly critical as a large percentage of directory usage will be looking up information about people. User interfaces will be better able to assist users if entries have names conforming to a common format, or small group of formats. It is suggested that the RDN should follow such a format. Alternative values of the common name attribute should be used to store extra naming information. It seems sensible to try to ensure that the RDN commonName value is genuinely the most common name for a person as it is likely that user interfaces may choose to place greater weight on matches on the RDN than on matches on one of the alternative names. It is proposed that pilots should ignore the standard's recommendations on storing personal titles, and letters indicating academic and professional qualifications within the commonName attribute, as this overloads the commonName attribute. A personalTitle attribute has already been specified in the COSINE and Internet Schema, and another attribute could be specified for information about qualifications.
大きい百分率のディレクトリ用法が人々の情報を調べることであるので、人々を命名することへの合理的に一貫したアプローチは特に批判的です。 エントリーに一般的な形式、または形式の小さいグループに従う名前があると、ユーザインタフェースはユーザをよりよく補助できるでしょう。 RDNがそのような形式に続くはずであると示唆されます。 一般名属性の代替の値は、余分な命名情報を格納するのに使用されるべきです。 ユーザインタフェースが、RDNの上のマッチのマッチより大きい重さを代替名の1つに置くのを選びそうなときRDN commonName値が人のための本当に最も一般的な名前であることを保証しようとするのは分別があるように思えます。 パイロットが個人的なタイトルを格納するときの規格の推薦、およびcommonName属性の中にアカデミックでプロの資格を示す手紙を無視するべきであるよう提案されます、これがcommonName属性を積みすぎるとき。 personalTitle属性はCOSINEとインターネットSchemaで既に指定されました、そして、別の属性は資格の情報に指定されるかもしれません。
Furthermore, the common name attribute should not be used to hold other attribute information such as telephone numbers, room numbers, or local codes. Such information should be stored within the appropriate attributes as defined in the COSINE and Internet X.500 Schema. If such attributes have to be used to disambiguate entries, multi-valued RDNs should be used, such that other attribute(s) be used for naming in addition to a common name.
その上、電話番号、部屋番号、またはローカルのコードなどの他の属性情報を保持するのに一般名属性を使用するべきではありません。 そのような情報はCOSINEとインターネットX.500 Schemaで定義されるように適切な属性の中に格納されるべきです。 そのような属性がエントリーのあいまいさを除くのに使用されなければならないなら、マルチ評価されたRDNsは使用されるべきです、そのようなものによって、他の属性は一般名に加えた命名に使用されます。
The choice of RDN for humans will be influenced by cultural considerations. In many countries the best choice will be of the form familiar-first-name surname. Thus, Steve Hardcastle-Kille is preferred as the RDN choice for one of this document's co-authors, while Stephen E. Hardcastle-Kille is stored as an alternative commonName value. Sets of initials should not be concatenated into a single "word", but be separated by spaces and/or "." characters. Pragmatic choices will have to be made for other cultures.
人間のためのRDNの選択は文化的な問題によって影響を及ぼされるでしょう。 多くの国では、最も良い選択がフォーム身近な名姓のものになるでしょう。 したがって、スティーブHardcastle-Killeはこのドキュメントの共著者のひとりのRDN選択として好まれます、スティーブンE.Hardcastle-Killeが代替のcommonName値として格納されますが。 「単一の「単語」にイニシャルのセットを連結するべきではありませんが、」 . 」 空間、そして/または、キャラクタは切り離してください。 他の文化のために実践的な選択をしなければならないでしょう。
3.6 Application Entities
3.6 アプリケーション実体
The guidelines of X.521 should be followed, in that the application entity should always be named relative to an Organisation or Organisational Unit. The application process will often correspond
X.521のガイドラインは従われるべきです、アプリケーション実体がいつもOrganisationかOrganisational Unitに比例して命名されるべきであるので。 アプリケーション・プロセスはしばしば対応するでしょう。
Barker & Hardcastle-Kille [Page 6] RFC 1384 Naming Guidelines January 1993
1993年1月とガイドラインを命名するバーカーとHardcastle-Kille[6ページ]RFC1384
to a system or host. In this case, the application entities should be named by Common Names which identify the service (e.g., "FTAM Service"). In cases where there is no useful distinction between application process and application entity, the application process may be omitted (This is often done for DSAs in the current pilot).
システムかホストに。 この場合、アプリケーション実体はサービス(例えば、「FTAMサービス」)を特定する俗称によって命名されるべきです。 アプリケーション・プロセスとアプリケーション実体の間にどんな役に立つ区別もない場合では、アプリケーション・プロセスは省略されるかもしれません(現在のパイロットのDSAsのためにしばしばこれをします)。
4 Multinational Organisations
4 多国籍の機構
The standard says that only international organisations may be placed under the root of the DIT. This implies that multi-national organisations must be represented as a number of separate entries underneath country or locality entries. This structure makes it more awkward to use X.500 within a multi-national to provide an internal organisational directory, as the data is now spread widely throughout the DIT, rather than all being grouped within a single sub-tree. Many people have expressed the view that this restriction is a severe limitation of X.500, and argue that the intentions of the standard should be ignored in this respect. This note argues, though, that the standard should be followed.
規格は、DITの根の下で国際機関だけを置いてもよいと言います。 これは、多くの別々のエントリー下部の国か場所エントリーとして多国籍の機構を代表しなければならないのを含意します。 この構造で、データが現在広く広げられるときすべての存在よりむしろただ一つの下位木の中で分類されたDITに内部のorganisationalディレクトリを供給するのは多国籍企業の中でX.500を使用するためにさらに無器用になります。 多くの人々が、この制限がX.500の厳しい限界であるという意見を述べて、規格の意志がこの点で無視されるべきであると主張します。 もっとも、この注意は、規格が続かれるべきであると主張します。
No attempt to precisely define multinational organisation is essayed here. Instead, the observation is made that the term is applied to a variety of organisational structures, where an organisation operates in more than one country. This suggests that a variety of DIT structures may be appropriate to accommodate these different organisational structures. This document suggests three approaches, and notes some of the characteristics associated with each of these approaches.
正確に多国籍の機構を定義する試みは全くここで試みられません。 代わりに、用語が機構が1つ以上の国で作動するさまざまなorganisational構造に適用されるという観測をします。 これは、さまざまなDIT構造はこれらの異なったorganisational構造に対応するのが適切であるかもしれないと示唆します。 このドキュメントは特性のいくつかがそれぞれのこれらのアプローチに関連づけた3つのアプローチ、および注意を示します。
Before considering the approaches, it is worth bearing in mind again that a major aim in the choice of a DIT structure is to facilitate querying, and that approaches which militate against this should be avoided wherever possible.
アプローチを考える前に、DIT構造の選択における主要な目的が質問するのを容易にすることであり、これに影響するアプローチがどこでも、可能であるところで避けられるべきであるのを再び覚えておく価値があります。
Barker & Hardcastle-Kille [Page 7] RFC 1384 Naming Guidelines January 1993
1993年1月とガイドラインを命名するバーカーとHardcastle-Kille[7ページ]RFC1384
4.1 The multi-national as a single entity
4.1 単一体としての多国籍企業
ROOT
/ | \
/ | \
C=GB C=FR C=US
/ | \
/ | \
O=MultiNat---->O=MultiNat<----O=MultiNat
/ | \
/ | \
/ | \
l=abc ou=def l=fgi
根/| \ / | \C=GB C=フランCはU.S./と等しいです。| \ / | \O=MultiNat---->O=MultiNat<。----O=MultiNat/| \ / | \ / | クールな\l=abc ou=lはfgiと等しいです。
---> means "alias to"
--->が意味する、「別名、」
Figure 1: The multi-national as a single entity
図1: 単一体としての多国籍企業
In many cases, a multi-national organisation will operate with a highly centralised structure. While the organisation may have large operations in a number of countries, the organisation is strongly controlled from the centre and the disparate parts of the organisation exist only as limbs of the main organisation. In such a situation, the model shown in figure 1 may be the best choice. The organisation's entries all exist under a single sub-tree. The organisational structure beneath the organisation entry should reflect the perceived structure of the organisation, and so no recommendations on this matter can be made here. To assist the person querying the directory, alias entries should be created for all countries where the organisation operates.
多くの場合、多国籍の機構は非常に集中化された構造で作動するでしょう。 機構が多くの国に大きい操作を持っているかもしれない間、機構はセンターから強く制御されます、そして、機構の異種の部分は単に主な機構の手足として存在しています。 そのような状況、図のモデルでは、1は最も良い選択であるかもしれません。 機構のエントリーはただ一つの下位木の下ですべて存在しています。 機構エントリーの下のorganisational構造が機構の知覚された構造を反映するはずであるので、ここでこの件における推薦状を全くすることができません。 ディレクトリについて質問している人を補助するために、別名エントリーは機構が作動するすべての国に作成されるべきです。
4.2 The multi-national as a loose confederation
4.2 自由な同盟者としての多国籍企業
Another common model of organisational structure is that where a multi-national consists of a number of national entities, which are in large part independent of both sibling national entities, and of any central entity. In such cases, the model shown in Figure 2 may be a
organisational構造の別の一般的なモデルは多国籍企業が多くの両方の兄弟の国家の実体、およびどんな中央の実体からも主に独立している国家の実体から成るところのそれです。 そのような場合、図2で見せられたモデルはaであるかもしれません。
Barker & Hardcastle-Kille [Page 8] RFC 1384 Naming Guidelines January 1993
1993年1月とガイドラインを命名するバーカーとHardcastle-Kille[8ページ]RFC1384
ROOT
/ | \
/ | \
C=GB C=FR C=US
/ | \
/ | \
O=MultiNat O=MultiNat O=MultiNat
/ | / | \ | \
/ | / | \ | \
L=GB L=FR / | \ L=FR L=US
L=GB L=FR L=US
根/| \ / | \C=GB C=フランCはU.S./と等しいです。| \ / | \O=MultiNat O=MultiNat O=MultiNat/| / | \ | \ / | / | \ | \L=GB L=フラン/| \L=フランL=U.S.L=GB L=フランLは米国と等しいです。
---> means "alias to"
--->が意味する、「別名、」
Figure 2: The multi-national as a loose confederation
図2: 自由な同盟者としての多国籍企業
better choice. Organisational entries exist within each country, and only that country's localities and organisational units appear directly beneath the appropriate organisational entry. Some binding together of the various parts of the organisation can be achieved by the use of aliases for localities and organisational units, and this can be done in a highly flexible fashion. In some cases, the national view might not contain all branches of the company, as illustrated in Figure 2.
より良い選択。 Organisationalエントリーは各国の中に存在しています、そして、その国だけの場所とorganisationalユニットは適切なorganisationalエントリーの直接下に現れます。 別名の場所とorganisationalユニットの使用で一緒に機構の様々な部分の何らかの結合を達成できます、そして、非常にフレキシブルなやり方でこれができます。 いくつかの場合、国家の視点は図2で例証されるように会社のすべてのブランチを含むかもしれないというわけではありません。
4.3 Loosely linked DIT sub-trees
4.3 緩くリンクされたDIT下位木
A third approach is to avoid aliasing altogether, and to use the looser binding provided by an attribute such as seeAlso. This approach treats all parts of an organisation as essentially separate.
3番目のアプローチは、全体でエイリアシングを避けて、seeAlsoなどの属性によって提供されたよりゆるい結合を使用することです。 このアプローチは同じくらい本質的には別々の状態で機構のすべての部分を治療します。
A unified view of the organisation can only be achieved by user interfaces choosing to follow the seeAlso links. This is a key difference with aliasing, where decisions to follow links may be specified within the protocol. (Note that it may be better to specify another attribute for this purpose, as seeAlso is likely to be used for a wide variety of purposes.)
seeAlsoリンクに続くのを選ぶユーザインタフェースは機構の統一見解を達成できるだけです。 これはエイリアシングがある主要な違いです。(そこでは、リンクに続くという決定がプロトコルの中で指定されるかもしれません)。 (このために別の属性を指定しているほうがよいかもしれないことに注意してください、seeAlsoがさまざまな目的に使用されそうなとき。)
4.4 Summary of advantages and disadvantages of the above approaches
4.4 利点の概要と上のアプローチの損失
Providing an internal directory
All the above methods can be used to provide an internal
directory. In the first two cases, the linkage to other parts of
the organisation can be followed by the protocol and thus
上記のAllを内部のディレクトリに供給して、内部のディレクトリを提供するのに方法を使用できます。 最初の2つの場合では、プロトコルはこのようにして機構の他の部分へのリンケージのあとに続くことができます。
Barker & Hardcastle-Kille [Page 9] RFC 1384 Naming Guidelines January 1993
1993年1月とガイドラインを命名するバーカーとHardcastle-Kille[9ページ]RFC1384
organisation-wide searches can be achieved by single X.500
operations. In the last case, interfaces would have to "know" to
follow the soft links indicated by the seeAlso attribute.
ただ一つのX.500操作で機構全体の検索を達成できます。 最後の場合では、インタフェースはseeAlso属性によって示された柔らかいリンクに続くのを「知らなければならないでしょう」。
Impact on naming
In the single-entity model, all DNs within the organisation will
be under one country. It could be argued that this will often
result in rather "unnatural" naming. In the loose-confederation
model, DNs are more natural, although the need to disambiguate
between organisational units and localities on an international,
rather than just a national, basis may have some impact on the
choice of names. For example, it may be necessary to add in an
extra level of organisational unit or locality information. In
the loosely-linked model, there is no impact on naming at all.
単一体モデルにInを任命するとき影響を与えてください、そして、機構の中のすべてのDNsが1つ未満の国になるでしょう。 これがしばしばかなり「不自然な」命名をもたらすと主張できました。 自由な同盟者モデルでは、DNsは、より当然です、間にあいまいさを除く必要性が正当であるというよりむしろ国際的なa同胞のユニットと場所をorganisationalしますが、基礎は名前の選択に何らかの影響力を持っているかもしれません。 例えば、余分なレベルのorganisationalユニットか場所情報を加えるのが必要であるかもしれません。 緩く繋がっているモデルには、全く命名への影響が全くありません。
Views of the organisation
The first method provides a unique view of the organisation. The
loose confederacy allows for a variety of views of the
organisation. The view from the centre of the organisation may
well be that all constituent organisations should be seen as part
of the main organisation, whereas other parts of the organisation
may only be interested in the organisation's centre and a few of
its sibling organisations. The third model gives an equally
flexible view of organisational structures.
最初の方法が機構のユニークな意見を提供する機構の視点。 ゆるい連盟は機構のさまざまな視点を考慮します。 たぶん、機構のセンターからの視点はすべての構成している機構が主な機構の一部と考えられるべきですが、機構の他の部分が機構のセンターと兄弟機構のいくつかに興味を持っているだけであるかもしれないということでしょう。 第3代モデルはorganisational構造の等しくフレキシブルな意見を与えます。
Lookup performance
All methods should perform reasonably well, providing information
is held, or at least replicated, within a single DSA.
情報が独身のDSAの中で保持されるか、または少なくとも模写されているなら、ルックアップ性能All方法は合理的によく振る舞うべきです。
5 Miscellany
5雑録
This section draws attention to two areas which frequently provoke questions, and where it is felt that a consistent approach will be useful.
このセクションは頻繁に質問を引き起こして、一貫したアプローチがなる役に立つのが感じられる2つの領域に注意を向けます。
5.1 Schema consistency of aliases
5.1 別名の図式の一貫性
According to the letter of the standard, an alias may point at any entry. It is beneficial for aliases to be ``schema consistent''. The following two checks should be made:
規格の手紙によると、別名はどんなエントリーも指し示すかもしれません。 別名が「図式一貫する」であることは、有益です。 以下の2つのチェックをするべきです:
1. The Relative Distinguished Name of the alias should be a valid
Relative Distinguished Name of the entry.
1. 別名のRelative Distinguished Nameはエントリーの有効なRelative Distinguished Nameであるべきです。
2. If the entry (aliased object) were placed where the alias is,
there should be no schema violation.
2. エントリー(物をaliasedした)が別名があるところに置かれるなら、図式違反が全くないでしょうに。
Barker & Hardcastle-Kille [Page 10] RFC 1384 Naming Guidelines January 1993
1993年1月とガイドラインを命名するバーカーとHardcastle-Kille[10ページ]RFC1384
5.2 Organisational Units
5.2 Organisationalユニット
There is a problem that many organisations can be either organisations or organisational units, dependent on the location in the DIT (with aliases giving the alternate names). For example, an organisation may be an independent national organisation and also an organisational unit of a parent organisation. To achieve this, it is important to allow an entry to be of both object class organisation and of object class organisational unit.
多くの機構が機構かorganisationalユニットのどちらかであるかもしれないという問題があります、DIT(別名が別名称を与えている)の位置に依存しています。 例えば、機構は、独立している全国的な組織とまた、母体のorganisational部隊であるかもしれません。 これを達成するために、エントリーが物のクラス機構と物のクラスorganisational単位の両方の、ものであることを許容するのは重要です。
References
参照
[1] P. Barker and S.E. Hardcastle-Kille. The COSINE and Internet
X.500 schema. Request for Comments RFC 1274, Department of
Computer Science, University College London, November 1991.
[1] P.バーカーと東南Hardcastle-Kille。 COSINEとインターネットX.500図式。 コメントには、1991年11月にRFC1274、コンピュータサイエンス学部、ユニバーシティ・カレッジロンドンを要求してください。
[2] The North American Directory Forum. A Naming Scheme for C=US,
September 1991. Also NADF-175.
[2] 北米のディレクトリフォーラム。 Cの命名体系は1991年9月に米国と等しいです。 NADF-175も。
[3] S.E. Hardcastle-Kille. X.500 and domains. Request for Comments
RFC 1279, Department of Computer Science, University College
London, November 1991.
[3] 東南Hardcastle-Kille。 X.500とドメイン。 コメントには、1991年11月にRFC1279、コンピュータサイエンス学部、ユニバーシティ・カレッジロンドンを要求してください。
6 Security Considerations
6 セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Barker & Hardcastle-Kille [Page 11] RFC 1384 Naming Guidelines January 1993
1993年1月とガイドラインを命名するバーカーとHardcastle-Kille[11ページ]RFC1384
7 Authors' Addresses
7人の作者のアドレス
Paul Barker
Department of Computer Science
University College London
Gower Street
WC1E 6BT
England
バーカー・コンピュータサイエンス学部のユニバーシティ・カレッジのロンドンガウアー・ストリートWC1E 6BTイギリスのポール
Phone:+44-71-380-7366
+44-71-380-7366に以下に電話をしてください。
EMail: P.Barker@CS.UCL.AC.UK
メール: P.Barker@CS.UCL.AC.UK
Steve Hardcastle-Kille
ISODE Consortium
P.O. Box 505
London
SW11 1DX
England
スティーブHardcastle-Kille ISODE共同体P.O. Box505ロンドンSW11 1DXイギリス
Phone:+44-71-223-4062
+44-71-223-4062に以下に電話をしてください。
EMail: S.Kille@ISODE.COM
メール: S.Kille@ISODE.COM
Barker & Hardcastle-Kille [Page 12]
バーカーとHardcastle-Kille[12ページ]
一覧
スポンサーリンク
