home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_ietf_a_c
/
draft-ietf-asid-whois-schema-00.txt
< prev
next >
Wrap
Text File
|
1996-11-26
|
46KB
|
1,233 lines
ASID Working Group Patrik Faltstrom
INTERNET-DRAFT Tele2/Swipnet
Expires May 1997 Martin Hamilton
Loughborough University
Leslie L. Daigle
Bunyip Information Systems, Inc.
Jon Knight
Loughborough University
November 1996
WHOIS++ templates
Filename: draft-ietf-asid-whois-schema-00.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:
[Page 1]
INTERNET-DRAFT November 1996
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++
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 though it was necessary we
[Page 2]
INTERNET-DRAFT November 1996
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
Desert:
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
ADDRESS clusters included in an ORGANIZATION template, the attributes
[Page 3]
INTERNET-DRAFT November 1996
from each ADDRESS cluster would be grouped together.
In the tables of attributes which follow, the "Rec. ?" heading is
used to indicate whether an attribute is recommended.
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, departement or province |
|Address-Street: | | Street |
|Address-Zip-Code: | | Zip code |
+------------------+--------+--------------------------------+
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 |
+------------+--------+---------------------+
[Page 4]
INTERNET-DRAFT November 1996
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.
[Page 5]
INTERNET-DRAFT November 1996
+-------------+--------+-----------------------------------+
|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 |
+-----------+--------+-------------------------------------+
PERSON cluster
This cluster is used to describe Homo Sapiens.
[Page 6]
INTERNET-DRAFT November 1996
+-----------------------------+--------+-------------------------------+
|Name | Rec. ? | Description |
+-----------------------------+--------+-------------------------------+
|Appointment-Time: | | Appointment time |
|Department: | R | Department to which person |
| | | belongs in organization |
|(EMAIL*) | | Electronic mail address(es) |
| | | of person |
|(ADDRESS*) | | Address of person |
|(PHONE*) | | Telephone contact information |
| | | of person |
|(NAME*) | R | Name of person |
|Organization-(ORGANIZATION*) | R | Information |
| | | about organization where |
| | | person works |
|Title: | | Title of person within |
| | | organization |
|Homepage-URI: | | Uniform Resource |
| | | Identifier of person's |
| | | home page |
|Picture-URI: | | Uniform Resource |
| | | Identifier of person's |
| | | picture |
+-----------------------------+--------+-------------------------------+
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 |
+------------+--------+----------------------------------+
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.
[Page 7]
INTERNET-DRAFT November 1996
+--------------------+--------+----------------------------+
|Name | Rec. ? | Description |
+--------------------+--------+----------------------------+
|PGP-Version: | R | PGP version, e.g. 2.6.3i |
|PGP-Key-ID: | | Public key ID |
|PGP-Key-Name: | | Name associated with PGP |
| | | public key |
|PGP-Public-Key: | R | base64 encoded PGP |
| | | public key |
|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: | R | 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 |
+---------------------------------------+--------+-------------------+
[Page 8]
INTERNET-DRAFT November 1996
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.
[Page 9]
INTERNET-DRAFT November 1996
+--------------------------+--------+------------------------------------+
|Name | Rec. ? | Description |
+--------------------------+--------+------------------------------------+
|Subject: | | The topic addressed by the work |
|Title: | | The name of the object |
|Author: | | The person(s) primarily |
| | | responsible for the intellectual |
| | | content of the object |
|Author-(PERSON*) | | See Author: |
|Publisher: | | The agent or agency |
| | | responsible for |
| | | making the object available |
|Publisher-(ORGANIZATION*) | | See Publisher: |
|Other-Agent | | The person(s), such as editors |
| | | and transcribers, who have made |
| | | other significant intellectual |
| | | contributions to the work |
|Other-Agent-(PERSON*) | | See Other-Agent: |
|Date: | | The date of publication |
|Object-Type: | | The genre of the object, such as |
| | | novel, poem, or dictionary |
|Form: | | The physical manifestation of the |
| | | object, such as Postscript file |
| | | or Windows executable file |
|Identifier: | | String or number used to uniquely |
| | | identify the object |
|Relation: | | Relationship to other objects |
|Source: | | Objects, either print or |
| | | electronic, from which this |
| | | object is derived, if |
| | | applicable |
|Language: | | Language of the intellectual |
| | | content |
|Coverage: | | The spatial locations and temporal |
| | | durations characteristic of the |
| | | object |
|(RECORD*) | | Record information |
+--------------------------+--------+------------------------------------+
ORGANIZATION template
This template is used to hold details about an organisation.
[Page 10]
INTERNET-DRAFT November 1996
+--------------------------+--------+---------------------------------+
|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 |
|(ORGANIZATION*) | | Actual organization information |
|(RECORD*) | | Record information |
+--------------------------+--------+---------------------------------+
SERVICE template
This template is used to describe an on-line service.
[Page 11]
INTERNET-DRAFT November 1996
+---------------------------+--------+---------------------------------+
|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 organisation |
| | | 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 |
+---------------------------+--------+---------------------------------+
[Page 12]
INTERNET-DRAFT November 1996
USER template
This template is used to hold details about a person.
+------------------+--------+-------------------------------------+
|Name | Rec. ? | Description |
+------------------+--------+-------------------------------------+
|Keywords: | | Any keywords which might facilitate |
| | | finding this record |
|(PERSON*) | | Actual user information |
|(PGP-PUBLIC-KEY*) | | Their PGP public |
| | | key(s) |
|(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.
[Page 13]
INTERNET-DRAFT November 1996
+-------------------+--------+------------------------+
|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 |
+-------------+--------+----------------------------+
[Page 14]
INTERNET-DRAFT November 1996
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, departement 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.
[Page 15]
INTERNET-DRAFT November 1996
+-------------------------+--------+---------------------------------+
|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
The proposed common set of WHOIS++ templates does not introduce any
new security related issues.
One of the main uses to which the WHOIS++ templates are expected to
be put is in the cataloguing of on-line information. Implementations
which manipulate externally produced cataloguing data 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.
This work was supported 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
[Page 16]
INTERNET-DRAFT November 1996
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>
12. Authors' addresses
Patrik Faltstrom
Tele2/Swipnet
[Page 17]
INTERNET-DRAFT November 1996
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
[Page 18]
INTERNET-DRAFT November 1996
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."
[Page 19]
INTERNET-DRAFT November 1996
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
[Page 20]
INTERNET-DRAFT November 1996
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 above punctuation) be used as WHOIS++ attributes, and
that the template type "DOCUMENT" be used to represent a WHOIS++ tem-
plate which uses the Dublin Core element set. For example, a "Title"
element which had the value "Cities of The Red Night" would be repre-
sented 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 qualifying sub-elements, such as
"scheme" and "type" associated 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!
[Page 21]
INTERNET-DRAFT November 1996
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.
[Page 22]
