Re: User Schema comments

[Kathy Dally <kdally@mitre.org>]

Hi Kurt!

Thanks for the comments.  Replies are in-line:  "kld".

Regards,
Kathy Dally


"Kurt D. Zeilenga" wrote:
> 
> 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.
kld:  My proposal is to move all of the syntaxes and matching rules to
2252bis.

> 
> >       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.
kld:  Generally, system attributes are not used by clients and are not
in this I-D.        However, I like the proposed change.
> 
> >   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.
kld:  On the first part of this comment, I don't see why this is not
suitable for the       Abstract.  The last paragraph should be moved to
the end of the General Issues       section, IMHO.
> 
> >
> >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.
kld:  Only if the syntaxes and matching rules are not moved to 2252bis.
> 
> >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.
kld:  It is my understanding and view that all of the attributes from
X.520 should be 
      covered.  This is the case in RFC 2256.  However, the status of
each attribute in 
      this section was not highlighted in RFC 2256.  Also, the
teletexTerminalIdentifier 
      attribute is deprecated in the 2000 version of X.520.  Although
this attribute is 
      still useable in the 1993 version, the withdrawal since then of
F.200 means that 
      the attribute syntax is no longer (fully) specified.  In terms of
the implementation 
      report, I think that these attributes should be marked so
implementation of them 
      does not need to be demonstrated.

> 
> >3.1  "MUST" Attribute Types
> 
> I would suggest use of REQUIRED above instead of "MUST".
> 
kld:  Yes.

> >   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.
kld:  In my experience, the user sees the values of the objectClass
attribute and uses 
      them to know the type of the entry.  Otherwise, I do not have a
strong opinion for 
      either document.
> 
> >3.2  "SHOULD" Attribute Types
> 
> I would suggest use of RECOMMENDED above instead of "SHOULD".
kld:  Yes.
> 
> >   An LDAP server implementation SHOULD recognize the attribute types
> >   described in this section.
> 
> I suggest the attributes be described in alphabetical order.
kld:  OK!
> 
> >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.
kld:  Yes.
> 
> >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.
kld:  Oops!  Thanks for the catch.