Re: Using X.500 to determine presentationAddresses

Peter Yee <> Wed, 26 May 1993 04:39 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa18814; 26 May 93 0:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18810; 26 May 93 0:39 EDT
Received: from by CNRI.Reston.VA.US id aa00675; 26 May 93 0:39 EDT
Received: from by with local SMTP id <>; Wed, 26 May 1993 04:55:13 +0100
Received: from by with Internet SMTP id <>; Wed, 26 May 1993 04:55:00 +0100
Received: from by with SMTP (PP); Tue, 25 May 1993 20:54:22 -0700
Subject: Re: Using X.500 to determine presentationAddresses
In-reply-to: Your message of "Thu, 20 May 1993 01:55:17 -0000." <>
Date: Tue, 25 May 1993 20:54:20 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Peter Yee <>
Message-ID: <9305260039.aa00675@CNRI.Reston.VA.US>

>1: Isn't a UFN is just a representation of a Directory Name with a default 
>sequence of attributes. Why is the user searching for the machine ? 
>Presumably because they have been told that some desired service is 
>accessible on it. So the name will have been presented in a form that 
>identifies the attribute types - either explicitly or by default according to 
>some set of rules.

Sure a UFN is as you describe.  The question is how do you give machines
names that are reasonably easy to remember yet are distinctive enough
to permit efficient searching/listing of the directory.

>2. By "well-defined subtree" Are you asking for all Organisations or
>Organisation Units to use the same structure below their level ?
>Surely not. Interaction of Locality and OU have different "obvious"
>answers depending on what kind of O you are.

My thoughts were that we might have to have a subtree that replicated
the "normal" portion of the tree, but contained machine/process info.
Not a particularly elegant solution, but one that permits machines to
be named in a fashion analogous to people, but without intermingling
the two.

>3. On a side issue (and at some risk of pedantry) why are we talking
>about machines ? A presentation address identifies a *process*
>(strictly, an application entity that is the projection of an
>application process into the communications environment), and the
>process may move from one machine to another. Yes, it makes sense to
>think of the process as being the machine if you want to login to it,
>but probably not if you after something with access to a distributed
>database or the like. service = machine is rather old-fashioned.

Sure it's old-fashioned.  But for most cases of presentation addresses
it is acceptable.  We have enough problems with naming machines and
processes withough worrying about how X.500 will handle things that
move (particularly if they move frequently).