Full_Name: Michael Str�der Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.80.206) cosine.schema is still based on obsoleted RFC 1274. It should be updated to RFC 4524.
Updated schema file cosine-update.schema attached. Note that some schema descriptions were copied from old cosine.schema to preserve backward compability since RFC 4524 does not contain all schema descriptions e.g. needed for 'pilotPerson'. Note that 'pilotPerson' is used as superior class for 'OpenLDAPperson'. Also some aliases were added to NAME of attribute type descriptions. IPR notice: This patch file is derived from OpenLDAP Software and RFC 4524 and RFC 1274. All of the modifications to OpenLDAP Software represented in the attached file were developed by Michael Ströder <michael@stroeder.com>. I have not assigned rights and/or interest in this work to any party.
On Jun 1, 2009, at 4:30 AM, michael@stroeder.com wrote: > This is a multi-part message in MIME format. > --------------080004030402080700020504 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 8bit > > Updated schema file cosine-update.schema attached. I note that differs are generally preferred, even where the file is mostly changed. This helps ensure changes that others might make to the file you started with are not lost. > Note that some schema > descriptions were copied from old cosine.schema to preserve backward > compability since RFC 4524 does not contain all schema descriptions > e.g. > needed for 'pilotPerson'. Note that 'pilotPerson' is used as superior > class for 'OpenLDAPperson'. Also some aliases were added to NAME of > attribute type descriptions. > > IPR notice: > This patch file is derived from OpenLDAP Software and RFC 4524 and RFC > 1274. All of the modifications to OpenLDAP Software represented in the > attached file were developed by Michael Ströder > <michael@stroeder.com>. > I have not assigned rights and/or interest in this work to any party. While this notice of origin is fine, you did not include a rights statement. > > > --------------080004030402080700020504 > Content-Type: text/plain; > name="cosine-update.schema" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; > filename="cosine-update.schema" > > # RFC 4524: COSINE LDAP/X.500 Schema > # $OpenLDAP: pkg/ldap/servers/slapd/schema/cosine.schema,v 1.26 > 2009/01/21 23:40:40 kurt Exp $ > ## This work is part of OpenLDAP Software <http://www.openldap.org/>. > ## > ## Copyright 1998-2009 The OpenLDAP Foundation. > ## All rights reserved. > ## > ## Redistribution and use in source and binary forms, with or without > ## modification, are permitted only as authorized by the OpenLDAP > ## Public License. > ## > ## A copy of this license is available in the file LICENSE in the > ## top-level directory of the distribution or, alternatively, at > ## <http://www.OpenLDAP.org/license.html>. > # > # RFC 4524: COSINE LDAP/X.500 Schema > # This file is mainly based on the schema descriptions found in RFC > 4524. > # To preserve backwards compability with 'pilotPerson' schema some > attribute > # types and object classes not declared in RFC 4524 were copied from > # (obsoleted) RFC 1274 and some attribute type descriptions were > extended > # with aliases for NAME. > # > # Depends on core.schema > > # > -------------------------------------------------------------------------- > # 2. COSINE Attribute Types > # > -------------------------------------------------------------------------- > # > # This section details COSINE attribute types for use in LDAP. > # > > # > -------------------------------------------------------------------------- > # 2.1. associatedDomain > # > # The 'associatedDomain' attribute specifies DNS [RFC1034][RFC2181] > # host names [RFC1123] that are associated with an object. That > is, > # values of this attribute should conform to the following ABNF: > # > # domain = root / label *( DOT label ) > # root = SPACE > # label = LETDIG [ *61( LETDIG / HYPHEN ) LETDIG ] > # LETDIG = %x30-39 / %x41-5A / %x61-7A ; "0" - "9" / "A"-"Z" / > "a"-"z" > # SPACE = %x20 ; space (" ") > # HYPHEN = %x2D ; hyphen ("-") > # DOT = %x2E ; period (".") > # > # For example, the entry in the DIT with a DN <DC=example,DC=com> > might > # have an associated domain of "example.com". > # > # (OpenLDAP-specific: Declared in core.schema) > # attributetype ( 0.9.2342.19200300.100.1.37 > # NAME 'associatedDomain' > # EQUALITY caseIgnoreIA5Match > # SUBSTR caseIgnoreIA5SubstringsMatch > # SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > # > # The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the > # 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are > # described in [RFC4517]. > # > # Note that the directory will not ensure that values of this > attribute > # conform to the <domain> production provided above. It is the > # application's responsibility to ensure that domains it stores > in this > # attribute are appropriately represented. > # > # Also note that applications supporting Internationalized Domain > Names > # SHALL use the ToASCII method [RFC3490] to produce <label> > components > # of the <domain> production. > > # > -------------------------------------------------------------------------- > # 2.2. associatedName > # > # The 'associatedName' attribute specifies names of entries in the > # organizational DIT associated with a DNS domain [RFC1034] > [RFC2181]. > # > > attributetype ( 0.9.2342.19200300.100.1.38 > NAME 'associatedName' > EQUALITY distinguishedNameMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) > > # > # The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax > and the > # 'distinguishedNameMatch' rule are described in [RFC4517]. > # > > # > -------------------------------------------------------------------------- > # 2.3. buildingName > # > # The 'buildingName' attribute specifies names of the buildings > where > # an organization or organizational unit is based, for example, > "The > # White House". > # > > attributetype ( 0.9.2342.19200300.100.1.48 > NAME 'buildingName' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are > described > # in [RFC4517]. > # > > # > -------------------------------------------------------------------------- > # 2.4. co > # > # The 'co' (Friendly Country Name) attribute specifies names of > # countries in human-readable format, for example, "Germany" and > # "Federal Republic of Germany". It is commonly used in > conjunction > # with the 'c' (Country Name) [RFC4519] attribute (whose values are > # restricted to the two-letter codes defined in [ISO3166]). > # > > attributetype ( 0.9.2342.19200300.100.1.43 > NAME 'co' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are > described > # in [RFC4517]. > # > > # > -------------------------------------------------------------------------- > # 2.5. documentAuthor > # > # The 'documentAuthor' attribute specifies the distinguished > names of > # authors (or editors) of a document. For example, > # > > attributetype ( 0.9.2342.19200300.100.1.14 > NAME 'documentAuthor' > EQUALITY distinguishedNameMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) > > # > # The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax > and the > # 'distinguishedNameMatch' rule are described in [RFC4517]. > # > > # > -------------------------------------------------------------------------- > # 2.6. documentIdentifier > # > # The 'documentIdentifier' attribute specifies unique identifiers > for a > # document. A document may be identified by more than one unique > # identifier. For example, RFC 3383 and BCP 64 are unique > identifiers > # that (presently) refer to the same document. > # > > attributetype ( 0.9.2342.19200300.100.1.11 > NAME 'documentIdentifier' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are > described > # in [RFC4517]. > # > > # > -------------------------------------------------------------------------- > # 2.7. documentLocation > # > # The 'documentLocation' attribute specifies locations of the > document > # original. > # > > attributetype ( 0.9.2342.19200300.100.1.15 > NAME 'documentLocation' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are > described > # in [RFC4517]. > # > > # > -------------------------------------------------------------------------- > # 2.8. documentPublisher > # > # The 'documentPublisher' attribute is the persons and/or > organizations > # that published the document. Documents that are jointly > published > # have one value for each publisher. > # > > attributetype ( 0.9.2342.19200300.100.1.56 > NAME 'documentPublisher' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are > described > # in [RFC4517]. > # > > # > -------------------------------------------------------------------------- > # 2.9. documentTitle > # > # The 'documentTitle' attribute specifies the titles of a document. > # Multiple values are allowed to accommodate both long and short > # titles, or other situations where a document has multiple > titles, for > # example, "The Lightweight Directory Access Protocol Technical > # Specification" and "The LDAP Technical Specification". > # > > attributetype ( 0.9.2342.19200300.100.1.12 > NAME 'documentTitle' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are > described > # in [RFC4517]. > # > > # > -------------------------------------------------------------------------- > # 2.10. documentVersion > # > # The 'documentVersion' attribute specifies the version > information of > # a document. > # > > attributetype ( 0.9.2342.19200300.100.1.13 > NAME 'documentVersion' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are > described > # in [RFC4517]. > # > > # > -------------------------------------------------------------------------- > # 2.11. drink > # > # The 'drink' (favouriteDrink) attribute specifies the favorite > drinks > # of an object (or person), for instance, "cola" and "beer". > # > > attributetype ( 0.9.2342.19200300.100.1.5 > NAME ( 'drink' 'favouriteDrink' ) > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are > described > # in [RFC4517]. > # > > # > -------------------------------------------------------------------------- > # 2.12. homePhone > # > # The 'homePhone' (Home Telephone Number) attribute specifies home > # telephone numbers (e.g., "+1 775 555 1234") associated with a > person. > # > > attributetype ( 0.9.2342.19200300.100.1.20 > NAME ( 'homePhone' 'homeTelephoneNumber' ) > EQUALITY telephoneNumberMatch > SUBSTR telephoneNumberSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) > > # > # The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and > the > # 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' > rules are > # described in [RFC4517]. > # > > # > -------------------------------------------------------------------------- > # 2.13. homePostalAddress > # > # The 'homePostalAddress' attribute specifies home postal > addresses for > # an object. Each value should be limited to up to 6 directory > strings > # of 30 characters each. (Note: It is not intended that the > directory > # service enforce these limits.) > # > > attributetype ( 0.9.2342.19200300.100.1.39 > NAME 'homePostalAddress' > EQUALITY caseIgnoreListMatch > SUBSTR caseIgnoreListSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) > > # > # The PostalAddress (1.3.6.1.4.1.1466.115.121.1.41) syntax and the > # 'caseIgnoreListMatch' and 'caseIgnoreListSubstringsMatch' rules > are > # described in [RFC4517]. > # > > # > -------------------------------------------------------------------------- > # 2.14. host > # > # The 'host' attribute specifies host computers, generally by their > # primary fully qualified domain name (e.g., my-host.example.com). > # > > attributetype ( 0.9.2342.19200300.100.1.9 > NAME 'host' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are > described > # in [RFC4517]. > # > > # > -------------------------------------------------------------------------- > # 2.15. info > # > # The 'info' attribute specifies any general information > pertinent to > # an object. This information is not necessarily descriptive of > the > # object. > # > # Applications should not attach specific semantics to values of > this > # attribute. The 'description' attribute [RFC4519] is available > for > # specifying descriptive information pertinent to an object. > # > > attributetype ( 0.9.2342.19200300.100.1.4 > NAME 'info' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are > described > # in [RFC4517]. > # > > # > -------------------------------------------------------------------------- > # 2.16. mail > # > # The 'mail' (rfc822mailbox) attribute type holds Internet mail > # addresses in Mailbox [RFC2821] form (e.g., user@example.com). > # > # (OpenLDAP-specific: Declared in core.schema) > # attributetype ( 0.9.2342.19200300.100.1.3 > # NAME 'mail' > # EQUALITY caseIgnoreIA5Match > # SUBSTR caseIgnoreIA5SubstringsMatch > # SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) > # > # The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the > # 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are > # described in [RFC4517]. > # > # Note that the directory will not ensure that values of this > attribute > # conform to the <Mailbox> production [RFC2821]. It is the > # application's responsibility to ensure that domains it stores > in this > # attribute are appropriately represented. > # > # Additionally, the directory will compare values per the matching > # rules named in the above attribute type description. As these > rules > # differ from rules that normally apply to <Mailbox> comparisons, > # operational issues may arise. For example, the assertion > # (mail=joe@example.com) will match "JOE@example.com" even though > the > # <local-parts> differ. Also, where a user has two <Mailbox>es > whose > # addresses differ only by case of the <local-part>, both cannot be > # listed as values of the user's mail attribute (as they are > considered > # equal by the 'caseIgnoreIA5Match' rule). > # > # Also note that applications supporting internationalized domain > names > # SHALL use the ToASCII method [RFC3490] to produce <sub-domain> > # components of the <Mailbox> production. > # > > # > -------------------------------------------------------------------------- > # 2.17. manager > # > # The 'manager' attribute specifies managers, by distinguished > name, of > # the person (or entity). > # > > attributetype ( 0.9.2342.19200300.100.1.10 > NAME 'manager' > EQUALITY distinguishedNameMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) > > # > # The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax > and the > # 'distinguishedNameMatch' rule are described in [RFC4517]. > # > > # > -------------------------------------------------------------------------- > # 2.18. mobile > # > # The 'mobile' (mobileTelephoneNumber) attribute specifies mobile > # telephone numbers (e.g., "+1 775 555 6789") associated with a > person > # (or entity). > # > > attributetype ( 0.9.2342.19200300.100.1.41 > NAME ( 'mobile' 'mobileTelephoneNumber' ) > EQUALITY telephoneNumberMatch > SUBSTR telephoneNumberSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) > > # > # The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and > the > # 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' > rules are > # described in [RFC4517]. > # > > # > -------------------------------------------------------------------------- > # 2.19. organizationalStatus > # > # The 'organizationalStatus' attribute specifies categories by > which a > # person is often referred to in an organization. Examples of > usage in > # academia might include "undergraduate student", "researcher", > # "professor", and "staff". Multiple values are allowed where the > # person is in multiple categories. > # > # Directory administrators and application designers SHOULD > consider > # carefully the distinctions between this and the 'title' and > # 'userClass' attributes. > # > > attributetype ( 0.9.2342.19200300.100.1.45 > NAME 'organizationalStatus' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are > described > # in [RFC4517]. > # > > # > -------------------------------------------------------------------------- > # 2.20. pager > # > # The 'pager' (pagerTelephoneNumber) attribute specifies pager > # telephone numbers (e.g., "+1 775 555 5555") for an object. > # > > attributetype ( 0.9.2342.19200300.100.1.42 > NAME ( 'pager' 'pagerTelephoneNumber' ) > EQUALITY telephoneNumberMatch > SUBSTR telephoneNumberSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) > > # > # The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and > the > # 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' > rules are > # described in [RFC4517]. > # > > # > -------------------------------------------------------------------------- > # 2.21. personalTitle > # > # The 'personalTitle' attribute specifies personal titles for a > person. > # Examples of personal titles are "Frau", "Dr.", "Herr", and > # "Professor". > # > > attributetype ( 0.9.2342.19200300.100.1.40 > NAME 'personalTitle' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are > described > # in [RFC4517]. > # > > # > -------------------------------------------------------------------------- > # 2.22. roomNumber > # > # The 'roomNumber' attribute specifies the room number of an > object. > # During periods of renumbering, or in other circumstances where > a room > # has multiple valid room numbers associated with it, multiple > values > # may be provided. Note that the 'cn' (commonName) attribute type > # SHOULD be used for naming room objects. > # > > attributetype ( 0.9.2342.19200300.100.1.6 > NAME 'roomNumber' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are > described > # in [RFC4517]. > # > > # > -------------------------------------------------------------------------- > # 2.23. secretary > # > # The 'secretary' attribute specifies secretaries and/or > administrative > # assistants, by distinguished name. > # > > attributetype ( 0.9.2342.19200300.100.1.21 > NAME 'secretary' > EQUALITY distinguishedNameMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) > > # > # The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax > and the > # 'distinguishedNameMatch' rule are described in [RFC4517]. > # > > # > -------------------------------------------------------------------------- > # 2.24. uniqueIdentifier > # > # The 'uniqueIdentifier' attribute specifies a unique identifier > for an > # object represented in the Directory. The domain within which the > # identifier is unique and the exact semantics of the identifier > are > # for local definition. For a person, this might be an > institution- > # wide payroll number. For an organizational unit, it might be a > # department code. > # > > attributetype ( 0.9.2342.19200300.100.1.44 > NAME 'uniqueIdentifier' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are > described > # in [RFC4517]. > # > # Note: X.520 also describes an attribute called 'uniqueIdentifier' > # (2.5.4.45), which is called 'x500UniqueIdentifier' in LDAP > # [RFC4519]. The attribute detailed here ought not be > confused > # with 'x500UniqueIdentifier'. > # > > # > -------------------------------------------------------------------------- > # 2.25. userClass > # > # The 'userClass' attribute specifies categories of computer or > # application user. The semantics placed on this attribute are for > # local interpretation. Examples of current usage of this > attribute in > # academia are "student", "staff", and "faculty". Note that the > # 'organizationalStatus' attribute type is now often preferred, > as it > # makes no distinction between persons as opposed to users. > # > > attributetype ( 0.9.2342.19200300.100.1.8 > NAME 'userClass' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are > described > # in [RFC4517]. > # > > > # > -------------------------------------------------------------------------- > # Attribute types from RFC 1274 which are missing in RFC 4524 > # > -------------------------------------------------------------------------- > # > # 9.3.2. Text Encoded O/R Address > # > # The Text Encoded O/R Address attribute type specifies a text > encoding > # of an X.400 O/R address, as specified in RFC 987. The use of this > # attribute is deprecated as the attribute is intended for interim > use > # only. This attribute will be the first candidate for the attribute > # expiry mechanisms! > # > # textEncodedORAddress ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # caseIgnoreStringSyntax > # (SIZE (1 .. ub-text-encoded-or-address)) > # ::= {pilotAttributeType 2} > # > > attributetype ( 0.9.2342.19200300.100.1.2 > NAME 'textEncodedORAddress' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > -------------------------------------------------------------------------- > # 9.3.7. Photo > # > # The Photo attribute type specifies a "photograph" for an object. > # This should be encoded in G3 fax as explained in recommendation T. > 4, > # with an ASN.1 wrapper to make it compatible with an X.400 > BodyPart as > # defined in X.420. > # > # IMPORT G3FacsimileBodyPart FROM { mhs-motis ipms modules > # information-objects } > # > # photo ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # CHOICE { > # g3-facsimile [3] G3FacsimileBodyPart > # } > # (SIZE (1 .. ub-photo)) > # ::= {pilotAttributeType 7} > # > > attributetype ( 0.9.2342.19200300.100.1.7 > NAME 'photo' > DESC 'RFC1274: photo (G3 fax)' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.23{25000} ) > > # > -------------------------------------------------------------------------- > # 9.3.18. Other Mailbox > # > # The Other Mailbox attribute type specifies values for electronic > # mailbox types other than X.400 and rfc822. > # > # otherMailbox ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # SEQUENCE { > # mailboxType PrintableString, -- e.g. Telemail > # mailbox IA5String -- e.g. X378:Joe > # } > # ::= {pilotAttributeType 22} > # > > attributetype ( 0.9.2342.19200300.100.1.22 > NAME 'otherMailbox' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.39 ) > > # > -------------------------------------------------------------------------- > # 9.3.22. DNS ARecord > # > # The A Record attribute type specifies a type A (Address) DNS > resource > # record [6] [7]. > # > # aRecord ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # DNSRecordSyntax > # ::= {pilotAttributeType 26} > # > ## incorrect syntax? > attributetype ( 0.9.2342.19200300.100.1.26 > NAME 'aRecord' > EQUALITY caseIgnoreIA5Match > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > ## missing from RFC1274 > ## incorrect syntax? > attributetype ( 0.9.2342.19200300.100.1.27 > NAME 'mDRecord' > EQUALITY caseIgnoreIA5Match > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > # > -------------------------------------------------------------------------- > # 9.3.23. MX Record > # > # The MX Record attribute type specifies a type MX (Mail Exchange) > DNS > # resource record [6] [7]. > # > # mXRecord ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # DNSRecordSyntax > # ::= {pilotAttributeType 28} > # > ## incorrect syntax!! > attributetype ( 0.9.2342.19200300.100.1.28 > NAME 'mXRecord' > EQUALITY caseIgnoreIA5Match > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > # > -------------------------------------------------------------------------- > # 9.3.24. NS Record > # > # The NS Record attribute type specifies an NS (Name Server) DNS > # resource record [6] [7]. > # > # nSRecord ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # DNSRecordSyntax > # ::= {pilotAttributeType 29} > # > ## incorrect syntax!! > > attributetype ( 0.9.2342.19200300.100.1.29 > NAME 'nSRecord' > EQUALITY caseIgnoreIA5Match > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > # > -------------------------------------------------------------------------- > # 9.3.25. SOA Record > # > # The SOA Record attribute type specifies a type SOA (Start of > # Authority) DNS resorce record [6] [7]. > # > # sOARecord ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # DNSRecordSyntax > # ::= {pilotAttributeType 30} > # > ## incorrect syntax!! > > attributetype ( 0.9.2342.19200300.100.1.30 > NAME 'sOARecord' > EQUALITY caseIgnoreIA5Match > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > # > -------------------------------------------------------------------------- > # 9.3.26. CNAME Record > # > # The CNAME Record attribute type specifies a type CNAME (Canonical > # Name) DNS resource record [6] [7]. > # > # cNAMERecord ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # iA5StringSyntax > # ::= {pilotAttributeType 31} > # > ## incorrect syntax!! > > attributetype ( 0.9.2342.19200300.100.1.31 > NAME 'cNAMERecord' > EQUALITY caseIgnoreIA5Match > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > # > -------------------------------------------------------------------------- > # 9.3.36. Janet Mailbox > # > # The Janet Mailbox attribute type specifies an electronic mailbox > # attribute following the syntax specified in the Grey Book of the > # Coloured Book series. This attribute is intended for the > convenience > # of U.K users unfamiliar with rfc822 and little-endian mail > addresses. > # Entries using this attribute MUST also include an rfc822Mailbox > # attribute. > # > # janetMailbox ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # caseIgnoreIA5StringSyntax > # (SIZE (1 .. ub-janet-mailbox)) > # ::= {pilotAttributeType 46} > # > attributetype ( 0.9.2342.19200300.100.1.46 > NAME 'janetMailbox' > DESC 'RFC1274: Janet mailbox' > EQUALITY caseIgnoreIA5Match > SUBSTR caseIgnoreIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) > > # > -------------------------------------------------------------------------- > # 9.3.37. Mail Preference Option > # > # An attribute to allow users to indicate a preference for > inclusion of > # their names on mailing lists (electronic or physical). The absence > # of such an attribute should be interpreted as if the attribute was > # present with value "no-list-inclusion". This attribute should be > # interpreted by anyone using the directory to derive mailing lists, > # and its value respected. > # > # mailPreferenceOption ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX ENUMERATED { > # no-list-inclusion(0), > # any-list-inclusion(1), -- may be added to any lists > # professional-list-inclusion(2) > # -- may be added to lists > # -- which the list provider > # -- views as related to the > # -- users professional inter- > # -- ests, perhaps evaluated > # -- from the business of the > # -- organisation or keywords > # -- in the entry. > # } > # ::= {pilotAttributeType 47} > # > > attributetype ( 0.9.2342.19200300.100.1.47 > NAME 'mailPreferenceOption' > DESC 'RFC1274: mail preference option' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) > > # > -------------------------------------------------------------------------- > # 9.3.43. Personal Signature > # > # The Personal Signature attribute type allows for a representation > of > # a person's signature. This should be encoded in G3 fax as > explained > # in recommendation T.4, with an ASN.1 wrapper to make it compatible > # with an X.400 BodyPart as defined in X.420. > # > # IMPORT G3FacsimileBodyPart FROM { mhs-motis ipms modules > # information-objects } > # > # personalSignature ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # CHOICE { > # g3-facsimile [3] G3FacsimileBodyPart > # } > # (SIZE (1 .. ub-personal-signature)) > # ::= {pilotAttributeType 53} > # > > attributetype ( 0.9.2342.19200300.100.1.53 > NAME 'personalSignature' > DESC 'RFC1274: Personal Signature (G3 fax)' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.23 ) > > # > -------------------------------------------------------------------------- > # 9.3.45. Audio > # > # The Audio attribute type allows the storing of sounds in the > # Directory. The attribute uses a u-law encoded sound file as used > by > # the "play" utility on a Sun 4. This is an interim format. > # > # audio ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # Audio > # (SIZE (1 .. ub-audio)) > # ::= {pilotAttributeType 55} > # > > attributetype ( 0.9.2342.19200300.100.1.55 > NAME 'audio' > DESC 'RFC1274: audio (u-law)' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.4{25000} ) > > > # > -------------------------------------------------------------------------- > # 3. COSINE Object Classes > # > -------------------------------------------------------------------------- > # > # This section details COSINE object classes for use in LDAP. > # > > # > -------------------------------------------------------------------------- > # 3.1. account > # > # The 'account' object class is used to define entries representing > # computer accounts. The 'uid' attribute SHOULD be used for naming > # entries of this object class. > # > > objectclass ( 0.9.2342.19200300.100.4.5 > NAME 'account' > SUP top STRUCTURAL > MUST uid > MAY ( description $ seeAlso $ l $ o $ ou $ host ) ) > > # > # The 'top' object class is described in [RFC4512]. The > 'description', > # 'seeAlso', 'l', 'o', 'ou', and 'uid' attribute types are > described in > # [RFC4519]. The 'host' attribute type is described in Section 2 > of > # this document. > # > # Example: > # > # dn: uid=kdz,cn=Accounts,dc=Example,dc=COM > # objectClass: account > # uid: kdz > # seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM > # > > # > -------------------------------------------------------------------------- > # 3.2. document > # > # The 'document' object class is used to define entries that > represent > # documents. > # > > objectclass ( 0.9.2342.19200300.100.4.6 > NAME 'document' > SUP top STRUCTURAL > MUST documentIdentifier > MAY ( cn $ description $ seeAlso $ l $ o $ ou $ > documentTitle $ documentVersion $ documentAuthor $ > documentLocation $ documentPublisher ) ) > > # > # The 'top' object class is described in [RFC4512]. The 'cn', > # 'description', 'seeAlso', 'l', 'o', and 'ou' attribute types are > # described in [RFC4519]. The 'documentIdentifier', > 'documentTitle', > # 'documentVersion', 'documentAuthor', 'documentLocation', and > # 'documentPublisher' attribute types are described in Section 2 of > # this document. > # > # Example: > # > # dn: documentIdentifier=RFC 4524,cn=RFC,dc=Example,dc=COM > # objectClass: document > # documentIdentifier: RFC 4524 > # documentTitle: COSINE LDAP/X.500 Schema > # documentAuthor: cn=Kurt D. > Zeilenga,cn=Persons,dc=Example,dc=COM > # documentLocation: http://www.rfc-editor.org/rfc/rfc4524.txt > # documentPublisher: Internet Engineering Task Force > # description: A collection of schema elements for use in LDAP > # description: Obsoletes RFC 1274 > # seeAlso: documentIdentifier=RFC 4510,cn=RFC,dc=Example,dc=COM > # seeAlso: documentIdentifier=RFC 1274,cn=RFC,dc=Example,dc=COM > # > > # > -------------------------------------------------------------------------- > # 3.3. documentSeries > # > # The 'documentSeries' object class is used to define an entry that > # represents a series of documents (e.g., The Request For Comments > # memos). > # > > objectclass ( 0.9.2342.19200300.100.4.9 > NAME 'documentSeries' > SUP top STRUCTURAL > MUST cn > MAY ( description $ l $ o $ ou $ seeAlso $ telephonenumber ) ) > > # > # The 'top' object class is described in [RFC4512]. The > 'description', > # 'l', 'o', 'ou', 'seeAlso', and 'telephoneNumber' attribute > types are > # described in [RFC4519]. > # > # Example: > # > # dn: cn=RFC,dc=Example,dc=COM > # objectClass: documentSeries > # cn: Request for Comments > # cn: RFC > # description: a series of memos about the Internet > # > > # > -------------------------------------------------------------------------- > # 3.4. domain > # > # The 'domain' object class is used to define entries that > represent > # DNS domains for objects that are not organizations, > organizational > # units, or other kinds of objects more appropriately defined > using an > # object class specific to the kind of object being defined (e.g., > # 'organization', 'organizationUnit'). > # > # The 'dc' attribute should be used for naming entries of the > 'domain' > # object class. > # > > objectclass ( 0.9.2342.19200300.100.4.13 > NAME 'domain' > SUP top STRUCTURAL > MUST dc > MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ > x121Address $ registeredAddress $ destinationIndicator $ > preferredDeliveryMethod $ telexNumber $ > teletexTerminalIdentifier $ telephoneNumber $ > internationaliSDNNumber $ facsimileTelephoneNumber $ street $ > postOfficeBox $ postalCode $ postalAddress $ > physicalDeliveryOfficeName $ st $ l $ description $ o $ > associatedName ) ) > > # > # The 'top' object class and the 'dc', 'userPassword', > 'searchGuide', > # 'seeAlso', 'businessCategory', 'x121Address', > 'registeredAddress', > # 'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber', > # 'teletexTerminalIdentifier', 'telephoneNumber', > # 'internationaliSDNNumber', 'facsimileTelephoneNumber', 'street', > # 'postOfficeBox', 'postalCode', 'postalAddress', > # 'physicalDeliveryOfficeName', 'st', 'l', 'description', and 'o' > types > # are described in [RFC4519]. The 'associatedName' attribute > type is > # described in Section 2 of this document. > # > # Example: > # > # dn: dc=com > # objectClass: domain > # dc: com > # description: the .COM TLD > # > > # > -------------------------------------------------------------------------- > # 3.5. domainRelatedObject > # > # The 'domainRelatedObject' object class is used to define > entries that > # represent DNS domains that are "equivalent" to an X.500 domain, > e.g., > # an organization or organizational unit. > # > > objectclass ( 0.9.2342.19200300.100.4.17 > NAME 'domainRelatedObject' > SUP top AUXILIARY > MUST associatedDomain ) > > # > # The 'top' object class is described in [RFC4512]. The > # 'associatedDomain' attribute type is described in Section 2 of > this > # document. > # > # Example: > # > # dn: dc=example,dc=com > # objectClass: organization > # objectClass: dcObject > # objectClass: domainRelatedObject > # dc: example > # associatedDomain: example.com > # o: Example Organization > # > # The 'organization' and 'dcObject' object classes and the 'dc' > and 'o' > # attribute types are described in [RFC4519]. > # > > # > -------------------------------------------------------------------------- > # 3.6. friendlyCountry > # > # The 'friendlyCountry' object class is used to define entries > # representing countries in the DIT. The object class is used to > allow > # friendlier naming of countries than that allowed by the object > class > # 'country' [RFC4519]. > # > > objectclass ( 0.9.2342.19200300.100.4.18 > NAME 'friendlyCountry' > SUP country STRUCTURAL > MUST co ) > > # > # The 'country' object class is described in [RFC4519]. The 'co' > # attribute type is described in Section 2 of this document. > # > # Example: > # > # dn: c=DE > # objectClass: country > # objectClass: friendlyCountry > # c: DE > # co: Deutschland > # co: Germany > # co: Federal Republic of Germany > # co: FRG > # > # The 'c' attribute type is described in [RFC4519]. > # > > # > -------------------------------------------------------------------------- > # 3.7. rFC822LocalPart > # > # The 'rFC822LocalPart' object class is used to define entries that > # represent the local part of Internet mail addresses [RFC2822]. > This > # treats the local part of the address as a 'domain' object. > # > > objectclass ( 0.9.2342.19200300.100.4.14 > NAME 'rFC822localPart' > SUP domain STRUCTURAL > MAY ( cn $ description $ destinationIndicator $ > facsimileTelephoneNumber $ internationaliSDNNumber $ > physicalDeliveryOfficeName $ postalAddress $ postalCode $ > postOfficeBox $ preferredDeliveryMethod $ registeredAddress $ > seeAlso $ sn $ street $ telephoneNumber $ > teletexTerminalIdentifier $ telexNumber $ x121Address ) ) > > # > # The 'domain' object class is described in Section 3.4 of this > # document. The 'cn', 'description', 'destinationIndicator', > # 'facsimileTelephoneNumber', 'internationaliSDNNumber, > # 'physicalDeliveryOfficeName', 'postalAddress', 'postalCode', > # 'postOfficeBox', 'preferredDeliveryMethod', 'registeredAddress', > # 'seeAlso', 'sn, 'street', 'telephoneNumber', > # 'teletexTerminalIdentifier', 'telexNumber', and 'x121Address' > # attribute types are described in [RFC4519]. > # > # Example: > # > # dn: dc=kdz,dc=example,dc=com > # objectClass: domain > # objectClass: rFC822LocalPart > # dc: kdz > # associatedName: cn=Kurt D. > Zeilenga,cn=Persons,dc=Example,dc=COM > # > # The 'dc' attribute type is described in [RFC4519]. > # > > # > -------------------------------------------------------------------------- > # 3.8. room > # > # The 'room' object class is used to define entries representing > rooms. > # The 'cn' (commonName) attribute SHOULD be used for naming > entries of > # this object class. > # > > objectclass ( 0.9.2342.19200300.100.4.7 > NAME 'room' > SUP top STRUCTURAL > MUST cn > MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) ) > > # > # The 'top' object class is described in [RFC4512]. The 'cn', > # 'description', 'seeAlso', and 'telephoneNumber' attribute types > are > # described in [RFC4519]. The 'roomNumber' attribute type is > described > # in Section 2 of this document. > # > # dn: cn=conference room,dc=example,dc=com > # objectClass: room > # cn: conference room > # telephoneNumber: +1 755 555 1111 > # > > # > -------------------------------------------------------------------------- > # 3.9. simpleSecurityObject > # > # The 'simpleSecurityObject' object class is used to require an > entry > # to have a 'userPassword' attribute when the entry's structural > object > # class does not require (or allow) the 'userPassword attribute'. > # > # (OpenLDAP-specific: Declared in core.schema) > # objectclass ( 0.9.2342.19200300.100.4.19 > # NAME 'simpleSecurityObject' > # SUP top AUXILIARY > # MUST userPassword ) > # > # The 'top' object class is described in [RFC4512]. The > 'userPassword' > # attribute type is described in [RFC4519]. > # > # dn: dc=kdz,dc=Example,dc=COM > # objectClass: account > # objectClass: simpleSecurityObject > # uid: kdz > # userPassword: My Password > # seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM > # > > # > -------------------------------------------------------------------------- > # Object classes from RFC 1274 which are missing in RFC 4524 > # > -------------------------------------------------------------------------- > # > # 8.3.2. Pilot Person > # > # The PilotPerson object class is used as a sub-class of person, to > # allow the use of a number of additional attributes to be assigned > to > # entries of object class person. > # > # pilotPerson OBJECT-CLASS > # SUBCLASS OF person > # MAY CONTAIN { > # userid, > # textEncodedORAddress, > # rfc822Mailbox, > # favouriteDrink, > # roomNumber, > # userClass, > # homeTelephoneNumber, > # homePostalAddress, > # secretary, > # personalTitle, > # preferredDeliveryMethod, > # businessCategory, > # janetMailbox, > # otherMailbox, > # mobileTelephoneNumber, > # pagerTelephoneNumber, > # organizationalStatus, > # mailPreferenceOption, > # personalSignature} > # ::= {pilotObjectClass 4} > # > > objectclass ( 0.9.2342.19200300.100.4.4 > NAME ( 'pilotPerson' 'newPilotPerson' ) > SUP person STRUCTURAL > MAY ( userid $ textEncodedORAddress $ rfc822Mailbox $ > favouriteDrink $ roomNumber $ userClass $ > homeTelephoneNumber $ homePostalAddress $ secretary $ > personalTitle $ preferredDeliveryMethod $ businessCategory $ > janetMailbox $ otherMailbox $ mobileTelephoneNumber $ > pagerTelephoneNumber $ organizationalStatus $ > mailPreferenceOption $ personalSignature ) ) > > # 8.3.9. DNS Domain > # > # The DNS Domain (Domain NameServer) object class is used to define > # entries for DNS domains. The usage of this object class is > described > # in more detail in [3]. > # > # dNSDomain OBJECT-CLASS > # SUBCLASS OF domain > # MAY CONTAIN { > # ARecord, > # MDRecord, > # MXRecord, > # NSRecord, > # SOARecord, > # CNAMERecord} > # ::= {pilotObjectClass 15} > # > > objectclass ( 0.9.2342.19200300.100.4.15 > NAME 'dNSDomain' > SUP domain STRUCTURAL > MAY ( ARecord $ MDRecord $ MXRecord $ NSRecord $ > SOARecord $ CNAMERecord ) ) > > > --------------080004030402080700020504-- > >
Kurt Zeilenga wrote: > > On Jun 1, 2009, at 4:30 AM, michael@stroeder.com wrote: >> Updated schema file cosine-update.schema attached. > > I note that differs are generally preferred, even where the file is > mostly changed. This helps ensure changes that others might make to the > file you started with are not lost. I thought about sending a diff but the file in this form is more readable for easy review. Could someone please look at it whether that's ok? Another approach would be to have two schema files, one which only contains the schema descriptions from RFC 4524 and one with the missing schema descriptions from RFC 1274 with the latter obviously being dependent on the former. >> IPR notice: >> This patch file is derived from OpenLDAP Software and RFC 4524 and RFC >> 1274. All of the modifications to OpenLDAP Software represented in the >> attached file were developed by Michael Ströder <michael@stroeder.com>. >> I have not assigned rights and/or interest in this work to any party. > > While this notice of origin is fine, you did not include a rights > statement. I, Michael Ströder, hereby place the modified schema file cosine.schema attached to ITS#6151 (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. Ciao, Michael.
changed state Open to Active
> Kurt Zeilenga wrote: >> >> On Jun 1, 2009, at 4:30 AM, michael@stroeder.com wrote: >>> Updated schema file cosine-update.schema attached. >> >> I note that differs are generally preferred, even where the file is >> mostly changed. This helps ensure changes that others might make to the >> file you started with are not lost. > > I thought about sending a diff but the file in this form is more > readable for easy review. Could someone please look at it whether that's > ok? > Another approach would be to have two schema files, one which only > contains the schema descriptions from RFC 4524 and one with the missing > schema descriptions from RFC 1274 with the latter obviously being > dependent on the former. I have one preliminary question for Kurt: since rfc4524 obsoletes rfc1274, should those schema items that were not brought forward be marked as OBSOLETE? If yes, then all schema could fit in one file. I'd like a clear way to separate valid from obsolete schema. The obsolete items should be available for backwards compatibility. As an alternative, I'd like to have a "slim" (without obsolete) and a complete version of the file. Could you please upload the file? Through the ITS attachments don't work too well. >>> IPR notice: >>> This patch file is derived from OpenLDAP Software and RFC 4524 and RFC >>> 1274. All of the modifications to OpenLDAP Software represented in the >>> attached file were developed by Michael Ströder <michael@stroeder.com>. >>> I have not assigned rights and/or interest in this work to any party. >> >> While this notice of origin is fine, you did not include a rights >> statement. > > I, Michael Ströder, hereby place the modified schema file cosine.schema > attached to ITS#6151 (and only these modifications) into the public > domain. Hence, these modifications may be freely used and/or > redistributed for any purpose with or without attribution and/or other > notice. Am I right in assuming this IPR is fine? Thanks, p.
On Apr 21, 2010, at 6:03 PM, masarati@aero.polimi.it wrote: >> Kurt Zeilenga wrote: >>> >>> On Jun 1, 2009, at 4:30 AM, michael@stroeder.com wrote: >>>> Updated schema file cosine-update.schema attached. >>> >>> I note that differs are generally preferred, even where the file is >>> mostly changed. This helps ensure changes that others might make to the >>> file you started with are not lost. >> >> I thought about sending a diff but the file in this form is more >> readable for easy review. Could someone please look at it whether that's >> ok? > >> Another approach would be to have two schema files, one which only >> contains the schema descriptions from RFC 4524 and one with the missing >> schema descriptions from RFC 1274 with the latter obviously being >> dependent on the former. > > I have one preliminary question for Kurt: since rfc4524 obsoletes rfc1274, > should those schema items that were not brought forward be marked as > OBSOLETE? obsoletes != OBSOLETE, so no. That is, the meaning of the term 'obsolete' is quite different in these two contexts. The latter context the term is defined as follows: The OBSOLETE field, if present, indicates the element is not active. For user application attribute types, whether the type is active or not is, I think, best left to the schema administrator. (Update operations upon an inactive element is limited to removal of the element.) > If yes, then all schema could fit in one file. I'd like a > clear way to separate valid from obsolete schema. The obsolete items > should be available for backwards compatibility. As an alternative, I'd > like to have a "slim" (without obsolete) and a complete version of the > file. I rather no element be specified in multiple files. > Could you please upload the file? Through the ITS attachments > don't work too well. > >>>> IPR notice: >>>> This patch file is derived from OpenLDAP Software and RFC 4524 and RFC >>>> 1274. All of the modifications to OpenLDAP Software represented in the >>>> attached file were developed by Michael Ströder <michael@stroeder.com>. >>>> I have not assigned rights and/or interest in this work to any party. >>> >>> While this notice of origin is fine, you did not include a rights >>> statement. >> >> I, Michael Ströder, hereby place the modified schema file cosine.schema >> attached to ITS#6151 (and only these modifications) into the public >> domain. Hence, these modifications may be freely used and/or >> redistributed for any purpose with or without attribution and/or other >> notice. > > Am I right in assuming this IPR is fine? Thanks, p. Yes. - Kurt
Kurt Zeilenga wrote: > obsoletes != OBSOLETE, so no. That is, the meaning of the term > 'obsolete' is quite different in these two contexts. > > The latter context the term is defined as follows: The OBSOLETE field, if > present, indicates the element is not active. I agree that OBSOLETE should not be set in this case. > For user application attribute types, whether the type is active or not is, > I think, best left to the schema administrator. Who is the schema administrator? I'm nitpicking here because on the OpenLDAP lists we all keep telling OpenLDAP admins not to mess with the standard schema at all. IMO this includes setting OBSOLETE. Ciao, Michael.
> Kurt Zeilenga wrote: >> obsoletes != OBSOLETE, so no. That is, the meaning of the term >> 'obsolete' is quite different in these two contexts. >> >> The latter context the term is defined as follows: The OBSOLETE field, >> if >> present, indicates the element is not active. > > I agree that OBSOLETE should not be set in this case. > >> For user application attribute types, whether the type is active or not >> is, >> I think, best left to the schema administrator. > > Who is the schema administrator? I'm nitpicking here because on the > OpenLDAP > lists we all keep telling OpenLDAP admins not to mess with the standard > schema > at all. IMO this includes setting OBSOLETE. I Think there's a misunderstanding. My understanding (and intention) is 1) You said you pulled in revisited cosine.schema also elements that were dropped in RFC4524. 2) I was asking whether the fact they were dropped implied they were OBSOLETE (i.e. had to be marked as OBSOLETE in their schema definition) 3) Kurt replied that they MUST NOT be marked as OBSOLETE. Whether they are loaded or not in a DSA's schema is at the DSA schema administrator's choice 4) This, IMHO, implies that we need to provide two separate files, to allow DSA admins to either load strict RFC4524 schema (no obsolete items) or loose RFC4524 (entire RFC1274 schema). Now, we have different options to arrange the resulting schema files (names used below are only an example, the final name can be discussed when there's consensus on the approach): a) cosine.schema (== RFC1274) cosine4524.schema (== RFC4524) mutually exclusive (Kurt does not like this) b) cosine4524.schema (== RFC4524) cosine.schema (== RFC1274 - RFC4524) the latter includes the former c) cosine4524.schema (== RFC4524) cosine1274.schema (== RFC1274 - RFC4524) (there might be more) Cases (a) and (b) have advantages: loading cosine.schema loads all RFC1274 schema, thus existing configurations surely do not break. I concur case (a) would cause a lot of complaints from people loading all available schema files and having conflicts. Case (c) needs to modify configuration, but avoids file nesting, if that's a problem at all. p.
masarati@aero.polimi.it wrote: > 4) This, IMHO, implies that we need to provide two separate files, to > allow DSA admins to either load strict RFC4524 schema (no obsolete items) > or loose RFC4524 (entire RFC1274 schema). > > Now, we have different options to arrange the resulting schema files > (names used below are only an example, the final name can be discussed > when there's consensus on the approach): > > a) cosine.schema (== RFC1274) > cosine4524.schema (== RFC4524) > mutually exclusive (Kurt does not like this) > > b) cosine4524.schema (== RFC4524) > cosine.schema (== RFC1274 - RFC4524) > the latter includes the former > > c) cosine4524.schema (== RFC4524) > cosine1274.schema (== RFC1274 - RFC4524) > > (there might be more) Yes, cosine.schema wrapping cosine4524.schema and cosine1274.schema might be best. > Cases (a) and (b) have advantages: loading cosine.schema loads all RFC1274 > schema, thus existing configurations surely do not break. I concur case > (a) would cause a lot of complaints from people loading all available > schema files and having conflicts. Case (c) needs to modify > configuration, but avoids file nesting, if that's a problem at all. File nesting has some implications in cn=config, which is why I made the above suggestion. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Apr 22, 2010, at 1:34 AM, michael@stroeder.com wrote: > Kurt Zeilenga wrote: >> obsoletes != OBSOLETE, so no. That is, the meaning of the term >> 'obsolete' is quite different in these two contexts. >> >> The latter context the term is defined as follows: The OBSOLETE field, if >> present, indicates the element is not active. > > I agree that OBSOLETE should not be set in this case. > >> For user application attribute types, whether the type is active or not is, >> I think, best left to the schema administrator. > > Who is the schema administrator? Generally speaking, the OpenLDAP admin administrates which schema elements to load into the schema and whether each such element is active and inactive. While in some cases a schema admin might design schema elements, I consider schema admin and schema element designer to be two separate roles. > I'm nitpicking here because on the OpenLDAP > lists we all keep telling OpenLDAP admins not to mess with the standard schema > at all. We often advise admins to load various schema elements into their schemas. We generally assume admins run have only active elements in the their schema as the need for inactive elements can generally be avoided. When at I say "don't mess with standard schema elements", what I mean is don't change aspects of schema specifications which are consider per the technical specifications to be immutable on published in a technical specification (or otherwise broadly published). There certainly are other changes one can make to standard schema elements without violating the technical specifications (e.g., changing the DESC value), and if such case were to arise more generally, I might be more precise in my general advice. That is, I rather only raise exceptions in advice when it's actually applicable to the situation raised by the admin. -- Kurt
Kurt Zeilenga wrote: > > On Apr 22, 2010, at 1:34 AM, michael@stroeder.com wrote: > >> Kurt Zeilenga wrote: >>> obsoletes != OBSOLETE, so no. That is, the meaning of the term >>> 'obsolete' is quite different in these two contexts. >>> >>> The latter context the term is defined as follows: The OBSOLETE field, if >>> present, indicates the element is not active. >> >> I agree that OBSOLETE should not be set in this case. >> >>> For user application attribute types, whether the type is active or not is, >>> I think, best left to the schema administrator. >> >> Who is the schema administrator? > > Generally speaking, the OpenLDAP admin administrates which schema elements > to load into the schema and whether each such element is active and > inactive. What does "active and inactive" mean exactly? Does that include changing the OBSOLETE keyword in schema files? I hope not... > While in some cases a schema admin might design schema elements, I consider > schema admin and schema element designer to be two separate roles. Agreed. >> I'm nitpicking here because on the OpenLDAP >> lists we all keep telling OpenLDAP admins not to mess with the standard schema >> at all. > > We often advise admins to load various schema elements into their schemas. The role for loading the shipped schema files is not the question here. > When at I say "don't mess with standard schema elements", what I mean is > don't change aspects of schema specifications which are consider per the > technical specifications to be immutable on published in a technical > specification (or otherwise broadly published). Does "immutable" include OBSOLETE? I hope so... Ciao, Michael.
On Apr 22, 2010, at 9:58 AM, Michael Ströder wrote: > Kurt Zeilenga wrote: >> >> On Apr 22, 2010, at 1:34 AM, michael@stroeder.com wrote: >> >>> Kurt Zeilenga wrote: >>>> obsoletes != OBSOLETE, so no. That is, the meaning of the term >>>> 'obsolete' is quite different in these two contexts. >>>> >>>> The latter context the term is defined as follows: The OBSOLETE field, if >>>> present, indicates the element is not active. >>> >>> I agree that OBSOLETE should not be set in this case. >>> >>>> For user application attribute types, whether the type is active or not is, >>>> I think, best left to the schema administrator. >>> >>> Who is the schema administrator? >> >> Generally speaking, the OpenLDAP admin administrates which schema elements >> to load into the schema and whether each such element is active and >> inactive. > > What does "active and inactive" mean exactly? Does that include changing the > OBSOLETE keyword in schema files? I hope not... The purpose of the OBSOLETE (inactive) flag is to support transition away from a particular schema element. Basically, if one no longer wants to use the attribute type 'x' in their directory, they should 1) mark x as inactive in the subschema, 2) then remove all uses of x, 3) then remove x from the subschema. The directory prevents all non-removal updates to inactive elements, allowing 2 to be well performed. > >> While in some cases a schema admin might design schema elements, I consider >> schema admin and schema element designer to be two separate roles. > > Agreed. > >>> I'm nitpicking here because on the OpenLDAP >>> lists we all keep telling OpenLDAP admins not to mess with the standard schema >>> at all. >> >> We often advise admins to load various schema elements into their schemas. > > The role for loading the shipped schema files is not the question here. > >> When at I say "don't mess with standard schema elements", what I mean is >> don't change aspects of schema specifications which are consider per the >> technical specifications to be immutable on published in a technical >> specification (or otherwise broadly published). > > Does "immutable" include OBSOLETE? I hope so... OBSOLETE is one of the mutable properties of a schema element (because otherwise it couldn't support local movements away from arbitrary schema elements). -- Kurt > > Ciao, Michael.
On Apr 22, 2010, at 10:20 AM, Kurt Zeilenga wrote: > The purpose of the OBSOLETE (inactive) flag is to support transition away from a particular schema element. Basically, if one no longer wants to use the attribute type 'x' in their directory, they should 1) mark x as inactive in the subschema, 2) then remove all uses of x, 3) then remove x from the subschema. One additional note, I generally would advise that a schema-aware client not alter it's update behavior of elements based upon whether said elements are active or inactive (OBSOLETE) in the schema. Instead, they should just try the update and, if it fails, report it as they normally would. Handling the inactive condition locally hides the error from the directory administrator, who is likely relying on directory server logs to find applications which using inactive schema. He may well not have access to all the clients' logs. -- Kurt
Kurt Zeilenga wrote: > One additional note, I generally would advise that a schema-aware client > not alter it's update behavior of elements based upon whether said elements > are active or inactive (OBSOLETE) in the schema. I disagree especially for cases when new data is added. > Instead, they should just > try the update and, if it fails, report it as they normally would. Modifying existing data I first have to think about... > Handling the inactive condition locally hides the error from the directory > administrator, who is likely relying on directory server logs to find > applications which using inactive schema. Hmm, that's not the case with a schema-aware client anyway which guides the user *not* to use OBSOLETE schema elements. You're likely talking about detecting pre-configured applications with hard-coded use of OBSOLETE object classes and attribute types. Most times these are not schema-aware at all. Ciao, Michael.
On Apr 22, 2010, at 2:58 PM, Michael Ströder wrote: > Kurt Zeilenga wrote: >> One additional note, I generally would advise that a schema-aware client >> not alter it's update behavior of elements based upon whether said elements >> are active or inactive (OBSOLETE) in the schema. > > I disagree especially for cases when new data is added. I think you're trying to make the client far smarter than it really ought to be. If the clients configured to place say place element of data in attribute x, it shouldn't try to put it elsewhere. It should fail. While certainly one could design a client such as it could be configured with fallbacks for attributes, and fallback for fallbacks, etc., this is an unnecessarily complication IMO. Also, note that were a client to attempt the above, it could still fail due to an element being marked inactive between the time it read the schema and the time it tried the DIT update. Of course, one could complicate the client further by trying to handle this as well. > >> Instead, they should just >> try the update and, if it fails, report it as they normally would. > > Modifying existing data I first have to think about... > >> Handling the inactive condition locally hides the error from the directory >> administrator, who is likely relying on directory server logs to find >> applications which using inactive schema. > > Hmm, that's not the case with a schema-aware client anyway which guides the > user *not* to use OBSOLETE schema elements. I generally assume the user is not selecting which attribute to store some piece of information into. I assume the client been programmed to collect a piece of information and configured (or programmed) where to store it. The client you refer to is what I would call an application-neutral LDAP directory administration tool. For such a tool, it might be reasonable to warn the user (whose generally an "administrator" of some sort as opposed to a "normal" user). > You're likely talking about > detecting pre-configured applications with hard-coded use of OBSOLETE object > classes and attribute types. > Most times these are not schema-aware at all. Well, pre-configured applications may be schema-aware but maybe not as fully as an LDAP directory administration tool might be. They might check that the element they were configured to use is appropriate for that use by examining its specification in the subschema. -- Kurt
moved from Incoming to Software Enhancements
has patch see ITS#8009
changed notes
*** Issue 8009 has been marked as a duplicate of this issue. ***
(In reply to Howard Chu from comment #9) > > a) cosine.schema (== RFC1274) > > cosine4524.schema (== RFC4524) > > mutually exclusive (Kurt does not like this) > > > > b) cosine4524.schema (== RFC4524) > > cosine.schema (== RFC1274 - RFC4524) > > the latter includes the former > > > > c) cosine4524.schema (== RFC4524) > > cosine1274.schema (== RFC1274 - RFC4524) > > > > (there might be more) > > Yes, cosine.schema wrapping cosine4524.schema and cosine1274.schema might be > best. Sounds like (d) is the best option then: cosine4524.schema cosine1274.schema cosine.schema ? Michael, do you want to update your patch for this?
Punting to 2.6