Re: Using X.500 to determine presentationAddresses

[Peter Furniss <[e-mail]>]

> 
> No, you didn't do anything wrong! But as long as there is no standard
> way for registering machines in the Directory I could use other schemas
> e.g. country=gr, o=FORTH, OU=ICS, machine=danae or
> country=gr, o=FORTH, OU=ICS, network=ICSnet, subnet=BuildingA, 
machine=danae
> 
> Given these different schemas how could anyone implement a DUA that 
is
> given as input UFNs for machines and return their entries?
> 
> >Am I missing something?
> 
> I just want to say that we need a well-defined subtree under every O or 
OU 
> level for registering machines so that anyone that writes a DUA that 
searches
> for machine: rubble, csd, uwo, ca (this is a UFN for rubble, right?) will 
know
> where to search. (This is because the end-user is not aware of domains or
> networks.)

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.

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.

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.


I may be way off course here, of course.

Peter