Re: Using X.500 to determine presentationAddresses

Christian Huitema <Christian.Huitema@sophia.inria.fr> Wed, 26 May 1993 11:45 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01766; 26 May 93 7:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01762; 26 May 93 7:45 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa05549; 26 May 93 7:45 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.02505-0@haig.cs.ucl.ac.uk>; Wed, 26 May 1993 11:28:41 +0100
Received: from mitsou.inria.fr by bells.cs.ucl.ac.uk with Internet SMTP id <g.23264-0@bells.cs.ucl.ac.uk>; Wed, 26 May 1993 11:28:33 +0100
Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA18382; Wed, 26 May 1993 12:28:52 +0200
Message-Id: <199305261028.AA18382@mitsou.inria.fr>
To: Colin Robbins <c.robbins@nexor.co.uk>
Cc: osi-ds@cs.ucl.ac.uk
Subject: Re: Using X.500 to determine presentationAddresses
In-Reply-To: Your message of "Wed, 26 May 93 10:57:49 BST." <199305260958.AA05616@sophia.inria.fr>
Date: Wed, 26 May 93 12:28:51 +0200
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Christian Huitema <Christian.Huitema@sophia.inria.fr>

Colin,

>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.

The concept of "supporting system" exist in ISO. Indeed, in a pure ISO
tradition, the system is a virtual ectoplasm that materialize wherever you
want -- but if you look at routing protocols, you end up with a pretty tight
correlation between systems and hardware platforms. 

A system has at least one NSAP, may have several if it has several
network attachments. Thus, a PSAP is really a system address (a set of NSAP)
qualified by "selectors" (T, S, P).

Note that I am not very interested in the details of the ISO stack. What count
for X.500 is the data base mechanism. There are many cases where an
"attribute" is in fact derive from "building blocks", e.g.:

 * a PSAP inherit the NSAP from the "supporting system" -- whatever the shape
   of this ectoplasm may be today. Should the NSAP change, all supported
   PSAPs should change automatically.

 * a mail address inherits the "domain name" of the mail domain, and qualify it
   with "personal" attributes. Should the "domain name" change, all mail
   addresses in the domain should change automatically. Should the personal
   name vary, the mail address should be updated automatically.

 * a snail mail address inherits the unit's address, and qualify it with
   personal name and room number,

 * etc.

I know how to express this in relational databases, and thus I know that an
X.500 front-end to these data base would have the adequate "automatic update"
properties. H. Afifi even started to implement "derived attributes" in Pizarro
to provide that. But the X.500 standard -- and the conformance tests -- come
in the way here, because:

 * if you derive the PSAP from another entry's NSAP, then you cannot update
   the PSAP component through X.500 -- you have to update another, different,
   attribute, from which the PSAP is derived.

 * Indeed, you can always return an error to the "modify" request -- this
   is a local decision. But you will have some severe problems when
   replicating your base on another software platform.

Which is why I believe that the X.500 data model is very naive...

Christian Huitema