[fa.info-vax] VT240 upgrade

info-vax@ucbvax.ARPA (06/27/85)

From: jww@SDCSVAX.ARPA (Joel West) (ttyj0)

From postnews Tue Jun 25 00:23:11 1985

Subject: Re: RFC920 domains
Newsgroups: net.mail.headers
Keywords: domains cow patties
References: <918@sdcsvax.UUCP> <532@deepthot.UUCP> <8066@ucbvax.ARPA> <2329@icarus.fluke.UUCP>

In article <8201@ucbvax.ARPA> jordan@ucbvax.ARPA writes:
> In article <2323@icarus.fluke.UUCP> joe@fluke.UUCP (Joe Kelsey) writes:
> 
> > I think that is important that anyone who is tempted to jump into the
> > domain discussion consider that what we really want is a way to name
> > hosts *independent* of their physical location or physical network
> > address, since both of these are volitile.  What we need is a user-intuitive
> > way of finding out host names, then a set up protocols to implement some
> > sort of limited distributed name server/resolver on the UUCP transport
> > mechanism.  This is possible, but an important step to take is to disconnect
> > your idea of hostname from physically restricting ideas, like geographic or
> > network addresses.
> 
> Independent of "physical network address", yes, of course, but I don't
> think that geographic reference in some instances is any more
> restricting than organizational domains.  ...  should
> a University in Germany be in the same domain as UC Berkeley because
> it is a University? ARPA says yes. UUCP should say no. Geography is
> counter-intuitive in the ARPA world. Not always in the UUCP world.

Needless to say, I agree whole-heartedly with jordan.  I would be willing to
bet my (minimal) reputation on a vote from net.general as to whether the
geographic approach is more "user-intuitive" than the NIC plan for each
respondent's home address.

In <2329@icarus.fluke.UUCP>  joe@fluke attempts to reply:
> When is everyone going to realize that the point of domains is to separate
> the physical addressing from the naming?
Joe, we realize that this is the "point" of those attempting to invent
such domains.  We just don't agree that this is a desireable "point" (read:
"goal") for designing a mail system.

> You asked what is wrong with setting up .UUCP as a top-level domain and
> using geographic subdomains?  Well, I'll tell you there is a LOT wrong with
> that idea.  For one thing, it creates artifical boundaries that people
> may confuse with routing.  

I cross through 4 municipalities en route from work to home.  These are
artificial boundaries.  When I make a phone call, I do not specify these
intermediate cities--but the prefix of my home phone implicitly gives
my city.  

The use of a geographic designator does not prohibit other routings.
In my previous example, bonnie.nj.uucp would still talk directly to
gould9.ca.uucp.  And I might be so smart as to say that any message
I get for ".nj.uucp" should go to bonnie, since she knows more
New Jersey sites than I do (and I know more San Diego sites).  My
friends might also give me ".nj.uucp" addresses since I have a friend
in New Jersey and they don't.

>Domain names have absolutely nothing to do with routing.  

"Absolutely nothing" is a bit strong.  When in doubt, X.ARPA will
send Y.ARPA mail via ARPAnet, IMP's, tcp, etc.  For example, that's
how nosc.ARPA sends mail to nosc-frog.arpa, even though they're in
the same building.  In San Diego, a smart machine would send
Y.SD.CA.UUCP to SDCC3.SD.CA.UUCP (or SDCC3.UCSD.EDU) which is a
de facto name server for the 30+ mail machines here in town.

> They have absolutely nothing to do with which other sites I choose
> to talk to - whether that communication be with UUCP or X.25 or TCP or ...

Again, I almost agree.  I hope gould9.ca.uucp will still talk to sdcsvax.edu
and nosc.mil.

> Geographic domains would force a nation-wide company to make up useless
> names for their physically separated computers simply to satisfy someones
> idea that there is some "logic" to this scheme.

