Subject: I-D ACTION:draft-ietf-ldapext-ldap-java-api-06.txt

From: [email-masked]
Date: Mon, 23 Aug 1999 07:02:27 -0400

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

	Title		: The Java LDAP Application Program Interface
	Author(s)	: R. Weltman, C. Tomlinson, T. Howes, M. Smith
	Filename	: draft-ietf-ldapext-ldap-java-api-06.txt
	Pages		: 87
	Date		: 20-Aug-99
	
This document defines a java language application program interface
to the lightweight directory access protocol (LDAP), in the form of a
class library. It compliments but does not replace RFC 1823 ([8]),
which describes a C language application program interface. It
updates and replaces Draft draft-ietf-ldapext-ldap-java-api-05.txt
[12], in correcting a few minor errors which are listed in appendix
B.
The companion document draft-ietf-ldapext-ldap-java-api-asynch-ext-
01.txt [13] defines the mandatory to implement asynchronous layer of
the API.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldap-java-api-06.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-ldapext-ldap-java-api-06.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-ldapext-ldap-java-api-06.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: "Manish Gupta" <[email-masked]>
Date: Mon, 23 Aug 1999 16:57:09 -0700

One of my collegaues just came across the following schema extension
restrictions placed by AD.

From "Extending the Schema" document:

"You cannot add a new mustContain to a class (directly or through
inheritance by adding an auxiliary class)"

Thus, I am unable to extend AD to accomodate the schema proposed in
draft-ryan-java-schema-01.rev.txt. The javaObject abstract class has the
mustContain attribute javaClassName and all aux classes such as
javaSerializedObject, etc. are derived from javaObject.

In this case I tend to think Microsoft has gotten it right. I dont very much
like the concept of mustContain attributes in aux. classes.

Comments?

Manish Gupta

---

From: Vincent Ryan <[email-masked]>
Date: Tue, 24 Aug 1999 11:38:05 +0100

> Manish Gupta wrote:
> draft-ryan-java-schema-01.rev.txt. The javaObject abstract class has
> the mustContain attribute javaClassName and all aux classes such as
> In this case I tend to think Microsoft has gotten it right. I dont
> very much like the concept of mustContain attributes in aux. classes.
> 
> Comments?
> 
> Manish Gupta

LDAP follows the X.500 data model and that model permits
mandatory and optional attributes to be defined for auxiliary
object classes. Several such classes are defined in RFC-2256:
strongAuthenticationUser, certificationAuthority.

BTW I notice that the AD schema already defines an auxiliary
object class called 'mailRecipient' which contains a mandatory
'cn' attribute.

---

From: "Manish Gupta" <[email-masked]>
Date: Tue, 24 Aug 1999 09:56:16 -0700

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Vincent Ryan
Sent: Tuesday, August 24, 1999 3:38 AM
To: Manish Gupta
Cc: [email-masked]
Subject: Re: Schema for Java objects and AD
(draft-ryan-java-schema-01.rev.txt)

[Manish] That is correct. Unfortunately, AD forces you to define the
association between an auxiliary class and a structural class apriori. When
we tried to associate the javaSerialiazedObject with the javaContainer the
request was rejected by the DS. It worked fine when we changed the
mustContain attributes to mayContain. So, my question is how do we proceed
forward since we do need to support AD as well?

Manish

---

From: Bruce Greenblatt <[email-masked]>
Date: Wed, 25 Aug 1999 08:44:35 -0700

At 09:56 AM 8/24/99 -0700, Manish Gupta wrote:
>It worked fine when we
>changed the  mustContain attributes to mayContain. So, my  question is how
>do we proceed forward since we do need to support AD as  well? Manish   

I think that you've answered the question yourself.  Since Microsoft does
not currently support auxiliary class definitions that have mandatory
attributes, you must modify the definitions so that those attributes are
optional before extending the Microsoft schema.  Thus, your application
should enforce the real schema since Microsoft's implementation won't do
this work for you.

Bruce
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

---

From: Vincent Ryan <[email-masked]>
Date: Wed, 25 Aug 1999 18:37:33 +0100

> association between an auxiliary class and a structural class apriori.
> When we tried to associate the javaSerialiazedObject with the
> javaContainer the request was rejected by the DS. It worked fine when
> we changed the mustContain attributes to mayContain. So, my question
> is how do we proceed forward since we do need to support AD as well?

This seems to be a significant limitation in Active Directory.
Its schema restriction conflicts with what is permitted by the
LDAP standards.

Perhaps someone from Microsoft could shed some light on this.