Reply to still on omittedORAddressComponent

Kevin Jordan <> Thu, 27 April 1995 22:30 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa12471; 27 Apr 95 18:30 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12467; 27 Apr 95 18:30 EDT
Received: from by CNRI.Reston.VA.US id aa16802; 27 Apr 95 18:30 EDT
Received: by; Thu, 27 Apr 95 17:00:49 -0500
X-From: Thu Apr 27 17:00 CDT 1995
Received: from localhost by; Thu, 27 Apr 95 17:00:47 -0500
To: Peter Cowen <>
Subject: Reply to still on omittedORAddressComponent
In-reply-to: Your message of "Thu, 27 Apr 95 16:59:18 BST" <>
Date: Thu, 27 Apr 95 17:00:46 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Kevin Jordan <>
Message-Id: <>

> However section 2 in the document states that the mechanism is "for
> use only within the X.400 to RFC 822 subtree ?
> But in that subtree you have the full OR address hence you know whats
> missing.
> Can someone explain the use of ommittedORAddressComponent ?
> I think an example using an ommittedORAddressComponent would be of us
> in the document ?

The main purpose of this object class is to accommodate X.400 to 822 mapping
rules such as:


In these cases, there would be no mHSOU entries registered in the directory
below the PRMD level, but the mapping rule demands that any OU's present
in an address be prefaced to the base RFC822 domain specified.  Therefore,
a placeholder entry is needed in the directory to represent the intentionally
missing O component specified in the mapping rule.  The
ommittedORAddressComponent class satisfies this need.  Without it, there
would not be a way to define X.500-based mapping rules such as the ones above.
It would be necessary to register explicitly all OU's directly under their
immediately superior PRMDs.