[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: commit: ldap/servers/slapd schemaparse.c


"Kurt D. Zeilenga" wrote:

> Can you provide a list of items missing OIDs?  I am sure we
> can hunt down OIDs for these items.

Alright, let me see if I find all of them.  Anyway, we still have
the problem of local definitions.  Many commercial products
permit creating local definitions without an OID allocation, because
for most, if not all, purposes in LDAP they are unnecessary.
Not providing a way out will create pressure towards extending the
syntax accepted by the old format definitions (since for
compatibility reasons those do not require an OID).

Since I have gone through all the new format schemas, I have also noted
a few cases where we are diverging from the definition.  In most cases,
this is due to missing matching rule definitions.  In some of these
cases I could pick up the definition from X.5xx, in other cases the
author made up a matching rule name out of thin air or maybe meant
something different.  It is also perfectly possible that I have missed
the definition and it was there all the time.  In other cases, the
definitions were originally in ASN.1 (but in the old syntax where
matching rules were not there) and support for the original definition
semantics required matching rules that were unknown.  Anyone who can
shed any light on any of the following definitions is welcome to do so.

OK, here I go.

***** Problems in core.schema:

# Show stopper: we don't have the definition of caseIgnoreListSubstringsMatch
#attribute ( 2.5.4.16 NAME 'postalAddress' EQUALITY caseIgnoreListMatch
#     SUBSTR caseIgnoreListSubstringsMatch
#     SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )

[I.e. that matching rule is unknown or was unkown when I wrote that.]

#
# LDAPsubEntry
#	OID not assigned (1.3.6.1.4.1.1466.115.121.1.??)
#
objectclass ( NAME 'LDAPsubEntry'
	DESC 'Limited X.501 Subentry class, named by cn'
	SUP top STRUCTURAL MUST ( cn ) )

***** Problems in misc.schema:

#objectclass ( 2.16.840.1.113730.3.2.[[TBD]] NAME 'inetLocalMailRecipient'
#	SUP top AUXILIARY
#	MAY	( mail $ mailAlternateAddress $ mailHost $ mailRoutingAddress )

***** Problems in nis.schema:

# TBC: caseIgnoreIA5SubstringsMatch is not defined

attribute ( 1.3.6.1.1.1.1.2 NAME 'gecos'
	DESC 'The GECOS field; the common name'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

[I.e. the SUBSTR matching rule in RFC2307 could not be used since
it is not defined.  Same goes for a few others.]

# TBC: caseIgnoreIA5SubstringsMatch is not defined

attribute ( 1.3.6.1.1.1.1.12 NAME 'memberUid'
	EQUALITY caseExactIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# TBC: caseIgnoreIA5SubstringsMatch is not defined

attribute ( 1.3.6.1.1.1.1.13 NAME 'memberNisNetgroup'
	EQUALITY caseExactIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# TBC: caseIgnoreIA5SubstringsMatch is not defined

attribute ( 1.3.6.1.1.1.1.27 NAME 'nisMapEntry'
	EQUALITY caseExactIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{1024} SINGLE-VALUE )

***** Problems in pilot.schema:

[The following two paragraphs at the top of the file summarize
the situation.]

# 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.

[Then there should be some uses of caseIgnoreIA5SubstringsMatch and
caseIgnoreListSubstringsMatch, that are not known.  I do not detail
them.]

# 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.

attribute ( abstract-oid NAME 'abstract'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attribute ( authorcn-oid NAME ( 'documentAuthorCommonName' 'authorCn' )
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attribute ( authorsn-oid NAME ( 'documentAuthorSurname' 'authorSn' )
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attribute ( documentStore-oid NAME 'documentStore'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attribute ( keyWords-oid NAME 'keyWords'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attribute ( obsoletedByDocument-oid NAME 'obsoletedByDocument'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

attribute ( obsoletesDocument-oid NAME 'obsoletesDocument'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

attribute ( subject-oid NAME 'subject'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

attribute ( updatedByDocument-oid NAME 'updatedByDocument'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

attribute ( updatesDocument-oid NAME 'updatesDocument'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

Well, I think that's what I have found with a quick scan.

Julio