mirror of
https://git.openldap.org/openldap/openldap.git
synced 2025-03-07 14:18:15 +08:00
Bring nadf back from attic, but note that it is obsolete
This commit is contained in:
Kurt Zeilenga
parent
2958cb4dd0
commit
053251ee88
@ -12,9 +12,10 @@ microsoft.ext.schema Microsoft
|
||||
microsoft.schema Microsoft
|
||||
microsoft.std.schema Microsoft
|
||||
misc.schema misc/experimental
|
||||
nadf.schema North American Directory Forum schema
|
||||
nis.schema Network Information Service
|
||||
openldap.schema OpenLDAP Project
|
||||
vendor.schema Vendor Information (RFC 3045) schema
|
||||
vendor.schema Vendor Information (RFC 3045) schema
|
||||
|
||||
Additional "generally useful" schema definitions can be submitted
|
||||
using the OpenLDAP Issue Tracking System <http://www.openldap.org/its/>.
|
||||
|
||||
178
servers/slapd/schema/nadf.schema
Normal file
178
servers/slapd/schema/nadf.schema
Normal file
@ -0,0 +1,178 @@
|
||||
# $OpenLDAP$
|
||||
|
||||
# These are definitions from the North American Directory Forum
|
||||
# They are intended to be used with QUIPU/X.500 not LDAPv3.
|
||||
# Your mileage may vary.
|
||||
|
||||
# They were acquired from ftp://ftp.gte.com/pub/nadf/nadf-docs/sd-04.ps
|
||||
# Our thanks to Harald T. Alvestrand that provided the pointer.
|
||||
|
||||
# This is a preliminary version and is likely to be incorrect in
|
||||
# a number of areas
|
||||
|
||||
# The root for OIDs is joint-iso-ccitt mhs-motis(6) group(6) grimstad(5)
|
||||
# nadf(2). In othor words, barring any error, 2.6.6.5.2. Then,
|
||||
# nadfOink ::= 2.6.6.5.2.0
|
||||
# nadfModule ::= 2.6.6.5.2.1
|
||||
# nadfAttributeType ::= 2.6.6.5.2.4
|
||||
# nadfObjectClass ::= 2.6.6.5.2.6
|
||||
|
||||
# Attribute Type Definition
|
||||
|
||||
# The spec says "leading zero is significant". Is this really a
|
||||
# numeric string?
|
||||
|
||||
attributetype ( 2.6.6.5.2.4.1 NAME 'fipsStateNumericCode'
|
||||
EQUALITY numericStringMatch
|
||||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{2} )
|
||||
|
||||
# It is probably inconvenient to give this attribute that syntax
|
||||
# (Printable String) instead of Directory String.
|
||||
|
||||
attributetype ( 2.6.6.5.2.4.2 NAME 'fipsStateAlphaCode'
|
||||
EQUALITY caseIgnoreMatch
|
||||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{2} )
|
||||
|
||||
# The spec says "leading zeros are significant". Is this really a
|
||||
# numeric string?
|
||||
|
||||
attributetype ( 2.6.6.5.2.4.3 NAME 'fipsCountyNumericCode'
|
||||
EQUALITY numericStringMatch
|
||||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{5} )
|
||||
|
||||
# It seems that fips55 is fipsPlaceNumericCode, is this so?
|
||||
|
||||
# The spec says "leading zeros are significant". Is this really a
|
||||
# numeric string?
|
||||
|
||||
attributetype ( 2.6.6.5.2.4.4 NAME ( 'fipsPlaceNumericCode' 'fips55' )
|
||||
EQUALITY numericStringMatch
|
||||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{5} )
|
||||
|
||||
attributetype ( 2.6.6.5.2.4.5 NAME 'ansiOrgNumericCode'
|
||||
EQUALITY integerMatch
|
||||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
|
||||
|
||||
# Apparently, 'ad' is an alias for 'addmdName'
|
||||
|
||||
attributetype ( 2.6.6.5.2.4.6 NAME ( 'addmdName' 'ad' )
|
||||
EQUALITY caseIgnoreMatch
|
||||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
|
||||
|
||||
# I don't know what syntax to give this. I will use binary for the
|
||||
# time being.
|
||||
|
||||
attributetype ( 2.6.6.5.2.4.7 NAME 'nadfSearchGuide'
|
||||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
|
||||
|
||||
attributetype ( 2.6.6.5.2.4.8 NAME 'supplementaryInformation'
|
||||
EQUALITY caseIgnoreMatch
|
||||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{76} )
|
||||
|
||||
attributetype ( 2.6.6.5.2.4.9 NAME 'namingLink'
|
||||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
|
||||
|
||||
attributetype ( 2.6.6.5.2.4.10 NAME 'reciprocalNamingLink'
|
||||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
|
||||
SINGLE-VALUE )
|
||||
|
||||
# Numbers 11 to 14 are obsolete
|
||||
|
||||
# Next one is unused. BTW, this attribute is supposed to be
|
||||
# case-exact match, but we cannot make that match unless we
|
||||
# define the string with IA5 syntax and we don't have a
|
||||
# clear base for this.
|
||||
|
||||
attributetype ( 2.6.6.5.2.4.15 NAME 'logicalDSAReference'
|
||||
EQUALITY caseIgnoreMatch
|
||||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
|
||||
|
||||
attributetype ( 2.6.6.5.2.4.16 NAME 'multiMediaInformation'
|
||||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
|
||||
|
||||
# Number 17, 18 and 19 are EDI-related attributes for the nadfEDIUser
|
||||
# class that we did not have and has been left out below.
|
||||
|
||||
# Object classes
|
||||
|
||||
# According to the intended use described in section 3.3.1 in the spec,
|
||||
# this can only be ABSTRACT.
|
||||
# We had lastModifiedTime as 'allows', but sd-04 has it as MUST.
|
||||
# We did not have multiMediaInformation neither on this class nor
|
||||
# on any of its derived classes.
|
||||
|
||||
objectclass ( 2.6.6.5.2.6.7 NAME 'nadfObject' SUP top ABSTRACT
|
||||
MUST lastModifiedTime
|
||||
MAY ( multiMediaInformation $ nadfSearchGuide $
|
||||
supplementaryInformation ) )
|
||||
|
||||
# I think all classes derived from locality should be considered
|
||||
# STRUCTURAL, since locality is.
|
||||
|
||||
objectclass ( 2.6.6.5.2.6.1 NAME 'usStateOrEquivalent'
|
||||
SUP ( locality $ nadfObject ) STRUCTURAL
|
||||
MUST ( l $ fipsStateNumericCode $ fipsStateAlphaCode $ st ) )
|
||||
|
||||
objectclass ( 2.6.6.5.2.6.2 NAME 'usPlace'
|
||||
SUP ( locality $ nadfObject ) STRUCTURAL
|
||||
MUST ( l $ fipsPlaceNumericCode ) )
|
||||
|
||||
objectclass ( 2.6.6.5.2.6.3 NAME 'usCountyOrEquivalent' SUP usPlace STRUCTURAL
|
||||
MUST fipsCountyNumericCode )
|
||||
|
||||
# applicationEntity is STRUCTURAL, so we will declare this one the same
|
||||
|
||||
objectclass ( 2.6.6.5.2.6.5 NAME 'nadfApplicationEntity'
|
||||
SUP applicationEntity STRUCTURAL
|
||||
MUST supportedApplicationContext )
|
||||
|
||||
# Following our heuristic, this one will be STRUCTURAL since organization
|
||||
# is too. We did not have 'o' as 'requires', but if this is really a
|
||||
# subclass of organization, then 'o' becomes MUST by inheritance
|
||||
|
||||
objectclass ( 2.6.6.5.2.6.6 NAME 'nadfADDMD'
|
||||
SUP ( organization $ nadfObject ) STRUCTURAL
|
||||
MUST addmdName )
|
||||
|
||||
# Number 7 is nadfObject described above.
|
||||
|
||||
# This one quacks like an AUXILIARY object class
|
||||
|
||||
objectclass ( 2.6.6.5.2.6.8 NAME 'publicObject' SUP top AUXILIARY
|
||||
MUST namingLink )
|
||||
|
||||
# And so does this one
|
||||
|
||||
objectclass ( 2.6.6.5.2.6.9 NAME 'providerObject' SUP top AUXILIARY
|
||||
MUST reciprocalNamingLink )
|
||||
|
||||
# The spec says number 10 is obsolete
|
||||
|
||||
# This one also strongly smells like AUXILIARY
|
||||
|
||||
objectclass ( 2.6.6.5.2.6.11 NAME 'fips55Object' SUP top AUXILIARY
|
||||
MUST fipsPlaceNumericCode
|
||||
MAY st )
|
||||
|
||||
# The spec says numbers 12 to 18 are obsolete
|
||||
|
||||
# Another obviously AUXILIARY class
|
||||
|
||||
objectclass ( 2.6.6.5.2.6.19 NAME 'nationalObject' SUP top AUXILIARY
|
||||
MUST c )
|
||||
|
||||
# So is this one
|
||||
|
||||
objectclass ( 2.6.6.5.2.6.20 NAME 'ansiOrgObject' SUP top AUXILIARY
|
||||
MUST ansiOrgNumericCode )
|
||||
|
||||
# We did not have the next one, but it is innocuous
|
||||
|
||||
objectclass ( 2.6.6.5.2.6.21 NAME 'caProvinceOrTerritory'
|
||||
SUP ( locality $ nadfObject ) STRUCTURAL
|
||||
MUST st )
|
||||
|
||||
# According to the spec, numbers 22, 23 and 24 are obsolete
|
||||
|
||||
# Number 25 was nadfEDIuser as a subclass of edi-user. Sorry we cannot
|
||||
# deal with this one and we did not have it anyway.
|
||||
Loading…
Reference in New Issue
Block a user