Skip to content
Snippets Groups Projects
Commit 62a588bd authored by Kurt Zeilenga's avatar Kurt Zeilenga
Browse files

Correct SMIME comment 

move pilot.schema to the Attic
parent e30826ea
Branches
Tags
No related merge requests found
Hide whitespace changes
Inline Side-by-side
servers/slapd/schema/README
+ 0
− 1
View file @ 62a588bd
......@@ -15,7 +15,6 @@ misc.schema misc. schema
nadf.schema North America Directory Forum schema
nis.schema Network Information Service schema
openldap.schema OpenLDAP Project schema
pilot.schema old Pilot schema
Additional schema definitions can be submitted using the OpenLDAP
Issue Tracking System <http://www.openldap.org/its/>.
......
servers/slapd/schema/inetorgperson.schema
+ 2
− 0
View file @ 62a588bd
......@@ -104,6 +104,7 @@ attributetype ( 2.16.840.1.113730.3.1.39
# this attribute are to be stored and requested in binary form, as
# 'userSMIMECertificate;binary'. If available, this attribute is
# preferred over the userCertificate attribute for S/MIME applications.
# OpenLDAP note: ";binary" transfer should NOT be used as syntax is binary
attributetype ( 2.16.840.1.113730.3.1.40
NAME 'userSMIMECertificate'
DESC 'RFC2798: PKCS#7 SignedData used to support S/MIME'
......@@ -115,6 +116,7 @@ attributetype ( 2.16.840.1.113730.3.1.40
# the userPKCS12 attribute should be used. This attribute is to be stored
# and requested in binary form, as 'userPKCS12;binary'. The attribute
# values are PFX PDUs stored as binary data.
# OpenLDAP note: ";binary" transfer should NOT be used as syntax is binary
attributetype ( 2.16.840.1.113730.3.1.216
NAME 'userPKCS12'
DESC 'RFC2798: PKCS #12 PFX PDU for exchange of
......
servers/slapd/schema/pilot.schema deleted 100644 → 0
+ 0
− 358
View file @ e30826ea
# $OpenLDAP$
# DO NOT USE THESE DEFINITIONS
# use cosine.schema instead!
# These come from RFC1274 and are in ASN.1 syntax. They have been
# translated with some imagination. Only attributes and classes we
# already had are here. In general, the matching rules in the
# attribute types are incomplete or incorrect and have to be checked.
# Note: It seems that the pilot schema evolved beyond what was
# described in RFC1274. It also seems that Umich followed the changes
# but we don't know where are documented. More worrisome is that it
# seems that Netscape does not know either. Searches on Altavista
# have not shed any light, so we will have to ask for help.
# This file uses definitions from core.schema
# ccitt.data.pss.ucl.pilot ( 0.9.2342.19200300.100 )
# 1 pilotAttributeType
# 3 pilotAttributeSyntax
# 4 pilotObjectClass
# 10 pilotGroups
# Believe it or not, this is case-insensitive
attributetype ( 0.9.2342.19200300.100.1.2 NAME 'textEncodedORAddress'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822Mailbox' )
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
attributetype ( 0.9.2342.19200300.100.1.4 NAME 'info' EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( 0.9.2342.19200300.100.1.5 NAME ( 'drink' 'favouriteDrink' )
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( 0.9.2342.19200300.100.1.6 NAME 'roomNumber'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( 0.9.2342.19200300.100.1.7 NAME 'photo'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
attributetype ( 0.9.2342.19200300.100.1.8 NAME 'userClass'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( 0.9.2342.19200300.100.1.9 NAME 'host'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( 0.9.2342.19200300.100.1.10 NAME 'manager'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
attributetype ( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( 0.9.2342.19200300.100.1.12 NAME 'documentTitle'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( 0.9.2342.19200300.100.1.13 NAME 'documentVersion'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
attributetype ( 0.9.2342.19200300.100.1.15 NAME 'documentLocation'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( 0.9.2342.19200300.100.1.20 NAME ( 'homeTelephoneNumber' 'homePhone' )
EQUALITY telephoneNumberMatch
SUBSTR telephoneNumberSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
attributetype ( 0.9.2342.19200300.100.1.21 NAME 'secretary'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
# Netscape defines this with syntax 1.15 TBC
attributetype ( 0.9.2342.19200300.100.1.22 NAME 'otherMailbox'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.39 )
# Netscape defines this with syntax 1.15 TBC
# Mathcing rules for this are unknown
attributetype ( 0.9.2342.19200300.100.1.23 NAME 'lastModifiedTime'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.53 )
attributetype ( 0.9.2342.19200300.100.1.24 NAME 'lastModifiedBy'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
# This is the definition as defined in RFC2247
# Terrific, we don't know about caseIgnoreIA5SubstringsMatch
# See RFC2247 define in core.schema
#attributetype ( 0.9.2342.19200300.100.1.25 NAME 'dc'
# EQUALITY caseIgnoreIA5Match
# SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
# This is aRecord in RFC1274. However, objectclass dNSDomain as we
# and Netscape use it is very different.
attributetype ( 0.9.2342.19200300.100.1.26 NAME 'dNSRecord'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# 0.9.2342.19200300.100.1.27 was probably intended to be mDRecord in
# RFC1274, but they got it wrong and did not define it, thought it
# is referenced by dNSDomain in it.
# 0.9.2342.19200300.100.1.28 was mXRecord in RFC1274
# 0.9.2342.19200300.100.1.29 was nSRecord in RFC1274
# 0.9.2342.19200300.100.1.30 was sOARecord in RFC1274
# 0.9.2342.19200300.100.1.31 was cNAMERecord in RFC1274
#attribute ( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain'
# EQUALITY caseIgnoreIA5Match
# SUBSTR caseIgnoreIA5SubstringsMatch
# SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( 0.9.2342.19200300.100.1.38 NAME 'associatedName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
# Netscape gives syntax 1.15 to this. TBC
# We take the matching rules from postalAddress in RFC2256
# Show stopper: we don't have the definition of caseIgnoreListSubstringsMatch
attributetype ( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress'
EQUALITY caseIgnoreListMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
attributetype ( 0.9.2342.19200300.100.1.40 NAME 'personalTitle'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( 0.9.2342.19200300.100.1.41 NAME ( 'mobileTelephoneNumber' 'mobile' )
EQUALITY telephoneNumberMatch
SUBSTR telephoneNumberSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
attributetype ( 0.9.2342.19200300.100.1.42 NAME ( 'pagerTelephoneNumber' 'pager' )
EQUALITY telephoneNumberMatch
SUBSTR telephoneNumberSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
attributetype ( 0.9.2342.19200300.100.1.43 NAME ( 'co' 'friendlyCountryName' )
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( 0.9.2342.19200300.100.1.45 NAME 'organizationalStatus'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( 0.9.2342.19200300.100.1.46 NAME 'janetMailbox'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# Netscape gives syntax 1.27 (integer). However, 1.32 is only listed
# in RFC2252 without explanation. The SINGLE-VALUE thing comes from
# Netscape and is not backed by RFC1274.
attributetype ( 0.9.2342.19200300.100.1.47 NAME 'mailPreferenceOption'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.32 SINGLE-VALUE )
attributetype ( 0.9.2342.19200300.100.1.48 NAME 'buildingName'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
# 0.9.2342.19200300.100.1.49 was dSAQuality in RFC1274
# 0.9.2342.19200300.100.1.50 was singleLevelQuality in RFC1274
# 0.9.2342.19200300.100.1.51 was subtreeMinimumQuality in RFC1274
# 0.9.2342.19200300.100.1.52 was subtreeMaximumQuality in RFC1274
# Netscape assigns binary syntax to this. RFC1274 is more detailed
# about this but RFC2252 does not seem to list a specific syntax.
# We had this as 'bin'
attributetype ( 0.9.2342.19200300.100.1.53 NAME 'personalSignature'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
attributetype ( 0.9.2342.19200300.100.1.54 NAME 'dITRedirect'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
# Netscape gives syntax 1.5 to this. We had it as 'bin'.
attributetype ( 0.9.2342.19200300.100.1.55 NAME 'audio'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.4 )
attributetype ( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# From RFC 2798 (inetOrgPerson)
attributetype ( 0.9.2342.19200300.100.1.60
NAME 'jpegPhoto'
DESC 'a JPEG image'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 )
# These attributes are pilot-related attributes that we had and Netscape
# has too, however, the OID is unknown for them and Netscape uses a
# string in place of the missing OID. We will do the same until we
# can make head or tails of this.
attributetype ( abstract-oid NAME 'abstract'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( authorcn-oid NAME ( 'documentAuthorCommonName' 'authorCn' )
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( authorsn-oid NAME ( 'documentAuthorSurname' 'authorSn' )
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( documentStore-oid NAME 'documentStore'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( keyWords-oid NAME 'keyWords'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( obsoletedByDocument-oid NAME 'obsoletedByDocument'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
attributetype ( obsoletesDocument-oid NAME 'obsoletesDocument'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
attributetype ( subject-oid NAME 'subject'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributetype ( updatedByDocument-oid NAME 'updatedByDocument'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
attributetype ( updatesDocument-oid NAME 'updatesDocument'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
# In classes, STRUCTURAL or AUXILIARY is chosen depending on the
# textual description that accompanies the class in RFC1274
# This is pilotObject from the RFC. However, we had both photo
# and jpegPhoto attributes. Nestcape does too.
objectclass ( 0.9.2342.19200300.100.4.3 NAME 'pilotObject' SUP top
AUXILIARY MAY ( info $ photo $ manager $ uniqueIdentifier $
lastModifiedTime $ lastModifiedBy $ dITRedirect $ audio $
jpegPhoto ) )
# This is probably wrong. RFC1274 defines a pilotPerson. We did not
# have it and we did have a newPilotPerson instead. However, the
# definition is the same. Maybe it changed and was not reflected
# in the RFC.
objectclass ( 0.9.2342.19200300.100.4.4 NAME 'newPilotPerson' SUP person
STRUCTURAL MAY ( uid $ textEncodedORAddress $ mail $ drink $
roomNumber $ userClass $ homePhone $ homePostalAddress $
secretary $ personalTitle $ preferredDeliveryMethod $
businessCategory $ janetMailbox $ otherMailbox $ mobile $
pager $ organizationalStatus $ mailPreferenceOption $
personalSignature ) )
# The text is unclear about whether it is STRUCTURAL or AUXILIARY
# I think it was meant to be STRUCTURAL, it is the least restrictive
# of the options and RFC2377 explains uidObject as an auxiliary.
objectclass ( 0.9.2342.19200300.100.4.5 NAME 'account' SUP top
STRUCTURAL MUST uid MAY ( description $ seeAlso $ l $ o $ ou $
host ) )
# Netscape says this is derived from pilotObject, but RFC1274 says top.
# Which is it? Our attribute list matches that of Netscape, so we will
# go with Netscape for the time being.
# Besides, this objectclass is a mess. I can only presume that
# originally documentAuthor, but later someone noticed that not all
# authors had DN's, so authorCN and authorSN were added. Other
# attributes were added as well. However, either no one remembered to
# assign OIDs to these attribute types or their assignments have been
# lost. See their definitions above for the Netscape kludge that we
# have adopted. FIX NEEDED.
objectclass ( 0.9.2342.19200300.100.4.6 NAME 'document' SUP pilotObject
MUST documentIdentifier MAY ( cn $ description $ seeAlso $ l $
o $ ou $ documentTitle $ documentVersion $ documentAuthor $
documentLocation $ documentPublisher $
abstract $ authorCN $ authorSN $ documentStore $ keywords $
obsoletedByDocument $ obsoletesDocument $ subject $
updatedByDocument $ updatesDocument ) )
objectclass ( 0.9.2342.19200300.100.4.7 NAME 'room' SUP top STRUCTURAL
MUST cn MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) )
objectclass ( 0.9.2342.19200300.100.4.9 NAME 'documentSeries' SUP top
STRUCTURAL MUST cn MAY ( description $ seeAlso $ telephonenumber $
l $ o $ ou ) )
# This definition is much longer than that in RFC1274 and is taken from RFC2247
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 ) )
# This class has in RFC1274 two attributes postalAttributeSet and
# telecomunicationAttributeSet that we did not have. We let them out
# for now. Netscape does not have them either.
objectclass ( 0.9.2342.19200300.100.4.14 NAME 'RFC822localPart' SUP domain
MAY ( cn $ sn $ description $ seeAlso $ telephonenumber ) )
# Another wonderful inconsistency. This objectclass has little
# relationship to the way it was defined in RFC1274, that was derived
# from domain, adding ARecord, MDRecord, MXRecord, NSRecord, SOARecord
# and CNAMERecord attribute types of syntax DNSRecordSyntax. On the
# other hand, we had dNSRecord and Netscape has it too. The OID for
# dNSRecord is the one used in RFC1274 for ARecord. Netscape also has
# a manager attribute type here that we did not. It seems a mistake
# and we do not include it.
objectclass ( 0.9.2342.19200300.100.4.15 NAME 'dNSDomain' SUP 'domain'
MAY dnsrecord )
objectclass ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject'
SUP 'top' MUST associatedDomain )
# Well, first notice we (and Netscape) were using co as short for
# friendlyCountryName
objectclass ( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry' SUP country
MUST co )
objectclass ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'
SUP top MUST userPassword )
# Nice test case of class with two superiors. Netscape does not give
# OID for this objectclass and gives top as its superior. We use the
# OID given in RFC1274
objectclass ( 0.9.2342.19200300.100.4.20 NAME 'pilotOrganization'
SUP ( organization $ organizationalUnit ) MAY buildingName )
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment