[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: LDIF last call
1. Yet another problem is that RFC2251 does not require servers to allow
modification of subschema entries. The relevant phrase from 3.2.2 is:
" ... MUST implement and provide access to these subschema entries, so that
its clients may discover the attributes and object classes which are
permitted to be present. "
with the emphasis on "may discover".
2. An additional requirement on reading the subschema entry is:
Clients MUST only retrieve attributes from a subschema entry by
requesting a base object search of the entry, where the search filter
is "(objectClass=subschema)".
The result of these conditions is that servers can do a one-way mapping from
some other internal representation of schema information onto that required
by Ldap V3.
> -----Original Message-----
> From: Jim Sermersheim [mailto:JIMSE@novell.com]
> Sent: Thursday, February 18, 1999 9:02 PM
> To: ggood@netscape.com; ietf-ldapext@netscape.com
> Subject: Re: LDIF last call
>
>
> I've noticed people using LDIF files to describe schema
> (I'll paste an excerpt). The problem I see is that they
> assume an entry called cn=schema holds the schema
> information. I guess this is fine as long as they know the
> directory using the file has been set up this way. I
> believe the proper way to modify the schema is to look at
> the subschemaSubentry operational attribute in the root DSE
> and use the dn listed there.
>
> Of course this programmatic behavior isn't available through
> an LDIF file. Do we live with this, and (a) hope that users
> of LDIF files check and possibly modify the dn which points
> to the schema entry, or (b) hope that all directories
> converge on the use of cn=schema as the dn of their schema entry?
>
> Or... should there be an optional keyword which means
> "schema entry"? Something like this would work:
> dn-spec = ("dn:" *SPACE dn) / ("dn::" *SPACE
> base64-dn) / "schemaentry"
>
> Hmm, not really a dn anymore. Also, this makes certain
> assumptions about there being only one schema entry. Any ideas?
>
> -- pasted excerpt --
> dn: cn=schema
> changetype: modify
> add: attributetypes
> attributetypes: ( 1.3.114.7.4.2.0.27 NAME
> 'fw1ISAKMP-DataEncMethod' SYNTAX '1.3.6.1.4.1.1466.115.121.1.26' )
>
> dn: cn=schema
> changetype: modify
> add: attributetypes
> attributetypes: ( 1.3.114.7.4.2.0.28 NAME 'fw1enc-methods'
> SYNTAX '1.3.6.1.4.1.1466.115.121.1.26' )
>
> dn: cn=schema
> changetype: modify
> add: objectclasses
> objectclasses: ( 1.3.114.7.3.2.0.1 NAME 'fw1template' DESC
> 'FireWall-1 Template' SUP 'top' MUST ( cn ) MAY (
> description $ fw1auth-method $ fw1auth-server $
> fw1pwdlastmod $ fw1skey-number $ fw1skey-seed $
> fw1skey-passwd $ fw1skey-mdm $ fw1expiration-date $
> fw1hour-range-from $ fw1hour-range-to $ fw1day $
> fw1allowed-src $ fw1allowed-dst $ fw1allowed-vlan $
> fw1SR-keym $ fw1SR-datam $ fw1SR-mdm $ fw1enc-fwz-expiration
> $ fw1exception-track $ fw1grouptemplate $
> fw1ISAKMP-EncMethod $ fw1ISAKMP-AuthMethods $
> fw1ISAKMP-HashMethods $ fw1ISAKMP-Transform $
> fw1ISAKMP-DataIntegrityMethod $ fw1ISAKMP-SharedSecret $
> fw1ISAKMP-DataEncMethod $ fw1enc-methods ) )
>
>
>
> >>> Gordon Good <ggood@netscape.com> 2/3/99 3:35:00 PM >>>
> Greetings. Now that the LDIF (LDAP Data Interchange Format) draft has
> been out for a while, I'd like to move it forward as a
> standards-track
> document. Although it's not an LDAPEXT document, I think most of the
> people who would be interested in providing review comments
> subscribe to
> this list.
>
> I'd like to propose starting last call on Monday, 8 February, with a
> review period of two weeks. On 22 February, I'll incorporate any
> comments and submit the document as a proposed standard.
>
> Thanks,
>
> -Gordon
>
> --
> Gordon Good (opinions expressed
> here are mine,
> Netscape Communications Corp. not necessarily my employer's)
> Mountain View, CA
>