RFC1781 日本語訳
1781 Using the OSI Directory to Achieve User Friendly Naming. S.Kille. March 1995. (Format: TXT=47129 bytes) (Obsoletes RFC1484) (Obsoleted by RFC3494) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Kille Request for Comments: 1781 ISODE Consortium Obsoletes: 1484 March 1995 Category: Standards Track
Killeがコメントのために要求するワーキンググループS.をネットワークでつないでください: 1781年のISODE共同体は以下を時代遅れにします。 1484 1995年3月のカテゴリ: 標準化過程
Using the OSI Directory to Achieve User Friendly Naming
ユーザフレンドリーな命名を達成するのにOSIディレクトリを使用します。
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are:
OSIディレクトリには、目標としてユーザフレンドリーな命名があります。 ディレクトリの簡単な気にされた使用法はこれを実現しません。 獲得されなかった2つの局面は以下の通りです。
o A user oriented notation
o ユーザは記法を適応させました。
o Guessability
o Guessability
This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a standard format for representing names, and to procedures to resolve them. This leads to a specification which allows directory names to be communicated between humans. The format in this specification is identical to that defined in [5], and it is intended that these specifications are compatible.
この提案は、好意的な態度で名前を表すためにいくつかのコンベンションを出して、本当に好意的な命名を達成するのにどうこれを使用できるかを示しています。 そして、これは、それらを決議するために名前を表して、手順への標準書式の仕様に通じます。 これはディレクトリ名が人間の間で伝えられるのを許容する仕様に通じます。 この仕様による形式は[5]で定義されたそれと同じです、そして、これらの仕様は互換性があることを意図します。
Table of Contents
目次
1. Why a notation is needed ................................... 2
2. The Notation ............................................... 3
3. Communicating Directory Names .............................. 7
4. Matching a purported name .................................. 9
4.1 Environment .......................................... 9
4.2 Matching ............................................. 10
4.3 Top Level ............................................ 12
4.4 Intermediate Level ................................... 13
4.5 Bottom Level ......................................... 14
5. Examples ................................................... 14
6. Support required from the standard ......................... 15
1. 記法が必要である理由… 2 2. 記法… 3 3. ディレクトリ名を伝えます… 7 4. 主張された名前を合わせます… 9 4.1環境… 9 4.2 合っています… 10 4.3はレベルを上回っています… 12 4.4 中間的レベル… 13 4.5 レベルに底をつけてください… 14 5. 例… 14 6. サポートが規格から必要です… 15
Kille [Page 1] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[1ページ]RFC1781
7. Support of OSI Services .................................... 15
8. Experience ................................................. 16
9. Relationship to other work ................................. 17
10. Issues ..................................................... 19
11. References ................................................. 20
12. Security Considerations .................................... 21
13. Author's Address ........................................... 21
A. Pseudo-code for the matching algorithm ..................... 22
List of Figures
1. Example usage of User Friendly Naming ................ 18
2. Matching Algorithm ................................... 22
List of Tables
1. Local environment for private DUA .................... 10
2. Local environment for US Public DUA .................. 11
7. OSIサービスのサポート… 15 8. 経験… 16 9. 他の仕事との関係… 17 10. 問題… 19 11. 参照… 20 12. セキュリティ問題… 21 13. 作者のアドレス… 合っているアルゴリズムのための21A.中間コード… 数字1の22リスト。 User Friendly Namingの例の使用法… 18 2. アルゴリズムを合わせます… テーブル1の22リスト。 個人的なDUAのための地方の環境… 10 2. 米国Public DUAのための地方の環境… 11
1. Why a notation is needed
1. 記法が必要である理由
Many OSI Applications make use of Distinguished Names (DN) as defined in the OSI Directory [1]. The main reason for having a notation for name format is to interact with a user interface. This specification is coming dangerously close to the sin of standardising interfaces. However, there are aspects of presentation which it is desirable to standardise.
多くのOSI ApplicationsがOSIディレクトリ[1]で定義されるようにDistinguished Names(DN)を利用します。 名前形式のための記法を持つ主な理由はユーザーインタフェースと対話することです。 この仕様は危険に標準化インタフェースの罪に近づいています。 しかしながら、標準化するのが望ましいプレゼンテーションの局面があります。
It is important to have a common format to be able to conveniently refer to names. This might be done to represent a directory name on a business card or in an email message. There is a need for a format to support human to human communication, which must be string based (not ASN.1) and user oriented.
便利に名前を示すことができるように一般的な形式を持っているのは重要です。 名刺の上、または、メールメッセージのディレクトリ名を表すためにこれをするかもしれません。 形式が人間のコミュニケーションに人間をサポートする必要があって、どれがストリングであるに違いないかは(ASN.1でない)と適応したユーザを基礎づけました。
In very many cases, a user will be required to input a name. This notation is designed to allow this to happen in a uniform manner across many user interfaces. The intention is that the name can just be typed in. There should not be any need to engage in form filling or complex dialogue. It should be possible to take the "human" description given at the meeting, and use it directly. The means in which this happens will become clear later.
非常に多くの場合では、ユーザが、名前を入力するのに必要でしょう。 この記法は、これが多くのユーザインタフェースの向こう側に一定の方法で起こるのを許容するように設計されています。 意志はただ名前をタイプできるということです。 用紙記入か複雑な対話に従事する少しの必要もあるべきではありません。 ミーティングで与えられた「人間」の記述を取って、直接それを使用するのは可能であるべきです。 後でこれが起こる手段は明確になるでしょう。
This approach uses the syntax defined in [5] for representing distinguished names. By relaxing some of the constraints on this specification, it is argued that a more user oriented specification is produced. However, this syntax cannot be mapped algorithmically onto a distinguished name without the use of a directory.
このアプローチは、分類名を表すのに[5]で定義された構文を使用します。 この仕様で規制のいくつかを弛緩することによって、より多くのユーザ指向の仕様が作り出されると主張されます。 しかしながら、ディレクトリの使用なしでこの構文を分類名にalgorithmicallyに写像できません。
This notation is targeted towards a general user oriented system, and in particular to represent the names of humans. Other syntaxes may be more appropriate for other uses of the directory. For example, the OSF Syntax may be more appropriate for some system oriented uses.
この記法は一般的なユーザ指向のシステム、人間の名前を表すために特定で狙います。 ディレクトリの他の用途には、他の構文は、より適切であるかもしれません。 例えば、いくつかのシステム指向の用途には、OSF Syntaxは、より適切であるかもしれません。
Kille [Page 2] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[2ページ]RFC1781
(The OSF Syntax uses "/" as a separator, and forms names in a manner intended to resemble UNIX filenames).
「(OSF Syntaxが」 /を使用する、」、中の方法がUNIXファイル名に類似するつもりであったa分離符、およびフォーム名、)
This notation is targeted towards names which follow a particular DIT structure: organisationally oriented. This may make it inappropriate for some types of application. There may be a requirement to extend this notation to deal more cleanly with fully geographical names.
この記法は特定のDIT構造に従う名前に向かって狙います: organisationallyに指向しています。 これで、それは何人かのタイプの適用に不適当になるかもしれません。 より清潔に完全に地理的な名前に対処するためにこの記法を広げるという要件があるかもしれません。
This approach effectively defines a definition of descriptive names on top of the primitive names defined by the OSI Directory.
事実上、このアプローチはOSIディレクトリによって定義された原始の名前の上で描写的である名前の定義を定義します。
2. The Notation
2. 記法
The notation used in this specification is defined in [5]. This notation defines an unambiguous representation of distinguished name, and this specification is designed to be used in conjunction with this format. Both specifications arise from the same piece of research work [4]. Some examples of the specification are given here. The author's User Friendly Name (UFN) might be written:
この仕様で使用される記法は[5]で定義されます。 この記法は分類名の明白な表現を定義します、そして、この仕様は、この形式に関連して使用されるように設計されています。 両方の仕様は同じ研究[4]から起こります。 仕様に関するいくつかの例がここに出されます。 作者のUser Friendly Name(UFN)は書かれているかもしれません:
Steve Kille, Computer Science, University College London, GB
スティーブKille、コンピュータサイエンス、ユニバーシティ・カレッジロンドン、GB
or
または
S. Kille, Computer Science, University College London, GB
S.Kille、コンピュータサイエンス、ユニバーシティ・カレッジロンドン、GB
This may be folded, perhaps to display in multi-column format. For example:
これは、恐らくマルチコラム形式で表示するために折り重ねられるかもしれません。 例えば:
Steve Kille, Computer Science, University College London, GB
スティーブKille、コンピュータサイエンス、ユニバーシティ・カレッジロンドン、GB
Another UFN might be:
別のUFNは以下の通りです。
Christian Huitema, INRIA, FR
クリスチャンのHuitema、INRIA、FR
or James Hacker, Basingstoke, Widget Inc, GB
または、ジェームスHacker、ベイジングストーク、ウィジェットInc、GB
The final example shows quoting of a comma in an Organisation name:
最終的な例はOrganisation名における、コンマの引用を示しています:
L. Eagle, "Sue, Grabbit and Runn", GB
L.ワシと、「スー、Grabbit、およびRunn」、GB
Kille [Page 3] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[3ページ]RFC1781
A purported name is what a user supplies to an interface for resolution into one or more distinguished names. A system should almost always store a name as a distinguished name. This will be more efficient, and avoid problems with purported names which become ambiguous when a new name appears. A user interface may display a distinguished name, using the distinguished name notation. However, it may display a purported name in cases where this will be more pleasing to the user. Examples of this might be:
主張された名前は1つ以上の分類名へのユーザが解決のためにインタフェースに供給するものです。 システムは分類名としてほとんどいつも名前を保存するはずです。 これは、より効率的であり、新しい名前が現れるとあいまいになる主張された名前に関する問題を避けるでしょう。 分類名記法を使用して、ユーザーインタフェースは分類名を表示するかもしれません。 しかしながら、それはこれがユーザには、より微笑ましくなる場合における主張された名前を表示するかもしれません。 この例は以下の通りです。
o Omission of the higher components of the distinguished name are
not displayed (abbreviation).
o 分類名の、より高いコンポーネントの省略は表示されません(略語)。
o Omission of attribute types, where the type is unlikely to be
needed to resolve ambiguity.
o 属性タイプの省略。そこでは、タイプがありそうもないですあいまいさを取り除くのが必要であるべきである。
The ways in which a purported name may vary from a distinguished name are now described:
主張された名前が分類名と異なるかもしれない方法は現在、述べられます:
Type Omission
省略をタイプしてください。
There are two cases of this.
2つのケースのこれがあります。
o Schema defaulting. In this case, although the type is not
present, a schema defaulting is used to deduce the type. The
first two types of schema defaulting may be used to deduce a
distinguished name without the use of the directory. The use
of schema defaulting may be useful to improve the performance
of UFN resolution. The types of schema defaulting are:
o 図式デフォルト。 この場合、タイプは出席していませんが、図式デフォルトは、タイプを推論するのに使用されます。 最初の2つのタイプの図式デフォルトは、ディレクトリの使用なしで分類名を推論するのに使用されるかもしれません。 図式デフォルトの使用は、UFN解決の性能を向上させるために役に立つかもしれません。 図式デフォルトのタイプは以下の通りです。
-- Default Schema
-- デフォルト図式
-- Context Dependent Default Schema
-- 文脈に依存するデフォルト図式
-- Data Dependent Default Schema
-- データに依存するデフォルト図式
o Omission of the type to be resolved by searching.
o 探すことによって決議されるべきタイプの省略。
Default Schema
デフォルト図式
The attribute type of an attribute may always be present. This may be done to emphasise the type structure of a name. In some cases, the typing may be omitted. This is done in a way so that in many common cases, no attribute types are needed. The following type hierarchy (schema) is assumed:
属性の属性タイプはいつも出席しているかもしれません。 名前のタイプ構造を強調するためにこれをするかもしれません。 いくつかの場合、タイプは省略されるかもしれません。 多くのよくある例では、属性タイプは全く必要でないように、方法でこれをします。 以下のタイプ階層構造(図式)は想定されます:
Kille [Page 4] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[4ページ]RFC1781
Common Name, (((Organisational Unit)*, Organisation,) Country).
俗称、((*、(Organisationalユニット)機構)国。)
Explicitly typed RDNs may be inserted into this hierarchy at any point. The least significant component is always of type Common Name. Other types follow the defined organisational hierarchy. The following are equivalent:
明らかにタイプされたRDNsは任意な点のこの階層構造に挿入されるかもしれません。 最も重要でないコンポーネントはいつもタイプ俗称のものです。 他のタイプは定義されたorganisational階層構造に従います。 以下は同等です:
Filestore Access, Bells, Computer Science, University College London, GB
Filestoreアクセス、ベル、コンピュータサイエンス、ユニバーシティ・カレッジロンドン、GB
and
そして
CN=Filestore Access, OU=Bells, OU=Computer Science, O=University College London, C=GB
CN=Filestoreアクセス(OU=ベル、OU=コンピュータサイエンスユニバーシティ・カレッジO=ロンドン、C)はGBと等しいです。
To interpet a distinguished name presented in this format, with some or all of the attributes with the type not specified, the types are derived according to the type hierarchy by the following algorithm:
タイプが指定されていない属性の分類名がいくつかでこの形式で寄贈したinterpetかすべてに、タイプ階層構造に従って、タイプは以下のアルゴリズムで引き出されます:
1. If the first attribute type is not specified, it is
CommonName.
1. 最初の属性タイプが指定されないなら、それはCommonNameです。
2. If the last attribute type is not specified, it is Country.
2. 最後の属性タイプが指定されないなら、それはCountryです。
3. If there is no organisation explicitly specified, the last
attribute with type not specified is of type Organisation.
3. 明らかに指定された機構が全くなければ、タイプOrganisationにはタイプが指定されていない最後の属性があります。
4. Any remaining attribute with type unspecified must be before
an Organisation or OrganisationalUnit attribute, and is of
type OrganisationalUnit.
4. タイプが不特定のどんな残っている属性も、OrganisationかOrganisationalUnit属性の前に、あるに違いなくて、タイプOrganisationalUnitにはあります。
To take a distinguished name, and generate a name of this format with attribute types omitted, the following steps are followed.
分類名を取って、属性タイプが省略されている状態でこの形式の名前を生成するために、以下の方法は従われています。
1. If the first attribute is of type CommonName, the type may be
omitted.
1. タイプCommonNameに最初の属性があるなら、タイプは省略されるかもしれません。
2. If the last attribute is of type Country, the type may be
omitted.
2. タイプCountryに最後の属性があるなら、タイプは省略されるかもしれません。
3. If the last attribute is of type Country, the last
Organisation attribute may have the type omitted.
3. タイプCountryに最後の属性があるなら、最後のOrganisation属性で、タイプを省略するかもしれません。
4. All attributes of type OrganisationalUnit may have the type
omitted, unless they are after an Organisation attribute or
the first attribute is of type OrganisationalUnit.
4. タイプOrganisationalUnitのすべての属性でタイプを省略するかもしれません、それらがタイプOrganisationalUnitにはOrganisation属性か最初の属性がある後でないなら。
Kille [Page 5] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[5ページ]RFC1781
Context Dependent Default Schema
文脈に依存するデフォルト図式
The distinguished name notation defines a fixed schema for type defaulting. It may be useful to have different defaults in different contexts. For example, the defaulting convention may be applied in a modified fashion to objects which are known not to be common name objects. This will always be followed if the least significant component is explicitly typed. In this case, the following hierarchy is followed:
分類名記法はタイプデフォルトのために固定図式を定義します。 異なった文脈における異なったデフォルトを持っているのは役に立つかもしれません。 例えば、デフォルトコンベンションは変更されたファッションで一般名オブジェクトでないことが知られているオブジェクトに適用されるかもしれません。 最も重要でないコンポーネントが明らかにタイプされると、これはいつも続かれるでしょう。 この場合、以下の階層構造は従われています:
((Organisational Unit)*, Organisation,) Country
(*、(Organisationalユニット)機構) 国
Data Dependent Defaulting
データに依存するデフォルト
There are cases where it would be optimal to default according to the data. For example, in:
ケースがデータによると、デフォルトとするのが最適であるところにあります。 例えば、そして、中:
Einar Stefferud, Network Management Associates, CA, US
Einar Stefferud、ネットワークマネージメント関連、カリフォルニア、米国
It would be useful to default "CA" to type State. This might be done by defaulting all two letter attributes under C=US to type State.
状態をタイプするのはデフォルト「カリフォルニア」の役に立つでしょう。 州をタイプするためにC=米国の下のデフォルトとするのによるすべての2つの手紙属性をこれにするかもしれません。
General Defaulting
一般デフォルト
A type may be omitted in cases where it does not follow a default schema hierarchy, and then type variants can be explored by searching. Thus a distinguished name could be represented by a uniquely matching purported name. For example,
それがデフォルト図式階層構造に従わない場合でタイプを省略するかもしれません、そして、次に、探すことによって、タイプ異形を探ることができます。 したがって、唯一合っている主張された名前は分類名を表すことができました。 例えば
James Hacker, Basingstoke, Widget Inc, GB
ジェームスHacker、ベイジングストーク、ウィジェットInc、GB
Would match the distinguished name:
分類名を合わせるでしょう:
CN=James Hacker, L=Basingstoke, O=Widget Inc, C=GB
○ = CNはジェームスHackerと等しく、Lはベイジングストークと等しく、ウィジェットInc、CはGBと等しいです。
Abbreviation
略語
Some of the more significant components of the DN will be omitted, and then defaulted in some way (e.g., relative to a local context). For example:
次に、DNのいくつかの、より重要な部品では、省略されて、遠くでデフォルトとするでしょう(例えば、ローカルの関係に比例した)。 例えば:
Steve Kille
スティーブKille
Kille [Page 6] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[6ページ]RFC1781
Could be interpreted in the context of an organisational default.
organisationalデフォルトの文脈で解釈できました。
Local Type Keywords
ローカルのタイプキーワード
Local values can be used to identify types, in addition to the keywords defined in [5]. For example, "Organisation" may be recognised as an alternative to "O".
[5]で定義されたキーワードに加えてタイプを特定するのに地方の値を使用できます。 例えば、「機構」は「O」に代わる手段として認識されるかもしれません。
Component Omission
コンポーネント省略
An intermediate component of the name may be omitted. Typically this will be an organisational unit. For example:
名前の中間的成分は省略されるかもしれません。 これは通常、organisationalユニットになるでしょう。 例えば:
Steve Kille, University College London, GB
スティーブKille、ユニバーシティ・カレッジロンドンGB
In some cases, this can be combined with abbreviation. For example:
いくつかの場合、これを略語に結合できます。 例えば:
Steve Kille, University College London
スティーブKille、ユニバーシティ・カレッジロンドン
Approximation
近似
Approximate renditions or alternate values of one or more of the components will be supplied. For example:
コンポーネントの1つ以上の大体の表現か代替の値を供給するでしょう。 例えば:
Stephen Kille, CS, UCL, GB
スティーブンKille、Cs、UCL、GB
or
または
Steve Keill, Comp Sci, Univarstiy College London, GB
スティーブ・キール、コンピュータSci、Univarstiy大学ロンドンGB
Friendly Country
友好国
A "friendly country name" can be used instead of the ISO 3166 two letter code. For example: UK; USA; France; Deutchland.
ISO3166 2レター・コードの代わりに「友好国名」を使用できます。 例えば: イギリス。 米国。 フランス。 Deutchland。
3. Communicating Directory Names
3. ディレクトリ名を伝えます。
A goal of this standard is to provide a means of communicating directory names. Two approaches are given, one defined in [5], and the other here. A future version of these specifications may contain only one of these approaches, or recommend use of one approach. The approach can usually be distinguished implicitly, as types are normally omitted in the UFN approach, and are always present in the Distinguished Name approach. No recommendation is made here, but the merits of each approach is given.
この規格の目標はディレクトリ名を伝える手段を提供することです。 2つのアプローチが、当然のことと、ある定義されたコネ[5]と、ここのもう片方です。 これらの仕様の将来のバージョンは、これらのアプローチについて1つだけを含んでいるか、または1つのアプローチの使用を推薦するかもしれません。 通常、それとなくアプローチを区別できます、タイプが通常、UFNアプローチで省略されて、Distinguished Nameアプローチでいつも出席しているとき。 ここで推薦状を全くしませんが、それぞれのアプローチの長所を与えます。
Kille [Page 7] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[7ページ]RFC1781
1. Distinguished Name or DN. A representation of the distinguished
name, according to the specification of [5].
1. 分類名かDN。 [5]の仕様に従った分類名の表現。
2. User Friendly Name or UFN. A purported name, which is expected to
unambiguously resolve onto the distinguished name.
2. ユーザフレンドリーな名前かUFN。 主張された名前。(その名前は明白に分類名への決心に予想されます)。
When a UFN is communicated, a form which should efficiently and unambiguously resolve onto a distinguished name should be chosen. Thus it is reasonable to omit types, or to use alternate values which will unambiguously identify the entry in question (e.g., by use of an alternate value of the RDN attribute type). It is not reasonable to use keys which are (or are likely to become) ambiguous. The approach used should be implicit from the context, rather than wired into the syntax. The terms "Directory Name" and "X.500 Name" should be used to refer to a name which might be either a DN or UFN. An example of appropriate usage of both forms is given in the Section which defines the Author's location in Section 12. Advantages of communicating the DN are:
UFNが伝えられるとき、分類名への効率的にそうするべきであるフォームと明白に決心は選ばれるべきです。 したがって、タイプを省略するか、または明白に、問題のエントリー(例えば、RDN属性タイプの交互の値の使用による)を特定する交互の値を使用するのが妥当です。 そうするキー(または、なりそうである)を使用するのは妥当ではありません。あいまい。 使用されるアプローチは構文に配線されるよりむしろ文脈から暗黙であるべきです。 用語「ディレクトリ名」と「X.500名」は、DNかUFNのどちらかであるかもしれない名前を示すのに使用されるべきです。 両方のフォームの適切な使用法に関する例はセクション12でAuthorの位置を定義するセクションで出されます。 DNを伝える利点は以下の通りです。
o The Distinguished Name is an unambiguous and stable reference to
the user.
o Distinguished Nameはユーザが明白で安定した言及です。
o The DN will be used efficiently by the directory to obtain
information.
o DNはディレクトリによって効率的に使用されて、情報を得るでしょう。
Advantages of communicating the UFN are:
UFNを伝える利点は以下の通りです。
o Redundant type information can be omitted (e.g., "California",
rather than "State=California", where there is known to be no
ambiguity.
o 余分なタイプ情報を省略できます。(例えば、「状態はカリフォルニアと等しい」よりむしろあいまいさでないことが知られている「カリフォルニア。」(そこに、あります)。
o Alternate values can be used to identify a component. This might
be used to select a value which is meaningful to the recipient, or
to use a shorter form of the name. Often the uniqueness
requirements of registration will lead to long names, which users
will wish to avoid.
o コンポーネントを特定するのに交互の値を使用できます。 これは、受取人にとって、重要な値を選択するか、または名前の、より短いフォームを使用するのに使用されるかもしれません。 しばしば、登録のユニークさの要件は長い名前につながるでしょう。(ユーザは名前を避けたくなるでしょう)。
o Levels of the hierarchy may be omitted. For example in a very
small organisation, where a level of hierarchy has been used to
represent company structure, and the person has a unique name
within the organisation.
o 階層構造のレベルは省略されるかもしれません。 例えば、非常に小さい機構で。そこでは、階層構造のレベルが社内体制を表すのに使用されて、人は機構の中にユニークな名前を持っています。
Where UFN form is used, it is important to specify an unambiguous form. In some ways, this is analogous to writing a postal address. There are many legal ways to write it. Care needs to be taken to make the address unambiguous.
UFNがどこに形成するかが、使用されている、明白なフォームを指定するのは重要です。 ある点では、これは郵便の宛先を書くのに類似しています。 それを書く多くの法的な方法があります。 注意は、アドレスを明白にするように取られる必要があります。
Kille [Page 8] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[8ページ]RFC1781
4. Matching a purported name
4. 主張された名前を合わせます。
The following approach specifies a default algorithm to be used with the User Friendly Naming approach. It is appropriate to modify this algorithm, and future specifications may propose alternative algorithms. Two simple algorithms are noted in passing, which may be useful in some contexts:
以下のアプローチは、User Friendly Namingアプローチと共に使用されるためにデフォルトアルゴリズムを指定します。 このアルゴリズムを変更するのは適切です、そして、将来の仕様は代替のアルゴリズムを提案するかもしれません。(通過はいくつかの文脈で役に立つかもしれません)。通過で2つの簡単なアルゴリズムに注意します:
1. Use type omission only, but otherwise require the value of the RDN
attribute to be present.
1. タイプ省略だけを使用しなさい、ただし、さもなければ、RDN属性の値が現在であるのを必要であってください。
2. Require each RDN to be identified as in 1), or by an exact match
on an alternate value of the RDN attribute.
2. 1)、またはRDN属性の交互の値の完全な一致のように各RDNが特定されるのを必要であってください。
These algorithms do not offer the flexibility of the default algorithm proposed, but give many of the benefits of the approach in a very simple manner.
これらのアルゴリズムは提案されたデフォルトアルゴリズムの柔軟性を提供しませんが、非常に簡単な方法によるアプローチの恩恵の多くをお願いします。
The major utility of the purported name is to provide the important "user friendly" characteristic of guessability. A user will supply a purported name to a user interface, and this will be resolved onto a distinguished name. When a user supplies a purported name there is a need to derive the DN. In most cases, it should be possible to derive a single name from the purported name. In some cases, ambiguities will arise and the user will be prompted to select from a multiple matches. This should also be the case where a component of the name did not "match very well".
主張された名前の主要なユーティリティはguessabilityの重要な「ユーザフレンドリーな」特性を提供することです。 ユーザは主張された名前をユーザーインタフェースに供給するでしょう、そして、これは分類名に決議されるでしょう。 ユーザが主張された名前を提供するとき、DNを引き出す必要があります。 多くの場合、主張された名前からただ一つの名前を得るのは可能であるべきです。 いくつかの場合、あいまいさは起こるでしょう、そして、ユーザが複数のマッチから選び抜くようにうながされるでしょう。 また、これは名前の成分が「非常によく合っていなかった」そうであるべきです。
There is an assumption that the user will simply enter the name correctly. The purported name variants are designed to make this happen! There is no need for fancy window based interfaces or form filling for many applications of the directory. Note that the fancy interfaces still have a role for browsing, and for more complex matching. This type of naming is to deal with cases where information on a known user is desired and keyed on the user's name.
ユーザが単に正しさという名前を入れるという仮定があります。 主張された名前異形は、これを起こらせるように設計されています! ディレクトリの多くのアプリケーションのための高級窓に基づいているインタフェースか用紙記入の必要は全くありません。 高級インタフェースにはブラウジング、および、より複雑なマッチングのための役割がまだあることに注意してください。 このタイプの命名は知られているユーザの情報がユーザの名前で望まれていて、合わせられるケースに対処することです。
4.1 Environment
4.1 環境
All matches occur in the context of a local environment. The local environment defines a sequence of names of a non-leaf objects in the DIT. This environment effectively defines a list of acceptable name abbreviations where the DUA is employed. The environment should be controllable by the individual user. It also defines an order in which to operate.
すべてのマッチが地方の環境の文脈に現れます。 地方の環境はDITの非葉の物の名前の系列を定義します。 事実上、この環境はDUAが採用している許容できる名前略語のリストを定義します。 環境は個々のユーザが制御可能であるべきです。 また、それは作動するオーダーを定義します。
This list is defined in the context of the number of name components supplied. This allows varying heuristics, depending on the environment, to make the approach have the "right" behaviour. In
このリストはコンポーネントが提供した名前の数の文脈で定義されます。 これで、アプローチに「正しい」ふるまいを持たせるように環境によって、発見的教授法を変えます。 コネ
Kille [Page 9] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[9ページ]RFC1781
most cases, the environment will start at a local point in the DIT, and move upwards. Examples are given in Tables 1 and 2. Table 1 shows an example for a typical local DUA, which has the following characteristics:
ほとんどのケースであり、環境は、DITのローカルのポイントで始まって、よくなるでしょう。 例はTables1と2で出されます。 テーブル1は以下の特性を持っている典型的な地方のDUAのための例を示しています:
One component
1つのコンポーネント
Assumed first to be a user in the department, then a user or department within the university, then a national organisation, and finally a country.
次に、最初に大学、次に、全国的な組織、および最終的に国の中の部のユーザ、ユーザまたは部であると思われます。
Two components
2つのコンポーネント
Most significant component is first assumed to be a national organisation, then a department (this might be reversed in some organisations), and finally a country.
最も重要なコンポーネントは最初に、全国的な組織と、次に、部(これはいくつかの機構で逆にされるかもしれない)と、最終的に国であると思われます。
Three or more components
3つ以上のコンポーネント
The most significant component is first assumed to be a country, then a national organisation, and finally a department.
最も重要なコンポーネントは最初に、国と、次に、全国的な組織と、最終的に部であると思われます。
4.2 Matching
4.2 マッチング
A purported name will be supplied, usually with a small number of components. This will be matched in the context of an environment. Where there are multiple components to be matched, these should be matched sequentially. If an unambiguous DN is determined, the match continues as if the full DN had been supplied. For example, if
通常、少ない数のコンポーネントを主張された名前に供給するでしょう。 これは環境の文脈で合わせられるでしょう。 合わせられるために複数のコンポーネントがあるところでは、これらは連続して合わせられるべきです。 明白なDNが断固としているなら、マッチはまるで完全なDNを供給したかのように続きます。 例えば
+-----------+--------------------------------------+
|Number of |Environment |
|Components | |
+-----------+--------------------------------------+
|1 |Physics, University College London, GB|
| |University College London, GB |
| |GB |
+-----------+--------------------------------------+
|2 |GB |
| |University College London, GB |
| |-- |
+-----------+--------------------------------------+
|3+ |-- |
| |GB |
| |University College London, GB |
+-----------+--------------------------------------+
+-----------+--------------------------------------+ |数|環境| |コンポーネント| | +-----------+--------------------------------------+ |1 |物理学、ユニバーシティ・カレッジロンドン、GB| | |ユニバーシティ・カレッジロンドン、GB| | |GB| +-----------+--------------------------------------+ |2 |GB| | |ユニバーシティ・カレッジロンドン、GB| | |-- | +-----------+--------------------------------------+ |3+ |-- | | |GB| | |ユニバーシティ・カレッジロンドン、GB| +-----------+--------------------------------------+
Table 1: Local environment for private DUA
テーブル1: 個人的なDUAのための地方の環境
Kille [Page 10] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[10ページ]RFC1781
+------------+-----------+
| Number of |Environment|
| Components | |
+------------+-----------+
| 1,2 | US |
| | CA |
| | -- |
+------------+-----------+
| 3+ | -- |
| | US |
| | CA |
+------------+-----------+
+------------+-----------+ | 数|環境| | コンポーネント| | +------------+-----------+ | 1,2 | 米国| | | カリフォルニア| | | -- | +------------+-----------+ | 3+ | -- | | | 米国| | | カリフォルニア| +------------+-----------+
Table 2: Local environment for US Public DUA
テーブル2: 米国Public DUAのための地方の環境
Stephen Kille, UCL
スティーブンKille、UCL
is being matched in the context of environment GB, first UCL is resolved to the distinguished name:
環境GBの文脈で合わせられて、最初に、UCLが分類名に決議されているということです:
University College London, GB
ユニバーシティ・カレッジロンドン、GB
Then the next component of the purported name is taken to determine the final name. If there is an ambiguity (e.g., if UCL had made two matches, both paths are explored to see if the ambiguity can be resolved. Eventually a set of names will be passed back to the user.
そして、最終的な名前を決定するために主張された名前の次の成分を取ります。 あいまいさがあります。例えば、UCLが2をマッチにしたなら、両方の経路は、あいまいさを取り除くことができるかどうか確認するために探検されます。(結局、1セットの名前はユーザに戻されるでしょう。
Each component of the environment is taken in turn. If the purported name has more components than the maximum depth, the environment element is skipped. The advantage of this will be seen in the example given later.
環境の各コンポーネントは順番にかかります。 主張された名前に最大の深さより多くのコンポーネントがあるなら、環境要素はスキップされます。 この利点は後で出された例で見られるでしょう。
A match of a name is considered to have three levels:
名前のマッチには3つのレベルがあると考えられます:
Exact A DN is specified exactly
正確なA DNはまさに指定されます。
Good Initially, a match should be considered good if it is
unambiguous, and exactly matches an attribute value in the entry.
For human names, a looser metric is probably desirable (e.g.,
S Kille should be a good match of S. Kille, S.E. Kille or Steve
Kille even if these are not explicit alternate values).
良いInitially、マッチはそれが明白であるなら良いと考えられるべきであり、まさにエントリーで属性値に合っています。 人間の名前、a、 よりゆるく、メートル法であることが、たぶんそうである、望ましさ(例えば、S Killeはこれらが明白な交互の値でなくてもS.Kille、東南KilleまたはスティーブKilleの良いマッチであるべきです。).
Poor Any other substring or approximate match
不十分なAny他のサブストリングの、または、大体のマッチ
Following a match, the reference can be followed, or the user prompted. If there are multiple matches, more than one path may be followed. There is also a shift/reduce type of choice: should any partial matches be followed or should the next element of the
マッチに続いて、参照は、続かれていてうながされたユーザであるかもしれません。 複数のマッチがあれば、1つ以上の経路が続かれるかもしれません。 あります、また、シフト/は選択のタイプを減少させます、: どんな部分的なマッチも続かれるべきであるか、または次の要素に続かれるべきです。
Kille [Page 11] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[11ページ]RFC1781
environment be tried. The following heuristics are suggested, which may be modified in the light of experience. The overall aim is to resolve cleanly specified names with a minimum of fuss, but give sufficient user control to prevent undue searching and delay.
環境、試みられてください。 以下の発見的教授法(経験の見地から変更されるかもしれない)は示されます。 総合的な目的が最小大騒ぎの清潔に指定された名前を決議することですが、過度の探すことを防ぐことができるくらいのユーザ支配力と遅れをお願いします。
1. Always follow an exact match.
1. いつも完全な一致に従ってください。
2. Follow all good matches if there are no exact matches.
2. 完全な一致が全くなければ、すべての良いマッチに続いてください。
3. If there are only poor matches, prompt the user. If the user
accepts one or more matches, they can be considered as good. If
all are rejected, this can be treated as no matches.
3. 不十分なマッチしかなければ、ユーザをうながしてください。 ユーザが1個以上のマッチを受け入れるなら、良いとそれらをみなすことができます。 すべてが拒絶されるなら、どんなマッチとしてもこれを扱うことができません。
4. Automatically move to the next element of the environment if no
matches are found.
4. マッチが全く見つけられないなら、自動的に環境の次の要素に動いてください。
When the final component is matched, a set of names will be identified. If none are identified, proceed to the next environment element. If the user rejects all of the names, processing of the next environment element should be confirmed.
最終的なコンポーネントが取り組んでいるとき、1セットの名前は特定されるでしょう。 なにも特定されないなら、次の環境要素に続いてください。 ユーザが名前のすべてを拒絶するなら、次の環境要素の処理は確認されるべきです。
The exact approach to matching will depend on the level of the tree at which matching is being done. We can now consider how attributes are matched at various levels of the DIT.
マッチングへの正確なアプローチはマッチングがどれであるかで行われる木のレベルに依存するでしょう。 私たちは、現在、属性がDITの様々なレベルでどのように合わせられているかを考えることができます。
There is an issue of approximate matching. Sometimes it helps, and sometimes just returns many spurious matches. When a search is requested, all relevant attributes should be returned, so that distinguished and non-distinguished values can be looked at. This will allow a distinction to be made between good and poor matches. It is important that where, for example, an acronym exactly matches an organisation, that the user is not prompted about other organisations where it matches as a substring.
大体のマッチングの問題があります。 それは、時々、助けて、時々ただ多くの偽物のマッチを返します。 検索が要求されているとき、すべての関連属性を返すべきです、そして、したがって、それは区別されました、そして、非顕著な値は見ることができます。 これで、区別は良くて不十分なマッチの間でするでしょう。 どこ、例えば、頭文字語がまさに機構に合うか、そして、ユーザがそれがサブストリングとして合っている他の機構に関してうながされないのは、重要です。
4.3 Top Level
4.3 トップレベル
In this case, a match is being done at the root of the DIT. Three approaches are suggested, dependent on the length of supplied name. All lead to a single level search of the top level of the DIT.
この場合、DITの根でマッチをしています。 3つのアプローチが、供給された名前の長さに提案されていて、依存しています。 すべてがDITのトップレベルのただ一つの平らな検索に通じます。
Exactly 2
まさに2
This is assumed to be a 3166 two letter country code, or an exact match on a friendly country or organisation (e.g., UK or UN). Do exact match on country and friendly country.
これは3166が2手紙国名略号、または友好国か機構(例えば、イギリスか国連)での完全な一致であったなら想定されます。 国と友好国で完全な一致をしてください。
Kille [Page 12] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[12ページ]RFC1781
Greater than 2
2よりすばらしいです。
Make an approximate and substring match on friendly country and organisation.
友好国と機構で大体とサブストリングマッチを作ってください。
4.4 Intermediate Level
4.4 中間的レベル
Once the root level has been dealt with, intermediate levels will be looking for organisational components (Organisation, Locality, Org Unit). In some cases, private schema control will allow the system to determine which is at the next level. In general this will not be possible. In each case, make a substring and approximate match search of one level. The choice depends on the base object used in the search.
根のレベルがいったん対処されると、中間的レベルはorganisationalの部品(機構、Locality、Org Unit)を探すでしょう。 いくつかの場合、個人的な図式コントロールで、システムは、どれが次のレベルにあるかを決定できるでしょう。 一般に、これは可能にならないでしょう。 その都度、1つのレベルのサブストリングと大体のマッチ検索をしてください。 この選択は検索に使用されるベース物の次第です。
1. If DN has no Organisation or Locality, filter on Organisation and
Locality.
1. DNにどんなOrganisationもLocalityもないなら、OrganisationとLocalityの上でフィルタです。
2. If DN has Org Unit, filter on Org Unit.
2. DNにOrg Unitがあるなら、Org Unitの上でフィルタです。
3. If DN has Organisation, filter on Locality and Org Unit.
3. DNにOrganisationがあるなら、LocalityとOrg Unitの上でフィルタです。
4. If DN has Locality, filter on Organisation.
4. DNにLocalityがあるなら、Organisationの上でフィルタです。
These allow some optimisation, based on legal choices of schema. Keeping filters short is usually desirable to improve performance. A few examples of this, where a base object has been determined (either by being the environment or by partial resolution of a purported name), and the next element of a purported name is being considered. This will generate a single level search. What varies is the types being filtered against. If the DN is:
これらは図式の法的な選択に基づいて何らかの最適化を許します。 通常、フィルタを短く保つのは性能を向上させるのにおいて望ましいです。 このいくつかの例。(そこでは、ベース物が断固としていて(環境であるか主張された名前の部分的な解決による)、主張された名前の次の原理は考えられています)。 これはただ一つの平らな検索を発生させるでしょう。 異なることはフィルターにかけられるタイプです。 DNがそうなら:
University College London, GB
ユニバーシティ・カレッジロンドン、GB
The search should be for Org Unit or Locality. If the DN is:
検索はOrg UnitかLocalityのためのものであるべきです。 DNがそうなら:
Organisation=UN
機構は国連と等しいです。
the search should be for Org Unit or Locality.
検索はOrg UnitかLocalityのためのものであるべきです。
There may be some improvements with respect to very short keys. Not making approximate or substring matches in these cases seems sensible (It might be desirable to allow "*" as a part of the purported name notation.)
非常に短いキーに関していくつかの改良があるかもしれません。 これらの大体かサブストリングマッチをケースにしないように分別があるように思えます。(記法という主張された名前の一部として「*」を許容するのは望ましいかもしれません。)
Kille [Page 13] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[13ページ]RFC1781
4.5 Bottom Level
4.5 下部レベル
The "Bottom Level" is to deal with leaf entries in the DIT. This will often be a person, but may also be a role, an application entity or something else.
「下部レベル」はDITで葉のエントリーに対処することです。 これはまた、役割、例えば、ほかにアプリケーション実体であるかもしれないこと以外のしばしば人になるでしょう。
The last component of a purported name may either reference a leaf or non-leaf. For this reason, both should be tested for. As a heuristic, if the base object for the search has two or more components it should be tested first as a bottom level name and then intermediate. Reverse this for shorter names. This optimises for the (normal) case of non-leaves high up the tree and leaves low down the tree.
主張された名前の最後の成分は葉か非葉に参照をつけるかもしれません。 この理由で、両方がないかどうかテストされるべきです。 ヒューリスティック、検索のためのベース物で2があるか、そして、または、より多くのコンポーネントとして、それは名前が最初に、下部レベルとしてテストされて、次に、中間介在物をテストされるべきです。 より短い名前のためにこれを逆にしてください。 これは、下にを木に高く木への非葉の(正常)のケースのために最適化して、低く残します。
For bottom level names, make an approximate and substring match against Common Name, Surname, and User ID. Where common name is looked for, a full subtree search will be used when at the second level of the DIT or lower, otherwise a single level search.
レベルが命名する下部に関しては、俗称に対する大体とサブストリングマッチ、Surname、およびUserをIDにしてください。 一般名が探されて、完全な下位木検索がDITの第2レベルにあるとき、使用されるか、または下ろされるところでは、そうでなければ、検索します平らなただ一つの。
For example, if I have resolved a purported name to the distinguished name
私がそうしたなら、例えば、決心しているaは分類名に名前を意味しました。
University College London, GB
ユニバーシティ・カレッジロンドン、GB
and have a single component Bloggs, this will generate a subtree search.
そして、ただ一つのコンポーネントBloggsを持ってください、そして、これは下位木検索を発生させるでしょう。
5. Examples
5. 例
This is all somewhat confusing, and a few examples are given. These are all in the context of the environment shown in Table 1 on Page 13.
これはいくらかすべて紛らわしいです、そして、いくつかの例が出されます。 これらはすべて13ページのTable1に示された環境の文脈にあります。
If "Joe Bloggs" is supplied, a subtree search of
「一般人」は供給されたa下位木検索です。
Physics, University College London, GB
物理学、ユニバーシティ・カレッジロンドン、GB
will be made, and the user prompted for "Joseph Z. Bloggs" as the only possible match.
作られて、可能だけとしての「ジョゼフZ.Bloggs」のためにうながされたユーザは合っています。
If "Computer Science" is supplied, first
最初に「コンピュータサイエンス」を供給するなら
Physics, University College London, GB
物理学、ユニバーシティ・カレッジロンドン、GB
will be searched, and the user will reject the approximate match of "Colin Skin". Then a subtree search of
捜されて、ユーザは「コリンSkin」の大体のマッチを拒絶するでしょう。 下位木が探すその時
University College London, GB
ユニバーシティ・カレッジロンドン、GB
Kille [Page 14] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[14ページ]RFC1781
will be made, looking for a person. Then a single level search will be made looking for Org Unit, and
人を探して、作られるでしょう。 そして次に、Org Unitを探しながらただ一つの平らな検索をする。
Computer Science, University College London, GB
コンピュータサイエンス、ユニバーシティ・カレッジロンドン、GB
will be returned without prompting (exact match). Supplying "Steve Kille" will lead to a failed subtree search of
うながすこと(完全な一致)なしで返すでしょう。 「スティーブKille」が失敗した下位木検索に導く供給
Physics, University College London, GB
物理学、ユニバーシティ・カレッジロンドン、GB
and lead straight to a subtree search of
そして、aへの下位木が探す異性愛者を導いてください。
University College London, GB
ユニバーシティ・カレッジロンドン、GB
This will lead to an exact value match, and so a single entry returned without prompting.
これが正確な値のマッチに通じるので、単一のエントリーはうながすのなしで戻りました。
If "Andrew Findlay, Brunel" is supplied, the first element of the environment will be skipped, single level search of "Brunel" under "GB" will find:
「アンドリュー・フィンドレイ、Brunel」を供給すると、環境の最初の要素をスキップするでしょう、と「GB」の下における"Brunel"のただ一つの平らな検索によって、わかるでしょう:
Brunel University, GB
Brunel大学、GB
and a subtree search for "Andrew Findlay" initiated. This will yield
そして、開始された「アンドリュー・フィンドレイ」の下位木検索。 これはもたらされるでしょう。
Andrew Findlay, Computing and Media Services, Brunel University, GB
アンドリュー・フィンドレイとコンピューティングとメディアサービス、Brunel大学、GB
Dr A J Findlay, Manufacturing and Engineering Systems, Brunel University, GB
A Jフィンドレイ博士と製造とエンジニアリング・システム、Brunel大学、GB
and the user will be prompted with a choice.
そして、ユーザは選択でうながされるでしょう。
This approach shows how a simple format of this nature will "do the right thing" in many cases.
このアプローチは、多くの場合、この種の簡単な形式がどのように「正しいことをするか」を示します。
6. Support required from the standard
6. サポートが規格から必要です。
Fortunately, all that is needed is there! It would be useful to have "friendly country name" as a standard attribute.
幸い、必要であるすべてがそこにあります! 標準の属性として「友好国名」を持っているのは役に立つでしょう。
7. Support of OSI Services
7. OSIサービスのサポート
The major focus of this work has been to provide a mechanism for identifying Organisations and Users. A related function is to identify applications. Where the Application is identified by an AET (Application Entity Title) with an RDN of Common Name, this specification leads to a natural usage. For example, if a filestore is named "gannet", then this could easily be identified by the name:
この仕事の主要な焦点は、メカニズムを提供しにOrganisationsとUsersを特定するのに行ったことがあります。 関連する機能はアプリケーションを特定することです。 Applicationが俗称のRDNと共にAET(アプリケーションEntity Title)によって特定されるところでは、この仕様は自然な用法につながります。 例えば、filestoreが「カツオドリ」と命名されるなら、これは名前によって容易に特定されるかもしれません:
Kille [Page 15] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[15ページ]RFC1781
Gannet, Computer Laboratory, Cambridge University, GB
カツオドリ、コンピュータ研究所、ケンブリッジ大学、GB
In normal usage, this might lead to access (using a purported name) of:
正常な用法で、これは以下のアクセス(主張された名前を使用する)に通じるかもしれません。
FTAM gannet,cambridge
FTAMカツオドリ、cambridge
A second type of access is where the user identifies an Organisation (Organisational Unit), and expects to obtain a default service. The service is implied by the application, and should not require any additional naming as far as the user is concerned. It is proposed that this is supported by User Friendly Naming in the following way.
2番目のタイプのアクセスはユーザがOrganisation(Organisational Unit)を特定して、デフォルトサービスを得ると予想するところです。 サービスは、アプリケーションで含意されて、ユーザに関する限り、少しの追加命名も必要とするべきではありません。 これがUser Friendly Namingによって以下の方法で支持されるよう提案されます。
1. Determine that the purported name identifies a non-leaf object,
which is of object class Organisation or Organisational Unit or
Locality.
1. 主張された名前が非葉の物を特定することを決定してください。(物は物のクラスのOrganisation、Organisational UnitまたはLocalityのものです)。
2. Perform a single level search for Application Entities which
support the required application contexts. This assumes that all
services which are supporting default access for the organisation
are registered at one level below (possibly by the use of
aliases), and that other services (specific machines or parts of
the organisation) are represented further down the tree. This
seems to be a reasonable layout, and its utility can be evaluated
by experiment.
2. 必要なアプリケーション文脈を支持するApplication Entitiesのただ一つの平らな検索を実行してください。 これは、機構のためにデフォルトアクセスを支持しているすべてのサービスが以下(ことによると別名の使用で)の1つのレベルで登録されて、他のサービス(特定のマシンか機構の部分)がさらに木の下側に表されると仮定します。 これは合理的なレイアウトであるように思えます、そして、実験でユーティリティは評価できます。
8. Experience
8. 経験
An experimental implementation of this has been written by Colin Robbins. The example in Figure 1 shows that it can be very effective at locating known individuals with a minimum of effort. This code has been deployed within the "FRED" interface of the PSI Pilot [9], and within an prototype interface for managing distribution lists. The user reaction has been favourable:
この実験的な実現はコリン・ロビンスによって書かれています。 図1の例は、それが最小努力で知られている個人の居場所を見つけるところで非常に効果的である場合があることを示します。 このコードはψのパイロット[9]の「フレッド」インタフェース以内と発送先リストを管理するための原型インタフェースの中で配備されました。 ユーザ反応は好都合です:
Some issues have arisen from this experience:
いくつかの問題がこの経験から起こりました:
o Where there is more than one level of Organisational Unit, and the
user guesses one which is not immediately below the organisation,
the algorithm works badly. There does not appear to be an easy
fix for this. It is not clear if this is a serious deficiency.
o Organisational Unitの1つ以上のレベルがあって、ユーザが機構のすぐ下にないものを推測するところでは、アルゴリズムはひどく利きます。 これのための簡単なフィックスはあるように見えません。 これが重大な欠乏であるかどうかは明確ではありません。
o Substring searching is currently done with leading and trailing
wildcards. As many implementations will not implement leading
wildcards efficiently, it may be preferable to only use trailing
wildcards. The effect of this on the algorithm needs to be
investigated.
o 現在、主で引きずっているワイルドカードでサブストリングの探すことをします。 多くの実現が効率的に主なワイルドカードを実行しないので、引きずっているワイルドカードを使用するだけが望ましいかもしれません。 アルゴリズムへのこの効果は、調査される必要があります。
Kille [Page 16] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[16ページ]RFC1781
Implementors of this specification are encouraged to investigate variants of the basic algorithm. A final specification should depend on experience with such variants.
この仕様の作成者が基本的なアルゴリズムの異形を調査するよう奨励されます。 最終的な仕様はそのような異形の経験によるべきです。
9. Relationship to other work
9. 他の仕事との関係
Colin Robbin's work on the interface "Tom" and implementation of a distribution list interface strongly influenced this specification [6].
発送先リストインタフェースのインタフェース「雄ネコ」と実現に対するコリン・ロビンの仕事は強くこの仕様[6]に影響を及ぼしました。
Some of the ideas used here originally came from a UK Proposal to the ISO/CCITT Directory Group on "New Name Forms" [2]. This defined, and showed how to implement, four different types of names:
元々ここで使用された考えのいくつかが「新しい名前は形成される」という[2]でイギリスのProposalからISO/CCITTディレクトリGroupに来ました。 これは、道具、4つの異なったタイプの名前へのその方法を定義して、示しました:
Typed and Ordered The current Distinguished Name is a restricted example of this type of name.
タイプされて、Orderedの現在のDistinguished Nameはこのタイプの名前の制限された例です。
Kille [Page 17] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[17ページ]RFC1781
-> t hales, csiro, australia
Found good match(es) for 'australia'
Found exact match(es) for 'csiro'
Please select from the following:
Trevor Hales, OC, HPCC, DIT, IICT, CSIRO, AU [y/n] ? y
The following were matched...
Trevor Hales, OC, HPCC, DIT, IICT, CSIRO, AU
->t hales、csiro、'csiro'Pleaseのための'australia'Found完全な一致(es)のためのaustralia Foundの良いマッチ(es)が以下から選び抜きます: トレバー・ヘール、OC、HPCC、DIT、IICT AU[y/n]?CSIRO、y、次の事柄は合わせられました… トレバー・ヘールズ、OC、HPCC、デイット、IICT、CSIRO、Au
-> g michaelson, queensland, au
Found exact match(es) for 'au'
Please select from the following:
University of Queensland, AU [y/n] ? y
Axolotl, AU [y/n] ? n
Please select from the following:
George Michaelson, Prentice Computer Centre, University of
Queensland, AU
[y/n] ? y
Manager, University of Queensland, AU [y/n] ? n
The following were matched...
George Michaelson, Prentice Computer Centre, University of
Queensland, AU
->g michaelson、queensland、'Au'PleaseのためのAu Found完全な一致(es)が以下から選び抜きます: クィーンズランド大学、AU[y/n]--y Axolotl、AU[y/n]--n Pleaseは以下から選び抜きます: ジョージMichaelson、PrenticeコンピュータCentre、クィーンズランド大学、AU[y/n]--yマネージャ、クィーンズランド大学、AU[y/n]--n、次の事柄は合わせられました… ジョージMichaelson、新米のコンピュータセンター、クィーンズランド大学、Au
-> r needham, cambridge
Found good match(es) for 'cambridge'
Please select from the following:
Roger Needham, Computer Lab, Cambridge University [y/n] ? y
The following were matched...
Roger Needham, Computer Lab, Cambridge University
->r needham、cambridge Foundの'cambridge'Pleaseに、良いマッチ(es)が以下から選び抜きます: コンピュータLab、ケンブリッジ大学[y/n]?了解、ニーダム、y。次の事柄は合わせられました… ロジャー・ニーダム、コンピュータ室、ケンブリッジ大学
-> kirstein
Found good match(es) for 'kirstein'
The following were matched...
Peter Kirstein
-次の事柄が'kirstein'合わせられたので、>kirstein Found利益は(es)に合っています… ピーター・カースタイン
Figure 1: Example usage of User Friendly Naming
図1: User Friendly Namingの例の使用法
Untyped and Ordered
Untypedされて、命令されます。
This is the type of name proposed here (with some extensions to allow optional typing). It is seen as meeting the key user requirement of disliking typed names, and is efficient to implement.
これはここ(任意のタイプを許すいくつかの拡大で)で提案された名前のタイプです。 それは、タイプされた名前が嫌であることの主要なユーザ要件を満たすのが見られて、実行するために効率的です。
Typed and Unordered
タイプされていて順不同のです。
This sort of name is proposed by others as the key basis for user friendly naming. Neufeld shows how X.500 can be used to provide this [7], and Peterson proposes the Profile system to provide this [8].
この種類の名前はユーザフレンドリーな命名の主要な基礎として他のものによって提案されます。 ニューフェルドはこの[7]を提供するのにどうX.500を使用できるかを示しています、そして、ピーターソンはこの[8]を提供するためにProfileシステムを提案します。
Kille [Page 18] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[18ページ]RFC1781
The author contends that whilst typed naming is interesting for some types of searching (e.g., yellow page searching), it is less desirable for naming objects. This is borne out by operational experience with OSI Directories [3].
作者は、タイプされた命名が何人かのタイプの探索(例えば、黄色いページの探す)によっておもしろいのですが、物を命名するには、それがそれほど望ましくないと主張します。 これはOSIディレクトリ[3]の運用経験で支持されます。
Untyped and Unordered
Untypedされていて順不同のです。
Surprisingly this form of name can be supported quite easily. However, a considerable gain in efficiency can be achieved by requiring ordering. In practice, users can supply this easily. Therefore, this type of name is not proposed.
驚いたことに、全く容易にこのフォームの名前をサポートできます。 しかしながら、注文するのを必要とすることによって、かなりの能率の増進を獲得できます。 実際には、ユーザは容易にこれを供給できます。 したがって、このタイプの名前は提案されません。
10. Issues
10. 問題
The following issues are noted, which would need to be resolved before this document is progressed as an Internet Standard.
以下の問題(このドキュメントがインターネットStandardとして進行される前に決議される必要がある)は注意されます。
Potential Ambiguity
潜在的あいまいさ
Whilst the intention of the notation is to allow for specification of alternate values, it inherently allows for ambiguous names to be specified. It needs to be demonstrated that problems of this characteristic are outweighed by other benefits of the notation.
記法の意志が交互の値の仕様を考慮することですが、それは、本来あいまいな名前が指定されるのを許容します。 それは、示されて、この特性のその問題が記法の諸手当より軽いということである必要があります。
Utility
ユーティリティ
Determine that the specification is being implemented and used.
仕様が履行されて、使用されていることを決定してください。
Performance
パフォーマンス
Measurements on the performance implications of using this approach should be made.
このアプローチを使用する性能含意に関する測定をするべきです。
Alogrithm
Alogrithm
The utility of the algorithm, and possible variants, should be investigated.
アルゴリズム、および可能な異形に関するユーティリティは調査されるべきです。
This format, and the procedures for resolving purported names, should be evolved to an Internet Standard. The syntax can be expected to be stable. In light of experience, the algorithm for resolving purported names may be changed.
この形式、および主張された名前を決議するための手順はインターネットStandardに発展されるべきです。 構文が安定していると予想できます。 経験の観点から、主張された名前を決議するためのアルゴリズムを変えるかもしれません。
Kille [Page 19] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[19ページ]RFC1781
11. References
11. 参照
[1] The Directory --- overview of concepts, models and services,
1993. CCITT X.500 Series Recommendations.
[1] ディレクトリ--- 概念の、そして、モデルの、そして、サービスの概観、1993。 CCITT X.500シリーズ勧告。
[2] S.E. Kille. New name forms, May 1989. ISO/IEC/JTC 21/ WG4/N797
UK National Body Contribution to the Oslo Directory Meeting.
[2] 東南Kille。 新しい名前は1989年5月に形成されます。 オスロのディレクトリミーティングへのISO/IEC/JTC21/WG4/N797イギリスの国家体貢献。
[3] S.E. Kille. The THORN large scale pilot exercise. Computer
Networks and ISDN Systems, 16(1):143--145, January 1989.
[3] 東南Kille。 THORN大規模パイロット運動。 コンピュータネットワークとISDNシステム、16(1): 143--145と、1989年1月。
[4] S.E. Kille. Using the OSI directory to achieve user friendly
naming. Research Note RN/20/29, Department of Computer Science,
University College London, February 1990.
[4] 東南Kille。 ユーザフレンドリーな命名を達成するのにOSIディレクトリを使用します。 1990年2月に注意Rn/20/29、コンピュータサイエンス学部、ユニバーシティ・カレッジロンドンについて研究してください。
[5] Kille, S., "A String Representation of Distinguished Names", RFC
1779, ISODE Consortium, March 1995.
[5]Kille、S.、「分類名のストリング表現」、RFC1779、ISODE共同体、1995年3月。
[6] S.E. Kille and C.J. Robbins. The ISO development environment:
User's manual (version 7.0), July 1991. Volume 5: QUIPU.
[6]東南KilleとC.J.ロビンス。 ISO開発環境: 1991年7月のユーザマニュアル(バージョン7.0)。 第5巻: 結び縄文字。
[7] G.W. Neufeld. Descriptive names in X.500. In SIGCOMM 89
Symposiun Communications Architectures and Protocols, pages 64--
71, September 1989.
[7] G.W.ニューフェルド。 X.500の描写的である名前。 SIGCOMM89Symposiun Communications Architecturesとプロトコル、64-- 71ページ、1989年9月に。
[8] L.L. Petersen. The profile naming service. ACM Transactions on
Computing Systems, 6(4):341--364, November 1988.
[8] L.L.ピーターセン。 サービスを命名するプロフィール。 コンピューティング・システムにおけるACM取引、6(4): 341--364と、1988年11月。
[9] M.T. Rose. Realizing the White Pages using the OSI Directory
Service. Technical Report 90--05--10--1, Performance Systems
International, Inc., May 1990.
[9] M.T.は上昇しました。 OSIディレクトリサービスを使用することでホワイトページがわかります。 技術報告書90--05--10--1、言語運用機構国際Inc.、5月1990日
Kille [Page 20] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[20ページ]RFC1781
12. Security Considerations
12. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
13. Author's Address
13. 作者のアドレス
Steve Kille ISODE Consortium The Dome The Square Richmond, Surrey TW9 1DT England
スティーブ・Kille ISODE共同体ドームの正方形のリッチモンド、サリーTW9 1DTイギリス
Phone:+44-181-332-9091 EMail: S.Kille@ISODE.COM
電話: +44-181-332-9091 メールしてください: S.Kille@ISODE.COM
DN: CN=Steve Kille, O=ISODE Consortium, C=GB
DN: CNはスティーブKille、O=ISODE共同体と等しく、CはGBと等しいです。
UFN: S. Kille, ISODE Consortium, GB
UFN: S。 Kille、ISODE共同体、GB
Kille [Page 21] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[21ページ]RFC1781
A. Pseudo-code for the matching algorithm
A。 合っているアルゴリズムのための中間コード
The following pseudo-code is intended to clarify the matching algorithm. The language uses ASN.1 data types, with flow control "C"-like, but with keywords upper-cased.
以下の中間コードが合っているアルゴリズムをはっきりさせることを意図します。 言語は上側にケースに入れられた状態でようなフロー制御「C」にもかかわらず、キーワードがあるASN.1データ型を使用します。
PurportedName ::= SEQUENCE OF String
-- simplication, as attribute types can optionally be
-- specified
PurportedName:、:= SEQUENCE OF String--simplication、属性として、タイプが任意にあることができます--指定されます。
-- Each element of the Purported Name is a string
-- which has been parsed from the BNF
-- Purported Nameの各要素はストリング(BNFから分析された)です。
Attribute ::= SEQUENCE {
type OBJECT IDENTIFIER,
value ANY }
以下を結果と考えてください:= 系列OBJECT IDENTIFIERをタイプしてください、そして、いずれも評価してください。
RDN ::= Attribute -- simplification, as can be multi-value
RDN:、:= 属性--マルチ値であることができることのような簡素化
DN ::= SEQUENCE OF RDN
DN:、:= RDNの系列
Environment ::= SEQUENCE OF DN
環境:、:= DNの系列
EnvironmentList ::= SEQUENCE OF SEQUENCE {
lower-bound INTEGER,
upper-bound INTEGER,
environment Environment }
EnvironmentList:、:= 系列の系列下界INTEGER、上限INTEGER、環境Environment
friendlyMatch(p: PurportedName; el: EnvironmentList): SET OF DN
{
-- Find correct environment
friendlyMatch(p: PurportedName; 高架鉄道: EnvironmentList): SET OF DN、--正しい環境を見つけてください
IF length(el) == 0 THEN return(NULL);
0長さ(高架鉄道)=THENが(NULL)を返すなら。
IF length(p) <= head(el).upper-bound
&& length(p) >= head(el).lower-bound THEN
return envMatch (p, head(el).environment);
ELSE
return(friendlyMatch(p, tail(el));
}
length(p)<がヘッド(高架鉄道).upper-boundと等しい、length(p)>はヘッド(高架鉄道).lower-bound THENリターンenvMatch(p、ヘッド(高架鉄道).environment)と等しいです。 ELSEが戻る、(friendlyMatch(p、テール(高架鉄道))。
envMatch(p: PurportedName; e: Environment): SET OF DN
{
-- Check elements of environment
-- in the defined order
envMatch(p: PurportedName; e: 環境): SET OF DN、--定義されたオーダーにおける環境の要素をチェックしてください
matches: SET OF DN;
マッチ: DNのセット。
Kille [Page 22] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[22ページ]RFC1781
IF length(e) == 0 THEN return(NULL);
0長さ(e)=THENが(NULL)を返すなら。
matches = purportedMatch(head(e).DN, p)
IF matches != NULL THEN
return(matches);
ELSE
return(envMatch(p, tail(e));
}
マッチ!=NULL THENが(マッチ)を返すなら、マッチはpurportedMatch(ヘッド(e).DN、p)と等しいです。 ELSEが戻る、(envMatch、(p、テール(e))。
purportedMatch(base: DN; p: PurportedName): SET OF DN
{
s: String = head(p);
matches: SET OF DN = NULL;
purportedMatch(ベース: DN; p: PurportedName): SET OF DN、s: ストリング=head(p); マッチ: SET OF DNはNULLと等しいです。
IF length(p) == 1 THEN
IF length(base) == 0 THEN
IF (matches = rootSearch(s)) != NULL THEN
return(matches);
ELSE return(leafSearch(base, s, one-level);
ELSE IF length(base) == 1 THEN
IF (matches = intSearch(base, s)) != NULL THEN
return(matches);
ELSE return(leafSearch(base, s, one-level);
ELSE
IF (matches = leafSearch(base, s, subtree)) !=
NULL THEN return(matches);
ELSE return(intsearch(base, s);
マッチはrootSearch(s))と等しいです!0 1つのTHEN IFのlength(p)=長さ(ベース)=THEN IFである、(= NULL THENは(マッチ)を返します。 ELSEが戻る、(leafSearch(ベース、s、1レベル); 1THEN IF(マッチはintSearch(ベース、s)と等しい)!=NULL THEN ELSE IFの長さ(ベース)=リターン(マッチ); ELSEが戻る、(leafSearch(ベース、s、1レベル); ELSE IF(マッチはleafSearch(ベース、s、下位木)と等しい)!=NULL THENリターン(マッチ); ELSEが戻る、(intsearch(ベース、s)。
IF length(base) == 0 THEN
FOR x IN rootSearch(s) DO
matches += (purportedMatch(x, tail(p));
ELSE
FOR x IN intSearch(base, s) DO
matches += (purportedMatch(x, tail(p));
return(matches);
}
0THEN FOR x IN長さ(ベース)=rootSearch(s)がマッチ+=をする、(purportedMatch(x、tail(p))、;、ELSE FOR x IN intSearch(ベース、s)がマッチ+=をする (purportedMatch(x、tail(p)); 戻ってください(マッチ)。
Kille [Page 23] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[23ページ]RFC1781
-- General. Might need to tighten the filter for short strings, -- in order to stop being flooded. Alternatively, this could be -- done if the loose search hits a size limit
-- 一般。 水につかるのを止めるのに脆いストリングのためにフィルタを締めるのが必要であるかもしれません。 あるいはまた、これはそうであるかもしれません--ゆるい検索がサイズ限界を打つなら、します。
rootSearch(s: String): SET OF DN
{
IF length(s) == 2 THEN
return(search(NULL, one-level, s, {CountryName,
FriendlyCountryName, OrganizationName},
{exact}, {Country, Organisation}));
-- test exact match only
-- probably a country code
ELSE
return(search(NULL, one-level, s, {OrganizationName,
FriendlyCountryName}, {substring, approx},
{Country, Organisation}));
}
rootSearch(s: ストリング): DNのセット探してください。2長さ=THENが戻る、((NULL(1レベル、s、CountryName、FriendlyCountryName、OrganizationName)が強要する、国、Organisation) ; --完全な一致だけを検査してください--、たぶん国名略号ELSEリターン、(検索、(NULL、1レベル、s、OrganizationName、FriendlyCountryName、サブストリング、約、国、Organisation)、。
intSearch( base: DN; s: String)
{
IF present(base, OrgUnitName) THEN
return(search(base, one-level, s, {OrgUnitName},
{substring, approx}, {OrgUnit}));
ELSE IF present(base, OrganisationName) THEN
return(search(base, one-level, s, {OrgUnitName,
LocalityName}, {substring, approx},
{Organization, OrgUnit, Locality}));
ELSE IF present(base, LocalityName) THEN
return(search(base, one-level, s, {OrganisationName},
{substring, approx}, {Locality});
ELSE
return(search(base, one-level, s, {OrganisationName,
LocalityName}, {substring, approx},
{Organisation, Locality}));
}
intSearch(ベース: DN; s: ストリング){ 現在(ベース、OrgUnitName)のTHENが戻る、(検索、(ベース、1レベル、s、OrgUnitName、サブストリング、約、OrgUnit)、;、ELSE IFの現在(ベース、OrganisationName)のTHENが戻る (検索、(ベース、1レベル、s、OrgUnitName、LocalityName、サブストリング、約、組織、OrgUnit、Locality); ELSE IFの現在(ベース、LocalityName)のTHENが戻る、(検索、(ベース、1レベル、s、OrganisationName、サブストリング、約、場所)、;、ELSEが戻る (検索、(ベース、1レベル、s、OrganisationName、LocalityName、サブストリング、約、機構、Locality)、; }
present(d: DN; t: AttributeType): BOOLEAN
{
FOR x IN d DO
IF x.type == t THEN return(TRUE);
return(FALSE);
}
以下を提示してください(d: DN; t: AttributeType)。 論理演算子FOR x IN dはt x.タイプ=THENは(TRUE)を返します; リターン(FALSE)ならします。
SearchScope := ENUMERATED (base-object, one-level, subtree)
数え上げられたSearchScope:=(ベース物、1レベル、下位木)
leafSearch(base: DN; s: String; search-scope: SearchScope)
leafSearch(ベース: DN; s: ストリング; 検索範囲: SearchScope)
Kille [Page 24] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[24ページ]RFC1781
{
return(search(base, search-scope, s, {CommonName, Surname,
UserId}, {substring, approx}));
}
リターン、(検索、(ベース、検索範囲、s、CommonName、Surname、UserId、サブストリング、約、)、。
search(base: DN; search-scope: SearchScope; s: string;
alist SET OF AttributeType; matchtypes SET OF MatchType
objectClasses SET OF ObjectClass OPTIONAL): SET OF DN
{
-- mapped onto Directory Search, with OR conjunction
-- of filter items
探してください(ベース: DN; 検索範囲: SearchScope; s: ストリング; 船が傾いているSET OF AttributeType; matchtypes SET OF MatchType objectClasses SET OF ObjectClass OPTIONAL): SET OF DN、フィルタの品目のOR接続詞でディレクトリ検索に写像されます。
return dNSelect (s, search-results, alist);
}
dNSelect(結果を探していて、船が傾いているs)を返してください。 }
read(base: DN; alist SET OF AttributeType): SET OF Attribute;
{
-- mapped onto Directory Read
-- Types repeated to deal with multiple values
-- This would be implemented by returning selected info
-- with the search operation
}
読んでください(ベース: DN; 船が傾いているSET OF AttributeType): 属性のセット。 索敵行動でタイプは複数の値に対処するために繰り返しました--これが戻っている選択されたインフォメーションによって実行されるだろうというディレクトリReadに写像されます。
dNSelect(s: String; dlist SET OF DN;
alist: SET OF AttributeType):16SET0OF DN
{
exact, good: SET OF DN;
dNSelect、(s: ストリング; dlist SET OF DN; 船が傾いている:、SET OF AttributeType) : 16SET0OF DN、正確である、利益: SET OF DN。
FOR x IN dlist DO
IF last(DN).Value == s THEN
exact += x;
ELSE IF FOR y IN read(x, alist) DO
IF y.value == s THEN
good += x;
s最後の(DN).Value=THENが+ =xを強要するなら、FOR x IN dlistはします。 INが読んだ(xの、そして、船が傾いている)ELSE IF FOR yはs THEN利益+=y.値=xであるならします。
IF exact != NULL THEN return(exact);
IF good != NULL THEN return(good);
return(userQuery(dlist));
}
正確であるなら、=NULL THENは戻ります(正確な)。 利益!=NULL THENが戻るなら(良い)。 戻ってください(userQuery(dlist))。 }
userQuery(dlist SET OF DN): SET OF DN
{
-- pass back up for manual checking
-- user can strip all matches to force progres....
}
userQuery(DNのdlistセット): DNのセットマニュアルのためのパス後部がチェックする場合、ユーザは、progresを強制するためにすべてのマッチを剥取ることができます。
head() -- return first element of list tail() -- return list with first element removed
ヘッド()--リストテール()の最初の要素を返してください--最初の要素を取り除いていてリストを返してください。
Kille [Page 25] RFC 1781 User Friendly Naming March 1995
1995年の命名行進のときにユーザフレンドリーなKille[25ページ]RFC1781
length() -- return size of list last() -- return last element of list
長さ()(リスト最終()リターンサイズ)はリストの最後の要素を返します。
Figure 2: Matching Algorithm
図2: 合っているアルゴリズム
Kille [Page 26]
Kille[26ページ]
一覧
スポンサーリンク
