Re: Using X.500 to determine presentationAddresses

[[e-mail]]

> From: Peter Yee <[e-mail]>

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

I am sorry to have to disagree with you Peter but
I think that your argument does not stand.

1. X.500 is not made for thinks that move very frequently, and for
example will never ba able to cope with say a "process table" (eg.
object with a time-life in the order a magnitude of seconds
or even less).
Other forms of directory are to be used (and generaly a local
only usage will be needed which don't request any "heavy" protocol).

2. If an entity (a process) move very fast, it is by no way a better
solution to "look for" a machine. There is no durable binding
between the entity and the machine, and thus there is no benefit
(for this purpose) in getting the machine attributes from
the directory.

3. entities that are of interest for "remote users' (oftten
applications) are those with a long enough time-life without
attribute modification. What would be the use of getting such
attributes if a little while after these a not correct any more
when the "user" tries to make use of them.


4. Conversely there are plenty of entities (servers, daemons) which
have long lifetime. Independantly from X.500 or not, they are the only
one that are of interest from remote users, just because
of 
  1. a well identified function (what the user looks for)
  2. enough stability over time (to give a chance to their user
	to "catch" them)


5. For those cases it would be outdated pratice and misuse
of new technology than to "look-for" these entities through
a machine name.
It is outdated pratice because before the emergence of directory
services the only solution to refer to these objects was to
use an address  (eg. a host + port number, or a PSAP)
thus the habit of having a machine name.
But the directory is here to enable using a name instead of an adress
and it would be dumb to stick to adresses.
  
  let's take a few example
    for an internet draft ftp server, do you prefer to go on
    with the hostname or (worse) the host IP address, or would you
    prefer to have a name (and thus not depend on the fact that
    the machine has to be changed from time to time).
    If you tell me that the host name is OK because stable
    and not depending on the hardware, OK that just indicates
    that a directory service is being used: the DNS and the DNS
    is only able to store hostnames (and no entity names).

    when an accounting application need to access the personal
    database of an institution is it better to "hardwire"
    the name of the host running this data base, or would it be better
    to 
       give a name to the service
       have all client applications use this name?

    even when someone wants to telnet or rlogin somewhere, the habits
    have given the impression that you are "connecting" to a machine
    when in fact what you are getting in touch with is some kind
    of "login server" or "login daemon" (thus a application entity
    not a machine) and moreover what you want to use is an
    interative server (with OS and disks and applications) and not
    a naked computer. Thus on one hand you probably don't care
    if the actual machine hardare has been changed (as long as the
    service remains the one you are loooking for) and moreover
    if the institution is using some advanced form of
    gatekeeper or firewall it is possible that in order to reach
    the desired server your client will physicaly have to
    connect first to a different physical address.


Of course there might be good reasons to store machine entries
in the directory. Some applications (say a distributed management
servie) may have interest in the machine themselves.
But that a completely different usage. The machine entry
will inded be a machine entry distinct from the server entries


regards,

-- PAP


> 
> 
> 
>