Browse Prior Art Database

On-line hostnames service (RFC0625)

IP.com Disclosure Number: IPCOM000003698D
Original Publication Date: 1974-Mar-07
Included in the Prior Art Database: 2000-Sep-13
Document File: 1 page(s) / 2K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M.D. Kudlick: AUTHOR [+2]

Abstract

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 100% of the total 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 ]