I don't know anything about your company.  But most of the nationwide
companies I know -- such as computer companies -- will usually refer to 
Joe Blow from the "San Diego office" or "St. Paul office".  My firm
has offices in at least 15 cities and we normally refer to sending
mail to the "LA office" or the "DC office".  Needless to say, sending
mail to AT&T in Holmdel, NJ would have to be more specific.

> There are going to be hosts with multiple network connections.  The most
> useful part of the domain name scheme is the fact that a host has *exactly*
> one name.  
Using unique host ids has disadvantages, but I'll stipulate this just to
eliminate any controversy. :-)

> It may have multiple physical addresses - one for each physical
> network it is connected to - but it has the same *user visible* name on
> each network.  Try thinking of the UUCP sitename as an address instead
> of a name, then you will be able to see the separation of *naming* from
> *addressing* and *routing*.

Just because I don't agree with you, don't think that means I don't
understand domain naming, domain servers, and so on.  It's fun to search
through my uucpmap files to find a good route to a new site--that is,
the first 3 or 4 times.  After that, it's not fun.  Automatic routing
is essential to a complete electronic mail system.

However, in the general UUCP world no true domains exist yet, and 
therefore their choice is totally arbitrary.    Why not choose something
that make sense more often than the NIC scheme?  As Jordan notes,
some of us pay for phone calls.  Conversely, I route some messages
to New Jersey and Illinois to get to Northern California, because
the path is shorter--smart domain addressing might send it from
San Diego to Silicon Valley in one hop.

The general reaction I've heard to my original posting is that I had failed
to realize that RFC920 was intended to meet the needs of the ARPA community, 
period.  There is no reason it has any bearing at all on what the UUCP 
community does-- as long as we adopt some domain addressing scheme.


From postnews Tue Jun 25 00:24:23 1985
Subject: Re: RFC920 domains
Newsgroups: net.mail.headers
Keywords: domains cow patties
References: <918@sdcsvax.UUCP> <532@deepthot.UUCP> <8066@ucbvax.ARPA> <2329@icarus.fluke.UUCP>

In article <8201@ucbvax.ARPA> jordan@ucbvax.ARPA writes:
> In article <2323@icarus.fluke.UUCP> joe@fluke.UUCP (Joe Kelsey) writes:
> 
> > I think that is important that anyone who is tempted to jump into the
> > domain discussion consider that what we really want is a way to name
> > hosts *independent* of their physical location or physical network
> > address, since both of these are volitile.  What we need is a user-intuitive
> > way of finding out host names, then a set up protocols to implement some
> > sort of limited distributed name server/resolver on the UUCP transport
> > mechanism.  This is possible, but an important step to take is to disconnect
> > your idea of hostname from physically restricting ideas, like geographic or
> > network addresses.
> 
> Independent of "physical network address", yes, of course, but I don't
> think that geographic reference in some instances is any more
> restricting than organizational domains.  ...  should
> a University in Germany be in the same domain as UC Berkeley because
> it is a University? ARPA says yes. UUCP should say no. Geography is
> counter-intuitive in the ARPA world. Not always in the UUCP world.

Needless to say, I agree whole-heartedly with jordan.  I would be willing to
bet my (minimal) reputation on a vote from net.general as to whether the
geographic approach is more "user-intuitive" than the NIC plan for each
respondent's home address.

In <2329@icarus.fluke.UUCP>  joe@fluke attempts to reply:
> When is everyone going to realize that the point of domains is to separate
> the physical addressing from the naming?
Joe, we realize that this is the "point" of those attempting to invent
such domains.  We just don't agree that this is a desireable "point" (read:
"goal") for designing a mail system.

> You asked what is wrong with setting up .UUCP as a top-level domain and
> using geographic subdomains?  Well, I'll tell you there is a LOT wrong with
> that idea.  For one thing, it creates artifical boundaries that people
> may confuse with routing.  

I cross through 4 municipalities en route from work to home.  These are
artificial boundaries.  When I make a phone call, I do not specify these
intermediate cities--but the prefix of my home phone implicitly gives
my city.  

