Peter Cowen <> Thu, 27 April 1995 16:08 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa05136; 27 Apr 95 12:08 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05128; 27 Apr 95 12:08 EDT
Received: from by CNRI.Reston.VA.US id aa08810; 27 Apr 95 12:08 EDT
Received: by; Thu, 27 Apr 95 10:49:43 -0500
X-From: Thu Apr 27 10:49 CDT 1995
Received: from by; Thu, 27 Apr 95 10:49:42 -0500
Received: from by; Thu, 27 Apr 95 10:49:39 -0500
Received: from (actually host by with SMTP (XT-PP); Thu, 27 Apr 1995 16:47:46 +0100
Subject: omittedORAddressComponent
Date: Thu, 27 Apr 1995 16:47:43 +0100
Message-ID: <>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Peter Cowen <>


Re the document "Use of X.500 Directory to support mapping between
X.400 and RFC 822 Addresses" (draft-ietf-mhsds-supmapping-06)

Whats the reasoning behind making an object class out of
omittedORAddressComponent rather having an oRAddressComponentType
attribute as a MAY CONTAIN attribute of rFC822ToX400Mapping object
class ?

If its a way to stay "backwardly compatible" to previous versions of
the mhs-ds documents 

(i.e the object identifier for rFC822ToX400Mapping object class in the
draft-ietf-mhsds-supmapping-06 is the exact same as the object
identifier for that class in the July 1993 version of the document), 

then that backwardly compatibility is broken by the dropping of the
nonAuthoritiveAssociatedORAddress attribute from this class.


P.S. how much trouble is going to occur because of the object class
OID staying the same for different documents where the object class
definitions change between documents ?