[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Schema for Java objects and AD (draft-ryan-java-schema-01.rev.txt)



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


> Manish Gupta wrote:
>
> 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

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.

[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