INTERNET-DRAFT Roland Hedberg <draft-ietf-ids-ph-00.txt> Umea University Expires: May, 1996 Steve Dorner Qualcomm Inc Paul Pomes Qualcomm Inc The CCSO Nameserver (Ph) Architecture Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of theis memo is unlimited. Comments and critique of this document are welcome. Send them to IETF IDS mailing list or directly to the authors . Abstract The PH Nameserver from the 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. It is now widely felt that the Internet community would benefit from having a more rigorous definition of the client-server protocol, this document will hopefully achieve that goal. The PH service as specified in this document are built around an information model, a client command language and the server responses. 1. Overview 1.1 Basic Information Model The Ph database can be thought of as a computer resident "phone book". It was designed to keep a relatively small amount of 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 he wants to present of the real-world objects that are to be represented in the database. To support this concept ph has the notion of named information; that is categorizing information and assigning names to the categories. Even if the database resides and is reachable from the Internet is local in the meaning that each Nameserver has no knowledge about the existence of other Nameservers, except for the possibility that there might be a list of other nameservers in the database. It is therefore up to the client to navigate between different servers. 1.1.1 Types The way to specify the views to be represented lies in the choice of "type"'s, which are named collections of fields. For instance one would assume that the type "person" should include a field for "name" as well as one for "personal_title". Apart from the fields defined to be need in the entry in this way every entry also must contain a number of default fields, namely "type" ,"last-changed" and "expire". Since each individual entry must have a field named "type", where the types of the entry are listed, the users of the database has a way of finding out what kind of information that can be extracted from the database regarding a specific entry. The type field can also be used when searching to limit the search to a set of entries. eg. "person"'s . 1.1.2 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 the field, and keywords describing the properties of the field. The keywords can be one of the following : Indexed: At least one indexed field must be present in each query. The indexed fields should be handled by the server in such away as to make searches on these fields especially efficient. Public: May be viewed by anyone, fields not marked public may only be viewed by the entry's owner in login mode or by someone in hero mode. Default: Printed if no return clause is given in the query. Lookup: May be used in the selection part of a query; a field not marked Lookup may not be used to select entries. Change: Can be changed by the owner of the entry. Encrypt: Must be encrypted before transmission. ForcePub: Viewable/searchable regardsless of the content of the suppress field NoPeople: No entry of type "person" may include this field. 1.1.3 Character Sets Historicly PH has been restricted to only handle printable characters, that is characters with hexadecimal values between 0x20 and 0x7f. Lately with the speading 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 the default characterset for PH. If a client can not handle US-ASCII it should request the server to return only US-ASCII by using the "set"-command, how the server performs the mapping between ISO-8859-1 and US-ASCII is not defined in this paper. 1.2 Standardization issues Each Nameserver manager is in essence free to name new types and fields to suit the special needs of his/her organization. But in order to make the directory service useful even outside of the organization it is recommended that a core set of standard types and fields always should be present. Therefore this document defines a couple of standard collections of fields, each coupled to a object type (Appendix A). Also note that the architecture makes no assumption about the search and retrival 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 retrive the information, if desired. The Ph simply functions as a known front-end, offering a simple data model as well as 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. 2. Basic Operation Initially, the server host starts the PH service by listening on TCP port 481. 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 exchanges commands and responses (respectively) until the connection is closed or aborted. 2.1 command syntax Commands in PH consists of a keyword possibly 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. 2.2 Respones syntax Responses consists of a result code followed by additional information possibly separated by entry index and/or field name and is 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, except the last, in the response 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 one entry is return on consecutive lines, and that all those lines must have one and the same entry index directly following the resultcode. The first entry index should be 1, and be incremented each time a new entry is being referred to. 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 intended for human consumption, or data from the Nameserver. Whitespace (spaces or tabs) may appear anywhere in the response. Since more than one specific piece of information may be manipu- lated by a particular command, it is possible for parts of a com- mand 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. As for FTP, the result codes are in the range 100-599 (or from -599 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 worthwile to try again. 5: Permanent failure 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. Client should not make any assumptions as to which numerical responses, within the above mentioned range, that are valid, since these may change over time (the ones active right now are listed in Appendix B). Also mark that the server is allowed to send one or more lines with resultcodes between -199 - -100 and 100 - 199, as status information, before the actual results are transmitted. 2.4 Mail address handling The handling of mailaddresses has a special tweak in PH. In order to make this clear some initial definitions are needed, in this text the following definitions are used: mailaddress - the address which the user wishes to present to the outside world. maildrop - the internal address to which her mail should be sent. If no maildrop is defined it should be computed using the following steps : First, we have the siteinfo command, which returns three relevant values: maildomain - the mail domain for entries in the database mailfield - the field containing the specific address of the entry mailbox - the field containing the entry's maildrop I will refer to the contents of these items with {}'s. So, if we have: siteinfo -200:1:maildomain:uiuc.edu -200:2:mailbox:alias -200:3:mailfield:email then "{maildomain}" means "uiuc.edu". Given the name of a field, a reference to the contents of that field in any given entry is written as the fieldname surrounded by <>. So, If "sdorner" in the value of an "alias" field, "<alias>" is equal to "sdorner". And if "mailfield" is defined to be "alias", "<{mailfield}>" consequently is "sdorner" . All phquery-type utilities that need maildrops should use <{mailbox}>. For addresses, follow this simple algorithm to find the address: if ({maildomain} is not empty) then <{mailfield}>@{maildomain} else <{mailfield}> end 2.5 Format of a searchstring Matching is not sensitive to upper or lower case letters and is 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. Word delimiters are the following characters: <SPACE>,<TAB>,<NEWLINE>,",",";" and ":" . However, special symbols, called "wildcard" characters, can be used if the exact spelling is unknown. The *(asterix) is used in place of one or more unknown characters, while ?(questionmark) 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 eg. [ei]. 3. Commands 3.1 status Prints the current status of the nameserver C: status S: 200: Database ready 3.2 siteinfo - optional Returns information about the servers site. Maildomain - domain to use for phquery-type mail. Mailfield - field to use for phquery-type mail. Mailbox - field to use as maildrop Administrator - guru in charge of service. Passwords - person in charge of ordinary password/change requests. C: siteinfo S: -200:1:maildomain:umu.se S: -200:2:mailfield:alias S: -200:3:mailbox:email S: -200:4:administrator:roland.hedberg@umdac.umu.se S: -200:5:passwords:roland.hedberg@umdac.umu.se S: 200: Ok. 3.3 types types [type ...] Without argument a list of all types should be delivered. With types as argument. a description of the named types are given. The output of the command consists of one or more lines per type, listing which fields that are defined to belong to the named type. The meaning of the type "default" is that all entries disregarding what types they are defined to be, will contain these fields. C: types S: -200:1:default:type last_modified expires S: -200:2:person:alias name personal_title email home_page_URL S: -200:2:person:PGP_key id S: -200:3:phone:phone fax S: -200:4:staff:office_phone office_address job_title S: -200:4:staff:deparment S: 200:Ok. 3.4 fields fields [field ...] Without argument a list of all field descriptors should be delivered. With field names as argument, a description of the named fields are given. The output of the command consists of two lines describing each field. The first line defines the field in technical terms (max length and field attributes), while the second line is a brief description of what the field is intended to hold. The second number of each respons is the field id number. C: fields S: -200:6:alias:max 32 Indexed Lookup Public Default Turn S: -200:6:alias:Unique name for user. S: -200:3:name:max 64 Indexed Lookup Public Default S: -200:3:name:Fullname S: -200:2:email:max 128 Lookup Public Default S: -200:2:email:Account to receive electronic mail. S: -200:16:other:max 256 Lookup Public Default Change S: -200:16:other:Other info the user finds important. S: -200:33:home_phone:max 60 Lookup Public Change S: -200:33:home_phone:Home telephone number. S: 200:Ok. 3.5 id id information Enters the given information in the Namerservers log. This command is used by the Ph client to enter the user id of the person running it. 3.6 set set [option=[value] ...] Sets an option for this nameserver session. Used withour arguments it return the setable options. C: set verbose=off S: 200:Done. C: set S: -200:echo:off S: -200:limit:2 S: -200:characterset:iso-8859-1 S: -200:verbose:off S: -200:addonly:off S: -200:nolog:off S: 200:Done. 3.7 login, passwd and logout login [your-alias] The "login" command allows you to identify yourself to the Nameserver. More specifically, it identifies you with a particular entry in the Nameserver and allows you to change the fields in that entry and possibly other entry. It is also necessary to be logged in to the Nameserver to view certain sensitive fields in your own entry. In order to use the "login" command, you must know both your ph alias and your ph password. C: login foo S: Enter nameserver password: C: bar S: 200:foo:Hi how are you? logout The "logout" command allows a user who is logged in to the Nameserver to logout. C: logout S: 200:Ok. 3.8 add add field=value... This command is used to add new entries to the database. C: add name="doe john" id="123456789" alias="j-doe" S: 200:Ok. 3.9 query/ph query [field=]value [field=value] . . . [return field1 [field2]] If no field is specified together with a value then the field is assumed to be "name" and/or "nickname". When more than one field-value specification are given in a query, entries matching all specifications are returned (implicit AND). It if possible to define which fields should be returned by adding a 'return' clause. If no return clause is defined the Ph server will return a default list of fields. A return clause consists of the word "return" followed by a list of fields or the word "all". If the word "all" is used the all viewable fields will be returned. 3.10 delete delete [field=]value... This command is used to delete entire new entries from the database. You must be logged in and have special privileges to use "delete". The arguments to the "delete" command are the same as the selection part of a "query" command. "Delete" finds all the entries that match the argument(s) and deletes them. The "delete" command obeys the Nameserver "limit" option, which can be used to prevent deletion of more entries than intended. 3.11 make make field="value"... The "make" command allows you to change fields in your own Nameserver entry. In order to use the "make" command, you must first login to the Nameserver. 3.12 change change [field=]value make field="value"... This command is used to change one or more fields to the values specified. The "change" command consists of two clauses, the "change" clause and the "make" clause. The "change" clause determines which entries will be affected by the command. It uses the same arguments as the selection clause of a "query" command. The "make" clause specifies which field(s) will be changed and the new value(s) of the specified field(s). You must be logged in to use "change". Change differs from the "make" command in that it can modify multiple ph entries simultaneously. The "change" command obeys the Nameserver "limit" option, which can be used to prevent changing the field contents of more entries than intended. 3.13 help [{native|client}] [topic ...] Prints help on the Nameserver as such or on specific clients . 3.14 quit/exit/stop C: quit S: 200:Bye! 4. Miscellaneous 4.1 Authors Addresses Roland Hedberg Umdac Umea University 901 87 Umea Sweden <Roland.Hedberg@umdac.umu.se> Paul Pomes Qualcomm Inc USA <ppomes@qualcomm.com> Steve Dorner Qualcomm Inc USA <sdorner@qualcomm.com> Appenix A Type definitions default type last-change expire phone Information you would find in a phonebook phone fax person Information about a human being alias name personal_title RFC822-email homepage_URL staff Information about employee department office_location office_address office_phone job_title minicall pager hours nickname unit Information about a organizational unit email address homepage_URL APPENDIX B Result codes 100 In progress (general). 101 Echo of current command. 102 Count of number of matches to query. 200 Success (general). 201 Database ready, but read only. 300 More information (general). 301 Encrypt this string. 400 Temporary error (general). 401 Internal database error. 402 Lock not obtained within timeout period. 475 Database unavailable; try later. 500 Permanent error (general). 501 No matches to query. 502 Too many matches to query. 503 Not authorized for requested information. 504 Not authorized for requested search criteria. 505 Not authorized to change requested field. 506 Request refused; mut be logged in to execute. 507 Field does not exist. 508 Field is not present in requested entry. 509 Alias already in use. 510 Not authorized to change this entry. 511 Not authorized to add entries. 512 Illegal value. 513 Unknown option. 514 Unknown command. 515 No indexed field in query. 516 No authorization for request. 517 Operation failed because database is read only. 518 To many entries selected by change command. 520 CPU usage limit exceeded. 521 Change command would have overriden existing field, and the "addonly" option is on. 522 Attempt to view "Encrypted" field. 523 Expecting "answer" or "clear". 524 Names of help topics may not contain "/". 598 Command unknown. 599 Syntax error. Appendix C Description of the client command language using the augmented Backus-Naur Form (RFC822) . command = ph-command CRLF ph-command = "status" / a-command / av-command / query-command / delete-command / change-command / "help" / quit-command a-command = ( siteinfo/types/fields/id/login/help ) [attribute] av-command = ( set / add / make ) 1*attribute-value query-command = ( query / ph ) 1*selection ["return" 1*attribute] quit-command = "quit" / "exit" / "stop" change-command = change 1*selection make 1*attribute-value delete-command = "delete" selection selection = ( value / attribute-value ) *( <SPACE> ( value / attribute-value ) ) attribute-value = attribute "=" value value = atom / quoted-string atom = 1*<any CHAR except specials, SPACE and CTLs> CTL = <any ASCII control character and DEL> ; ( 0-31 , 127 ) CHAR = < any ISO-8859-1 character > ; ( 0-255 ) SPACE = < ASCII SP > ; ( 32 ) attribute = 1*( ALPHA / DIGIT / "_" / "-" ) ALPHA = <any ASCII alphabetic character> ; (65-90,97-122 ) DIGIT = <any ASCII decimal digit) ; (48-57 ) quoted-string = <"> *(qtext/quoted-pair) <"> quoted-pair = "\" CHAR qtext = <any CHAR excepting <">,"\" & CR, and including linear-white-space> linear-white-space = 1*([CRLF] LWSP-char) LWSP-char = SPACE / HTAB CRLF = CR LF HTAB = <ASCII HT, horizontal tab> ; ( 9 ) CR = <ASCII CR, carriage-return> ; ( 13 ) LF = <ASCII LF, linefeed> ; ( 10 ) specials = "=" / "*" / "?" / "\" / <">
Datatracker
Report a datatracker bug
draft-ietf-ids-ph-00
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 2378.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |