rfc2378.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,236 行 · 第 1/3 页

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.

   Turn:     Users may turn off visibility of a field to everyone except
             themselves and Heros by prefixing the field text with '*'.

   Unique:   Any change to the field will be rejected if the change
             causes the modified field to match the same field in any
             other entry.

1.1.2.  Character Sets

   Historically Ph has been restricted to only handle printable
   characters, that is characters with hexadecimal values between 0x20
   and 0x7f.  Lately with the spreading of 8-bit clean Operating Systems
   there is no reason to keep this limitation.

   This document therefore proposes that ISO-8859-1 shall be regarded as
   an alternative character set for Ph, the default still being US-
   ASCII.

   Clients that utilize ISO-8859-1 should request that the server return
   ISO-8859-1 by using the "set"-command.

   In the instance that values are stored using ISO-8859-1 and are to be
   shown to a client expecting US-ASCII, the characters with character
   codes outside of the US-ASCII range should be displayed in the
   "Quoted-Printable" content-transfer-encoding form defined in RFC-2045
   [MIME].

   1.2.  Standardization issues

   Each Nameserver manager is in essence free to name new fields to suit
   the special needs of his/her organization.  But in order to make the
   directory service useful outside of the organization it is
   recommended that a core set of standard fields always should be
   present.

   Therefore this document defines a couple of standard collections of
   fields (Appendix A).




Hedberg & Pomes              Informational                      [Page 3]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


   Also note that the architecture makes no assumption about the search
   and retrieval mechanisms used within individual servers.  Operators
   are thereby free to use any kind of dedicated databases, fast
   indexing software or even gateways to other directory services to
   store and retrieve the information, if desired.

   Ph simply functions as a known front-end, offering a simple data
   model in addition to a well known port and simple query language.

1.3.  Conventions Used in this Document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

1.4.  Heros

   For Ph a Hero is equivalent to a superuser or operator.  Being in
   Hero mode means that some or all artificial limits are removed; full
   Heros may change any field in any entry in the database, as well as
   view as many entries as they wish.  Heros can also be limited to one
   field of one other entry.  Hero mode is used mostly for
   administrative purposes, delegation of group authority over selected
   fields, and is controlled by the acl field.

2.  Basic Operation

   Initially, the server host starts the Ph service by listening on TCP
   port 105.  When a client host wishes to make use of the service, it
   establishes a TCP connection to the server host.  The client and the
   Ph server then exchange commands and responses (respectively) until
   the connection is closed or aborted.

2.1.  Command syntax

   Commands in Ph consist of a keyword optionally followed by zero or
   more keywords or values, separated by spaces, tabs or newlines, and
   followed by a carriage return-linefeed (CRLF) pair. A more thorough
   description using BNF is given in Appendix C.

   Values containing spaces, tabs or newlines must be enclosed in double
   quotes ('"').  In addition the sequences "\n", "\t","\"" and "\\" may
   be used to mean newline, tab, double quote and backslash,
   respectively.

   Keywords must be given in lower case; case in the values of fields is
   preserved, although queries are not case-sensitive.





Hedberg & Pomes              Informational                      [Page 4]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


2.2.  Response syntax

   Responses consist of a result code followed by additional information
   possibly separated by entry index and/or field name and are
   terminated by a CRLF pair.

      result code:[entry index:][field name:]text

   Responses to some commands might be multi-lined.  In these cases each
   line in the response, except the last, has the appropriate result
   code negated (prefaced with "-").  The last line then starts with the
   appropriate result code without negation.  Each line must be
   terminated by a CRLF pair.

   If a particular command can apply to more than one entry, then the
   multilined response must be so organized that all information
   pertaining to each entry is returned on consecutive lines, and that
   each of those lines must have one and the same entry index directly
   following the resultcode.  The first entry index should be 1 and
   incremented each time a new entry is referred to.

      C: query hedberg return email name title
      S: 102:There were 3 matches to your request.
      S: -200:1:        email: [e-mail]
      S: -200:1:         name: Carl Johan Hedberg
      S: -200:1:        title: Student
      S: -200:2:        email: [e-mail]
      S: -200:2:         name: Par Hedberg
      S: -200:2:        title: Student
      S: -200:3:        email: [e-mail]
      S: -200:3:         name: Roland Hedberg
      S: -200:3:        title: Boss of the Network group
      S: 200:Ok

   Commands that can apply to more than one field must have the name of
   the field to which the response applies directly following the entry
   index.

   The text of the response will be either an error message in human
   readable format, or data from the Nameserver.  Whitespace (spaces or
   tabs) may appear anywhere in the response, but the field name and
   text columns if present must each begin with a whitespace character.

   Since more than one specific piece of information may be manipulated
   by a particular command, it is possible for parts of a command to
   succeed, while other parts of the same command fail.  This situation
   is handled as a single multi-line response with the result code
   changing as appropriate.



