Subject: I-D ACTION:draft-ietf-ldapbis-user-schema-00.txt

From: [email-masked]
Date: Mon, 09 Apr 2001 06:50:03 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the LDAP (v3) Revision Working Group of the IETF.

	Title		: A Summary of the X.500(3rd edition) User Schema for 
                          use with LDAPv3
	Author(s)	: K. Dally
	Filename	: draft-ietf-ldapbis-user-schema-00.txt
	Pages		: 24
	Date		: 06-Apr-01
	
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, in particular those intended for 
use by directory clients.  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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-user-schema-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ldapbis-user-schema-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ldapbis-user-schema-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 13 Apr 2001 13:03:41 -0700

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
>
>   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 
>   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.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 16 Apr 2001 16:47:32 -0700

RFC 2253 says 'dc' and 'uid' needs to be recognized by LDAP
implementations which are described in RFC 1274 (and 2247).

Like other information we need to extract from RFC 1274, I
suggest we incorporate the specification of 'dc' and 'uid'
directly into the User Schema I-D.  I note that RFC 2247,
Section 4, provides an updated specification of 'dc'.  Also,
RFC 2798 provides an LDAPv3 attribute type description for
'uid'.

Please note this is not a call to suck in all of RFC 1274
defined schema, but only that schema which the LDAPv3 TS
relies on.

Comments?

Kurt

---

From: Kathy Dally <[email-masked]>
Date: Tue, 17 Apr 2001 15:22:24 -0400

Hi Kurt!

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

Regards,
Kathy Dally

> I note this document also describes some LDAP syntaxes as well
kld:  My proposal is to move all of the syntaxes and matching rules to
2252bis.

>         ..., 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.
> and the current abstract be turned into an "Introduction" or
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.
> Same for syntaxes and matching rules.
kld:  Only if the syntaxes and matching rules are not moved to 2252bis.
> specifications are still available in rfc2256 which this I-D will
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.

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

> 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.
> I would suggest use of RECOMMENDED above instead of "SHOULD".
kld:  Yes.
> I suggest the attributes be described in alphabetical order.
kld:  OK!
> a manner similar to that of attribute types.
kld:  Yes.
> RFC 2256 was a product of the IETF ASID Working Group.
kld:  Oops!  Thanks for the catch.

---

From: [email-masked] (Mark C Smith)
Date: Thu, 19 Apr 2001 11:32:14 -0400

> defined schema, but only that schema which the LDAPv3 TS

I agree -- we should include the essential schema in a core LDAPv3
document such as the User Schema one.

-- 
Mark Smith
Directory Product Development / Netscape

---

From: [email-masked] (Mark C Smith)
Date: Thu, 19 Apr 2001 11:32:14 -0400