The CCSO Nameserver (Ph) Architecture
RFC 2378
Document | Type |
RFC - Informational
(September 1998; No errata)
Was draft-ietf-ids-ph (ids WG)
|
|
---|---|---|---|
Authors | Paul Pomes , Roland Hedberg | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2378 (Informational) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group R. Hedberg Request for Comments: 2378 Umea University Category: Informational P. Pomes QUALCOMM, Inc. September 1998 The CCSO Nameserver (Ph) Architecture Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract The Ph Nameserver from the Computing and Communications Services Office (CCSO), University of Illinois at Urbana-Champaign has for some time now been used by several organizations as their choice of publicly available database for information about people as well as other things. This document provides a formal definition of the client-server protocol. The Ph service as specified in this document is built around an information model, a client command language and the server responses. 1. Overview 1.1. Basic Information Model At its simplest the Ph database can be thought of as a computer- resident "phone book". However, it can be used to collect arbitrary information about people, and in response to a query about an object named in the database, return information about that entity. It is in short a nameserver for people and objects. It was designed to keep a relatively small amount of arbitrary information about a relatively large number of people or things, and provide access to that information over the Internet. In order to structure the information the manager of the database has to decide which views to present of the real-world objects that are to be represented in the database. Each view is then composed of a number of fields and their values. To support this concept Ph has the notion of named information, i.e., categorizing information into what are called fields and assigning descriptive names to those fields. Hedberg & Pomes Informational [Page 1] RFC 2378 The CCSO Nameserver (Ph) Architecture September 1998 Even if the database resides and is reachable from the Internet it is local in the meaning that no server is supposed to be able to refer a client to another server which might hold the wanted information. However a server may contain a list of other Nameservers which can be used by clients to query other Nameservers for information. 1.1.1. Fields A field descriptor is associated with each field and is used to describe the type and behavior of the field. A field descriptor includes the fieldname, the maximum length of information the field can store before truncation, keywords describing the properties of the field as well as free text describing what kind of information the field is supposed to hold. The keywords can be any of the following: Always: Forces the field's contents to be always printed in addition to whatever fields specified by the query. Any: This field is always searched by queries. To be most use ful, a field marked as Any should also have the Indexed and Lookup keywords as well. Change: Can be changed by the owner of the entry. Default: Printed if no return clause is given in the query. Encrypt: Must be encrypted before transmission. ForcePub: Viewable/searchable regardless of the content of the suppress field Indexed: Fields that are kept track of in the database's index for efficient lookups. At least one indexed field must be present in each query. LocalPub: May be viewed by anyone in the "local" domain or address space. Fields with this keyword are completely invisible outside of the "local" domain. They will not be shown with the fields command (section 3.3), and are disallowed in query commands or return clauses (section 3.8). Lookup: May be used in the selection part of a query. A Field without this keyword may not be used to select entries. NoMeta: Wildcard searches are disallowed. Hedberg & Pomes Informational [Page 2] RFC 2378 The CCSO Nameserver (Ph) Architecture September 1998 NoPeople: No entry of type "person" may include this field. Private: Field may be viewed by Heros (section 1.4) only. Public: May be viewed by anyone. Fields not marked with this keyword may only be viewed by the entry's owner or a Hero. Sacred: Changes to the field are prohibited except via non-network invocations of the server, i.e., from a tty, file, or pipe.Show full document text