omittedORAddressComponent
Peter Cowen <p.cowen@nexor.co.uk> Thu, 27 April 1995 16:08 UTC
Received: from ietf.nri.reston.va.us 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 mercury91.udev.cdc.com by CNRI.Reston.VA.US id aa08810; 27 Apr 95 12:08 EDT
Received: by mercury.udev.cdc.com; Thu, 27 Apr 95 10:49:43 -0500
X-From: p.cowen@nexor.co.uk Thu Apr 27 10:49 CDT 1995
Received: from cdsmail.cdc.com by mercury.udev.cdc.com; Thu, 27 Apr 95 10:49:42 -0500
Received: from victor.nexor.co.uk by cdsmail.cdc.com; Thu, 27 Apr 95 10:49:39 -0500
Received: from nexor.co.uk (actually host victor.nexor.co.uk) by victor.nexor.co.uk with SMTP (XT-PP); Thu, 27 Apr 1995 16:47:46 +0100
To: mhs-ds@mercury.udev.cdc.com
Subject: omittedORAddressComponent
Date: Thu, 27 Apr 1995 16:47:43 +0100
Message-ID: <20610.798997663@nexor.co.uk>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Peter Cowen <p.cowen@nexor.co.uk>
Hello, 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. Peter 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 ?
- omittedORAddressComponent Peter Cowen