Hedberg & Pomes              Informational                      [Page 5]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


   As for FTP, the result codes are in the range 100-699 (or from -699
   to -100 for multiline responses), where the leading digit has the
   following significance:

      1: In progress
      2: Success
      3: More information needed
      4: Temporary failure; it may be worthwhile to try again.
      5: Permanent failure
      6: Phquery specific codes

   Many commands generate more than one line of response; every client
   should be prepared to deal with such continued responses.  Note that
   a command is finished when and only when the result code on a
   response line (treated as a signed integer) is greater than or equal
   to 200.

   Clients should assume that any numeric response, within the above
   mentioned ranges, are valid.  Also note that the server is allowed to
   send one or more lines with result codes between -199 - -100 (the
   leading "-" indicates a continuation line) and 100 - 199, as status
   information, before the actual results are transmitted.

2.3.  Format of a search string

   Matching is not sensitive to upper or lower case letters and is
   normally done on a word-by-word basis. That is, both the query
   expression and the entry information is broken up into words, and
   individual words are compared using exact matching.  If the order of
   the words is important in a query, then the query string can be
   surrounded by '"' (double quotes), whereby the complete search string
   is matched against the information in the Nameserver database.

   Word delimiters are the following characters: <SPACE>, <TAB>, <NEW-
   LINE>, ",", ";" and ":" .  These characters are not indexed and
   should not be part of the search string.

   However, special symbols, called "wildcard" characters, can be used
   if the exact spelling is unknown.  The '*' (asterisk, 0x2A) is used
   in place of zero or more characters, '+' (plus, 0x2B) in place of one
   or more unknown characters, and '?' (question mark, 0x3F) can be used
   when exactly one character is unknown.  If the unknown character can
   be one of a limited set this can be specified by surrounding the set
   with brackets, e.g., [ei] means that in that place an 'e' or an 'i'
   would match.






Hedberg & Pomes              Informational                      [Page 6]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


3.  Commands

3.1.  status

   status

   Prints the message of the day and the current status of the
   nameserver.

      C: status
      S: 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

3.2.  siteinfo

   siteinfo

   Returns information about the servers site. Possible fields are

   Version        Version information for the server.
   Maildomain     The mail domain to use for phquery-type mail.
   Mailfield      The field containing the specific email address.
   Mailbox        Mandatory entry that names the field to use as
                  maildrop.
   Administrator  Guru in charge of service.
   Passwords      Person in charge of ordinary password/change requests.
   Authenticate   Authentication methods supported by the server,
                  ordered in the site-preferred way.  Presently the
                  following options are defined:

                    1   attempt auto login
                    2   allowed to be interactive if needed
                    4   use ANSI X9.9 challenge/response
                    8   use v4 Kerberos login
                    16  use v5 Kerberos [KRB5] login
                    32  use GSS-API [GSS-API] login
                    64  use email login
                    128 password encrypted response to challenge
                    256 use clear-text password
                    512 use HMAC [HMAC] with SHA-1 of challenge string








Hedberg & Pomes              Informational                      [Page 7]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


   Example

        C: siteinfo
        S: -200:1:version:3.1
        S: -200:2:maildomain:umu.se
        S: -200:3:mailfield:alias
        S: -200:4:mailbox:email
        S: -200:5:administrator:[e-mail]
        S: -200:6:passwords:[e-mail]
        S: -200:7:authenticate:64:32:128
        S: 200: Ok.

   The mail fields in the siteinfo command direct how address
   information stored in the Nameserver is to be used for delivering