[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
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    |
        |                    |        |   <paf@swip.net>           |
        |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 <URL:ftp://ftp.internic.net/rfc/>, 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 <draft-ietf-asid-whoispp-02.txt>.

     [2] S. Weibel.  "Metadata: The Foundations of Resource Descrip-
     tion", D-Lib Magazine, July 1995.
     <URL:http://www.ukoln.ac.uk/dlib/dlib/July95/07weibel.html>
     <URL:http://www.dlib.org/dlib/July95/07weibel.html>

     [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.
     <URL:http://purl.org/metadata/dublin_core>

     [10] L. Dempsey, S. Weibel.  "The Warwick Metadata Workshop: A
     Framework for the Deployment of Resource Description", D-Lib Maga-
     zine, July/August 1996.
     <URL:http://www.ukoln.ac.uk/dlib/dlib/july96/07weibel.html>
     <URL:http://www.dlib.org/dlib/july96/07weibel.html>

     [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" <jd@ftp.bar.org> 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.