# $OpenLDAP$ # 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 )