# $OpenLDAP$ # These are definitions from the North American Directory Forum # They were taken from ftp://ftp.gte.com/pub/nadf/nadf-docs/sd-04.ps # Our thanks to Harald T. Alvestrand that provided the pointer. # Some attribute types and object classes defined in the spec # and that we did not have are not included in this file. # 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 AUXILIARY. # 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 AUXILIARY 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.