Re: Using X.500 to determine presentationAddresses

Colin Robbins <> Wed, 26 May 1993 11:44 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa01725; 26 May 93 7:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01721; 26 May 93 7:44 EDT
Received: from by CNRI.Reston.VA.US id aa05510; 26 May 93 7:44 EDT
X400-Received: by mta in / 400/C=gb/; Relayed; Wed, 26 May 1993 10:58:43 +0100
Date: Wed, 26 May 1993 10:58:43 +0100
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/ 400/C=gb/; haig.cs.uc.363:]
Priority: Non-Urgent
DL-Expansion-History: ; Wed, 26 May 1993 10:58:43 +0100;
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Colin Robbins <>
Message-ID: <"26411 Wed May 26 10:58:06 1993">
To: Christian Huitema <>
In-Reply-To: <>
Subject: Re: Using X.500 to determine presentationAddresses

   >1) The LDAP debate ...

I agree that distributing the high level searches is very difficult to
do, but as you point out later, replication can be used to solve the

What is needed is this case is an agreed DIT wide replication model.
An attempt has been made with the "Internet X.500 Replication model" -
RFC 1276, but this has not been widely adopted.  Hence the point in my
previous mail about needing to allow for DSAs that cannot perform
these searches.

There are a number of other (perhaps more acceptable) ways the required
replication can be achieved.  We could adopt the proposed 1992
X.500 standard replication protocol, or possibly use something along
the lines of the NADF KAN model.

ASIDE:  Does anybody know what is happening with the proposed "1992"
X.500 standards? I have heard rumours that they may not be accepted as

With such replication in place, DUA implementors can start to offer
users the consistent level of service required.

   >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

Doesn't this model require that the NSAP for the "machine address" is
the same as the NSAP for the "application" entries.
Or do you mean by 'inherit the NSAP' that the "application" will inherit
an NSAP prefix from the "machine", and append it specific address
In anycase, doesn't this model tie the NSAP for an "application" to
that of a "machine", I thought we were trying to get away from this situation.