User Schema comments

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Editorial and technical issues (with suggestions) are raised in-line.

>From <draft-ietf-ldapbis-user-schema-00> [TRIMMED]:
>   A Summary of the X.500(3rd edition) User Schema for use with LDAPv3
>
>Abstract
>
>   This document provides an overview of the attribute types and object
>   classes defined by the ISO/IEC JTC1 and ITU-T committees in the 
>   IS0/IEC 9594 and X.500 documents,

I note this document also describes some LDAP syntaxes as well
as some matching rules.

>	in particular those intended for use by directory clients.

Aren't all directory attribute intended to be used by some
directory client?

I would suggest:
	..., in particular user application schema.

>   This is the most widely used schema for 
>   LDAP/X.500 directories, and many other schema definitions for white 
>   pages objects use it as a basis.  This document does not cover 
>   attributes used for the administration of X.500 directory servers, 
>   nor does it include attributes defined by other ISO/ITU-T documents.
>
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in RFC 2119 [6].
>

I suggest the above not be placed under the Abstract header,
but a "Conventions" header.  Or, a new brief Abstract be added
and the current abstract be turned into an "Introduction" or
"Overview" section.

>
>1. General Issues
>
>   This document references syntaxes given in section 4 of this 
>   document and section 6 of [1].  Matching rules are listed in 
>   section 6 of this document and section 8 of [1].
>
>   The attribute type and object class definitions are written using the
>   BNF form of AttributeTypeDescription and ObjectClassDescription given
>   in [1].

Same for syntaxes and matching rules.



>3. Attribute Types
>
>   Two kinds of attribute types are contained in this section:  ones 
>   for holding user information and others which have been superseded 
>   or withdrawn.

It might be appropriate for this I-D not to include specifications
of superceded or withdrawn schema elements.  I note that the
specifications are still available in rfc2256 which this I-D will
itself supercede.


>3.1  "MUST" Attribute Types

I would suggest use of REQUIRED above instead of "MUST".

>   An LDAP server implementation MUST recognize the attribute types
>   described in this section.
>
>3.1.1  objectClass
>
>   The values of the objectClass attribute describe the kind of object
>   which an entry represents.  The objectClass attribute is present in
>   every entry.  
>
>
>
>
>    ( 2.5.4.0 NAME 'objectClass' 
>      EQUALITY objectIdentifierMatch
>      SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

I believe this attribute description should be moved to RFC 2252bis I-D.
While its usage is userApplications, it's actually an operational
attribute (in the sense the server makes use of it).  This fact should
be noted in the description.


>3.2  "SHOULD" Attribute Types

I would suggest use of RECOMMENDED above instead of "SHOULD".

>   An LDAP server implementation SHOULD recognize the attribute types
>   described in this section.

I suggest the attributes be described in alphabetical order.


>5.  Object Classes
>
>   LDAP servers MUST recognize the object class "top".  LDAP servers 
>   SHOULD recognize all the other object classes listed here as values 
>   of the objectClass attribute.

I note this section needs to be flushed out with short descriptions
of each object class.  I also note that it should be presented in
a manner similar to that of attribute types.

>8.  Acknowledgements
>
>   The definitions, on which this document is based, have been developed
>   by committees for telecommunications and international standards.  
>   No new attribute definitions have been added.  
>
>   This document is an update of RFC 2256 by Mark Wahl.  RFC 2256 was a
>   product of the IETF LDAPBIS Working Group.

RFC 2256 was a product of the IETF ASID Working Group.