Re: Using X.500 to determine presentationAddresses

[Peter Yee <[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.

I do agree with your points 1, 2, 3, and 4.  My point in response to Monsieur
Furniss was that X.500 would not be suitable (as you state) for processes
that move around frequently.  Be warned, however, that DEC intends to use
X.500 for NSAP mapping (and I guess really PSAP mapping), and thus I need to
figure out a naming scheme before they do the wrong thing.

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

No argument there.

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

Agreed.  That's why I'm looking for a solution to stable entities, and in
particular ones that are the common case.

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

Sure.

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

Those are the servers I'm most interested in using X.500 to map.  Servers
that are independent of a particular machine are fine, but when I say
vt atlas.arc.nasa.gov, I expect to end up connected to atlas.

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

No argument with these cases, since it is the overall service (database
access) that is of interest.  But I've cited cases where it is access to
a particular machine that interests me, and more over, I don't really care
all that much which service (telnet, rlogin, or vt) gets me there!

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

You don't care what the hardware is, but typically you want a very specific
computer entity and regardless of how intervening servers and firewalls
affect that, you still want to be connected to the destination computer.  The
reason is that while it may be easy to shift servers and daemons around,
quite frequently, despite advanced networking software, account and user files
don't move around or are not accessible in a transparent manner.  Thus, when
I say that I wish to telnet to ames.arc.nasa.gov, I specifically want one
computer and one computer alone, since I know that if some other telnet server
handles my request, I'm unlikely to see the service I want.  I agree with you,
however, that this is an old-fashioned.  It is also relevant in the short
term.

>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

Fine, but we still haven't arrived at a naming scheme that allows one
to derive a PSAP, either by entity name or machine name+service port!
Theoretical considerations aside, I need a solution in the near term.
This doesn't sound pleasing, but I'll have to fix things down the line.
Right now, I want a naming scheme that doesn't make a hopeless mess of
things, until I can institute a name lookup service akin to want Peter and
Paul-Andre suggest.
							-Peter