One document matched: draft-ietf-asid-whois-schema-02.txt
Differences from draft-ietf-asid-whois-schema-01.txt
ASID Working Group Patrik Faltstrom
INTERNET-DRAFT Tele2/Swipnet
Expires April 1998 Martin Hamilton
Loughborough University
Leslie L. Daigle
Bunyip Information Systems, Inc.
Jon Knight
Loughborough University
October 1997
WHOIS++ templates
Filename: draft-ietf-asid-whois-schema-02.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 RFC 1835, 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.
[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.
| PAFTECH AB 2003-2026 | 2026-04-19 15:20:40 |