On-line hostnames service
A response supporting FTP and ASCII for distributing host names.
Kudlick, M.D. and E.J. Feinler, "On-line hostnames service", RFC 625, DOI 10.17487/RFC0625, March 1974, <https://www.rfc-editor.org/info/rfc625>.
@misc{rfc625,
series = {Request for Comments},
number = 625,
howpublished = {RFC 625},
publisher = {RFC Editor},
doi = {10.17487/RFC0625},
url = {https://www.rfc-editor.org/info/rfc625},
author = {M.D. Kudlick and E.J. Feinler},
title = {{On-line hostnames service}},
pagetotal = 1,
year = 1974,
month = mar,
} RFC text
Network Working Group Mike Kudlick (SRI-ARC)
RFC # 625 Jake Feinler (SRI-ARC)
NIC # 22152 March 7, 1974
ON LINE HOSTNAMES SERVICE
We agree with the suggestion in RFC 623 that more than one Host should
be responsible for maintaining a copy of the Hostnames data base. The
NIC is certainly willing to continue to maintain the master data base,
and make it available to any secondary Host that volunteers to maintain
a copy. We would be pleased to have UCSB serve as one of the secondary
Hosts.
However, we disagree with the suggestion in RFC 623 that a server
process should be implemented to give user processes access to the
official Hostnames file at the NIC. The file in question is a
sequential file and it seems to us that FTP is entirely appropriate for
this need. As far as setting up common login parameters among the
servers, this doesn't appear to be a major problem. Even with a
user/server process there would be a requirement for additional protocol
agreements, so it doesn't seem that much of an added burden to decide on
common login parameters when using FTP.
We are puzzled by the apparent distaste for FTP. In our opinion the
goal has been to set up a network file transfer mechanism that everyone
can use for a variety of needs without further programming required. If
FTP is that bad, shouldn't the criticism and work be directed towards
improving or replacing it, rather than making end runs around it? FTP
is surely more complex than is required for any particular application
including this one, but isn't that true by definition of a general
facility?
We also prefer to maintain the file in ASCII. It is easier, it seems to
us, to check out data or data transfer problems in that form rather than
in binary.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alex McKenzie with ]
[ support from GTE, formerly BBN Corp. 10/99 ]
ISO Plain Language
On this page
§1Agreement on Secondary Copies
The authors agree with RFC 623 that more than one host should maintain a copy of the host-name database. The NIC is willing to keep the master database and make it available to secondary hosts that volunteer; the authors welcome UCSB as one such host.
The authors support keeping secondary copies of the database. The NIC would continue to maintain the master and make it available to volunteers.
§2FTP Rather Than a Dedicated Server
The authors disagree with the suggestion to create a server process for access to the NIC's official host-name file. Because the file is sequential, they consider FTP appropriate for retrieving it. They also say agreeing on common login parameters does not seem like a major problem, and that a dedicated process would still require additional protocol agreements.
They argue that FTP was intended as a reusable network file-transfer mechanism and suggest that criticism should lead to improving or replacing FTP rather than bypassing it for each simple application.
The authors think FTP is a reasonable way to transfer this sequential file. They say a separate service would still need rules for how programs use it.
§3Preference for ASCII
The authors also prefer to keep the host-name file in ASCII rather than binary. They say ASCII makes it easier to check the data and diagnose transfer problems.
The authors prefer a text file because people can inspect it when checking the data or investigating a transfer problem.