Re: Using X.500 to determine presentationAddresses

Christian Huitema <> Wed, 26 May 1993 08:58 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa01076; 26 May 93 4:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01072; 26 May 93 4:58 EDT
Received: from by CNRI.Reston.VA.US id aa03057; 26 May 93 4:58 EDT
Received: from by with local SMTP id <>; Wed, 26 May 1993 09:29:03 +0100
Received: from by with Internet SMTP id <>; Wed, 26 May 1993 09:28:51 +0100
Received: by (5.65c/IDA-1.2.8) id AA18017; Wed, 26 May 1993 10:29:09 +0200
Message-Id: <>
To: Jean-Paul Le Guigner <>
Subject: Re: Using X.500 to determine presentationAddresses
In-Reply-To: Your message of "26 May 93 09:34:56 +0200." <199305260734.AA16316(l)a(r)>
Date: Wed, 26 May 93 10:29:06 +0200
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Christian Huitema <>


Both the LDAP and the "PresentationAddress" debate indicate how buggy X.500

1) The LDAP debate showed that some implementations are perfectly conformant,
yet don't do what the user want. Behind that lies a hard fact: we dont know
how to distribute "searches" -- that is, in general. Distributing them along a
hierarchy almost work, provided the hierarchy is not "too branchy". Top levels
are traditionally very very branchy... 

2) The PSAP debate showed that people are naturally reluctant to duplicate
their "machine addresses" in all their "application" entries. Indeed, that is
the first rule of data base management -- never duplicate information, less you
end up with inconsistant updates. In a relational SGBD, the "application"
tuple would have a "support system identifier" entry, and inherit the NSAP
address from this entry. The X.500 schema, from that point of view, is very

Maybe we should start defining our own X.500 dialect, adding whatever
features are required. In the short term, it may mean that "top level" DSAs
should perform massive replications -- i.e. collect the full description of
all the member organizations -- following the model of "data base servers"
rather than that of "DNS servers". 

The single reservation I have with this model is that the more "service" we
place in the top level servers, the less we can justify a monopoly, and the
more we need to go away from the hierarchical organization of servers.

Christian Huitema