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

From: [email-masked]
Date: Tue, 15 Feb 2005 10:33:50 -0500

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-13.txt
	Pages		: 51
	Date		: 2005-2-14
	
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, as used in LDAP.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-13.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-13.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: Tue, 15 Feb 2005 12:27:13 -0800

It is hoped that this revision adequately addresses comments
received during IESG review.  In particular, the following change
was made to clarify the relationship to ITU recommendations and
the applicability of LDAP-specific adaptations:

 This document includes material, with and without adaptation, from
-[X.501].  The material in this document takes precedence over that
-in [X.501].
+[X.501] as necessary to describe this protocol.  These adaptations
+(and any other differences herein) apply to this protocol, and only
+this protocol.

I see a few minor issues need to be resolved prior to further
IESG consideration.
  1) incorporation of 'supportedFeatures' [RFC3674],
  2) addition of statement regarding properties (commutative, etc.)
     which equality matching rules should have,
  3) addition of statement that each value must be equal
     (or equivalent) to itself to be included in a set of
     attribute values, and
  4) clarifications of matchingRuleUse 'APPLIES'.

I intend to offer specific text in 1-3 later today, and will
work with Jim on 4.

Kurt

At 07:33 AM 2/15/2005, [email-masked] wrote:
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-ldapbis-models-13.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ldapbis-models-13.txt>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 16 Feb 2005 12:45:59 -0800

To incorporate of 'supportedFeatures' [RFC3674] into [Models],
I suggest adding the following text:

        5.1.X. 'supportedFeatures'

        The 'supportedFeatures' attribute lists object identifiers
        identifying elective features which the server supports.  If
        the server does not support any discoverable elective features,
        this attribute will be absent.

            ( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures'
                EQUALITY objectIdentifierMatch
                SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
                USAGE dSAOperation )

        Procedures for registering object identifiers used to discovery
        of protocol mechanisms are detailed in BCP 64 [BCP64bis].

        The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and
        objectIdentifierMatch matching rule are defined in [Syntaxes].

as well as adding 'supportedFeatures' to section 5.1 bullet
list of root DSE attribute.  Additionally, it would be noted
that [Models] obsoletes [RFC3674] in header and Section 1.1.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 16 Feb 2005 13:21:14 -0800

I suggest adding the following statement to section 2.2 of
[Models] (just before its last paragraph):

  Additionally, no attribute is to have a value which is not
  equivalent to itself.  For example, the 'givenName' attribute
  cannot have as a value a directory string which includes the
  REPLACEMENT CHARACTER (U+FFFD) code point as matching involving
  that directory string is Undefined per this
  attribute's equality matching rule.

-- Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 16 Feb 2005 14:23:37 -0800

I think that replacing the first sentence of 4.1.4 with
the following adequately clarifies the matter as far as
[Models] is concerned.
 
  A matching rule use lists the attribute types which are
  suitable for use with an extensibleMatch search filter.

I see no reason replace "types and their subtypes" here
as these subtypes are themselves suitable types and
would might actually cause confusion.  That is, if
both 'name' and 'cn' where listed, one might think
'cn' was listed not because it was suitable but because
it was a subtype.

In [Protocol], I suggest replacing 
   - If the type field is absent and the matchingRule is present, the
     matchValue is compared against all attributes in an entry which
     support that matchingRule.
with:
   - If the type field is absent and the matchingRule is present, the
     matchingValue is compared against all attributes in an entry
     which the matchingRule applies to.

- Kurt