From 053251ee8818b41fb975efa62a07fe66255348bc Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Wed, 9 Jan 2002 00:19:20 +0000 Subject: [PATCH] Bring nadf back from attic, but note that it is obsolete --- servers/slapd/schema/README | 3 +- servers/slapd/schema/nadf.schema | 178 +++++++++++++++++++++++++++++++ 2 files changed, 180 insertions(+), 1 deletion(-) create mode 100644 servers/slapd/schema/nadf.schema diff --git a/servers/slapd/schema/README b/servers/slapd/schema/README index 9e425955c6..0b5e3c35b6 100644 --- a/servers/slapd/schema/README +++ b/servers/slapd/schema/README @@ -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 . diff --git a/servers/slapd/schema/nadf.schema b/servers/slapd/schema/nadf.schema new file mode 100644 index 0000000000..98fe9a41e5 --- /dev/null +++ b/servers/slapd/schema/nadf.schema @@ -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. -- 2.39.5