overloading cn= in the DIT
George Michaelson <G.Michaelson@cc.uq.oz.au> Fri, 17 July 1992 04:03 UTC
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04415; 17 Jul 92 0:03 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04411; 17 Jul 92 0:03 EDT
Received: from haig.cs.ucl.ac.uk by NRI.Reston.VA.US id aa10835; 17 Jul 92 0:06 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.00479-0@haig.cs.ucl.ac.uk>; Fri, 17 Jul 1992 04:26:09 +0100
Received: from brolga.cc.uq.oz.au by bells.cs.ucl.ac.uk with Internet SMTP id <g.04771-0@bells.cs.ucl.ac.uk>; Fri, 17 Jul 1992 04:25:59 +0100
Received: from cc.uq.oz.au by brolga.cc.uq.oz.au id <09198-0@brolga.cc.uq.oz.au>; Fri, 17 Jul 1992 13:25:37 +1000
To: osi-ds@cs.ucl.ac.uk
Subject: overloading cn= in the DIT
Date: Fri, 17 Jul 1992 13:25:37 +1000
From: George Michaelson <G.Michaelson@cc.uq.oz.au>
Sender: G.Michaelson@cc.uq.oz.au
Message-ID: <9207170006.aa10835@NRI.Reston.VA.US>
I'm doing alpha work for somebody on X.500 based routing for X.400 -Neccessitates making suitable data be present in the directory. cn=AnimalName was nice for a pilot, but is a major bummer in the context of a real-world global tree. cn=MhsMtaName is just as crocked. People, ordinary people, have no idea that the global namespace means that an object called cn=George could be any of: a DSA a person an MTA an arbitrary object co=erced into cn= form I think this is a chronically bad way to name objects in the global DIT. cn= should be reserved for one, and only one kind of naming instance, and more appropriate nameforms should be used to identify and RDN/DN instantiate things of a different context. now I've finished my diatribe, somebody shoot me down in flames. Please do not include any statement of the form: but its specified in the standards... \ -George
- overloading cn= in the DIT George Michaelson
- Re: overloading cn= in the DIT George Michaelson
- Re: overloading cn= in the DIT Andrew Waugh
- Re: overloading cn= in the DIT Andrew Waugh
- Re: overloading cn= in the DIT ren
- Re: overloading cn= in the DIT Andrew Findlay
- Re: overloading cn= in the DIT Erik Skovgaard