3 # These are definitions from the North American Directory Forum
4 # They were taken from ftp://ftp.gte.com/pub/nadf/nadf-docs/sd-04.ps
5 # Our thanks to Harald T. Alvestrand that provided the pointer.
7 # Some attribute types and object classes defined in the spec
8 # and that we did not have are not included in this file.
10 # This is a preliminary version and is likely to be incorrect in
13 # The root for OIDs is joint-iso-ccitt mhs-motis(6) group(6) grimstad(5)
14 # nadf(2). In othor words, barring any error, 2.6.6.5.2. Then,
15 # nadfOink ::= 2.6.6.5.2.0
16 # nadfModule ::= 2.6.6.5.2.1
17 # nadfAttributeType ::= 2.6.6.5.2.4
18 # nadfObjectClass ::= 2.6.6.5.2.6
20 # Attribute Type Definition
22 # The spec says "leading zero is significant". Is this really a
25 attributetype ( 2.6.6.5.2.4.1 NAME 'fipsStateNumericCode'
26 EQUALITY numericStringMatch
27 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{2} )
29 # It is probably inconvenient to give this attribute that syntax
30 # (Printable String) instead of Directory String.
32 attributetype ( 2.6.6.5.2.4.2 NAME 'fipsStateAlphaCode'
33 EQUALITY caseIgnoreMatch
34 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{2} )
36 # The spec says "leading zeros are significant". Is this really a
39 attributetype ( 2.6.6.5.2.4.3 NAME 'fipsCountyNumericCode'
40 EQUALITY numericStringMatch
41 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{5} )
43 # It seems that fips55 is fipsPlaceNumericCode, is this so?
45 # The spec says "leading zeros are significant". Is this really a
48 attributetype ( 2.6.6.5.2.4.4 NAME ( 'fipsPlaceNumericCode' 'fips55' )
49 EQUALITY numericStringMatch
50 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{5} )
52 attributetype ( 2.6.6.5.2.4.5 NAME 'ansiOrgNumericCode'
54 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
56 # Apparently, 'ad' is an alias for 'addmdName'
58 attributetype ( 2.6.6.5.2.4.6 NAME ( 'addmdName' 'ad' )
59 EQUALITY caseIgnoreMatch
60 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
62 # I don't know what syntax to give this. I will use binary for the
65 attributetype ( 2.6.6.5.2.4.7 NAME 'nadfSearchGuide'
66 SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
68 attributetype ( 2.6.6.5.2.4.8 NAME 'supplementaryInformation'
69 EQUALITY caseIgnoreMatch
70 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{76} )
72 attributetype ( 2.6.6.5.2.4.9 NAME 'namingLink'
73 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
75 attributetype ( 2.6.6.5.2.4.10 NAME 'reciprocalNamingLink'
76 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
79 # Numbers 11 to 14 are obsolete
81 # Next one is unused. BTW, this attribute is supposed to be
82 # case-exact match, but we cannot make that match unless we
83 # define the string with IA5 syntax and we don't have a
84 # clear base for this.
86 attributetype ( 2.6.6.5.2.4.15 NAME 'logicalDSAReference'
87 EQUALITY caseIgnoreMatch
88 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
90 attributetype ( 2.6.6.5.2.4.16 NAME 'multiMediaInformation'
91 SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
93 # Number 17, 18 and 19 are EDI-related attributes for the nadfEDIUser
94 # class that we did not have and has been left out below.
98 # According to the intended use described in section 3.3.1 in the spec,
99 # this can only be AUXILIARY.
100 # We had lastModifiedTime as 'allows', but sd-04 has it as MUST.
101 # We did not have multiMediaInformation neither on this class nor
102 # on any of its derived classes.
104 objectclass ( 2.6.6.5.2.6.7 NAME 'nadfObject' SUP top AUXILIARY
105 MUST lastModifiedTime
106 MAY ( multiMediaInformation $ nadfSearchGuide $
107 supplementaryInformation ) )
109 # I think all classes derived from locality should be considered
110 # STRUCTURAL, since locality is.
112 objectclass ( 2.6.6.5.2.6.1 NAME 'usStateOrEquivalent'
113 SUP ( locality $ nadfObject ) STRUCTURAL
114 MUST ( l $ fipsStateNumericCode $ fipsStateAlphaCode $ st ) )
116 objectclass ( 2.6.6.5.2.6.2 NAME 'usPlace'
117 SUP ( locality $ nadfObject ) STRUCTURAL
118 MUST ( l $ fipsPlaceNumericCode ) )
120 objectclass ( 2.6.6.5.2.6.3 NAME 'usCountyOrEquivalent' SUP usPlace STRUCTURAL
121 MUST fipsCountyNumericCode )
123 # applicationEntity is STRUCTURAL, so we will declare this one the same
125 objectclass ( 2.6.6.5.2.6.5 NAME 'nadfApplicationEntity'
126 SUP applicationEntity STRUCTURAL
127 MUST supportedApplicationContext )
129 # Following our heuristic, this one will be STRUCTURAL since organization
130 # is too. We did not have 'o' as 'requires', but if this is really a
131 # subclass of organization, then 'o' becomes MUST by inheritance
133 objectclass ( 2.6.6.5.2.6.6 NAME 'nadfADDMD'
134 SUP ( organization $ nadfObject ) STRUCTURAL
137 # Number 7 is nadfObject described above.
139 # This one quacks like an AUXILIARY object class
141 objectclass ( 2.6.6.5.2.6.8 NAME 'publicObject' SUP top AUXILIARY
144 # And so does this one
146 objectclass ( 2.6.6.5.2.6.9 NAME 'providerObject' SUP top AUXILIARY
147 MUST reciprocalNamingLink )
149 # The spec says number 10 is obsolete
151 # This one also strongly smells like AUXILIARY
153 objectclass ( 2.6.6.5.2.6.11 NAME 'fips55Object' SUP top AUXILIARY
154 MUST fipsPlaceNumericCode
157 # The spec says numbers 12 to 18 are obsolete
159 # Another obviously AUXILIARY class
161 objectclass ( 2.6.6.5.2.6.19 NAME 'nationalObject' SUP top AUXILIARY
166 objectclass ( 2.6.6.5.2.6.20 NAME 'ansiOrgObject' SUP top AUXILIARY
167 MUST ansiOrgNumericCode )
169 # We did not have the next one, but it is innocuous
171 objectclass ( 2.6.6.5.2.6.21 NAME 'caProvinceOrTerritory'
172 SUP ( locality $ nadfObject ) STRUCTURAL
175 # According to the spec, numbers 22, 23 and 24 are obsolete
177 # Number 25 was nadfEDIuser as a subclass of edi-user. Sorry we cannot
178 # deal with this one and we did not have it anyway.