Re: LDIF last call

[Jim Sermersheim <JIMSE@novell.com>]

I like your first approach as long as schema and entries both exist in the LDIF file.  It uses existing operational attributes to convey the intent and doesn't add to the LDIF BNF.

In the case where an LDIF file contains *only* schema information, I like what Mark Wahl suggested.
<<From Mark's message
dn: 
changetype modify
add: subschemaSubentry
subschemaSubentry: cn=appl-specific subschema, ***YOUR DN HERE***


dn: cn=appl-specific subschema, ***YOUR DN HERE***
changetype: add
..
>>

As long as it's acceptable for the importing server to interpret this information, a server that uses a single directory-wide schema could look at this file and apply the correct schema modifications (as opposed to adds, as the LDIF file specifies).

I've been ignorant of the SCHEMA WG and the draft Mark Wahl pointed out.  Perhaps I should be look there and try to push people to use that rather than LDIF when transferring schema.

Jim


>>> Gordon Good <ggood@netscape.com> 2/19/99 11:14:21 AM >>>
...
Approach 1) Associate an entry with its schema via the
"subschemasubentry" attribute. For example, an LDIF file exported from a
server with a single, server-wide schema might contain a schema
definition with the DN "cn=schema". Each entry in the LDIF file would
contain the attribute:

subschemasubentry: cn=schema

It's up to the importing server to do the right thing with the schema.

Another server that supports multiple schemas per server might export
two schema definitions, as subentries within the appropriate tree. For
example, if the LDIF file contains two subtrees "o=foo.com" and
"o=bar.com", each with distinct schemas, there might be two schema
entries named "cn=schema, o=foo.com" and "cn=schema, o=bar.com". All of
the entries within "o=foo.com" would contain the attribute:

subschemasubentry: cn=schema, o=foo.com

and all of the entries within "o=bar.com" would contain the attribute:

subschemasubentry: cn=schema, o=bar.com

Again, it's up to the importing server to decide what to do about this.
Some servers, like umich-derived servers, would not be able to import
this LDIF file.

The advantage of this approach is that it doesn't require any changes to
the LDIF BNF, and the semantics are already specified in RFC 2252.

Approach 2) Divide the LDIF file into sections, with an optional header
section describing the schema in effect for that section. I'm not in
favor of this approach because it isn't backwards-compatible with
existing LDIF. It also violates the principle of keeping LDIF close to
DITs and LDAP operations.


-- 
Gordon Good                          (opinions expressed here are mine, 
Netscape Communications Corp.         not necessarily my employer's)
Mountain View, CA