RFC4519 日本語訳
4519 Lightweight Directory Access Protocol (LDAP): Schema for UserApplications. A. Sciberras, Ed.. June 2006. (Format: TXT=64996 bytes) (Obsoletes RFC2256) (Updates RFC2247, RFC2798, RFC2377) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Sciberras, Ed. Request for Comments: 4519 eB2Bcom Obsoletes: 2256 June 2006 Updates: 2247, 2798, 2377 Category: Standards Track
ワーキンググループA.Sciberras、エドをネットワークでつないでください。コメントのために以下を要求してください。 4519eB2Bcomは以下を時代遅れにします。 2256 2006年6月は以下をアップデートします。 2247、2798、2377カテゴリ: 標準化過程
Lightweight Directory Access Protocol (LDAP):
Schema for User Applications
ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP): ユーザアプリケーションのための図式
Status of This 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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document is an integral part of the Lightweight Directory Access Protocol (LDAP) technical specification. It provides a technical specification of attribute types and object classes intended for use by LDAP directory clients for many directory services, such as White Pages. These objects are widely used as a basis for the schema in many LDAP directories. This document does not cover attributes used for the administration of directory servers, nor does it include directory objects defined for specific uses in other documents.
このドキュメントはライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)技術仕様書の不可欠の部分です。 それは使用のためにLDAPディレクトリクライアントによって意図された属性タイプとオブジェクトのクラスに関する技術仕様書を多くのディレクトリサービスに提供します、ホワイトPagesなどのように。 これらのオブジェクトは多くのLDAPディレクトリの図式の基礎として広く使用されます。 このドキュメントはディレクトリサーバの管理に使用される属性をカバーしていません、そして、それは他のドキュメントにおける特定の用途のために定義されたディレクトリオブジェクトを含んでいません。
Sciberras Standards Track [Page 1] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[1ページ]: ユーザアプリケーション2006年6月のための図式
Table of Contents
目次
1. Introduction ....................................................3
1.1. Relationship with Other Specifications .....................3
1.2. Conventions ................................................4
1.3. General Issues .............................................4
2. Attribute Types .................................................4
2.1. 'businessCategory' .........................................5
2.2. 'c' ........................................................5
2.3. 'cn' .......................................................5
2.4. 'dc' .......................................................6
2.5. 'description' ..............................................6
2.6. 'destinationIndicator' .....................................7
2.7. 'distinguishedName' ........................................7
2.8. 'dnQualifier' ..............................................8
2.9. 'enhancedSearchGuide' ......................................8
2.10. 'facsimileTelephoneNumber' ................................9
2.11. 'generationQualifier' .....................................9
2.12. 'givenName' ...............................................9
2.13. 'houseIdentifier' .........................................9
2.14. 'initials' ...............................................10
2.15. 'internationalISDNNumber' ................................10
2.16. 'l' ......................................................10
2.17. 'member' .................................................11
2.18. 'name' ...................................................11
2.19. 'o' ......................................................11
2.20. 'ou' .....................................................12
2.21. 'owner' ..................................................12
2.22. 'physicalDeliveryOfficeName' .............................12
2.23. 'postalAddress' ..........................................13
2.24. 'postalCode' .............................................13
2.25. 'postOfficeBox' ..........................................14
2.26. 'preferredDeliveryMethod' ................................14
2.27. 'registeredAddress' ......................................14
2.28. 'roleOccupant' ...........................................15
2.29. 'searchGuide' ............................................15
2.30. 'seeAlso' ................................................15
2.31. 'serialNumber' ...........................................16
2.32. 'sn' .....................................................16
2.33. 'st' .....................................................16
2.34. 'street' .................................................17
2.35. 'telephoneNumber' ........................................17
2.36. 'teletexTerminalIdentifier' ..............................17
2.37. 'telexNumber' ............................................18
2.38. 'title' ..................................................18
2.39. 'uid' ....................................................18
2.40. 'uniqueMember' ...........................................19
2.41. 'userPassword' ...........................................19
1. 序論…3 1.1. 他の仕様との関係…3 1.2. コンベンション…4 1.3. 一般問題…4 2. タイプを結果と考えてください…4 2.1. 'businessCategory'…5 2.2. 'c'…5 2.3. 'cn'…5 2.4. 'dc'…6 2.5. '記述'…6 2.6. 'destinationIndicator'…7 2.7. 'distinguishedName'…7 2.8. 'dnQualifier'…8 2.9. 'enhancedSearchGuide'…8 2.10. 'facsimileTelephoneNumber'…9 2.11. 'generationQualifier'…9 2.12. 'givenName'…9 2.13. 'houseIdentifier'…9 2.14. 'イニシャル'…10 2.15. 'internationalISDNNumber'…10 2.16. 'l'…10 2.17. 'メンバー'…11 2.18. '命名します'。11 2.19. 'o'…11 2.20. 'ou'…12 2.21. '所有者'…12 2.22. 'physicalDeliveryOfficeName'…12 2.23. 'postalAddress'…13 2.24. 'postalCode'…13 2.25. 'postOfficeBox'…14 2.26. 'preferredDeliveryMethod'…14 2.27. 'registeredAddress'…14 2.28. 'roleOccupant'…15 2.29. 'searchGuide'…15 2.30. 'seeAlso'…15 2.31. 'serialNumber'…16 2.32. 'sn'…16 2.33. 'st'…16 2.34. '通り'…17 2.35. 'telephoneNumber'…17 2.36. 'teletexTerminalIdentifier'…17 2.37. 'telexNumber'…18 2.38. 'タイトル'…18 2.39. 'uid'…18 2.40. 'uniqueMember'…19 2.41. 'userPassword'…19
Sciberras Standards Track [Page 2] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[2ページ]: ユーザアプリケーション2006年6月のための図式
2.42. 'x121Address' ............................................20
2.43. 'x500UniqueIdentifier' ...................................20
3. Object Classes .................................................20
3.1. 'applicationProcess' ......................................21
3.2. 'country' .................................................21
3.3. 'dcObject' ................................................21
3.4. 'device' ..................................................21
3.5. 'groupOfNames' ............................................22
3.6. 'groupOfUniqueNames' ......................................22
3.7. 'locality' ................................................23
3.8. 'organization' ............................................23
3.9. 'organizationalPerson' ....................................24
3.10. 'organizationalRole' .....................................24
3.11. 'organizationalUnit' .....................................24
3.12. 'person' .................................................25
3.13. 'residentialPerson' ......................................25
3.14. 'uidObject' ..............................................26
4. IANA Considerations ............................................26
5. Security Considerations ........................................28
6. Acknowledgements ...............................................28
7. References .....................................................29
7.1. Normative References ......................................29
7.2. Informative References ....................................30
Appendix A Changes Made Since RFC 2256 ...........................32
2.42. 'x121Address'…20 2.43. 'x500UniqueIdentifier'…20 3. クラスは反対します…20 3.1. 'applicationProcess'…21 3.2. '国'…21 3.3. 'dcObject'…21 3.4. 'デバイス'…21 3.5. 'groupOfNames'…22 3.6. 'groupOfUniqueNames'…22 3.7. '場所'…23 3.8. '組織'…23 3.9. 'organizationalPerson'…24 3.10. 'organizationalRole'…24 3.11. 'organizationalUnit'…24 3.12. '人'…25 3.13. 'residentialPerson'…25 3.14. 'uidObject'…26 4. IANA問題…26 5. セキュリティ問題…28 6. 承認…28 7. 参照…29 7.1. 標準の参照…29 7.2. 有益な参照…RFC2256以来変化が作った30付録…32
1. Introduction
1. 序論
This document provides an overview of attribute types and object classes intended for use by Lightweight Directory Access Protocol (LDAP) directory clients for many directory services, such as White Pages. Originally specified in the X.500 [X.500] documents, these objects are widely used as a basis for the schema in many LDAP directories. This document does not cover attributes used for the administration of directory servers, nor does it include directory objects defined for specific uses in other documents.
このドキュメントは使用のためにライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)ディレクトリクライアントによって意図された属性タイプとオブジェクトのクラスの概要を多くのディレクトリサービスに提供します、ホワイトPagesなどのように。 元々X.500で指定された[X.500]ドキュメント、これらのオブジェクトは多くのLDAPディレクトリの図式の基礎として広く使用されます。 このドキュメントはディレクトリサーバの管理に使用される属性をカバーしていません、そして、それは他のドキュメントにおける特定の用途のために定義されたディレクトリオブジェクトを含んでいません。
1.1. Relationship with Other Specifications
1.1. 他の仕様との関係
This document is an integral part of the LDAP technical specification [RFC4510], which obsoletes the previously defined LDAP technical specification, RFC 3377, in its entirety. In terms of RFC 2256, Sections 6 and 8 of RFC 2256 are obsoleted by [RFC4517]. Sections 5.1, 5.2, 7.1, and 7.2 of RFC 2256 are obsoleted by [RFC4512]. The remainder of RFC 2256 is obsoleted by this document. The technical specification for the 'dc' attribute type and 'dcObject' object class found in RFC 2247 are superseded by sections 2.4 and 3.3 of this document. The remainder of RFC 2247 remains in force.
このドキュメントはLDAP技術仕様書[RFC4510]の不可欠の部分です。(それは、以前に定義されたLDAP技術仕様書、RFC3377を全体として時代遅れにします)。 RFC2256に関して、RFC2256のセクション6と8は[RFC4517]によって時代遅れにされます。 RFC2256のセクション5.1、5.2、7.1、および7.2は[RFC4512]によって時代遅れにされます。 RFC2256の残りはこのドキュメントによって時代遅れにされます。 'dc'属性タイプと'dcObject'オブジェクトのクラスのための技術仕様書によって、RFCで2247がこのドキュメントのセクション2.4と3.3によって取って代わられるのがわかりました。 RFC2247の残りは有効なままで残っています。
Sciberras Standards Track [Page 3] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[3ページ]: ユーザアプリケーション2006年6月のための図式
This document updates RFC 2798 by replacing the informative description of the 'uid' attribute type with the definitive description provided in Section 2.39 of this document.
このドキュメントは、このドキュメントのセクション2.39に決定的な記述を提供している'uid'属性タイプの有益な記述を取り替えることによって、RFC2798をアップデートします。
This document updates RFC 2377 by replacing the informative description of the 'uidObject' object class with the definitive description provided in Section 3.14 of this document.
このドキュメントは、このドキュメントのセクション3.14に決定的な記述を提供している'uidObject'オブジェクトのクラスの有益な記述を取り替えることによって、RFC2377をアップデートします。
A number of schema elements that were included in the previous revision of the LDAP Technical Specification are not included in this revision of LDAP. PKI-related schema elements are now specified in [RFC4523]. Unless reintroduced in future technical specifications, the remainder are to be considered Historic.
LDAP仕様書の前の改正に含まれていた多くの図式要素はLDAPのこの改正に含まれていません。 PKI関連の図式要素は現在、[RFC4523]で指定されます。 将来の技術仕様書で再紹介されない場合、残りはHistoricであると考えられることです。
The descriptions in this document SHALL be considered definitive for use in LDAP.
LDAPにおける使用に決定的に考えられて、これの記述はSHALLを記録します。
1.2. Conventions
1.2. コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.3. General Issues
1.3. 一般答弁
This document references Syntaxes defined in Section 3 of [RFC4517] and Matching Rules defined in Section 4 of [RFC4517].
[RFC4517]のセクション3で定義されたこのドキュメント参照Syntaxesと[RFC4517]のセクション4で定義されたMatching Rules。
The definitions of Attribute Types and Object Classes are written using the Augmented Backus-Naur Form (ABNF) [RFC4234] of AttributeTypeDescription and ObjectClassDescription given in [RFC4512]. Lines have been folded for readability. When such values are transferred as attribute values in the LDAP Protocol, the values will not contain line breaks.
Attribute TypesとObject Classesの定義は、[RFC4512]で与えられているAttributeTypeDescriptionとObjectClassDescriptionのAugmented BN記法(ABNF)[RFC4234]を使用することで書かれています。 読み易さのために線を折り重ねてあります。 LDAPプロトコルの属性値としてそのような値を移すとき、値はラインブレイクを含まないでしょう。
2. Attribute Types
2. 属性タイプ
The attribute types contained in this section hold user information.
このセクションに含まれた属性タイプはユーザー情報を保持します。
There is no requirement that servers implement the 'searchGuide' and 'teletexTerminalIdentifier' attribute types. In fact, their use is greatly discouraged.
サーバが、'searchGuide'と'teletexTerminalIdentifier'が属性タイプであると実装するという要件が全くありません。 事実上、彼らの使用は大いにお勧めできないです。
An LDAP server implementation SHOULD recognize the rest of the attribute types described in this section.
SHOULDが、属性タイプの残りがこのセクションで説明したと認めるLDAPサーバ実装。
Sciberras Standards Track [Page 4] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[4ページ]: ユーザアプリケーション2006年6月のための図式
2.1. 'businessCategory'
2.1. 'businessCategory'
The 'businessCategory' attribute type describes the kinds of business performed by an organization. Each kind is one value of this multi-valued attribute. (Source: X.520 [X.520])
'businessCategory'属性タイプは組織によって行われたビジネスの種類について説明します。 各種類はこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.15 NAME 'businessCategory'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
(2.5.4.15名前'businessCategory'平等caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch構文1.3.6.1.4.1、.1466、.115、.121、.1、.15)
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.15、ディレクトリString構文[RFC4517]を示します。
Examples: "banking", "transportation", and "real estate".
例: 「銀行業」、「輸送」、および「不動産。」
2.2. 'c'
2.2. 'c'
The 'c' ('countryName' in X.500) attribute type contains a two-letter
ISO 3166 [ISO3166] country code.
(Source: X.520 [X.520])
'c'(X.500の'countryName')属性タイプは2文字のISO3166[ISO3166]国名略号を含みます。 (ソース: X.520[X.520])
( 2.5.4.6 NAME 'c'
SUP name
SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
SINGLE-VALUE )
(2.5.4.6NAME'c'SUP名前SYNTAX1.3.6.1.4.1、.1466、.115、.121、.1、.11SINGLE-VALUE)
1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.11、Country String構文[RFC4517]を示します。
Examples: "DE", "AU" and "FR".
例: 「DE」、「Au」、および"FR"。
2.3. 'cn'
2.3. 'cn'
The 'cn' ('commonName' in X.500) attribute type contains names of an
object. Each name is one value of this multi-valued attribute. If
the object corresponds to a person, it is typically the person's full
name.
(Source: X.520 [X.520])
'cn'(X.500の'commonName')属性タイプはオブジェクトの名前を含みます。 各名前はこのマルチ評価された属性の1つの値です。 オブジェクトが人に文通されるなら、それは通常人のフルネームです。 (ソース: X.520[X.520])
( 2.5.4.3 NAME 'cn'
SUP name )
(.4.3NAME'cn'SUPが命名する2.5)
Examples: "Martin K Smith", "Marty Smith" and "printer12".
例: 「マーチン・Kスミス」、「マーティ・スミス」、および"printer12""。
Sciberras Standards Track [Page 5] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[5ページ]: ユーザアプリケーション2006年6月のための図式
2.4. 'dc'
2.4. 'dc'
The 'dc' ('domainComponent' in RFC 1274) attribute type is a string
holding one component, a label, of a DNS domain name
[RFC1034][RFC2181] naming a host [RFC1123]. That is, a value of this
attribute is a string of ASCII characters adhering to the following
ABNF [RFC4234]:
'dc'(RFC1274の'domainComponent')属性タイプは1つのコンポーネントを保持するストリングです、DNSドメイン名のラベル[RFC1034][RFC2181]が[RFC1123]にホストを任命して。 すなわち、この属性の値は以下のABNF[RFC4234]を固く守る一連のASCII文字です:
label = (ALPHA / DIGIT) [*61(ALPHA / DIGIT / HYPHEN) (ALPHA / DIGIT)]
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
DIGIT = %x30-39 ; "0"-"9"
HYPHEN = %x2D ; hyphen ("-")
=(アルファー/DIGIT)[*61(アルファー/DIGIT/HYPHEN)(アルファー/DIGIT)]アルファー=%をx41-5A/%x61-7Aとラベルしてください。 --「Z」/“a"--「z」ケタ=%x30-39。 「0インチ--」 9インチは=%x2Dをハイフンで結びます。 ハイフン("-")
The encoding of IA5String for use in LDAP is simply the characters of the ASCII label. The equality matching rule is case insensitive, as is today's DNS. (Source: RFC 2247 [RFC2247] and RFC 1274 [RFC 1274])
LDAPにおける使用のためのIA5Stringのコード化は単にASCIIラベルのキャラクタです。 平等の合っている規則は今日のDNSのように大文字と小文字を区別しないです。 (ソース: RFC2247[RFC2247]とRFC1274[RFC1274])
( 0.9.2342.19200300.100.1.25 NAME 'dc'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )
(0.9.2342.19200300.100.1.25名前'dc'平等caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch構文1.3.6の.115の.121の.1の.26のただ一つの.1.4.1.1466価値)
1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.26、IA5 String構文[RFC4517]を示します。
Examples: Valid values include "example" and "com" but not "example.com". The latter is invalid as it contains multiple domain components.
例: 有効値は"example.com"ではなく「例」と"com"を含んでいます。 複数のドメインコンポーネントを含むとき、後者は無効です。
It is noted that the directory service will not ensure that values of this attribute conform to the host label restrictions [RFC1123] illustrated by the <label> production provided above. It is the directory client's responsibility to ensure that the labels it stores in this attribute are appropriately restricted.
ディレクトリサービスが、この属性の値が上に提供された<ラベル>生産で例証されたホストラベル制限[RFC1123]に従うのを確実にしないことに注意されます。 それがこの属性で保存するラベルが適切に制限されるのを保証するのは、ディレクトリクライアントの責任です。
Directory applications supporting International Domain Names SHALL use the ToASCII method [RFC3490] to produce the domain component label. The special considerations discussed in Section 4 of RFC 3490 [RFC3490] should be taken, depending on whether the domain component is used for "stored" or "query" purposes.
国際Domain Names SHALLをサポートするディレクトリアプリケーションがドメインコンポーネントラベルを作り出すToASCIIメソッド[RFC3490]を使用します。 RFC3490[RFC3490]のセクション4で議論した特別な問題を取るべきです、ドメインコンポーネントが「保存」か「質問」目的に使用されるかどうかによって。
2.5. 'description'
2.5. '記述'
The 'description' attribute type contains human-readable descriptive phrases about the object. Each description is one value of this multi-valued attribute. (Source: X.520 [X.520])
'記述'属性タイプはオブジェクトに関する人間読み込み可能な描写的である句を含みます。 各記述はこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
Sciberras Standards Track [Page 6] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[6ページ]: ユーザアプリケーション2006年6月のための図式
( 2.5.4.13 NAME 'description'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
(2.5.4.13名'記述'平等caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch構文1.3.6.1.4.1の.1466、.115、.121、.1、.15)
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.15、ディレクトリString構文[RFC4517]を示します。
Examples: "a color printer", "Maintenance is done every Monday, at
1pm.", and "distribution list for all technical staff".
例: 「カラープリンタ」と「午後1時に毎週月曜日にメインテナンスをします」。. 「すべての技術スタッフのための発送先リスト。」
2.6. 'destinationIndicator'
2.6. 'destinationIndicator'
The 'destinationIndicator' attribute type contains country and city strings associated with the object (the addressee) needed to provide the Public Telegram Service. The strings are composed in accordance with CCITT Recommendations F.1 [F.1] and F.31 [F.31]. Each string is one value of this multi-valued attribute. (Source: X.520 [X.520])
属性タイプが含む'destinationIndicator'国とオブジェクト(受け取り人)に関連している都市のストリングは、Public Telegram Serviceを提供する必要がありました。 CCITT Recommendations F.1[F.1]とF.31[F.31]によると、ストリングは構成されます。 各ストリングはこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.27 NAME 'destinationIndicator'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
(2.5.4.27名前'destinationIndicator'平等caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch構文1.3.6.1.4.1、.1466、.115、.121、.1、.44)
1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.44、Printable String構文[RFC4517]を示します。
Examples: "AASD" as a destination indicator for Sydney, Australia.
"GBLD" as a destination indicator for London, United
Kingdom.
例: シドニー(オーストラリア)への目的地インディケータとしての"AASD"。 ロンドン、イギリスへの目的地インディケータとしての"GBLD"。
It is noted that the directory will not ensure that values of this attribute conform to the F.1 and F.31 CCITT Recommendations. It is the application's responsibility to ensure destination indicators that it stores in this attribute are appropriately constructed.
ディレクトリが、この属性の値がF.1とF.31 CCITT Recommendationsに従うのを確実にしないことに注意されます。 それがこの属性で保存する目的地インディケータが適切に構成されるのを保証するのは、アプリケーションの責任です。
2.7. 'distinguishedName'
2.7. 'distinguishedName'
The 'distinguishedName' attribute type is not used as the name of the object itself, but it is instead a base type from which some user attribute types with a DN syntax can inherit.
'distinguishedName'属性タイプはオブジェクト自体の名前として使用されませんが、それは代わりにDN構文をもっている何人かのユーザ属性タイプが世襲できるベースタイプです。
It is unlikely that values of this type itself will occur in an entry. LDAP server implementations that do not support attribute subtyping need not recognize this attribute in requests. Client implementations MUST NOT assume that LDAP servers are capable of performing attribute subtyping.
このタイプ自体の値がエントリーに起こるのは、ありそうもないです。 属性副タイプをサポートしないLDAPサーバ実装は要求におけるこの属性を認識する必要はありません。 クライアント実装は、LDAPサーバが属性副タイプを実行できると仮定してはいけません。
Sciberras Standards Track [Page 7] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[7ページ]: ユーザアプリケーション2006年6月のための図式
(Source: X.520 [X.520])
(ソース: X.520[X.520])
( 2.5.4.49 NAME 'distinguishedName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
(2.5.4.49名前'distinguishedName'平等distinguishedNameMatch構文1.3.6.1.4.1、.1466、.115、.121、.1、.12)
1.3.6.1.4.1.1466.115.121.1.12 refers to the DN syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.12、DN構文[RFC4517]を示します。
2.8. 'dnQualifier'
2.8. 'dnQualifier'
The 'dnQualifier' attribute type contains disambiguating information strings to add to the relative distinguished name of an entry. The information is intended for use when merging data from multiple sources in order to prevent conflicts between entries that would otherwise have the same name. Each string is one value of this multi-valued attribute. It is recommended that a value of the 'dnQualifier' attribute be the same for all entries from a particular source. (Source: X.520 [X.520])
エントリーの相対的な分類名に加えるために情報ストリングのあいまいさを除く属性タイプが含む'dnQualifier'。 そうでなければ同じ名前を持っているエントリーの間の闘争を防ぐために複数のソースからのデータを合併するとき、情報は使用のために意図します。 各ストリングはこのマルチ評価された属性の1つの値です。 特定のソースからのすべてのエントリーに、'dnQualifier'属性の値が同じであることは、お勧めです。 (ソース: X.520[X.520])
( 2.5.4.46 NAME 'dnQualifier'
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
(2.5.4.46名'dnQualifier'平等caseIgnoreMatch注文caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch構文1.3.6.1.4.1.1466の.115、.121、.1、.44)
1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.44、Printable String構文[RFC4517]を示します。
Examples: "20050322123345Z" - timestamps can be used to disambiguate
information.
"123456A" - serial numbers can be used to disambiguate
information.
例: "20050322123345Z"--情報のあいまいさを除くのにタイムスタンプを使用できます。 "123456A"--情報のあいまいさを除くのに通し番号を使用できます。
2.9. 'enhancedSearchGuide'
2.9. 'enhancedSearchGuide'
The 'enhancedSearchGuide' attribute type contains sets of information for use by directory clients in constructing search filters. Each set is one value of this multi-valued attribute. (Source: X.520 [X.520])
'enhancedSearchGuide'属性タイプは検索フィルタを組み立てる際にディレクトリクライアントによる使用のために情報のセットを含みます。 各セットはこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.47 NAME 'enhancedSearchGuide'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
(2.5.4.47名'enhancedSearchGuide'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.21)
1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.21、Enhancedガイド構文[RFC4517]を示します。
Sciberras Standards Track [Page 8] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[8ページ]: ユーザアプリケーション2006年6月のための図式
Examples: "person#(sn$APPROX)#wholeSubtree" and
"organizationalUnit#(ou$SUBSTR)#oneLevel".
例: 「人#($を約snします)の#wholeSubtree」と「organizationalUnit#ou$(SUBSTR)#oneLevel。」
2.10. 'facsimileTelephoneNumber'
2.10. 'facsimileTelephoneNumber'
The 'facsimileTelephoneNumber' attribute type contains telephone numbers (and, optionally, the parameters) for facsimile terminals. Each telephone number is one value of this multi-valued attribute. (Source: X.520 [X.520])
'facsimileTelephoneNumber'属性タイプはファクシミリ端末への電話番号(任意にパラメタ)を含みます。 各電話番号はこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.23 NAME 'facsimileTelephoneNumber'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
(2.5.4.23名'facsimileTelephoneNumber'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.22)
1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone Number syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.22、Facsimile Telephone Number構文[RFC4517]を示します。
Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution".
例: 「「+61 3、9896 7801、」 」 +81 3、347の7418ドルのfineResolution、」
2.11. 'generationQualifier'
2.11. 'generationQualifier'
The 'generationQualifier' attribute type contains name strings that are typically the suffix part of a person's name. Each string is one value of this multi-valued attribute. (Source: X.520 [X.520])
'generationQualifier'属性タイプは通常、人の名前の接尾語部分である名前ストリングを含みます。 各ストリングはこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.44 NAME 'generationQualifier'
SUP name )
(.4.44NAME'generationQualifier'SUPが命名する2.5)
Examples: "III", "3rd", and "Jr.".
例: 「III」、「3番目」、および「Jr.。」
2.12. 'givenName'
2.12. 'givenName'
The 'givenName' attribute type contains name strings that are the part of a person's name that is not their surname. Each string is one value of this multi-valued attribute. (Source: X.520 [X.520])
'givenName'属性タイプはそれらの姓でない人の名前の部分である名前ストリングを含みます。 各ストリングはこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.42 NAME 'givenName'
SUP name )
(.4.42NAME'givenName'SUPが命名する2.5)
Examples: "Andrew", "Charles", and "Joanne".
例: 「アンドリュー」、「チャールズ」、および「ジョアン。」
2.13. 'houseIdentifier'
2.13. 'houseIdentifier'
The 'houseIdentifier' attribute type contains identifiers for a building within a location. Each identifier is one value of this multi-valued attribute. (Source: X.520 [X.520])
'houseIdentifier'属性タイプは位置の中にビルのための識別子を保管しています。 各識別子はこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
Sciberras Standards Track [Page 9] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[9ページ]: ユーザアプリケーション2006年6月のための図式
( 2.5.4.51 NAME 'houseIdentifier'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
(2.5.4.51名前'houseIdentifier'平等caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch構文1.3.6.1.4.1、.1466、.115、.121、.1、.15)
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.15、ディレクトリString構文[RFC4517]を示します。
Example: "20" to represent the house number 20.
例: 「番地20を表す20インチ。」
2.14. 'initials'
2.14. 'イニシャル'
The 'initials' attribute type contains strings of initials of some or all of an individual's names, except the surname(s). Each string is one value of this multi-valued attribute. (Source: X.520 [X.520])
'イニシャル'属性タイプはいくつかのイニシャルのストリングか姓以外の個人の名前のすべてを含みます。 各ストリングはこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.43 NAME 'initials'
SUP name )
(SUPが命名する2.5.4.43NAME'イニシャル')
Examples: "K. A." and "K".
例: 「K。」 「A.」と「K。」
2.15. 'internationalISDNNumber'
2.15. 'internationalISDNNumber'
The 'internationalISDNNumber' attribute type contains Integrated Services Digital Network (ISDN) addresses, as defined in the International Telecommunication Union (ITU) Recommendation E.164 [E.164]. Each address is one value of this multi-valued attribute. (Source: X.520 [X.520])
'internationalISDNNumber'属性タイプはIntegrated Services Digital Network(ISDN)アドレスを含みます、国際電気通信連合(ITU)推薦E.164[E.164]で定義されるように。 各アドレスはこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.25 NAME 'internationalISDNNumber'
EQUALITY numericStringMatch
SUBSTR numericStringSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
(2.5.4.25名前'internationalISDNNumber'平等numericStringMatch SUBSTR numericStringSubstringsMatch構文1.3.6.1.4.1、.1466、.115、.121、.1、.36)
1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.36、Numeric String構文[RFC4517]を示します。
Example: "0198 333 333".
例: "0198 333 333".
2.16. 'l'
2.16. 'l'
The 'l' ('localityName' in X.500) attribute type contains names of a
locality or place, such as a city, county, or other geographic
region. Each name is one value of this multi-valued attribute.
(Source: X.520 [X.520])
'l'(X.500の'localityName')属性タイプは場所か場所の名前を含みます、都市、カウンティー、または他の地理的な領域などのように。 各名前はこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
Sciberras Standards Track [Page 10] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[10ページ]: ユーザアプリケーション2006年6月のための図式
( 2.5.4.7 NAME 'l'
SUP name )
(2.5.4.7NAME'l'SUP名)
Examples: "Geneva", "Paris", and "Edinburgh".
例: 「ジュネーブ」、「パリ」、および「エディンバラ。」
2.17. 'member'
2.17. 'メンバー'
The 'member' attribute type contains the distinguished names of objects that are on a list or in a group. Each name is one value of this multi-valued attribute. (Source: X.520 [X.520])
'メンバー'属性タイプはリストかグループにはあるオブジェクトの分類名を含みます。 各名前はこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.31 NAME 'member'
SUP distinguishedName )
(2.5.4.31名前'メンバー'一口distinguishedName)
Examples: "cn=James Clarke,ou=Finance,o=Widget\, Inc." and
"cn=John Xerri,ou=Finance,o=Widget\, Inc." may
be two members of the financial team (group) at Widget,
Inc., in which case, both of these distinguished names
would be present as individual values of the member
attribute.
例: 「cnはジェームス・クラークと等しいです、=が融資するou、o=ウィジェット\Inc.」と「cnはジョンXerriと等しいです、ou=財政、o=ウィジェット\Inc.」は存在するかもしれません。Widget Inc.には財政的なチーム(グループ)の2人のメンバーがいます、その場合、これらの分類名の両方がメンバー属性の個人価値として存在しているでしょう。
2.18. 'name'
2.18. '名前'
The 'name' attribute type is the attribute supertype from which user attribute types with the name syntax inherit. Such attribute types are typically used for naming. The attribute type is multi-valued.
'名前'属性タイプは構文という名前をもっているユーザ属性タイプが世襲する属性「スーパー-タイプ」です。 そのような属性タイプは命名に通常使用されます。 属性タイプはマルチ大切です。
It is unlikely that values of this type itself will occur in an entry. LDAP server implementations that do not support attribute subtyping need not recognize this attribute in requests. Client implementations MUST NOT assume that LDAP servers are capable of performing attribute subtyping. (Source: X.520 [X.520])
このタイプ自体の値がエントリーに起こるのは、ありそうもないです。 属性副タイプをサポートしないLDAPサーバ実装は要求におけるこの属性を認識する必要はありません。 クライアント実装は、LDAPサーバが属性副タイプを実行できると仮定してはいけません。 (ソース: X.520[X.520])
( 2.5.4.41 NAME 'name'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
(2.5.4.41名'名前'平等caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch構文1.3.6.1.4.1の.1466、.115、.121、.1、.15)
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.15、ディレクトリString構文[RFC4517]を示します。
2.19. 'o'
2.19. 'o'
The 'o' ('organizationName' in X.500) attribute type contains the
names of an organization. Each name is one value of this
multi-valued attribute.
'o'(X.500の'organizationName')属性タイプは組織の名前を含みます。 各名前はこのマルチ評価された属性の1つの値です。
Sciberras Standards Track [Page 11] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[11ページ]: ユーザアプリケーション2006年6月のための図式
(Source: X.520 [X.520])
(ソース: X.520[X.520])
( 2.5.4.10 NAME 'o'
SUP name )
(2.5.4.10NAME'o'SUP名)
Examples: "Widget", "Widget, Inc.", and "Widget, Incorporated.".
例: そして、「ウィジェット」、「ウィジェットInc.」、「ウィジェット取り入れられて、
2.20. 'ou'
2.20. 'ou'
The 'ou' ('organizationalUnitName' in X.500) attribute type contains
the names of an organizational unit. Each name is one value of this
multi-valued attribute.
(Source: X.520 [X.520])
'ou'(X.500の'organizationalUnitName')属性タイプは組織的なユニットの名前を含みます。 各名前はこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.11 NAME 'ou'
SUP name )
(.4.11NAME'ou'SUPが命名する2.5)
Examples: "Finance", "Human Resources", and "Research and
Development".
例: 「財政」、「人的資源」、および「研究開発。」
2.21. 'owner'
2.21. '所有者'
The 'owner' attribute type contains the distinguished names of objects that have an ownership responsibility for the object that is owned. Each owner's name is one value of this multi-valued attribute. (Source: X.520 [X.520])
'所有者'属性タイプは所有されているオブジェクトへの所有権責任を持っているオブジェクトの分類名を含みます。 各所有者の名前はこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.32 NAME 'owner'
SUP distinguishedName )
(2.5.4.32名前'所有者'一口distinguishedName)
Example: The mailing list object, whose DN is "cn=All Employees,
ou=Mailing List,o=Widget\, Inc.", is owned by the Human
Resources Director.
例: メーリングリストオブジェクト(DNは「ou=メーリングリスト、ウィジェット\o=Inc.のcn=全社員」である)は人事部のディレクターによって所有されています。
Therefore, the value of the 'owner' attribute within the
mailing list object, would be the DN of the director (role):
"cn=Human Resources Director,ou=employee,o=Widget\, Inc.".
したがって、メーリングリストオブジェクトの中の'所有者'属性の値はディレクター(役割)のDNでしょう: 「cnは人事部のディレクターと等しく、ouはウィジェット\o=Inc.の従業員と等しいです。」
2.22. 'physicalDeliveryOfficeName'
2.22. 'physicalDeliveryOfficeName'
The 'physicalDeliveryOfficeName' attribute type contains names that a Postal Service uses to identify a post office. (Source: X.520 [X.520])
'physicalDeliveryOfficeName'属性タイプはPostal Serviceが郵便局を特定するのに使用する名前を含みます。 (ソース: X.520[X.520])
Sciberras Standards Track [Page 12] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[12ページ]: ユーザアプリケーション2006年6月のための図式
( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
(2.5.4.19名前'physicalDeliveryOfficeName'平等caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch構文1.3.6.1.4.1、.1466、.115、.121、.1、.15)
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.15、ディレクトリString構文[RFC4517]を示します。
Examples: "Bremerhaven, Main" and "Bremerhaven, Bonnstrasse".
例: 「ブレーマーハーフェン、メイン」と「ブレーマーハーフェン、Bonnstrasse。」
2.23. 'postalAddress'
2.23. 'postalAddress'
The 'postalAddress' attribute type contains addresses used by a Postal Service to perform services for the object. Each address is one value of this multi-valued attribute. (Source: X.520 [X.520])
'postalAddress'属性タイプはオブジェクトのためのサービスを実行するのにPostal Serviceによって使用されたアドレスを含みます。 各アドレスはこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.16 NAME 'postalAddress'
EQUALITY caseIgnoreListMatch
SUBSTR caseIgnoreListSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
(2.5.4.16名前'postalAddress'平等caseIgnoreListMatch SUBSTR caseIgnoreListSubstringsMatch構文1.3.6.1.4.1、.1466、.115、.121、.1、.41)
1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.41、Postal Address構文[RFC4517]を示します。
Example: "15 Main St.$Ottawa$Canada".
例: 「主な15$オタワ聖ドルのカナダ。」
2.24. 'postalCode'
2.24. 'postalCode'
The 'postalCode' attribute type contains codes used by a Postal Service to identify postal service zones. Each code is one value of this multi-valued attribute. (Source: X.520 [X.520])
'postalCode'属性タイプは郵便業務ゾーンを特定するのにPostal Serviceによって使用されたコードを含みます。 各コードはこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.17 NAME 'postalCode'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
(2.5.4.17名前'postalCode'平等caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch構文1.3.6.1.4.1、.1466、.115、.121、.1、.15)
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.15、ディレクトリString構文[RFC4517]を示します。
Example: "22180", to identify Vienna, VA, in the USA.
例: 「22180」 米国でウィーン(ヴァージニア)を特定するために。
Sciberras Standards Track [Page 13] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[13ページ]: ユーザアプリケーション2006年6月のための図式
2.25. 'postOfficeBox'
2.25. 'postOfficeBox'
The 'postOfficeBox' attribute type contains postal box identifiers that a Postal Service uses when a customer arranges to receive mail at a box on the premises of the Postal Service. Each postal box identifier is a single value of this multi-valued attribute. (Source: X.520 [X.520])
顧客が、現場の間、箱にメールを受け取るように手配するとき、'postOfficeBox'属性タイプはPostal ServiceについてPostal Serviceが使用する郵便の箱の識別子を含みます。 それぞれの郵便の箱の識別子はこのマルチ評価された属性のただ一つの値です。 (ソース: X.520[X.520])
( 2.5.4.18 NAME 'postOfficeBox'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
(2.5.4.18名前'postOfficeBox'平等caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch構文1.3.6.1.4.1、.1466、.115、.121、.1、.15)
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.15、ディレクトリString構文[RFC4517]を示します。
Example: "Box 45".
例: 「箱の45インチ。」
2.26. 'preferredDeliveryMethod'
2.26. 'preferredDeliveryMethod'
The 'preferredDeliveryMethod' attribute type contains an indication of the preferred method of getting a message to the object. (Source: X.520 [X.520])
'preferredDeliveryMethod'属性タイプはメッセージをオブジェクトに得る適した方法のしるしを含みます。 (ソース: X.520[X.520])
( 2.5.4.28 NAME 'preferredDeliveryMethod'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
SINGLE-VALUE )
(2.5.4.28名前'preferredDeliveryMethod'構文1.3.6の.115の.121の.1の.14のただ一つの.1.4.1.1466価値)
1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.14、Delivery Method構文[RFC4517]を示します。
Example: If the mhs-delivery Delivery Method is preferred over
telephone-delivery, which is preferred over all other
methods, the value would be: "mhs $ telephone".
例: mhs-配送Delivery Methodが都合のよい電話配送(他のメソッド、すべての値より好まれる)がそうするならである: 「mhs$電話。」
2.27. 'registeredAddress'
2.27. 'registeredAddress'
The 'registeredAddress' attribute type contains postal addresses suitable for reception of telegrams or expedited documents, where it is necessary to have the recipient accept delivery. Each address is one value of this multi-valued attribute. (Source: X.520 [X.520])
'registeredAddress'属性タイプは、電報のレセプションに適当な郵便の宛先を含んだか、またはドキュメントを速めました。そこでは、受取人に荷渡しを承諾させるのが必要です。 各アドレスはこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.26 NAME 'registeredAddress'
SUP postalAddress
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
(2.5.4.26名前'registeredAddress'一口postalAddress構文1.3.6.1.4.1、.1466、.115、.121、.1、.41)
Sciberras Standards Track [Page 14] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[14ページ]: ユーザアプリケーション2006年6月のための図式
1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.41、Postal Address構文[RFC4517]を示します。
Example: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada".
例: 「受付係$15ドルのウィジェットのInc.の主な通り$オタワ$カナダ。」
2.28. 'roleOccupant'
2.28. 'roleOccupant'
The 'roleOccupant' attribute type contains the distinguished names of objects (normally people) that fulfill the responsibilities of a role object. Each distinguished name is one value of this multi-valued attribute. (Source: X.520 [X.520])
'roleOccupant'属性タイプは役割のオブジェクトの責任を実現させるオブジェクト(通常人々)の分類名を含みます。 各分類名はこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.33 NAME 'roleOccupant'
SUP distinguishedName )
(2.5.4.33名の'roleOccupant'一口distinguishedName)
Example: The role object, "cn=Human Resources
Director,ou=Position,o=Widget\, Inc.", is fulfilled by two
people whose object names are "cn=Mary
Smith,ou=employee,o=Widget\, Inc." and "cn=James
Brown,ou=employee,o=Widget\, Inc.". The 'roleOccupant'
attribute will contain both of these distinguished names,
since they are the occupants of this role.
例: オブジェクト名が「cnはメアリ・スミスと等しいです、ou=従業員、o=ウィジェット\Inc.」と「cnはジェームス・ブラウンと等しいです、ou=従業員、o=ウィジェット\Inc.」である2人の人が「cnは人事部のディレクターと等しいです、ou=位置、ウィジェット\o=Inc.」という役割のオブジェクトを実現させています。 'roleOccupant'属性は、彼らがこの役割の占有者であるので、これらの分類名の両方を含むでしょう。
2.29. 'searchGuide'
2.29. 'searchGuide'
The 'searchGuide' attribute type contains sets of information for use by clients in constructing search filters. It is superseded by 'enhancedSearchGuide', described above in Section 2.9. Each set is one value of this multi-valued attribute. (Source: X.520 [X.520])
'searchGuide'属性タイプは検索フィルタを組み立てる際にクライアントによる使用のために情報のセットを含みます。 それはセクション2.9で上で説明された'enhancedSearchGuide'によって取って代わられます。 各セットはこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.14 NAME 'searchGuide'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
(2.5.4.14名'searchGuide'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.25)
1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.25、ガイド構文[RFC4517]を示します。
Example: "person#sn$EQ".
例: 「人#sn$EQ。」
2.30. 'seeAlso'
2.30. 'seeAlso'
The 'seeAlso' attribute type contains the distinguished names of objects that are related to the subject object. Each related object name is one value of this multi-valued attribute. (Source: X.520 [X.520])
'seeAlso'属性タイプは対象のオブジェクトに関連するオブジェクトの分類名を含みます。 それぞれの関連するオブジェクト名はこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.34 NAME 'seeAlso'
SUP distinguishedName )
(2.5.4.34名の'seeAlso'一口distinguishedName)
Sciberras Standards Track [Page 15] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[15ページ]: ユーザアプリケーション2006年6月のための図式
Example: The person object "cn=James Brown,ou=employee,o=Widget\,
Inc." is related to the role objects "cn=Football Team
Captain,ou=sponsored activities,o=Widget\, Inc." and
"cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.".
Since the role objects are related to the person object, the
'seeAlso' attribute will contain the distinguished name of
each role object as separate values.
例: 人のオブジェクト「cnはジェームス・ブラウンと等しいです、ou=従業員、ウィジェット\o=Inc.」はそうです。役割のオブジェクト「フットボール・チームがキャプテンを務めるcn=、ou=は活動を後援しました、o=ウィジェット\Inc.」と「チェスcn=チーム、ou=は活動を後援しました、o=ウィジェット\Inc.」に関連しました。 役割のオブジェクトが人のオブジェクトに関連するので、'seeAlso'属性は別々の値としてそれぞれの役割のオブジェクトの分類名を含むでしょう。
2.31. 'serialNumber'
2.31. 'serialNumber'
The 'serialNumber' attribute type contains the serial numbers of devices. Each serial number is one value of this multi-valued attribute. (Source: X.520 [X.520])
'serialNumber'属性タイプはデバイスの通し番号を含みます。 各通し番号はこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.5 NAME 'serialNumber'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
(2.5.4.5名前'serialNumber'平等caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch構文1.3.6.1.4.1、.1466、.115、.121、.1、.44)
1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.44、Printable String構文[RFC4517]を示します。
Examples: "WI-3005" and "XF551426".
例: 「ウィスコンシン-3005」と"XF551426"。
2.32. 'sn'
2.32. 'sn'
The 'sn' ('surname' in X.500) attribute type contains name strings
for the family names of a person. Each string is one value of this
multi-valued attribute.
(Source: X.520 [X.520])
'sn'(X.500の'姓')属性タイプは人の姓のための名前ストリングを含みます。 各ストリングはこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.4 NAME 'sn'
SUP name )
(.4.4NAME'sn'SUPが命名する2.5)
Example: "Smith".
例: 「スミス。」
2.33. 'st'
2.33. 'st'
The 'st' ('stateOrProvinceName' in X.500) attribute type contains the
full names of states or provinces. Each name is one value of this
multi-valued attribute.
(Source: X.520 [X.520])
'st'(X.500の'stateOrProvinceName')属性タイプは州か州のフルネームを含みます。 各名前はこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.8 NAME 'st'
SUP name )
(2.5.4.8NAME 'st' SUP名)
Example: "California".
例: 「カリフォルニア。」
Sciberras Standards Track [Page 16] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[16ページ]: ユーザアプリケーション2006年6月のための図式
2.34. 'street'
2.34. '通り'
The 'street' ('streetAddress' in X.500) attribute type contains site
information from a postal address (i.e., the street name, place,
avenue, and the house number). Each street is one value of this
multi-valued attribute.
(Source: X.520 [X.520])
'通り'(X.500の'streetAddress')属性タイプは郵便の宛先(すなわち、通り名、場所、大通り、および番地)からのサイト情報を含みます。 各通りはこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.9 NAME 'street'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
(2.5.4.9名'通り'平等caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch構文1.3.6.1.4の.1の.1466、.115、.121、.1、.15)
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.15、ディレクトリString構文[RFC4517]を示します。
Example: "15 Main St.".
例: 「15の主な通り。」
2.35. 'telephoneNumber'
2.35. 'telephoneNumber'
The 'telephoneNumber' attribute type contains telephone numbers that comply with the ITU Recommendation E.123 [E.123]. Each number is one value of this multi-valued attribute. (Source: X.520 [X.520])
'telephoneNumber'属性タイプはITU Recommendation E.123[E.123]に従う電話番号を含みます。 各数はこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.20 NAME 'telephoneNumber'
EQUALITY telephoneNumberMatch
SUBSTR telephoneNumberSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
(2.5.4.20名前'telephoneNumber'平等telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch構文1.3.6.1.4.1、.1466、.115、.121、.1、.50)
1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.50、Telephone Number構文[RFC4517]を示します。
Example: "+1 234 567 8901".
例: "+1 234 567 8901".
2.36. 'teletexTerminalIdentifier'
2.36. 'teletexTerminalIdentifier'
The withdrawal of Recommendation F.200 has resulted in the withdrawal of this attribute. (Source: X.520 [X.520])
Recommendation F.200の退出はこの属性の退出をもたらしました。 (ソース: X.520[X.520])
( 2.5.4.22 NAME 'teletexTerminalIdentifier'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
(2.5.4.22名'teletexTerminalIdentifier'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.51)
1.3.6.1.4.1.1466.115.121.1.51 refers to the Teletex Terminal Identifier syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.51、Teletex Terminal Identifier構文[RFC4517]を示します。
Sciberras Standards Track [Page 17] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[17ページ]: ユーザアプリケーション2006年6月のための図式
2.37. 'telexNumber'
2.37. 'telexNumber'
The 'telexNumber' attribute type contains sets of strings that are a telex number, country code, and answerback code of a telex terminal. Each set is one value of this multi-valued attribute. (Source: X.520 [X.520])
'telexNumber'属性タイプはテレックス番号であるストリングのセット、国名略号、およびテレックス端末のアンサーバックコードを含みます。 各セットはこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.21 NAME 'telexNumber'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
(2.5.4.21名'telexNumber'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.52)
1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.52、Telex Number構文[RFC4517]を示します。
Example: "12345$023$ABCDE".
例: 「12345 023ドルドルのABCDE。」
2.38. 'title'
2.38. 'タイトル'
The 'title' attribute type contains the title of a person in their organizational context. Each title is one value of this multi-valued attribute. (Source: X.520 [X.520])
'タイトル'属性タイプはそれらの組織的な文脈の人のタイトルを含みます。 各タイトルはこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.12 NAME 'title'
SUP name )
Examples: "Vice President", "Software Engineer", and "CEO".
(.4.12NAME'タイトル'SUPが命名する2.5)例: 「副社長」、「ソフトウェア技術者」、および「最高経営責任者。」
2.39. 'uid'
2.39. 'uid'
The 'uid' ('userid' in RFC 1274) attribute type contains computer
system login names associated with the object. Each name is one
value of this multi-valued attribute.
(Source: RFC 2798 [RFC2798] and RFC 1274 [RFC1274])
'uid'(RFC1274の'ユーザID')属性タイプはオブジェクトに関連しているコンピュータ・システムログイン名を含みます。 各名前はこのマルチ評価された属性の1つの値です。 (ソース: RFC2798[RFC2798]とRFC1274[RFC1274])
( 0.9.2342.19200300.100.1.1 NAME 'uid'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
(0.9.2342.19200300.100.1.1名前'uid'平等caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch構文1.3.6.1.4.1、.1466、.115、.121、.1、.15)
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.15、ディレクトリString構文[RFC4517]を示します。
Examples: "s9709015", "admin", and "Administrator".
例: "s9709015"、「アドミン」、および「管理者。」
Sciberras Standards Track [Page 18] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[18ページ]: ユーザアプリケーション2006年6月のための図式
2.40. 'uniqueMember'
2.40. 'uniqueMember'
The 'uniqueMember' attribute type contains the distinguished names of an object that is on a list or in a group, where the relative distinguished names of the object include a value that distinguishes between objects when a distinguished name has been reused. Each distinguished name is one value of this multi-valued attribute. (Source: X.520 [X.520])
'uniqueMember'属性タイプはリストの上、または、オブジェクトの相対的な分類名が分類名が再利用されたときオブジェクトを見分ける値を含んでいるグループであるオブジェクトの分類名を含みます。 各分類名はこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.50 NAME 'uniqueMember'
EQUALITY uniqueMemberMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
(2.5.4.50名前'uniqueMember'平等uniqueMemberMatch構文1.3.6.1.4.1、.1466、.115、.121、.1、.34)
1.3.6.1.4.1.1466.115.121.1.34 refers to the Name and Optional UID syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.34、NameとOptional UID構文[RFC4517]を示します。
Example: If "ou=1st Battalion,o=Defense,c=US" is a battalion that was
disbanded, establishing a new battalion with the "same" name
would have a unique identifier value added, resulting in
"ou=1st Battalion, o=Defense,c=US#'010101'B".
例: 「最初のou=Battalion、o=ディフェンス、cは米国と等しく」解散された大隊であり、「同じ」名前で新しい大隊を設立するとユニークな識別子付加価値、結果になることが持たれている「ouは最初のBattalionと等しいです、o=ディフェンス、米国c=#010101''B」であるなら。
2.41. 'userPassword'
2.41. 'userPassword'
The 'userPassword' attribute contains octet strings that are known only to the user and the system to which the user has access. Each string is one value of this multi-valued attribute.
'userPassword'属性はユーザだけにおいて知られている八重奏ストリングとユーザがアクセサリーを持っているシステムを含んでいます。 各ストリングはこのマルチ評価された属性の1つの値です。
The application SHOULD prepare textual strings used as passwords by transcoding them to Unicode, applying SASLprep [RFC4013], and encoding as UTF-8. The determination of whether a password is textual is a local client matter. (Source: X.509 [X.509])
SHOULDが原文のストリングを準備するアプリケーションはパスワードとしてコード変換でユニコードにそれらを使用しました、SASLprep[RFC4013]、およびUTF-8としてのコード化を適用して。 パスワードが原文であるかどうかに関する決断はローカルのクライアント問題です。 (ソース: X.509[X.509])
( 2.5.4.35 NAME 'userPassword'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
(2.5.4.35名前'userPassword'平等octetStringMatch構文1.3.6.1.4.1、.1466、.115、.121、.1、.40)
1.3.6.1.4.1.1466.115.121.1.40 refers to the Octet String syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.40、Octet String構文[RFC4517]を示します。
Passwords are stored using an Octet String syntax and are not encrypted. Transfer of cleartext passwords is strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the password to unauthorized parties.
パスワードは、Octet String構文を使用することで保存されて、暗号化されていません。 cleartextパスワードの転送は基本的な輸送サービスが秘密性を保証できないで、パスワードの公開をもたらすかもしれないところで強く権限のないパーティーにお勧めできないです。
An example of a need for multiple values in the 'userPassword' attribute is an environment where every month the user is expected to
'userPassword'属性における複数の値の必要性に関する例は毎月ユーザが予想される環境です。
Sciberras Standards Track [Page 19] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[19ページ]: ユーザアプリケーション2006年6月のための図式
use a different password generated by some automated system. During transitional periods, like the last and first day of the periods, it may be necessary to allow two passwords for the two consecutive periods to be valid in the system.
何らかの自動化されたシステムによって生成された異なったパスワードを使用してください。 過渡的な期間、期間の最終と初日のように、2回の連続した期間の2つのパスワードがシステムで有効であることを許容するのが必要であるかもしれません。
2.42. 'x121Address'
2.42. 'x121Address'
The 'x121Address' attribute type contains data network addresses as defined by ITU Recommendation X.121 [X.121]. Each address is one value of this multi-valued attribute. (Source: X.520 [X.520])
ITU Recommendation X.121[X.121]によって定義されるように'x121Address'属性タイプはデータ網アドレスを含みます。 各アドレスはこのマルチ評価された属性の1つの値です。 (ソース: X.520[X.520])
( 2.5.4.24 NAME 'x121Address'
EQUALITY numericStringMatch
SUBSTR numericStringSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
(2.5.4.24名前'x121Address'平等numericStringMatch SUBSTR numericStringSubstringsMatch構文1.3.6.1.4.1、.1466、.115、.121、.1、.36)
1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.36、Numeric String構文[RFC4517]を示します。
Example: "36111222333444555".
例: "36111222333444555".
2.43. 'x500UniqueIdentifier'
2.43. 'x500UniqueIdentifier'
The 'x500UniqueIdentifier' attribute type contains binary strings that are used to distinguish between objects when a distinguished name has been reused. Each string is one value of this multi-valued attribute.
'x500UniqueIdentifier'属性タイプは分類名が再利用されたとき、オブジェクトを見分けるのに使用される2進のストリングを含みます。 各ストリングはこのマルチ評価された属性の1つの値です。
In X.520 [X.520], this attribute type is called 'uniqueIdentifier'. This is a different attribute type from both the 'uid' and 'uniqueIdentifier' LDAP attribute types. The 'uniqueIdentifier' attribute type is defined in [RFC4524]. (Source: X.520 [X.520])
X.520[X.520]では、この属性タイプは'uniqueIdentifier'と呼ばれます。 これは両方の'uid'と'uniqueIdentifier'LDAP属性タイプからの異なった属性タイプです。 'uniqueIdentifier'属性タイプは[RFC4524]で定義されます。 (ソース: X.520[X.520])
( 2.5.4.45 NAME 'x500UniqueIdentifier'
EQUALITY bitStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
(2.5.4.45名前'x500UniqueIdentifier'平等bitStringMatch構文1.3.6.1.4.1、.1466、.115、.121、.1、.6)
1.3.6.1.4.1.1466.115.121.1.6 refers to the Bit String syntax [RFC4517].
1.3.6.1.4.1.1466.115.121.1.6、Bit String構文[RFC4517]を示します。
3. Object Classes
3. オブジェクトのクラス
LDAP servers SHOULD recognize all the Object Classes listed here as values of the 'objectClass' attribute (see [RFC4512]).
LDAPサーバSHOULDは、ここに記載されたすべてのObject Classesが'objectClass'属性の値であると認めます([RFC4512]を見てください)。
Sciberras Standards Track [Page 20] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[20ページ]: ユーザアプリケーション2006年6月のための図式
3.1. 'applicationProcess'
3.1. 'applicationProcess'
The 'applicationProcess' object class definition is the basis of an entry that represents an application executing in a computer system. (Source: X.521 [X.521])
'applicationProcess'オブジェクトクラス定義はコンピュータ・システムで実行されるアプリケーションを表すエントリーの基礎です。 (ソース: X.521[X.521])
( 2.5.6.11 NAME 'applicationProcess'
SUP top
STRUCTURAL
MUST cn
MAY ( seeAlso $
ou $
l $
description ) )
(2.5.6.11NAME'applicationProcess'SUPの最高STRUCTURAL MUST cn5月(seeAlso$ou$l$記述))
3.2. 'country'
3.2. '国'
The 'country' object class definition is the basis of an entry that represents a country. (Source: X.521 [X.521])
'国'オブジェクトクラス定義は国を代表するエントリーの基礎です。 (ソース: X.521[X.521])
( 2.5.6.2 NAME 'country'
SUP top
STRUCTURAL
MUST c
MAY ( searchGuide $
description ) )
(2.5.6.2NAME'国'SUPの最高STRUCTURAL MUST c5月(searchGuide$記述))
3.3. 'dcObject'
3.3. 'dcObject'
The 'dcObject' object class permits an entry to contains domain component information. This object class is defined as auxiliary, because it will be used in conjunction with an existing structural object class. (Source: RFC 2247 [RFC2247])
クラスがエントリーを可能にする'dcObject'オブジェクトはドメインコンポーネント情報を含んでいます。 それが既存の構造的なオブジェクトのクラスに関連して使用されるので、このオブジェクトのクラスは同じくらい補助していた状態で定義されます。 (ソース: RFC2247[RFC2247])
( 1.3.6.1.4.1.1466.344 NAME 'dcObject'
SUP top
AUXILIARY
MUST dc )
(1.3.6.1.4.1.1466.344NAME'dcObject'SUP先端AUXILIARY MUST dc)
3.4. 'device'
3.4. 'デバイス'
The 'device' object class is the basis of an entry that represents an appliance, computer, or network element. (Source: X.521 [X.521])
'デバイス'オブジェクトのクラスは器具、コンピュータ、またはネットワーク要素を表すエントリーの基礎です。 (ソース: X.521[X.521])
Sciberras Standards Track [Page 21] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[21ページ]: ユーザアプリケーション2006年6月のための図式
( 2.5.6.14 NAME 'device'
SUP top
STRUCTURAL
MUST cn
MAY ( serialNumber $
seeAlso $
owner $
ou $
o $
l $
description ) )
(2.5.6.14NAME'デバイス'SUPの最高STRUCTURAL MUST cn5月(serialNumber$seeAlso$所有者$ou$o$l$記述))
3.5. 'groupOfNames'
3.5. 'groupOfNames'
The 'groupOfNames' object class is the basis of an entry that represents a set of named objects including information related to the purpose or maintenance of the set. (Source: X.521 [X.521])
'groupOfNames'オブジェクトのクラスはセットの目的かメインテナンスに関連する情報を含む1セットの命名されたオブジェクトを表すエントリーの基礎です。 (ソース: X.521[X.521])
( 2.5.6.9 NAME 'groupOfNames'
SUP top
STRUCTURAL
MUST ( member $
cn )
MAY ( businessCategory $
seeAlso $
owner $
ou $
o $
description ) )
(2.5.6.9NAME'groupOfNames'SUPの最高STRUCTURAL MUST(メンバー$cn)5月(businessCategory$seeAlso$所有者$ou$o$記述))
3.6. 'groupOfUniqueNames'
3.6. 'groupOfUniqueNames'
The 'groupOfUniqueNames' object class is the same as the 'groupOfNames' object class except that the object names are not repeated or reassigned within a set scope. (Source: X.521 [X.521])
オブジェクト名がセット範囲の中で繰り返されもしませんし、再選任もされないのを除いて、'groupOfUniqueNames'オブジェクトのクラスは'groupOfNames'オブジェクトのクラスと同じです。 (ソース: X.521[X.521])
Sciberras Standards Track [Page 22] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[22ページ]: ユーザアプリケーション2006年6月のための図式
( 2.5.6.17 NAME 'groupOfUniqueNames'
SUP top
STRUCTURAL
MUST ( uniqueMember $
cn )
MAY ( businessCategory $
seeAlso $
owner $
ou $
o $
description ) )
(2.5.6.17NAME'groupOfUniqueNames'SUPの最高STRUCTURAL MUST(uniqueMember$cn)5月(businessCategory$seeAlso$所有者$ou$o$記述))
3.7. 'locality'
3.7. '場所'
The 'locality' object class is the basis of an entry that represents a place in the physical world. (Source: X.521 [X.521])
'場所'オブジェクトのクラスは物理的な世界の場所を表すエントリーの基礎です。 (ソース: X.521[X.521])
( 2.5.6.3 NAME 'locality'
SUP top
STRUCTURAL
MAY ( street $
seeAlso $
searchGuide $
st $
l $
description ) )
(2.5.6.3NAME'場所'SUPがSTRUCTURAL MAYを上回っている、(通りの$seeAlso$searchGuide$、第$l$記述)
3.8. 'organization'
3.8. '組織'
The 'organization' object class is the basis of an entry that represents a structured group of people. (Source: X.521 [X.521])
'組織'オブジェクトのクラスは人々の構造化されたグループを代表するエントリーの基礎です。 (ソース: X.521[X.521])
( 2.5.6.4 NAME 'organization'
SUP top
STRUCTURAL
MUST o
MAY ( userPassword $ searchGuide $ seeAlso $
businessCategory $ x121Address $ registeredAddress $
destinationIndicator $ preferredDeliveryMethod $
telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationalISDNNumber $
facsimileTelephoneNumber $ street $ postOfficeBox $
postalCode $ postalAddress $ physicalDeliveryOfficeName $
st $ l $ description ) )
(2.5の.6の.4NAME'組織'SUPの最高STRUCTURAL MUST oがそうするかもしれない、(userPassword$searchGuide$seeAlso$businessCategory$x121Address$registeredAddress$destinationIndicator$preferredDeliveryMethod$telexNumber$teletexTerminalIdentifier$telephoneNumber$internationalISDNNumber$facsimileTelephoneNumber$通りの$postOfficeBox$postalCode$postalAddress$physicalDeliveryOfficeName$、第$l$記述)
Sciberras Standards Track [Page 23] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[23ページ]: ユーザアプリケーション2006年6月のための図式
3.9. 'organizationalPerson'
3.9. 'organizationalPerson'
The 'organizationalPerson' object class is the basis of an entry that represents a person in relation to an organization. (Source: X.521 [X.521])
'organizationalPerson'オブジェクトのクラスは組織と関連して人の代理をするエントリーの基礎です。 (ソース: X.521[X.521])
( 2.5.6.7 NAME 'organizationalPerson'
SUP person
STRUCTURAL
MAY ( title $ x121Address $ registeredAddress $
destinationIndicator $ preferredDeliveryMethod $
telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationalISDNNumber $
facsimileTelephoneNumber $ street $ postOfficeBox $
postalCode $ postalAddress $ physicalDeliveryOfficeName $
ou $ st $ l ) )
(2.5、.6.7NAME'organizationalPerson'SUP人のSTRUCTURAL MAY、(タイトル$x121Address$registeredAddress$destinationIndicator$preferredDeliveryMethod$telexNumber$teletexTerminalIdentifier$telephoneNumber$internationalISDNNumber$facsimileTelephoneNumber$通りの$postOfficeBox$postalCode$postalAddress$physicalDeliveryOfficeName$ou$、第$l)
3.10. 'organizationalRole'
3.10. 'organizationalRole'
The 'organizationalRole' object class is the basis of an entry that represents a job, function, or position in an organization. (Source: X.521 [X.521])
'organizationalRole'オブジェクトのクラスは組織で仕事、機能、または位置を表すエントリーの基礎です。 (ソース: X.521[X.521])
( 2.5.6.8 NAME 'organizationalRole'
SUP top
STRUCTURAL
MUST cn
MAY ( x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $
teletexTerminalIdentifier $ telephoneNumber $
internationalISDNNumber $ facsimileTelephoneNumber $
seeAlso $ roleOccupant $ preferredDeliveryMethod $
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ ou $ st $ l $
description ) )
(2.5に、.6.8NAME'organizationalRole'SUPがSTRUCTURAL MUST cn5月を付ける、(x121Address$registeredAddress$destinationIndicator$preferredDeliveryMethod$telexNumber$teletexTerminalIdentifier$telephoneNumber$internationalISDNNumber$facsimileTelephoneNumber$seeAlso$roleOccupant$preferredDeliveryMethod$通りの$postOfficeBox$postalCode$postalAddress$physicalDeliveryOfficeName$ou$、第$l$記述)
3.11. 'organizationalUnit'
3.11. 'organizationalUnit'
The 'organizationalUnit' object class is the basis of an entry that represents a piece of an organization. (Source: X.521 [X.521])
'organizationalUnit'オブジェクトのクラスは組織の1つの断片を表すエントリーの基礎です。 (ソース: X.521[X.521])
Sciberras Standards Track [Page 24] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[24ページ]: ユーザアプリケーション2006年6月のための図式
( 2.5.6.5 NAME 'organizationalUnit'
SUP top
STRUCTURAL
MUST ou
MAY ( businessCategory $ description $ destinationIndicator $
facsimileTelephoneNumber $ internationalISDNNumber $ l $
physicalDeliveryOfficeName $ postalAddress $ postalCode $
postOfficeBox $ preferredDeliveryMethod $
registeredAddress $ searchGuide $ seeAlso $ st $ street $
telephoneNumber $ teletexTerminalIdentifier $
telexNumber $ userPassword $ x121Address ) )
(2.5に、.6.5NAME'organizationalUnit'SUPがSTRUCTURAL MUST ou5月を付ける、(businessCategory$記述$destinationIndicator$facsimileTelephoneNumber$internationalISDNNumber$l$physicalDeliveryOfficeName$postalAddress$postalCode$postOfficeBox$preferredDeliveryMethod$registeredAddress$searchGuide$seeAlso$、第$通りの$telephoneNumber$teletexTerminalIdentifier$telexNumber$userPassword$x121Address)
3.12 'person'
3.12 '人'
The 'person' object class is the basis of an entry that represents a human being. (Source: X.521 [X.521])
'人'オブジェクトのクラスは人間の代理をするエントリーの基礎です。 (ソース: X.521[X.521])
( 2.5.6.6 NAME 'person'
SUP top
STRUCTURAL
MUST ( sn $
cn )
MAY ( userPassword $
telephoneNumber $
seeAlso $ description ) )
(2.5の.6.6NAME'人'SUP最高なSTRUCTURAL MUST(sn$cn)5月(userPassword$telephoneNumber$seeAlso$記述))
3.13. 'residentialPerson'
3.13. 'residentialPerson'
The 'residentialPerson' object class is the basis of an entry that includes a person's residence in the representation of the person. (Source: X.521 [X.521])
'residentialPerson'オブジェクトのクラスは人の表現に人の住居を含んでいるエントリーの基礎です。 (ソース: X.521[X.521])
( 2.5.6.10 NAME 'residentialPerson'
SUP person
STRUCTURAL
MUST l
MAY ( businessCategory $ x121Address $ registeredAddress $
destinationIndicator $ preferredDeliveryMethod $
telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationalISDNNumber $
facsimileTelephoneNumber $ preferredDeliveryMethod $
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ st $ l ) )
(2.5が.6.10NAME'residentialPerson'SUP人のSTRUCTURAL MUST lそうするかもしれない、(businessCategory$x121Address$registeredAddress$destinationIndicator$preferredDeliveryMethod$telexNumber$teletexTerminalIdentifier$telephoneNumber$internationalISDNNumber$facsimileTelephoneNumber$preferredDeliveryMethod$通りの$postOfficeBox$postalCode$postalAddress$physicalDeliveryOfficeName$、第$l)
Sciberras Standards Track [Page 25] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[25ページ]: ユーザアプリケーション2006年6月のための図式
3.14. 'uidObject'
3.14. 'uidObject'
The 'uidObject' object class permits an entry to contains user identification information. This object class is defined as auxiliary, because it will be used in conjunction with an existing structural object class. (Source: RFC 2377 [RFC2377])
クラスがエントリーを可能にする'uidObject'オブジェクトはユーザ登録名情報を含んでいます。 それが既存の構造的なオブジェクトのクラスに関連して使用されるので、このオブジェクトのクラスは同じくらい補助していた状態で定義されます。 (ソース: RFC2377[RFC2377])
( 1.3.6.1.1.3.1 NAME 'uidObject'
SUP top
AUXILIARY
MUST uid )
(1.3.6.1.1.3.1NAME'uidObject'SUP先端AUXILIARY MUST uid)
4. IANA Considerations
4. IANA問題
The Internet Assigned Numbers Authority (IANA) has updated the LDAP descriptors registry as indicated in the following template:
インターネットAssigned民数記Authority(IANA)は以下のテンプレートにみられるようにLDAP記述子登録をアップデートしました:
Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comments
Object Identifier: see comments
Person & email address to contact for further information:
Andrew Sciberras <andrew.sciberras@eb2bcom.com>
Usage: (A = attribute type, O = Object Class) see comment
Specification: RFC 4519
Author/Change Controller: IESG
Subject: LDAP Descriptor Registration Update Descriptor(省略名)のために以下を要求してください。 Object Identifierが論評するのを確実にしてください: 詳細のために連絡するコメントPersonとEメールアドレスを見てください: アンドリュー Sciberras <andrew.sciberras@eb2bcom.com 、gt;、用法: (=属性タイプ、オブジェクトO=Class) コメントSpecificationを見てください: RFC4519作者/変化コントローラ: IESG
Comments
コメント
In the LDAP descriptors registry, the following descriptors (short
names) have been updated to refer to RFC 4519. Names that need to
be reserved, rather than assigned to an Object Identifier, will
contain an Object Identifier value of RESERVED.
LDAP記述子登録では、RFC4519について言及するために、以下の記述子(省略名)をアップデートしました。 Object Identifierに割り当てられるよりむしろ予約される必要がある名前がRESERVEDのObject Identifier値を含むでしょう。
NAME Type OID
------------------------ ---- ----------------------------
applicationProcess O 2.5.6.11
businessCategory A 2.5.4.15
c A 2.5.4.6
cn A 2.5.4.3
commonName A 2.5.4.3
country O 2.5.6.2
countryName A 2.5.4.6
dc A 0.9.2342.19200300.100.1.25
dcObject O 1.3.6.1.4.1.1466.344
description A 2.5.4.13
destinationIndicator A 2.5.4.27
device O 2.5.6.14
名前タイプOID------------------------ ---- ---------------------------- applicationProcess O2.5.6.11businessCategory A2.5.4.15c A2.5.4.6cn、A2.5.4.3commonName A2.5.4.3国のO2.5.6.2countryName A2.5.4.6dc A0.9.2342.19200300.100.1.25dcObject O1.3.6.1.4.1.1466.344記述A2.5.4.13destinationIndicator A、2.5.4.27デバイスO2.5.6.14
Sciberras Standards Track [Page 26] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[26ページ]: ユーザアプリケーション2006年6月のための図式
NAME Type OID
------------------------ ---- ----------------------------
distinguishedName A 2.5.4.49
dnQualifier A 2.5.4.46
domainComponent A 0.9.2342.19200300.100.1.25
enhancedSearchGuide A 2.5.4.47
facsimileTelephoneNumber A 2.5.4.23
generationQualifier A 2.5.4.44
givenName A 2.5.4.42
gn A RESERVED
groupOfNames O 2.5.6.9
groupOfUniqueNames O 2.5.6.17
houseIdentifier A 2.5.4.51
initials A 2.5.4.43
internationalISDNNumber A 2.5.4.25
l A 2.5.4.7
locality O 2.5.6.3
localityName A 2.5.4.7
member A 2.5.4.31
name A 2.5.4.41
o A 2.5.4.10
organization O 2.5.6.4
organizationName A 2.5.4.10
organizationalPerson O 2.5.6.7
organizationalRole O 2.5.6.8
organizationalUnit O 2.5.6.5
organizationalUnitName A 2.5.4.11
ou A 2.5.4.11
owner A 2.5.4.32
person O 2.5.6.6
physicalDeliveryOfficeName A 2.5.4.19
postalAddress A 2.5.4.16
postalCode A 2.5.4.17
postOfficeBox A 2.5.4.18
preferredDeliveryMethod A 2.5.4.28
registeredAddress A 2.5.4.26
residentialPerson O 2.5.6.10
roleOccupant A 2.5.4.33
searchGuide A 2.5.4.14
seeAlso A 2.5.4.34
serialNumber A 2.5.4.5
sn A 2.5.4.4
st A 2.5.4.8
street A 2.5.4.9
surname A 2.5.4.4
telephoneNumber A 2.5.4.20
teletexTerminalIdentifier A 2.5.4.22
telexNumber A 2.5.4.21
名前タイプOID------------------------ ---- ---------------------------- distinguishedName A2.5.4.49dnQualifier A2.5.4.46domainComponent A0.9.2342.19200300、.100、.1、2.5.4.44givenName A2.5.4.42gn A RESERVED groupOfNames O2.5.6.25enhancedSearchGuide A2.5.4.47facsimileTelephoneNumber A2.5.4.23generationQualifier A.9groupOfUniqueNames O、2.5.6.17houseIdentifier A2.5.4.51のイニシャルA2.5.4.43internationalISDNNumber A2.5.4.25l A2.5.4.7場所O2.5.6.3、localityName A2.5.4.7メンバーA2.5.4.31名前A2.5.4.41o A2.5.4.10組織O2.5.6.4organizationName A2.5; 4.10organizationalPerson O2.5.6.7、organizationalRole O2.5.6.8organizationalUnit O2.5.6.5organizationalUnitName A2.5.4.11ou A2.5.4.11所有者A2.5.4.32人O2.5.6、.6physicalDeliveryOfficeName A2.5.4.19postalAddress A2.5.4.16postalCode A、2.5.4.17postOfficeBox A2.5.4.18preferredDeliveryMethod A2.5.4.28registeredAddress A2.5.4.26residentialPerson O2.5.6.10roleOccupant A2.5.4.33、searchGuide A2.5.4.14seeAlso A2.5.4.34serialNumber A2.5.4.5sn A2.5.4第.4A2.5.4.8通りAの2.5.4.9 surname A2.5.4.4telephoneNumber A2.5.4.20teletexTerminalIdentifier A2.5.4.22telexNumber A2.5.4.21
Sciberras Standards Track [Page 27] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[27ページ]: ユーザアプリケーション2006年6月のための図式
NAME Type OID
------------------------ ---- ----------------------------
title A 2.5.4.12
uid A 0.9.2342.19200300.100.1.1
uidObject O 1.3.6.1.1.3.1
uniqueMember A 2.5.4.50
userid A 0.9.2342.19200300.100.1.1
userPassword A 2.5.4.35
x121Address A 2.5.4.24
x500UniqueIdentifier A 2.5.4.45
名前タイプOID------------------------ ---- ---------------------------- タイトルA2.5.4.12uid A0.9.2342.19200300.100.1.1uidObject O1.3.6.1.1.3.1uniqueMember A2.5.4.50ユーザID A0.9.2342.19200300.100.1.1userPassword A2.5.4.35x121Address A2.5.4.24x500UniqueIdentifier A2.5.4.45
5. Security Considerations
5. セキュリティ問題
Attributes of directory entries are used to provide descriptive information about the real-world objects they represent, which can be people, organizations, or devices. Most countries have privacy laws regarding the publication of information about people.
ディレクトリエントリーの属性は、彼らが表す人々、組織、またはデバイスであるかもしれない本当の世界オブジェクトの描写的である情報を提供するのに使用されます。 ほとんどの国には、人々の情報の公表に関するプライバシー法があります。
Transfer of cleartext passwords is strongly discouraged where the underlying transport service cannot guarantee confidentiality and integrity, since this may result in disclosure of the password to unauthorized parties.
cleartextパスワードの転送は基本的な輸送サービスが秘密性と保全を保証できないところで強くお勧めできないです、これが権限のないパーティーへのパスワードの公開をもたらすかもしれないので。
Multiple attribute values for the 'userPassword' attribute need to be used with care. Especially reset/deletion of a password by an administrator without knowing the old user password gets tricky or impossible if multiple values for different applications are present.
'userPassword'属性のための複数の属性値が、慎重に使用される必要があります。 異なったアプリケーションのための複数の値が存在しているなら、古いユーザパスワードを知っていることのない管理者による特にパスワードのリセット/削除は油断のならないか不可能になります。
Certainly, applications that intend to replace the 'userPassword' value(s) with new value(s) should use modify/replaceValues (or modify/deleteAttribute+addAttribute). In addition, server implementations are encouraged to provide administrative controls that, if enabled, restrict the 'userPassword' attribute to one value.
確かに、'userPassword'値を(s)が使用するべきである新しい値に取り替えるつもりであるアプリケーションが/replaceValuesを変更します(/deleteAttribute+addAttributeを変更してください)。 さらに、サーバ実装が可能にされるなら'userPassword'属性を1つの値に制限する運営管理コントロールを提供するよう奨励されます。
Note that when used for authentication purposes [RFC4513], the user need only prove knowledge of one of the values, not all of the values.
認証目的[RFC4513]に使用されると、ユーザが値のすべてではなく、値の1つに関する知識を立証するだけでよいことに注意してください。
6. Acknowledgements
6. 承認
The definitions, on which this document is based, have been developed by committees for telecommunications and international standards.
定義(このドキュメントは基づいている)はテレコミュニケーションと世界規格のために委員会によって開発されました。
This document is an update of RFC 2256 by Mark Wahl. RFC 2256 was a product of the IETF ASID Working Group.
このドキュメントはマーク・ウォールによるRFC2256の最新版です。 RFC2256はIETF ASID作業部会の製品でした。
Sciberras Standards Track [Page 28] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[28ページ]: ユーザアプリケーション2006年6月のための図式
The 'dc' attribute type definition and the 'dcObject' object class definition in this document supersede the specification in RFC 2247 by S. Kille, M. Wahl, A. Grimstad, R. Huber, and S. Sataluri.
'dc'属性型定義と'dcObject'オブジェクトクラス定義はS.Kille、M.ウォール、A.グリムスター、R.ヒューバー、およびS.Sataluriで本書ではRFC2247の仕様に取って代わります。
The 'uid' attribute type definition in this document supersedes the specification of the 'userid' in RFC 1274 by P. Barker and S. Kille and of the uid in RFC 2798 by M. Smith.
'uid'属性型定義はRFC2798でM.スミスで本書ではP.バーカーとS.KilleによるRFC1274の'ユーザID'とuidの仕様に取って代わります。
The 'uidObject' object class definition in this document supersedes the specification of the 'uidObject' in RFC 2377 by A. Grimstad, R. Huber, S. Sataluri, and M. Wahl.
'uidObject'オブジェクトクラス定義はRFC2377でA.グリムスター、R.ヒューバー、S.Sataluri、およびM.ウォールで本書では'uidObject'の仕様に取って代わります。
This document is based upon input of the IETF LDAPBIS working group. The author wishes to thank S. Legg and K. Zeilenga for their significant contribution to this update. The author would also like to thank Kathy Dally, who edited early versions of this document.
このドキュメントはIETF LDAPBISワーキンググループの入力に基づいています。 作者はこのアップデートへの彼らの重要な貢献についてS.LeggとK.Zeilengaに感謝したがっています。 また、作者はキャシー・ダリーに感謝したがっています。(彼はこのドキュメントの早めのバージョンを編集しました)。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[E.123] Notation for national and international telephone numbers,
ITU-T Recommendation E.123, 1988
国家的、そして、国際的な電話番号のための[E.123]記法、ITU-T Recommendation E.123、1988
[E.164] The international public telecommunication numbering plan,
ITU-T Recommendation E.164, 1997
[E.164] 国際的な公共の電気通信付番プラン、ITU-T Recommendation E.164、1997
[F.1] Operational Provisions For The International Public
Telegram Service Transmission System, CCITT Recommendation
F.1, 1992
国際公共の電報サービス伝動装置、CCITT推薦F.1、1992年の[F.1]操作上の条項
[F.31] Telegram Retransmission System, CCITT Recommendation F.31,
1988
[F.31]電報Retransmissionシステム、CCITT推薦F.31、1988
[ISO3166] ISO 3166, "Codes for the representation of names of
countries".
[ISO3166]ISO3166、「国の名前の表現のためのコード。」
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2181] ElzとR.とR.ブッシュ、「DNS仕様への明確化」、RFC2181、1997年7月。
Sciberras Standards Track [Page 29] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[29ページ]: ユーザアプリケーション2006年6月のための図式
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、「アプリケーション(IDNA)におけるドメイン名を国際的にします」、RFC3490、2003年3月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
and Passwords", RFC 4013, February 2005.
[RFC4013]Zeilenga、K.、「SASLprep:」 「ユーザ名とパスワードのためのStringprepプロフィール」、RFC4013、2005年2月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, June
2006.
[RFC4510] Zeilenga、K.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「仕様書ロードマップ」、RFC4510、2006年6月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, June
2006.
[RFC4512] Zeilenga、K.、「軽量のディレクトリアクセスは以下について議定書の中で述べ(LDAP)」。 「ディレクトリ情報モデル」、RFC4512、2006年6月。
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
(LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4517] Legg、S.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「構文とマッチングは統治する」RFC4517、2006年6月。
[X.121] International numbering plan for public data networks,
ITU-T Recommendation X.121, 1996
公衆データネットワーク、ITU-T Recommendation X.121、1996年の[X.121]国際付番プラン
[X.509] The Directory: Authentication Framework, ITU-T
Recommendation X.509, 1993
[X.509] ディレクトリ: 認証フレームワーク、ITU-T推薦X.509、1993
[X.520] The Directory: Selected Attribute Types, ITU-T
Recommendation X.520, 1993
[X.520] ディレクトリ: 選択された属性タイプ、ITU-T推薦X.520、1993
[X.521] The Directory: Selected Object Classes. ITU-T
Recommendation X.521, 1993
[X.521] ディレクトリ: 選択されたオブジェクトは属します。 ITU-T推薦X.521、1993
7.2. Informative References
7.2. 有益な参照
[RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500
Schema", RFC 1274, November 1991.
[RFC1274] バーカー、P.、S.Kille、および「コサインとインターネットX.500図式」、RFC1274、11月1991日
[RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.
Sataluri, "Using Domains in LDAP/X.500 Distinguished
Names", RFC 2247, January 1998.
[RFC2247] Kille、S.、ウォール、M.、グリムスター、A.、ヒューバー、R.、およびS.Sataluri、「LDAP/X.500分類名にドメインを使用します」、RFC2247(1998年1月)。
[RFC2377] Grimstad, A., Huber, R., Sataluri, S., and M. Wahl,
"Naming Plan for Internet Directory-Enabled Applications",
RFC 2377, September 1998.
[RFC2377] グリムスター、A.、ヒューバー、R.、Sataluri、S.、およびM.ウォール、「命名はインターネットのディレクトリで可能にされたアプリケーションの計画を立てる」RFC2377、1998年9月。
[RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object
Class", RFC 2798, April 2000.
[RFC2798] スミス、M.、「inetOrgPerson LDAPオブジェクトのクラスの定義」、RFC2798、2000年4月。
Sciberras Standards Track [Page 30] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[30ページ]: ユーザアプリケーション2006年6月のための図式
[RFC4513] Harrison R., Ed., "Lightweight Directory Access Protocol
(LDAP): Authentication Methods and Security Mechanisms",
RFC 4513, June 2006.
[RFC4513] ハリソンR.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「認証方法とセキュリティー対策」、RFC4513、6月2006日
[RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP) Schema Definitions for X.509 Certificates", RFC
4523, June 2006.
[RFC4523]Zeilenga、K.、「X.509証明書のためのライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)図式定義」、RFC4523、2006年6月。
[RFC4524] Zeilenga, E., Ed., "COSINE LDAP/X.500 Schema", RFC 4524,
June 2006.
[RFC4524] Zeilenga、E.、エド、「コサインLDAP/X.500図式」、RFC4524、6月2006日
[X.500] ITU-T Recommendations X.500 (1993) | ISO/IEC 9594-1:1994,
Information Technology - Open Systems Interconnection -
The Directory: Overview of concepts, models and services.
[X.500]ITU-T推薦X.500(1993)| 情報技術--オープン・システム・インターコネクション--ISO/IEC9594-1:1994、ディレクトリ: 概念の、そして、モデルの、そして、サービスの概要。
Sciberras Standards Track [Page 31] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[31ページ]: ユーザアプリケーション2006年6月のための図式
Appendix A. Changes Made Since RFC 2256
付録A.変化は以来、RFCを2256にしました。
This appendix lists the changes that have been made from RFC 2256 to RFC 4519.
この付録はRFC2256からRFC4519まで行われた変更を記載します。
This appendix is not a normative part of this specification, which has been provided for informational purposes only.
この付録はこの仕様の標準の部分ではありません。(それは、情報の目的だけに提供されました)。
1. Replaced the document title.
1. ドキュメントタイトルを置き換えました。
2. Removed the IESG Note.
2. IESG注意を取り除きました。
3. Dependencies on RFC 1274 have been eliminated.
3. RFC1274における依存は根絶されました。
4. Added a Security Considerations section and an IANA
Considerations section.
4. Security Considerations部とIANA Considerations部を加えました。
5. Deleted the conformance requirement for subschema object
classes in favor of a statement in [RFC4517].
5. [RFC4517]での声明を支持してサブスキーマオブジェクトのクラスのための順応要件を削除しました。
6. Added explanation to attribute types and to each object class.
6. 属性タイプと、そして、それぞれのオブジェクトのクラスに説明を追加しました。
7. Removed Section 4, Syntaxes, and Section 6, Matching Rules,
(moved to [RFC4517]).
7. 取り除かれたセクション4、構文、およびセクション6 規則を合わせて、([RFC4517]に動く。)です。
8. Removed the certificate-related attribute types:
authorityRevocationList, cACertificate,
certificateRevocationList, crossCertificatePair,
deltaRevocationList, supportedAlgorithms, and userCertificate.
8. 証明書関連の属性タイプを外します: authorityRevocationList、cACertificate、certificateRevocationList、crossCertificatePair、deltaRevocationList、supportedAlgorithms、およびuserCertificate。
Removed the certificate-related Object Classes:
certificationAuthority, certificationAuthority-V2,
cRLDistributionPoint, strongAuthenticationUser, and
userSecurityInformation
証明書関連のObject Classesを取り外します: certificationAuthority、certificationAuthority-V2、cRLDistributionPoint、strongAuthenticationUser、およびuserSecurityInformation
LDAP PKI is now discussed in [RFC4523].
現在、[RFC4523]でLDAP PKIについて議論します。
9. Removed the dmdName, knowledgeInformation,
presentationAddress, protocolInformation, and
supportedApplicationContext attribute types and the dmd,
applicationEntity, and dSA object classes.
9. dmdName、knowledgeInformation、presentationAddress、protocolInformation、supportedApplicationContext属性タイプ、dmd、applicationEntity、およびdSAオブジェクトのクラスを取り外しました。
10. Deleted the aliasedObjectName and objectClass attribute type
definitions. Deleted the alias and top object class
definitions. They are included in [RFC4512].
10. aliasedObjectNameとobjectClass属性型定義を削除しました。 別名と最高オブジェクトクラス定義を削除しました。 それらは[RFC4512]に含まれています。
Sciberras Standards Track [Page 32] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[32ページ]: ユーザアプリケーション2006年6月のための図式
11. Added the 'dc' attribute type from RFC 2247, making the
distinction between 'stored' and 'query' values when preparing
IDN strings.
11. IDNにストリングを準備するとき、'保存'と'質問'値の間で区別をして、RFC2247から'dc'属性タイプを加えました。
12. Numerous editorial changes.
12. 多数の社説は変化します。
13. Removed upper bound after the SYNTAX oid in all attribute
definitions where it appeared.
13. すべてのSYNTAX oidが現れたところで定義を結果と考えた後に上限を取り除きました。
14. Added text about Unicode, SASLprep [RFC4013], and UTF-8 for
userPassword.
14. userPasswordのためにユニコードに関するテキスト、SASLprep[RFC4013]、およびUTF-8を加えました。
15. Included definitions, comments and references for 'dcObject'
and 'uidObject'.
15. 'dcObject'と'uidObject'の含まれている定義、コメント、および参照。
16. Replaced PKI schema references to use RFC 4523.
16. RFC4523を使用するためにPKI図式参照を置き換えました。
17. Spelt out and referenced ABNF on first usage.
17. 最初に、用法でABNFに詳しく説明して、参照をつけました。
18. Removed Section 2.4 (Source). Replaced the source table with
explicit references for each definition.
18. 取り除かれたセクション2.4 (ソース。) ソーステーブルをそれぞれの定義の明白な参照に取り替えました。
19. All references to an attribute type or object class are
enclosed in single quotes.
19. 属性タイプかオブジェクトのクラスについてのすべての言及がシングル・クォーテション・マークに同封されます。
20. The layout of attribute type definitions has been changed to
provide consistency throughout the document:
> Section Heading
> Description of Attribute type
> Multivalued description
> Source Information
> Definition
> Example
> Additional Comments
20. 一貫性をドキュメントに供給するために属性型定義のレイアウトを変えました: Attributeタイプ>Multivalued記述>Source情報>Definition>Example>Additional Commentsの>セクションHeading>記述
Adding this consistent output included the addition of
examples to some definitions.
この一貫した出力を加えると、例の追加はいくつかの定義に含められました。
21. References to alternate names for attributes types are
provided with a reference to where they were originally
specified.
21. 彼らが元々指定されたところの参照を別名称の属性タイプの参照に提供します。
22. Clarification of the description of 'distinguishedName' and
'name', in regards to these attribute types being supertypes.
22. 'distinguishedName'の記述の明確化と「スーパー-タイプ」であるこれらの属性タイプに関する'名前'。
23. Spelt out ISDN on first usage.
23. 最初に、用法にISDNについて詳しく説明しました。
Sciberras Standards Track [Page 33] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[33ページ]: ユーザアプリケーション2006年6月のための図式
24. Inserted a reference to [RFC4517] for the
'teletexTerminalIdentifier' definition's SYNTAX OID.
24. [RFC4517]の'teletexTerminalIdentifier'定義のSYNTAX OIDの参照を挿入しました。
25. Additional names were added to the IANA Considerations. Names
include 'commonName', 'dcObject', 'domainComponent', 'GN',
'localityName', 'organizationName', 'organizationUnitName',
'surname', 'uidObject' and 'userid'.
25. 追加名前はIANA Considerationsに加えられました。 名前は'commonName'、'dcObject'、'domainComponent'、'GN'、'localityName'、'organizationName'、'organizationUnitName'、'姓'、'uidObject'、および'ユーザID'を含んでいます。
26. Renamed all instances of supercede to supersede.
26. 取って代わるsupercedeのすべてのインスタンスに改名されます。
27. Moved [F.1], [F.31] and [RFC4013] from informative to
normative references.
27. 有益であるのから引用規格まで[F.1]、[F.31]、および[RFC4013]を動かしました。
28. Changed the 'c' definition to be consistent with X.500.
28. X.500と一致しているように'c'定義を変えました。
Author's Address
作者のアドレス
Andrew Sciberras eB2Bcom Suite 3, Woodhouse Corporate Centre, 935 Station Street, Box Hill North, Victoria 3129 AUSTRALIA
アンドリューSciberras eB2Bcom Suite3、ウッドハウスCorporateのセンター、935Station通り、北のBoxヒル、ビクトリア・3129オーストラリア
Phone: +61 3 9896 7833 EMail: andrew.sciberras@eb2bcom.com
以下に電話をしてください。 +61 3 9896 7833はメールされます: andrew.sciberras@eb2bcom.com
Sciberras Standards Track [Page 34] RFC 4519 LDAP: Schema for User Applications June 2006
Sciberras規格はRFC4519LDAPを追跡します[34ページ]: ユーザアプリケーション2006年6月のための図式
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Sciberras Standards Track [Page 35]
Sciberras標準化過程[35ページ]
一覧
スポンサーリンク
