CCSO Nameserver

A CCSO name-server or Ph protocol was an early form of database search on the web. In its most common form it was used to lookup information such as phone numbers and e-mail addresses. [cite web |url=http://www.faqs.org/faqs/ph-faq/ |title=ph (cso nameserver) Frequently Asked Questions (FAQ) |accessdate=2007-05-12] Today this service has been largely replaced by LDAP. It was used mainly in the early-to-middle 1990s. [cite web |title=Ph and Gopher |url=http://groups.google.com/group/comp.infosystems.gopher/browse_frm/thread/eef4cfbdbc862afe/9cbc3e3690b8fb4e?lnk=st&q=%22cso+nameserver%22&rnum=19&hl=en#9cbc3e3690b8fb4e |accessdate=2007-09-18] The name-server was developed by Steve Dorner at the University of Illinois at Urbana-Champaign.

Overview

The name-server directories were frequently organized in Gopher hierarchies. The tools "Ph" and "Qi" were the two components of the system: Ph was a client that queried the Qi server.

The Ph protocol was formally defined by RFC 2378 in September 1998. However the memo issued at this time references its prior use for an unspecified period of time before this date. [cite web |url=http://www.faqs.org/rfcs/rfc2378.html |title=RFC 2378 - The CCSO Nameserver (Ph) Architecture |accessdate=2007-07-14] It defines sixteen keywords that can be used on the server side to define record properties. It also defines how clients should access records on the server and what responses the server should give. Ph sever communication takes place on TCP port 105.

Command Structure

All commands and response are initially assumed to be in US-ASCII encoding for historical reasons unless the client explicitly asks for 8-bit(ISO-8859-1) encoding. As a result only characters between 0x20 and 0x7f are initial sent by the server in raw form. Other characters if present in entries will be escaped using the RFC 2045 defined "Quoted-Printable" encoding. The initial request from the client is a text base keyword optionally followed by one or more parameters as defined in the RFC 2378. The server then responds to the request. The following example response to a status request is provided by the RFC memo.

C: statusS: 100:Qi server $Revision: 1.6 $S: 100:Ph passwords may be obtained at CCSO Accounting,S: 100:1420 Digital Computer Lab, between 8:30 and 5 Monday-Friday.S: 100:Be sure to bring your U of I ID card.S: 200:Database ready

Each command defined by the RFC 2378 memo consists of a keyword followed as needed by one or more parameters or key words. They can be separated by spaces tabs or the end of the line. Each line must be terminated in CRLF style.

The fallowing are a few of the commands:

status

This command takes no parameters and simply asks the server to report its status as above.

siteinfo

Returns information such as server version mail domain and who to contact about password issues and authentication methods.

fields [field ...]

List all available entry fields on the server or only those of the specified name or names.

id information

Causes the server to log the specified information as the current user id without login.

set [option [=value] ...]

Sets the specified option on the server to value. If used without parameters it lists the current server settings.

login [alias] logout

This is the actual login/logout commands for the server here the alias must be the users Ph alias. Logging in allows a user to change their own entry and view certain fields in it flag for restricted access.

answer encrypted-responseclear cleartext-password

The client normally uses one of these to send the password information after the login command is sent.

quitexitstop

One or more of these will be recognized by the server as an end of session command closing the connection.

Database

As distributed, the nameserver was backed by a flat file database. In the early 1990s, Indiana University software developer Larry Hughes implemented a version of Qi (called "Phd") that was written in perl and backed by a relational database. That code was distributed under an open source license for several years prior to the university's transition to LDAP.

References