[Date Prev][Date Next]
User Schema comments
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
> 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
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 .
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
>1. General Issues
> This document references syntaxes given in section 4 of this
> document and section 6 of . Matching rules are listed in
> section 6 of this document and section 8 of .
> The attribute type and object class definitions are written using the
> BNF form of AttributeTypeDescription and ObjectClassDescription given
> in .
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
>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.
> The values of the objectClass attribute describe the kind of object
> which an entry represents. The objectClass attribute is present in
> every entry.
> ( 18.104.22.168 NAME 'objectClass'
> EQUALITY objectIdentifierMatch
> SYNTAX 22.214.171.124.4.1.14126.96.36.199.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.
> 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.