ASID Working Group Patrik Faltstrom INTERNET-DRAFT Tele2/Swipnet Expires Septebmer 1998 Martin Hamilton Loughborough University Leslie L. Daigle Bunyip Information Systems, Inc. Jon Knight Loughborough University March 1998 WHOIS++ templates Filename: draft-ietf-asid-whois-schema-03.txt 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 ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Abstract WHOIS++ is a simple Internet search and retrieval protocol, specified in [1], which allows clients and servers to exchange structured data objects known as templates. In the interests of interoperability it is desirable to have a common base schema for these templates. This document suggests a schema drawn from implementation and deployment experience to date with WHOIS++. Table of Contents: 1. Purpose and motivation 2. Scope of this document 3. What we did 4. Templates and clusters 5. Cluster definitions 6. Template definitions 7. System templates 8. Security considerations 9. Conclusions 10. Acknowledgements 11. References 12. Authors' addresses A. APPENDIX A: Description of elementary attribute values B. APPENDIX B: Representing the Dublin Core in WHOIS++ C. APPENDIX C: Representing the Internet Whitepages Schema (IWPS) in WHOIS++ 1. Purpose and motivation The goal of this document is to stimulate discussion on the issue of templates for WHOIS++ [1] databases. In particular we would like to recommend a few typical templates and a set of attributes for them. By recommending the use of particular templates, we hope to standardize WHOIS++ databases and thus make them easier to search. Of course we cannot demand that everyone use the same templates, but it is still a good idea to recommend that people derive their own templates from well known exemples. Amongst other things this allows clients to behave rationally for all fields in a "base class". 2.. Scope of this document Note that we are not trying to describe all possible information that could be put in a database but rather to cover common and useful elements. 3. What we did We looked at IETF drafts, the content of deployed WHOIS++ servers, other White and Yellow Pages servers, and at the work of the Dublin Core group [2] on cataloguing on-line document-like objects. The proposed templates are a mix of all these things but are most strongly influenced by the templates defined by the IAFA working group of the IETF [3]. In fact some of the text in this document is taken verbatim from IAFA documents. We should also mention that wherever we thought it was necessary we tried improving on existing ways of doing things, in particular we tried to improve on the consistency of attribute naming and of the general nomenclature. 4. Templates and clusters To ease the understanding of how the templates are defined, consider that each template is defined by attributes and clusters. Each cluster is in turn also defined by attributes and clusters. This clustering principle is only used in this specification to make it easier to describe what attributes should be grouped together, and what attributes are required in a template. One can see the clustering principle we use in this document as a sort of grammar. As an example, one can have the following cluster definition: Cluster INGREDIENTS Name: Color: Weight: Volume: If the template definition then is Template DESSERT Dessert: Ingredients-(INGREDIENTS*): Then the following record is legal: Dessert: Chocolate Mousse Ingredients-Name: Chocolate Ingredients-Color: Brown Ingredients-Weight: 150g Ingredients-Name: Cream Ingredients-Color: White Ingredients-Weight: 2.5dl Each attribute may be repeated within one record (as you can see above). It is important to note that the WHOIS++ protocol imposes ordering on the attributes within the templates. For example - if there were two INGREDIENTS clusters included in a DESSERT template, the attributes from each INGREDIENTS cluster would be grouped together. In the tables of attributes which follow, the "Rec. ?" heading is used to indicate whether an attribute is recommended. All attributes are essentially optional, e.g. the Volume attribute in the INGREDIENTS cluster above, but templates will typically need to contain at least the recommended attributes in order to be useful. 5. Cluster definitions ADDRESS cluster This cluster describes the physical address of an object. If any of the more detailed Address-* attributes are specified, they should mirror the content of the Address attribute which should always be specified. +------------------+--------+-------------------------------+ |Name | Rec. ? | Description | +------------------+--------+-------------------------------+ |Address: | R | Full address | |Address-Type: | | Type of address, e.g. Work or | | | | Home | |Address-City: | R | City | |Address-Country: | R | Country | |Address-Room: | | Room | |Address-State: | | State, county or province | |Address-Street: | | Street | |Address-Zip-Code: | | Zip code | |Address-Locality: | | Geographic region | +------------------+--------+-------------------------------+ CERTNAME cluster This cluster is used to describe the name of an organization issuing a certificate, Certificate Revocation List (CRL) or the name of a certificate holder. +------------+--------+---------------------+ |Name | Rec. ? | Description | +------------+--------+---------------------+ |Country: | R | Country | |Name: | R | Organization name | |Department: | | Organizational unit | |CommonName: | | Common name | +------------+--------+---------------------+ CERTVALID cluster This cluster is used to describe validity period of a certifi- cate/CRL. +----------------------+--------+--------------------------+ |Name | Rec. ? | Description | +----------------------+--------+--------------------------+ |Date-Valid-NotBefore: | R | Start of validity period | |Date-Valid-NotAfter: | R | End of validity period | +----------------------+--------+--------------------------+ EMAIL cluster This cluster describes the email address of an object. Separate forms are given for Internet and X.400/MHS style email addresses, so as to avoid confusion between the two. +------------+--------+-------------------------+ |Name | Rec. ? | Description | +------------+--------+-------------------------+ |Email: | | Electronic mail address | |Email-X400: | | X.400 mail address | +------------+--------+-------------------------+ NAME cluster This cluster may be used to describe a person's name. Several permu- tations are provided, to cater for the various approaches to writing names in different cultures. If any of the more detailed Name-* attributes are specified, they should mirror the content of the Name attribute which should always be specified. +-------------+--------+-----------------------------------+ |Name | Rec. ? | Description | +-------------+--------+-----------------------------------+ |Name: | R | Full name | |Name-First: | | First name | |Name-Last: | | Last name | |Name-Middle: | | Middle name or initial | |Name-Prefix: | | Includes idenfitiers such as Dr., | | | | Ms., Prof. | |Name-Suffix: | | Includes identifiers such as Jr., | | | | Sr., ... | +-------------+--------+-----------------------------------+ ORGANIZATION cluster This cluster is used to describe an organization in a particular tem- plate. +-----------+--------+-------------------------------------+ |Name | Rec. ? | Description | +-----------+--------+-------------------------------------+ |(ADDRESS*) | | Address of organization | |(EMAIL*) | | Electronic mail address(es) of | | | | organization | |Name: | R | Name of organization | |(PHONE*) | | Telephone number(s) of organization | |Type: | | Type of organization (University, | | | | commercial, etc.) | |URI: | | Uniform Resource Identifier of | | | | organization | +-----------+--------+-------------------------------------+ ORG-PERSON cluster This adds information about the organization the person is associated with, for use with the PERSON cluster. +-----------------------------+--------+-----------------------------+ |Name | Rec. ? | Description | +-----------------------------+--------+-----------------------------+ |Department: | R | Department to which person | | | | belongs in organization | |Organization-(ORGANIZATION*) | R | Information about the | | | | organization where person | | | | works | |Title: | | Title of person within | | | | organization | +-----------------------------+--------+-----------------------------+ PERSON cluster This cluster is used to describe Homo Sapiens. +--------------+--------+-------------------------------+ |Name | Rec. ? | Description | +--------------+--------+-------------------------------+ |(EMAIL*) | | Electronic mail address(es) | | | | of person | |(ADDRESS*) | | Address of person | |(PHONE*) | | Telephone contact information | | | | of person | |(NAME*) | R | Name of person | |(ORG-PERSON*) | R | Organization related | | | | personal contact | | | | information | |Homepage-URI: | | Uniform Resource | | | | Identifier of person's | | | | home page | |Picture-URI: | | Uniform Resource | | | | Identifier of person's | | | | picture | |Language-pref:| | Person's language of | | | | preference | +--------------+--------+-------------------------------+ PHONE cluster This cluster is used to hold telephone contact details for an object. +------------+--------+----------------------------------+ |Name | Rec. ? | Description | +------------+--------+----------------------------------+ |Phone-Type: | | Type of phone, e.g. Work or Home | |Cellular: | | Cellular telephone number | |Fax: | | Fax telephone number | |Pager: | | Pager telephone number | |Phone: | | Telephone number | +------------+--------+----------------------------------+ Note that we recommend that full international format be used for telephone numbers for portability - e.g. +44 1509 228237. See Appendix A for more information. PGP-PUBLIC-KEY cluster This cluster is used to include or refer to a PGP [4] public key. If included directly, the PGP public key should be base64 encoded ("ASCII armored") for portability. +--------------------+--------+----------------------------+ |Name | Rec. ? | Description | +--------------------+--------+----------------------------+ |PGP-Version: | | PGP version, e.g. 2.6.3i | |PGP-Key-Length: | R | Public key length, | | | | e.g. 1024 | |PGP-Key-ID: | R | Public key ID, | | | | e.g. FB5E1519 | |PGP-Key-Name: | R | Name associated with key | | | | e.g. Patrik Faltstrom | | | | | |PGP-Fingerprint: | | Public key checksum, | | | | e.g. 2C E2 6F... | |PGP-Public-Key: | R | PGP key in "ASCII Armour" | |PGP-Public-Key-URI: | | Uniform Resource | | | | Identifier of public key | +--------------------+--------+----------------------------+ RECORD cluster This cluster is used to hold administrative information about a record. +---------------------------------------+--------+-------------------+ |Name | Rec. ? | Description | +---------------------------------------+--------+-------------------+ |Record-Creation-Contact-(PERSON*) | | Contact | | | | information for | | | | person who | | | | created this | | | | record | |Record-Creation-Date: | | The date this | | | | record was | | | | created | |Record-Last-Modified-Contact-(PERSON*) | | Contact | | | | information for | | | | person who last | | | | modified this | | | | record | |Record-Last-Modified-Date: | | The date this | | | | record was last | | | | modified | |Record-Last-Verified-Contact-(PERSON*) | | Contact | | | | information for | | | | person who last | | | | verified this | | | | record | |Record-Last-Verified-Date: | | The date this | | | | record was last | | | | verified | +---------------------------------------+--------+-------------------+ 6. Template definitions DOCUMENT template This template is used to hold information about document-like objects. Note that an expanded set of attributes may be used to fully repre- sent Dublin Core objects, as per Appendix B. At the time of writing these were still under development. +--------------------------+--------+-------------------------------------+ |Name | Rec. ? | Description | +--------------------------+--------+-------------------------------------+ |Title: | | The name of the resource | |Creator: | | The person(s) primarily | | | | responsible for the intellectual | | | | content of the resource | |Creator-(PERSON*) | | See Creator: | |Subject: | | The topic addressed by the resource | | | | or a set of appropriate keywords | |Description: | | A plain text description or | | | | abstract about the resource | |Publisher: | | The agent or agency responsible for | | | | making the resource available | |Publisher-(ORGANIZATION*) | | See Publisher: | |Contributors: | | The person(s), such as editors | | | | and transcribers, who have made | | | | other significant intellectual | | | | contributions to the work | |Contributors-(PERSON*) | | See Contributors: | |Date: | | The date of publication | |Type: | | The genre of the resource, such as | | | | novel, poem, or dictionary | |Format: | | The physical manifestation of the | | | | resource, such as Postscript file | | | | or Windows executable file | |Identifier: | | String or number used to uniquely | | | | identify the resource | |Source: | | Resources, either print or | | | | electronic, from which this | | | | resource is derived, if | | | | applicable | |Language: | | Language of the intellectual | | | | content | |Relation: | | Relationship to other resources | |Coverage: | | The spatial locations and temporal | | | | durations characteristic of the | | | | resource | |Rights: | | Information concerning the | | | | intellectual property rights that | | | | are being exercised over the | | | | resource (including access terms) | |(RECORD*) | | Record information | +--------------------------+--------+-------------------------------------+ ORGANIZATION template This template is used to hold details about an organization. In practice both spellings - "ORGANISATION" and "ORGANIZATION" - may be in use. We recommend that ORGANIZATION be given preference to avoid confusion. +-----------------------------+--------+---------------------------------+ |Name | Rec. ? | Description | +-----------------------------+--------+---------------------------------+ |Keywords: | | Any keywords which might | | | | facilitate finding this | | | | record | |Internet-Domain: | | Organization's Internet | | | | domain name | |Domain-Contact-(PERSON*): | | Admin contact for this | | | | domain | |(ORGANIZATIION*) | | Actual organization information | |(RECORD*) | | Record information | +-----------------------------+--------+---------------------------------+ ORG-ROLE template This template is used to hold details about a particular role within an organization. These roles (like "president", "front desk", "service counter") may or may not be associated with a person or persons. This template will contain necessary contact information for the role irrespective of the (current) incumbent person, if any. +------------------------------+--------+-------------------------------+ |Name | Rec. ? | Description | +------------------------------+--------+-------------------------------+ |Keywords: | | Any keywords which might | | | | facilitate finding this | | | | record | |Org-Role: | R | Name of the role | |(EMAIL*) | | E-mail contact info for role | |(PHONE*) | | Phone contact info for role | |Organization-(ORGANIZATION*) | | The organization to which | | | | this role belongs | |(NAME*) | | Name of person in role | |(PGP-PUBLIC-KEY*) | | The role's PGP public key(s) | |(RECORD*) | | Record information | +------------------------------+--------+-------------------------------+ SERVICE template This template is used to describe an on-line service. +---------------------------+--------+---------------------------------+ |Name | Rec. ? | Description | +---------------------------+--------+---------------------------------+ |Title: | R | Title of object | |Category: | | Type of object | |Short-Title: | | Summary title | |Alternative-Title: | | An alternative to the Title | | | | or Short-Title fields | |Source: | | Information as to the | | | | definitive version | |Discussion: | | Appropriate discussion forums | |Language: | | The language of the object | |ISSN: | | International Standard Serial | | | | Number if appropriate | |URI: | R | Uniform Resource Identifier | |Admin-(USER*) | | Admin contact information | |Owner-(ORGANIZATION*) | | The organization | | | | sponsoring the service | |Sponsoring-(ORGANIZATION*) | | The | | | | sponsoring organization | |Publisher-(ORGANIZATION*) | | The organization | | | | publishing the service | |Description: | R | Free text description | |Authentication: | | Authentication information | |Registration: | | How to register for this | | | | service | |Charging-Policy: | | Description of any | | | | charging mechanism in place | |Access-Policy: | | Policies and restrictions | | | | for using this service | |Access-Times: | | Time ranges for mandatory | | | | or preferred access | |Keywords: | R | Keywords appropriate for | | | | describing this service | |Subject-Descriptor-Scheme: | | Name of | | | | classification scheme | |Subject-Descriptor: | | A classification | | | | mark for this resource | |To-Be-Reviewed-Date: | | Date on which the | | | | resource is to be re-assessed | |Comments: | | Comments by the template | | | | creators | |Destination: | | Which database the | | | | template is destined for | |(PGP-PUBLIC-KEY*) | | PGP public key(s) | |(RECORD*) | | Record information | +---------------------------+--------+---------------------------------+ USER template This template is used to hold details about a person. The IDS Working Group of the IETF has proposed an abstract schema for Internet white pages services [11]; the details of how that abstract schema can be represented in a WHOIS++ USER template are provided in Appendix C. +------------------+--------+-------------------------------------+ |Name | Rec. ? | Description | +------------------+--------+-------------------------------------+ |Keywords: | | Any keywords which might facilitate | | | | finding this record | |(PERSON*) | | Actual user information | |(PGP-PUBLIC-KEY*) | | Their PGP public | | | | key(s) | |X509-CERT-URI | | URI for the USER's X.509 certificate| | | | (May be a Whois++ URI for the | | | | appropriate X509-CERT template) | |(RECORD*) | | Record information | +------------------+--------+-------------------------------------+ X509-CERT template This template is used to describe an X.509 [5] certificate. +--------------------+--------+--------------------------------+ |Name | Rec. ? | Description | +--------------------+--------+--------------------------------+ |X509-Version: | | Certificate version number | |SerialNumber: | R | Certificate serial number | |Signature: | | Signature of issuer | |Issuer-(CERTNAME*) | R | Issuer of certificate | |(CERTVALID*) | | Validity period of certificate | |Subject-(CERTNAME*) | | Subject of certificate | |Subject-PublicKey: | | Public key of subject | |Certificate: | R | The certificate | |(RECORD*) | | Record information | +--------------------+--------+--------------------------------+ X509-CRL template. This template is used to describe a Certificate Revocation List. +-------------------+--------+------------------------+ |Name | Rec. ? | Description | +-------------------+--------+------------------------+ |Signature: | | Signature of issuer | |Issuer-(CERTNAME*) | | Issuer of CRL | |(CERTVALID*) | | Validity period of CRL | |CRL: | R | The CRL | |(RECORD*) | | Record information | +-------------------+--------+------------------------+ 7. System templates CONSTRAINT template This template is used by the "constraints" command to list valid con- straints supported by the server. +------------+--------+------------------------------------------+ |Name | Rec. ? | Description | +------------+--------+------------------------------------------+ |Default: | R | The default value for this constraint | |Constraint: | R | The constraint described | |Range: | | A list of values supported by the server | |(RECORD*) | | Record information | +------------+--------+------------------------------------------+ HELP template This template is used by the "help" command to access a simple help subsystem giving information about the available commands. +-------------+--------+----------------------------+ |Name | Rec. ? | Description | +-------------+--------+----------------------------+ |Command: | R | Command name | |Description: | R | Description of the command | |Topic: | R | Command category | |Usage: | R | Command usage | |(RECORD*) | | Record information | +-------------+--------+----------------------------+ SERVERHANDLE template This template describes a WHOIS++ server. +-----------------------------+--------+-------------------------------+ |Name | Rec. ? | Description | +-----------------------------+--------+-------------------------------+ |Administrator-(PERSON*) | | Contact information about | | | | the person administering | | | | the server | |City: | | City where the server resides | |Country: | | Country where the server | | | | resides | |Description: | | Human readable information | | | | about the server | |Host-Name: | R | Host name | |Host-Port: | R | Port name used by server | |Organization-(ORGANIZATION*) | | Organization responsible for | | | | the server | |Server-Handle: | R | Registered server handle | |State: | | State, or province | | | | where the server resides | |(PGP-PUBLIC-KEY*) | | Server's PGP key | |(RECORD*) | | Record information | +-----------------------------+--------+-------------------------------+ VERSION template This template is used by the "version" command to obtain the current version of the WHOIS++ protocol supported by the server. +-------------------------+--------+---------------------------------+ |Name | Rec. ? | Description | +-------------------------+--------+---------------------------------+ |Database-Name: | | Name of the underlying database | | | | program | |Database-Version: | | Version of the underlying | | | | database program | |Program-Author-(PERSON*) | | Information about the server | | | | programmer | |Program-Name: | | Name of the server program | |Program-Version: | | Version of the server program | |Version: | R | Version of the WHOIS++ protocol | |(RECORD*) | | Record information | +-------------------------+--------+---------------------------------+ 8. Security considerations A WHOIS++ server is only serving the data that is stored in the server itself. Neither the storage, the movement into the server nor the fetching of the data can be seen as secure operations. Because of that, data that is stored in a WHOIS++ server have to be controlled for correctness by an out of band mechanism. For example, public keys stored in a WHOIS++ server have to be signed when stored there. A key checksum of a public key when stored in a WHOIS++ server cannot be treated as correct because of this. It is just there for informa- tion. A directory service hands out information, but does not guarantee the correctness of any information. One of the main uses to which WHOIS++ templates are expected to be put is in the cataloguing of externally produced information. Imple- mentations which manipulate this should treat it with caution - for example, to avoid buffer overrun problems and unexpected evaluation of metacharacters. 9. Conclusions This document has outlined a number of template definitions which it is appropriate to use within a WHOIS++ based system. Whilst it is not going to be possible to satisfy everyone's requirements in a sin- gle schema, we believe that the above templates cater for the major- ity of cases. Further discussion of this work is directed to the WHOIS++ schema mailing list - whoispp-schema@bunyip.com. Send mail to major- domo@bunyip.com with the message body "subscribe whoispp-schema" to join the list. 10. Acknowledgements Thanks to Lorcan Dempsey and Rachel Heery for their comments on draft versions of this document, and to Francois Perrault for initial work on WHOIS++ template usage. This work was supported in part by UK Electronic Libraries Programme (eLib) grant 12/39/01, the European Commission's Telematics for Research Programme, grant RE 1004, and National Science Foundation grant NCR-9521074. 11. References Request for Comments (RFC) documents and Internet Drafts are available from , and numerous mirror sites. [1] P. Deutsch, R. Schoultz, P. Faltstrom and C. Weider. "Archi- tecture of the WHOIS++ service", RFC 1835. August 1995. An update to this document is . [2] S. Weibel. "Metadata: The Foundations of Resource Descrip- tion", D-Lib Magazine, July 1995. [3] P. Deutsch, A. Emtage, M. Koster, and M. Stumpf. "Publishing Information on the Internet with Anonymous FTP", Internet Draft (work in progress), June 1995. [4] D. Atkins, W. Stallings, P. Zimmermann. "PGP Message Exchange Formats", RFC 1991. August 1996. [5] ITU-T Recommendation X.509 (1993) | ISO/IEC 9594-8: 1993, Information Technology - Open Systems Interconnection - The Direc- tory: Authentication Framework. [6] D. Crocker. "Standard for the format of ARPA Internet text messages", RFC 822. August 1982. [7] R. Braden. "Requirements for Internet hosts - application and support", RFC 1123. October 1989. [8] BibTeX(1) Manual Page, Oren Patashnik, June 1984. [9] S. Weibel, E. Miller. Dublin Core Home Page. [10] L. Dempsey, S. Weibel. "The Warwick Metadata Workshop: A Framework for the Deployment of Resource Description", D-Lib Maga- zine, July/August 1996. [11] T. Genovese, Barbara Jennings, "A Common Schema for the Internet White Pages Service", IETF IDS Working Group draft, June 1997. 12. Authors' addresses Patrik Faltstrom Tele2/Swipnet Box 62 Borgarfjordsgatan 16 S-164 94 Kista Sweden Email: paf@swip.net Leslie L. Daigle Bunyip Information Systems Inc. 310 Ste. Catherine St. West Suite 300 Montreal, Quebec, Canada H2X 2A1 Email: leslie@bunyip.com Martin Hamilton Department of Computer Studies Loughborough University of Technology Leics. LE11 3TU, UK Email: m.t.hamilton@lut.ac.uk Jon Knight Department of Computer Studies Loughborough University of Technology Leics. LE11 3TU, UK Email: j.p.knight@lut.ac.uk APPENDIX A: Description of elementary attribute values The IAFA draft and RFC822 [6] already define formats for: email addresses hostnames IP addresses numeric values dates times time ranges telephone numbers latitude and longitudes person names Here is a reminder of what those elementary data elements should look like according to IAFA: All electronic mail (Email addresses must be as defined in RFC 822, Section 6. Names and comments may be included in the Email address. For example, both "John Doe" and jd@ftp.bar.org are valid email addresses. All hostnames are to be given as Fully Qualified Domain Names as defined in RFC 1034, Section 3. For example: "foo.bar.com" All host IP addresses are given in "dotted-quad" (or "dotted- decimal") notation. For example: "127.0.0.1" All numeric values are in decimal unless otherwise stated. Dates/times must be given as defined in RFC 822, Section 5.1 and mod- ified in RFC 1123 [7], Section 5.2.14: date-time = [ day "," ] date [time] day = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun" date = 1*2DIGIT month 2*4DIGIT ; day month year ; e.g. 20 Jun 1982 month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" time = hour zone ; ANSI hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] ; 00:00:00 - 23:59:59 zone = "UT" / "GMT" ; Universal Time ; North American : UT / "EST" / "EDT" ; Eastern: - 5/ - 4 / "CST" / "CDT" ; Central: - 6/ - 5 / "MST" / "MDT" ; Mountain: - 7/ - 6 / "PST" / "PDT" ; Pacific: - 8/ - 7 ; / ( ("+" / "-") 4DIGIT ) ; Local differential ; hours+min. (HHMM) For example the string "Sat, 18 Jun 1993 12:36:47 -0500" is a valid date, and the string "12:36:47 GMT" is a valid time. Quoting from RFC 1123, Section 5.2.14: "There is a strong trend towards the use of numeric timezone indicators, and implementations SHOULD use numeric timezones instead of timezone names. However, all implementations MUST accept either notation. If timezone names are used, they MUST be exactly as defined in RFC 822." Time ranges (or periods) must be specified as pairs of time values (as defined above in note (5)), separated by a "/". Multiple time ranges are separated by whitespace. All times in a range should be specified with the same timezone. For example 12:00 GMT / 05:45 GMT. "whitespace" is defined as one or more blank (hex 0x20) and/or tab (octal 11) ASCII characters. References to "UT" mean Universal Time (also known as Greenwich Mean Time or "GMT"). All telephone numbers are to be given as a minimum in full, with a leading '+' and country and routing codes without non-space separa- tors. The number should be given assuming someone calling interna- tionally (without local access codes). The number given in the local convention may optionally be specified in brackets. For example, Telephone: +44 71 732 8011 or Telephone: +1 514 875 8189 (0514-875-8611). Latitude and longitude are specified in that order as CDD.MM.SS/CDD.MM.SS where DD is in degrees MM is in minutes SS is in seconds C is the direction designator which is for latitude "+" is north of the equator and "-" is south of the equator. For lon- gitude "+" is west of the Greenwich meridian and "-" is east of the Greenwich meridian. The double quotes (") are not part of the desig- nator, but are used here to delimit the symbols. Person name fields should conform to a particular format (based on BibTeX [8]), so that they can be parsed into parts. A name can have four parts: first, von, last, junior, each of which can consist of more than one word. For example, "John Paul von Braun, Jr." has "John Paul" as the first part, "von" as the von part, "Braun" as the last part, and "Jr." as the junior part Use one of these formats for a name: First von Last von Last, First von Last, Junior, First The last part is assumed to be one word, or all the words after the von part. Anything in braces will be treated as one word, so use braces to surround last names that contain more than one word. The von part is recognized by looking for words that begin with lowercase letters. When possible, enter the full first name(s). Actually, the rules for isolating the name parts are a bit more complicated, so they do the right thing for names like "de la Grand Round, Chuck". If there are multiple authors or editors, they should all be sepa- rated by the word and. APPENDIX B: Representing Dublin Core in WHOIS++ The Dublin Core is a simple resource description format which arose out of a loose grouping of "librarians, archivists, humanities schol- ars and geographers, as well as standards makers in the Internet, Z39.50 and Standard Generalized Markup Language (SGML) communities" [2]. This document proposes a mapping from the abstract model of the Dublin Core to WHOIS++. We suggest that the Dublin Core element set [9] (with the concrete syntax given in the DOCUMENT template above) be used as WHOIS++ attributes, and that the template type "DOCUMENT" be used to represent a WHOIS++ template which uses the Dublin Core element set. For example, a "Title" element which had the value "Cities of The Red Night" would be represented within WHOIS++ as the attribute/value pair: Title: Cities of The Red Night One aspect of the Dublin Core does not translate directly to WHOIS++ - each element may have additional qualifiers such as "scheme" asso- ciated with it. This provides the creator of the record with a way of indicating additional semantics, e.g. the classification scheme being used in the "Subject" element. Since WHOIS++, like most Internet based search and retrieval proto- cols, is attribute/value oriented, it is necessary to find a place to put this extra information. We propose that it be placed in an addi- tional attribute/value pair which precedes the main information about the element. For example, if the subject classification for the above book were 813 in the Dewey Decimal system, the resulting Dublin Core elements expressed via WHOIS++ might look like this: Subject-Scheme: DDC Subject: 813 Since the order of the attribute/value pairs in a WHOIS++ record is significant, this provides a simple and easily implemented mechanism for grouping together elements and their qualifying information. Needless to say, scheme information should only appear in the WHOIS++ record if the attribute it qualifies also appears! It is important to note that the Dublin Core element set is intended for use in describing document-like objects, and not as a means of describing arbitrary objects. Furthermore, the number of elements is strictly limited in the interests of interoperability. Work is ongoing on the Warwick Framework [10], which attempts to pro- vide a mechanism for packaging together collections of descriptive information. It is envisaged that this would be used in cases where the Dublin Core element set did not provide enough descriptive capa- bility. This is a subject for further study and is beyond the scope of this specification. APPENDIX C: Representing the Internet Whitepages Schema (IWPS) in WHOIS++ The IETF's IDS working group has defined a standardized abstract schema for "a simple Internet Whitepages Service". The reader is referred to the documentation describing that schema ([11]) for details on the expected syntax, precise content and length limitations for individual attributes. +-------------------------+-----------------------------------+ | IWPS Field | WHOIS++ USER Template Attribute | +-------------------------+-----------------------------------+ | Email | Email or Email-X400 | | Cert | (* see below) | | Home Page | Homepage-URI | | Common Name | Name | | Given Name | Name-First | | Surname | Name-Last | | Organization | Organization-Name | | Locality | Address-Locality | | Country | Address-Country | | Language Spoken | Language-Pref | | Personal Phone | Phone | | Personal Fax | Fax | | Personal Mobile Phone | Cellular | | Personal Pager Number | Pager | | Personal Postal Address | Address | | Description | Picture-URI | | Title | Title | | Office Phone | Organization-Phone | | Office Fax | Organization-Fax | | Office Mobile Phone | Organization-Cellular | | Office Pager | Organization-Page | | Office Postal Address | Organization-Address | | Creation Date | Record-Creation-Date | | Creator Name | Record-Creation-Contact-Name | | Modified Date | Record-Last-Modified-Date | | Modifier Name | Record-Last-Modified-Contact-Name| +-------------------------+-----------------------------------+ The "Cert" attribute, as described by the IWPS document, is as follows: "The certificate field is intended to hold any kind of certificate; X.509 certificates are one example. A specific implementation will specify how to indicate the type of certificate when describing the mapping of the IWPS schema onto the implementation schema." As the Whois++ USER certificate is set up to accommodate both PGP keys and X.509 pointers, this one IWPS field is defined to conditionally be mapped to the appropriate fields for each technology: PGP-Version PGP-Key-Length PGP-Key-ID PGP-Fingerprint PGP-Public-Key and/or PGP-Public-Key-URI and/or X509-CERT-URI with appropriate attendant information (e.g. PGP-NAME, etc) as appropriate.