Re: LDAP subentry schema request for last call - Further

["Ed Reed" <eer@OnCallDBA.COM>]

After further reviewing the minutes from Australia, the LDUP meeting minutes
called for a discussion on use of Auxilliary classes with LDAPsubentry in favor of deriving 
new classes from LDAPsubentry, as a general rule, and the LDUP minutes asked that the document
be revised to include that advisory direction to readers.  However, it was noted there that naming
is an issue again, when AUX classes don't resolve.

The draft on the web site doesn't address this.

Section 3.1 begins with the following statement:

"The class ldapSubEntry is intended to be used as a super 
class when defining other structural classes to be used as 
LDAP Subentries.  The presence of ldapSubEntry in the list 
of super-classes of an entry in the directory makes that 
entry an LDAP Subentry.  Object classes derived from 
ldapSubEntry are themselves considered ldapSubEntry 
classes, for the purpose of this discussion."

We could elaborate on the request, here, such as...

"The class ldapSubEntry is intended to be used as a super-
class when defining other structural classes to be used
as LDAP Subentries, and as the structural class to which
Auxilliary classes may be added for application specific
subentry information.  Where possible, the use of Auxilliary
classes to extend ldapSubEntries is strongly preferred.

The presence of ldapSubEntry in the list..."

I think that would leave the naming issue (not using cn
to name the subentry) as an excersize for the Auxilliary
class definer, which might be a cruel booby-prize...but if
Kurt and others find it acceptible, fine.

I'm sorry I found this note in the minutes after I'd already
said the doc was ready to go to last call.  I'll make the change,
as described here in the version that goes to the RFC editor.
Does that work?

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065
http://www.Reed-Matthews.COM

>>> "Ed Reed" <eer@OnCallDBA.COM> 07/13/00 09:55AM >>>
After reviewing the recent comments on LDAPsubentry (and posting my reply), and reviewing where the March 9 version of the doc (as posted on the LDUP wg web site) stands with regard to MUST/MAY (cn) and naming, I think the document, as published, should go forward for last call.

With regard to naming, the doc says LDAPsubentry MAY be named by cn, which is where I think the concensus of the list now resides.

With regard to MUST/MAY {cn} as an attribute, the document now says MAY, and leaves the class as a STRUCTURAL class.  Of course, that means that a naming rule will need to use CN as it's naming attribute if no other attributes are defined on the class, which pretty much turns it into a MUST in those cases, but when other classes are derived from LDAPsubentry other attributes may also be defined, and then cn need not be used as a naming attribute.  I think we could also make it be MUST {cn} and require cns to be populated, even if they're not being used to name the LDAPsubentry, and I'll be happy to make that change after last call if needed.  I just don't see the need to bother, now.

With regard to making LDAPsubentry fully compatible with the X.500 subentry, it's been pointed out that people wanting to use the X.500 subentry should feel free to do so - it's incorporated by reference in the base LDAP definitions.  The purpose of this proposal is to define a subset of the X.500 functionality (and extend the structural rules by allowing nesting of LDAPsubentries) for use by certain LDAP applications which find the subset functionality a useful simplification.

So - Please, put out the last call for the draft as posted on the LDUP WG IETF Charter page, document draft-ietf-ldup-subentry-02.txt, dated 9 March 2000.

Ed


=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065
http://www.Reed-Matthews.COM