RE: LDIF last call

["Salter, Thomas A" <Thomas.Salter@unisys.com>]

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
 >