The use of a geographic designator does not prohibit other routings.
In my previous example, bonnie.nj.uucp would still talk directly to
gould9.ca.uucp.  And I might be so smart as to say that any message
I get for ".nj.uucp" should go to bonnie, since she knows more
New Jersey sites than I do (and I know more San Diego sites).  My
friends might also give me ".nj.uucp" addresses since I have a friend
in New Jersey and they don't.

>Domain names have absolutely nothing to do with routing.  

"Absolutely nothing" is a bit strong.  When in doubt, X.ARPA will
send Y.ARPA mail via ARPAnet, IMP's, tcp, etc.  For example, that's
how nosc.ARPA sends mail to nosc-frog.arpa, even though they're in
the same building.  In San Diego, a smart machine would send
Y.SD.CA.UUCP to SDCC3.SD.CA.UUCP (or SDCC3.UCSD.EDU) which is a
de facto name server for the 30+ mail machines here in town.

> They have absolutely nothing to do with which other sites I choose
> to talk to - whether that communication be with UUCP or X.25 or TCP or ...

Again, I almost agree.  I hope gould9.ca.uucp will still talk to sdcsvax.edu
and nosc.mil.

> Geographic domains would force a nation-wide company to make up useless
> names for their physically separated computers simply to satisfy someones
> idea that there is some "logic" to this scheme.

I don't know anything about your company.  But most of the nationwide
companies I know -- such as computer companies -- will usually refer to 
Joe Blow from the "San Diego office" or "St. Paul office".  My firm
has offices in at least 15 cities and we normally refer to sending
mail to the "LA office" or the "DC office".  Needless to say, sending
mail to AT&T in Holmdel, NJ would have to be more specific.

> There are going to be hosts with multiple network connections.  The most
> useful part of the domain name scheme is the fact that a host has *exactly*
> one name.  
Using unique host ids has disadvantages, but I'll stipulate this just to
eliminate any controversy. :-)

> It may have multiple physical addresses - one for each physical
> network it is connected to - but it has the same *user visible* name on
> each network.  Try thinking of the UUCP sitename as an address instead
> of a name, then you will be able to see the separation of *naming* from
> *addressing* and *routing*.

Just because I don't agree with you, don't think that means I don't
understand domain naming, domain servers, and so on.  It's fun to search
through my uucpmap files to find a good route to a new site--that is,
the first 3 or 4 times.  After that, it's not fun.  Automatic routing
is essential to a complete electronic mail system.

However, in the general UUCP world no true domains exist yet, and 
therefore their choice is totally arbitrary.    Why not choose something
that make sense more often than the NIC scheme?  As Jordan notes,
some of us pay for phone calls.  Conversely, I route some messages
to New Jersey and Illinois to get to Northern California, because
the path is shorter--smart domain addressing might send it from
San Diego to Silicon Valley in one hop.

The general reaction I've heard to my original posting is that I had failed
to realize that RFC920 was intended to meet the needs of the ARPA community, 
period.  There is no reason it has any bearing at all on what the UUCP 
community does-- as long as we adopt some domain addressing scheme.



From postnews Wed Jun 26 22:36:05 1985
Subject: VT240 upgrades
Newsgroups: net.graphics,net.periphs

DEC recently announced a new whiz-bang upgrade to the VT240.  It
supposedly adds both performance and capability.

I bought my VT240 about 6 months ago, and was quoted about $350 for
the upgrade.  Since I (my company) bought it for the day I get the
time to sit down and figure out how to make pretty pictures, I don't
know enough about what it can do to know whether it's worthwhile....

Does anyone know what it entails, and what its practical value is?
I'd also be interested in hearing from anyone with experience using
a VT240 or 241.  In particular, I've heard the performance sucks.
Also, I'm curious whether people are using it as a Regis device
(for which there's no software) or as a 4014 emulator.

PS: The 240 becomes a 241 by buying a new monitor (according to a DEC
rep)  Is this a worthwhile use of money?