Subject: I-D ACTION:draft-ietf-ldapbis-models-01.txt

From: [email-masked]
Date: Thu, 30 May 2002 07:27:48 -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		: LDAP: Directory Information Models
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-ldapbis-models-01.txt
	Pages		: 46
	Date		: 29-May-02
	
The Lightweight Directory Access Protocol (LDAP) is an Internet
protocol for accessing distributed directory services which act in
accordance with X.500 data and service models.  This document
describes the X.500 Directory Information Models.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-models-01.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-models-01.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: Thu, 30 May 2002 07:47:27 -0700

Summary of technical changes made:
  - Common ABNF flushed out to cover productions common to
    the whole TS, not just this I-D;
  - ABNFs were scrubbed, minor bugs fixed;
  - Added description of alias entries (adapted from X.501);
  - removed mention of ;binary and other transfer options;
  - clarified schema publishing / discovery;
  - IANA Considerations section added;
  - Changes since appendix updated (more work needed);
  - numerous editorial changes.

Kurt
        
At 04:27 AM 2002-05-30, you wrote:
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-ldapbis-models-01.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ldapbis-models-01.txt>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 30 May 2002 22:36:30 -0700

>  - clarified schema publishing / discovery;

A little elaboration...

This revision includes clarifications aimed at resolving a
couple of subschema discovery issues.

Over the years, a number of questions have been raised
regarding how clients determine that a server supports
capabilities associated with elements of schema, in
particular, operational attributes.  For example, how
does a client determine whether a server supports
DIT Content Rules.

I've taken statements in Section 4.1.4 of RFC 2251 that
the attributeTypes attribute is used to indicate "support"
for an attribute type.  In -00 revision of the I-D, a
server indicated support for a number of capabilities
(such as DIT Content Rules) by publishing the definition(s)
of attribute type(s) associated with the capability.

But for this to be a clear indication of support, it is
necessary to disallow servers which don't support the feature
from publishing the defintions associated with that feature.
Hence, the -01 revision includes the statement:

   A server SHALL only publish schema definitions for
   elements it supports.

Without this, the discovery mechanism would be fundamentally
broken.

However, the added statement can be viewed as inconsistent
with other statements made in existing "core" technical
specification.  So, it might be appropriate to clarify
that the subschema mechanism is not capability discovery
mechanism.  If so, do we need one or can we live with
trial and error discovery mechanism?  (Personally, I can
live with trail and error, that's what most clients will
do anyways.)