Reply to Representing O/R Address in Directory

Kevin Jordan <> Tue, 07 March 1995 15:45 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa06090; 7 Mar 95 10:45 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06086; 7 Mar 95 10:45 EST
Received: from by CNRI.Reston.VA.US id aa07597; 7 Mar 95 10:45 EST
Received: by; Tue, 7 Mar 95 09:44:35 -0600
X-From: Tue Mar 7 09:44 CST 1995
Received: from localhost by; Tue, 7 Mar 95 09:44:12 -0600
To: Vicki Cox <>
Subject: Reply to Representing O/R Address in Directory
In-reply-to: Your message of "Wed, 01 Mar 95 14:32:08 +0500" <>
Date: Tue, 07 Mar 95 09:44:10 -0600
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Kevin Jordan <>
Message-Id: <>

> We (representing DoD) would like the IETF X.500 directory to be the
> repository for several types of information.  This particular request is for
> changes to the O/R address portion of the schema.   We were planning on
> sending the following template to the X.500 Schema Working Group at
>  Seeking some guidance, we asked Tim Howes of the
> X.500 Schema group for his opinion of our template.  He responded by saying
> he that we were attempting to redefine existing schema elements.   One
> recommendation he suggested was to work with the mhs-ds group to get the
> definintions changed.

The Internet Draft which specifies the parts of the schema for which you are
requesting changes is currently being progressed as an Experimental Internet
Standard.  It is too late to make changes to this RFC.  In addition, I'm not
sure how possible/practical it would be to change the existing schema
definitions.  These schema elements are already in use in the Internet DIT,
so many DSA's have already incorporated the associated object class

The changes you are proposing would add some new optional attributes which
would be used for identifying owners of objects, for providing descriptive
strings, etc.  Couldn't you accomplish what you need doing either of the

   1. Define a new object class which includes only your new attributes.
      Create objects in your DIT by combining this object class with
      the appropriate MHS-DS object class.

   2. Define a set of new object classes which are subclasses of the
      MHS-DS object classes.  The schema for this new subclasses would
      include only your new optional attributes, and they would inherit
      O/R address attributes from their respective superclasses.

> Something we did not point out to Mr. Howes and perhaps should have was that
> we have found a few differences in the description of the O/R Address between
> the Network Working Group and the X.500 Schema Working Group.  For example,
> the attributes in the X.500 Schema Working Group schema under the
> mHSOrganisation and mHSOrganisationalUnit (with an s instead of a z)object
> classes are mHS-0 (vice mHSOrganizationName) and mHS-OU (vice
> mHSOrganizationalUnitName). The Object IDs are also different, i.e.
> mhs-ds-tables-oc 5 (vice oc-mhs-organization) and mhs-ds-tables-oc 6(vice
> oc-mhs-organizational-unit).  mHSPerson is also different, etc.  It appears
> that the two WGs seem to be solving the same requirement.  If this is the
> case, has there been any harmonization between the two groups?  Or is our
> assumption incorrect?  This also raises the question, are we sending this
> request to the correct place?

I suspect that the X.500 Schema Working Group was working from old revisions
of the MHS-DS Internet Drafts.  The schema definitions in MHS-DS drafts (soon
to be published as RFC's) are authoritative.