From: Kurt Zeilenga Date: Wed, 14 Jun 2006 22:53:46 +0000 (+0000) Subject: Use private name space X-Git-Tag: OPENLDAP_REL_ENG_2_4_3ALPHA~9^2~105 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=d6ac2453a4e9dbd4434d33347d1cd184a978a8db;p=openldap Use private name space Reference RFC 4520 --- diff --git a/doc/guide/admin/schema.sdf b/doc/guide/admin/schema.sdf index 93f8712a08..6a14fb3e7e 100644 --- a/doc/guide/admin/schema.sdf +++ b/doc/guide/admin/schema.sdf @@ -96,9 +96,9 @@ OID Assignment 1.1.1 SNMP Elements 1.1.2 LDAP Elements 1.1.2.1 AttributeTypes -1.1.2.1.1 myAttribute +1.1.2.1.1 x-my-Attribute 1.1.2.2 ObjectClasses -1.1.2.2.1 myObjectClass +1.1.2.2.1 x-my-ObjectClass !endblock You are, of course, free to design a hierarchy suitable to your @@ -130,25 +130,27 @@ Alternatively, OID name space may be available from a national authority (e.g., {{ORG:ANSI}}, {{ORG:BSI}}). -H3: Name Prefix +H3: Naming Elements In addition to assigning a unique object identifier to each schema element, you should provide a least one textual name for each -element. The name should be both descriptive and not likely to -clash with names of other schema elements. In particular, any name -you choose should not clash with present or future Standard Track -names. +element. Names should be registered with the {{ORG:IANA}} or +prefixed with "x-" to place in the "private use" name space. -To reduce (but not eliminate) the potential for name clashes, the -convention is to prefix names of non-Standard Track with a few -letters to localize the changes to your organization. The smaller -the organization, the longer your prefix should be. +The name should be both descriptive and not likely to clash with +names of other schema elements. In particular, any name you choose +should not clash with present or future Standard Track names (this +is assured if you registered names or use names begining with "x-"). -In the examples below, we have chosen a short prefix '{{EX:my}}' -(to save space). Such a short prefix would only be suitable for a -very large, global organization. In general, we recommend something -like '{{EX:deFirm}}' (German company) or '{{EX:comExample}}' (elements -associated with organization associated with {{EX:example.com}}). +It is noted that you can obtain your own registered name +prefix so as to avoid having to register your names individually. +See {{REF:RFC4520}} for details. + +In the examples below, we have used a short prefix '{{EX:x-my-}}'. +Such a short prefix would only be suitable for a very large, global +organization. In general, we recommend something like '{{EX:x-de-Firm-}}' +(German company) or '{{EX:x-com-Example}}' (elements associated with +organization associated with {{EX:example.com}}). H3: Local schema file @@ -283,7 +285,7 @@ for usage by user applications. Neither is obsolete nor collective. The following subsections provide a couple of examples. -H4: myUniqueName +H4: x-my-UniqueName Many organizations maintain a single unique name for each user. Though one could use {{EX:displayName}} ({{REF:RFC2798}}), this @@ -292,7 +294,7 @@ organization. We could just copy the definition of {{EX:displayName}} from {{F:inetorgperson.schema}} and replace the OID, name, and description, e.g: -> attributetype ( 1.1.2.1.1 NAME 'myUniqueName' +> attributetype ( 1.1.2.1.1 NAME 'x-my-UniqueName' > DESC 'unique name with my organization' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch @@ -303,22 +305,22 @@ However, if we want this name to be included in {{EX:name}} assertions [e.g. {{EX:(name=*Jane*)}}], the attribute could alternatively be defined as a subtype of {{EX:name}}, e.g.: -> attributetype ( 1.1.2.1.1 NAME 'myUniqueName' +> attributetype ( 1.1.2.1.1 NAME 'x-my-UniqueName' > DESC 'unique name with my organization' > SUP name ) -H4: myPhoto +H4: x-my-Photo Many organizations maintain a photo of each each user. A -{{EX:myPhoto}} attribute type could be defined to hold a photo. +{{EX:x-my-Photo}} attribute type could be defined to hold a photo. Of course, one could use just use {{EX:jpegPhoto}} ({{REF:RFC2798}}) (or a subtype) to hold the photo. However, you can only do this if the photo is in {{JPEG File Interchange Format}}. Alternatively, an attribute type which uses the {{Octet String}} syntax can be defined, e.g.: -> attributetype ( 1.1.2.1.2 NAME 'myPhoto' +> attributetype ( 1.1.2.1.2 NAME 'x-my-Photo' > DESC 'a photo (application defined format)' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 > SINGLE-VALUE ) @@ -337,7 +339,7 @@ pointing to the photo. You can model such an attribute after {{EX:labeledURI}} ({{REF:RFC2079}}) or simply create a subtype, e.g.: -> attributetype ( 1.1.2.1.3 NAME 'myPhotoURI' +> attributetype ( 1.1.2.1.3 NAME 'x-my-PhotoURI' > DESC 'URI and optional label referring to a photo' > SUP labeledURI ) @@ -371,18 +373,18 @@ OID in numeric form (e.g. {{EX:1.1.0}}), qdescrs is one or more names, and oids is one or more names and/or OIDs. -H4: myPhotoObject +H4: x-my-PhotoObject To define an {{auxiliary}} object class which allows -myPhoto to be added to any existing entry. +x-my-Photo to be added to any existing entry. -> objectclass ( 1.1.2.2.1 NAME 'myPhotoObject' -> DESC 'mixin myPhoto' +> objectclass ( 1.1.2.2.1 NAME 'x-my-PhotoObject' +> DESC 'mixin x-my-Photo' > AUXILIARY -> MAY myPhoto ) +> MAY x-my-Photo ) -H4: myPerson +H4: x-my-Person If your organization would like have a private {{structural}} object class to instantiate users, you can subclass one of @@ -390,15 +392,15 @@ the existing person classes, such as {{EX:inetOrgPerson}} ({{REF:RFC2798}}), and add any additional attributes which you desire. -> objectclass ( 1.1.2.2.2 NAME 'myPerson' +> objectclass ( 1.1.2.2.2 NAME 'x-my-Person' > DESC 'my person' > SUP inetOrgPerson -> MUST ( myUniqueName $ givenName ) -> MAY myPhoto ) +> MUST ( x-my-UniqueName $ givenName ) +> MAY x-my-Photo ) The object class inherits the required/allowed attribute -types of {{EX:inetOrgPerson}} but requires {{EX:myUniqueName}} -and {{EX:givenName}} and allows {{EX:myPhoto}}. +types of {{EX:inetOrgPerson}} but requires {{EX:x-my-UniqueName}} +and {{EX:givenName}} and allows {{EX:x-my-Photo}}. !if 0 H2: Transferring Schema @@ -430,12 +432,12 @@ This will return {{TERM:LDIF}} output containing many type/value pairs. The following is an abbreviated example: > dn: cn=Subschema -> objectClasses: ( 1.1.2.2.2 NAME 'myPerson' DESC 'my person' SUP inet -> OrgPerson MUST ( myUniqueName $ givenName ) MAY myPhoto ) -> attributeTypes: ( 1.1.2.1.1 NAME 'myUniqueName' DESC 'unique name wi -> th my organization' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubst -> ringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) -> attributeTypes: ( 1.1.2.1.2 NAME 'myPhoto' DESC 'a photo (applicatio +> objectClasses: ( 1.1.2.2.2 NAME 'x-my-Person' DESC 'my person' SUP inet +> OrgPerson MUST ( x-my-UniqueName $ givenName ) MAY x-my-Photo ) +> attributeTypes: ( 1.1.2.1.1 NAME 'x-my-UniqueName' DESC 'unique name wi +> th my organization' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstrin +> gsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) +> attributeTypes: ( 1.1.2.1.2 NAME 'x-my-Photo' DESC 'a photo (applicatio > n defined format)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 Capture the output of the search in a file and then edit the file: @@ -451,20 +453,20 @@ Capture the output of the search in a file and then edit the file: For the three type/value pairs in our example, the edit should result in a file with contains of: -> attributetype ( 1.1.2.1.1 NAME 'myUniqueName' +> attributetype ( 1.1.2.1.1 NAME 'x-my-UniqueName' > DESC 'unique name with my organization' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 > SINGLE-VALUE ) -> attributeType ( 1.1.2.1.2 NAME 'myPhoto' +> attributeType ( 1.1.2.1.2 NAME 'x-my-Photo' > DESC 'a photo (application defined format)' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 -> objectClass ( 1.1.2.2.2 NAME 'myPerson' +> objectClass ( 1.1.2.2.2 NAME 'x-my-Person' > DESC 'my person' > SUP inetOrgPerson -> MUST ( myUniqueName $ givenName ) -> MAY myPhoto ) +> MUST ( x-my-UniqueName $ givenName ) +> MAY x-my-Photo ) Save in an appropriately named file (e.g. {{F:local.schema}}). You may now include this file in your {{slapd.conf}}(5) file. @@ -489,11 +491,11 @@ and their use in defining schema elements: > objectIdentifier myLDAP myOID:2 > objectIdentifier myAttributeType myLDAP:1 > objectIdentifier myObjectClass myLDAP:2 -> attributetype ( myAttributeType:3 NAME 'myPhotoURI' +> attributetype ( myAttributeType:3 NAME 'x-my-PhotoURI' > DESC 'URI and optional label referring to a photo' > SUP labeledURI ) -> objectclass ( myObjectClass:1 NAME 'myPhotoObject' -> DESC 'mixin myPhoto' +> objectclass ( myObjectClass:1 NAME 'x-my-PhotoObject' +> DESC 'mixin x-my-Photo' > AUXILIARY -> MAY myPhoto ) +> MAY x-my-Photo ) diff --git a/doc/guide/preamble.sdf b/doc/guide/preamble.sdf index a623896e50..01d044cfe6 100644 --- a/doc/guide/preamble.sdf +++ b/doc/guide/preamble.sdf @@ -229,4 +229,5 @@ RFC4516|PS|Lightweight Directory Access Protocol (LDAP): Uniform Resource Locato RFC4517|PS|Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules|http://www.rfc-editor.org/rfc/rfc4517.txt RFC4518|PS|Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation|http://www.rfc-editor.org/rfc/rfc4518.txt RFC4519|PS|Lightweight Directory Access Protocol (LDAP): Schema for User Applications|http://www.rfc-editor.org/rfc/rfc4519.txt +RFC4520|BCP|IANA Considerations for LDAP|http://www.rfc-editor.org/rfc/rfc4520.txt !endblock