idnits 2.17.1
draft-ietf-asid-whois-schema-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in
this document.
Expected boilerplate is as follows today (2024-04-25) according to
https://trustee.ietf.org/license-info :
IETF Trust Legal Provisions of 28-dec-2009, Section 6.a:
This Internet-Draft is submitted in full conformance with the provisions
of BCP 78 and BCP 79.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2:
Copyright (c) 2024 IETF Trust and the persons identified as the document
authors. All rights reserved.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3:
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last page.
** The document seems to lack a 1id_guidelines paragraph about
Internet-Drafts being working documents.
** The document seems to lack a 1id_guidelines paragraph about 6 months
document validity -- however, there's a paragraph with a matching
beginning. Boilerplate error?
** The document seems to lack a 1id_guidelines paragraph about the list of
current Internet-Drafts.
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
** The document is more than 15 pages and seems to lack a Table of Contents.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== It seems as if not all pages are separated by form feeds - found 0 form
feeds but 22 pages
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** There are 186 instances of too long lines in the document, the longest
one being 3 characters in excess of 72.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 764: '...and implementations SHOULD use numeric...'
RFC 2119 keyword, line 766: '... MUST accept either notation. If ti...'
Miscellaneous warnings:
----------------------------------------------------------------------------
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (November 1996) is 10023 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Downref: Normative reference to an Historic RFC: RFC 1835 (ref. '1')
-- Possible downref: Non-RFC (?) normative reference: ref. '2'
-- Possible downref: Non-RFC (?) normative reference: ref. '3'
** Obsolete normative reference: RFC 1991 (ref. '4') (Obsoleted by RFC 4880)
-- Possible downref: Non-RFC (?) normative reference: ref. '5'
** Obsolete normative reference: RFC 822 (ref. '6') (Obsoleted by RFC 2822)
-- Possible downref: Non-RFC (?) normative reference: ref. '8'
-- Possible downref: Non-RFC (?) normative reference: ref. '9'
-- Possible downref: Non-RFC (?) normative reference: ref. '10'
Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 ASID Working Group Patrik Faltstrom
2 INTERNET-DRAFT Tele2/Swipnet
3 Expires May 1997 Martin Hamilton
4 Loughborough University
5 Leslie L. Daigle
6 Bunyip Information Systems, Inc.
7 Jon Knight
8 Loughborough University
9 November 1996
11 WHOIS++ templates
13 Filename: draft-ietf-asid-whois-schema-00.txt
15 Status of this Memo
17 This document is an Internet-Draft. Internet-Drafts are working
18 documents of the Internet Engineering Task Force (IETF), its
19 areas, and its working groups. Note that other groups may also
20 distribute working documents as Internet-Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six
23 months and may be updated, replaced, or obsoleted by other
24 documents at any time. It is inappropriate to use Internet-
25 Drafts as reference material or to cite them other than as ``work
26 in progress.''
28 To learn the current status of any Internet-Draft, please check
29 the ``1id-abstracts.txt'' listing contained in the Internet-
30 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
31 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
32 Coast), or ftp.isi.edu (US West Coast).
34 Distribution of this document is unlimited.
36 Abstract
38 WHOIS++ is a simple Internet search and retrieval protocol,
39 specified in RFC 1835, which allows clients and servers to exchange
40 structured data objects known as templates. In the interests of
41 interoperability it is desirable to have a common base schema for
42 these templates. This document suggests a schema drawn from
43 implementation and deployment experience to date with WHOIS++.
45 Table of Contents:
47 1. Purpose and motivation
48 2. Scope of this document
49 3. What we did
50 4. Templates and clusters
51 5. Cluster definitions
52 6. Template definitions
53 7. System templates
54 8. Security considerations
55 9. Conclusions
56 10. Acknowledgements
57 11. References
58 12. Authors' addresses
59 A. APPENDIX A: Description of elementary attribute values
60 B. APPENDIX B: Representing the Dublin Core in WHOIS++
62 1. Purpose and motivation
64 The goal of this document is to stimulate discussion on the issue of
65 templates for WHOIS++ [1] databases.
67 In particular we would like to recommend a few typical templates and
68 a set of attributes for them. By recommending the use of particular
69 templates, we hope to standardize WHOIS++ databases and thus make
70 them easier to search.
72 Of course we cannot demand that everyone use the same templates, but
73 it is still a good idea to recommend that people derive their own
74 templates from well known exemples. Amongst other things this allows
75 clients to behave rationally for all fields in a "base class".
77 2. Scope of this document
79 Note that we are not trying to describe all possible information that
80 could be put in a database but rather to cover common and useful
81 elements.
83 3. What we did
85 We looked at IETF drafts, the content of deployed WHOIS++ servers,
86 other White and Yellow Pages servers, and at the work of the Dublin
87 Core group [2] on cataloguing on-line document-like objects.
89 The proposed templates are a mix of all these things but are most
90 strongly influenced by the templates defined by the IAFA working
91 group of the IETF [3]. In fact some of the text in this document is
92 taken verbatim from IAFA documents.
94 We should also mention that wherever we though it was necessary we
95 tried improving on existing ways of doing things, in particular we
96 tried to improve on the consistency of attribute naming and of the
97 general nomenclature.
99 4. Templates and clusters
101 To ease the understanding of how the templates are defined, consider
102 that each template is defined by attributes and clusters. Each
103 cluster is in turn also defined by attributes and clusters. This
104 clustering principle is only used in this specification to make it
105 easier to describe what attributes should be grouped together, and
106 what attributes are required in a template.
108 One can see the clustering principle we use in this document as a
109 sort of grammar.
111 As an example, one can have the following cluster definition:
113 Cluster INGREDIENTS
115 Name:
116 Color:
117 Weight:
118 Volume:
120 If the template definition then is
122 Template DESSERT
124 Desert:
125 Ingredients-(INGREDIENTS*):
127 Then the following record is legal:
129 Dessert: Chocolate Mousse
130 Ingredients-Name: Chocolate
131 Ingredients-Color: Brown
132 Ingredients-Weight: 150g
133 Ingredients-Name: Cream
134 Ingredients-Color: White
135 Ingredients-Weight: 2.5dl
137 Each attribute may be repeated within one record (as you can see
138 above).
140 It is important to note that the WHOIS++ protocol imposes ordering on
141 the attributes within the templates. For example - if there were two
142 ADDRESS clusters included in an ORGANIZATION template, the attributes
143 from each ADDRESS cluster would be grouped together.
145 In the tables of attributes which follow, the "Rec. ?" heading is
146 used to indicate whether an attribute is recommended.
148 5. Cluster definitions
150 ADDRESS cluster
152 This cluster describes the physical address of an object.
154 If any of the more detailed Address-* attributes are specified, they
155 should mirror the content of the Address attribute which should
156 always be specified.
158 +------------------+--------+--------------------------------+
159 |Name | Rec. ? | Description |
160 +------------------+--------+--------------------------------+
161 |Address: | R | Full address |
162 |Address-Type: | | Type of address, e.g. Work or |
163 | | | Home |
164 |Address-City: | R | City |
165 |Address-Country: | R | Country |
166 |Address-Room: | | Room |
167 |Address-State: | | State, departement or province |
168 |Address-Street: | | Street |
169 |Address-Zip-Code: | | Zip code |
170 +------------------+--------+--------------------------------+
172 CERTNAME cluster
174 This cluster is used to describe the name of an organization issuing
175 a certificate, Certificate Revocation List (CRL) or the name of a
176 certificate holder.
178 +------------+--------+---------------------+
179 |Name | Rec. ? | Description |
180 +------------+--------+---------------------+
181 |Country: | R | Country |
182 |Name: | R | Organization name |
183 |Department: | | Organizational unit |
184 |CommonName: | | Common name |
185 +------------+--------+---------------------+
187 CERTVALID cluster
189 This cluster is used to describe validity period of a certifi-
190 cate/CRL.
192 +----------------------+--------+--------------------------+
193 |Name | Rec. ? | Description |
194 +----------------------+--------+--------------------------+
195 |Date-Valid-NotBefore: | R | Start of validity period |
196 |Date-Valid-NotAfter: | R | End of validity period |
197 +----------------------+--------+--------------------------+
199 EMAIL cluster
201 This cluster describes the email address of an object.
203 Separate forms are given for Internet and X.400/MHS style email
204 addresses, so as to avoid confusion between the two.
206 +------------+--------+-------------------------+
207 |Name | Rec. ? | Description |
208 +------------+--------+-------------------------+
209 |Email: | | Electronic mail address |
210 |Email-X400: | | X.400 mail address |
211 +------------+--------+-------------------------+
213 NAME cluster
215 This cluster may be used to describe a person's name. Several permu-
216 tations are provided, to cater for the various approaches to writing
217 names in different cultures.
219 If any of the more detailed Name-* attributes are specified, they
220 should mirror the content of the Name attribute which should always
221 be specified.
223 +-------------+--------+-----------------------------------+
224 |Name | Rec. ? | Description |
225 +-------------+--------+-----------------------------------+
226 |Name: | R | Full name |
227 |Name-First: | | First name |
228 |Name-Last: | | Last name |
229 |Name-Middle: | | Middle name or initial |
230 |Name-Prefix: | | Includes idenfitiers such as Dr., |
231 | | | Ms., Prof. |
232 |Name-Suffix: | | Includes identifiers such as Jr., |
233 | | | Sr., ... |
234 +-------------+--------+-----------------------------------+
236 ORGANIZATION cluster
238 This cluster is used to describe an organization in a particular tem-
239 plate.
241 +-----------+--------+-------------------------------------+
242 |Name | Rec. ? | Description |
243 +-----------+--------+-------------------------------------+
244 |(ADDRESS*) | | Address of organization |
245 |(EMAIL*) | | Electronic mail address(es) of |
246 | | | organization |
247 |Name: | R | Name of organization |
248 |(PHONE*) | | Telephone number(s) of organization |
249 |Type: | | Type of organization (University, |
250 | | | commercial, etc.) |
251 |URI: | | Uniform Resource Identifier of |
252 | | | organization |
253 +-----------+--------+-------------------------------------+
255 PERSON cluster
257 This cluster is used to describe Homo Sapiens.
259 +-----------------------------+--------+-------------------------------+
260 |Name | Rec. ? | Description |
261 +-----------------------------+--------+-------------------------------+
262 |Appointment-Time: | | Appointment time |
263 |Department: | R | Department to which person |
264 | | | belongs in organization |
265 |(EMAIL*) | | Electronic mail address(es) |
266 | | | of person |
267 |(ADDRESS*) | | Address of person |
268 |(PHONE*) | | Telephone contact information |
269 | | | of person |
270 |(NAME*) | R | Name of person |
271 |Organization-(ORGANIZATION*) | R | Information |
272 | | | about organization where |
273 | | | person works |
274 |Title: | | Title of person within |
275 | | | organization |
276 |Homepage-URI: | | Uniform Resource |
277 | | | Identifier of person's |
278 | | | home page |
279 |Picture-URI: | | Uniform Resource |
280 | | | Identifier of person's |
281 | | | picture |
282 +-----------------------------+--------+-------------------------------+
284 PHONE cluster
286 This cluster is used to hold telephone contact details for an object.
288 +------------+--------+----------------------------------+
289 |Name | Rec. ? | Description |
290 +------------+--------+----------------------------------+
291 |Phone-Type: | | Type of phone, e.g. Work or Home |
292 |Cellular: | | Cellular telephone number |
293 |Fax: | | Fax telephone number |
294 |Pager: | | Pager telephone number |
295 |Phone: | | Telephone number |
296 +------------+--------+----------------------------------+
298 PGP-PUBLIC-KEY cluster
300 This cluster is used to include or refer to a PGP [4] public key.
302 If included directly, the PGP public key should be base64 encoded
303 ("ASCII armored") for portability.
305 +--------------------+--------+----------------------------+
306 |Name | Rec. ? | Description |
307 +--------------------+--------+----------------------------+
308 |PGP-Version: | R | PGP version, e.g. 2.6.3i |
309 |PGP-Key-ID: | | Public key ID |
310 |PGP-Key-Name: | | Name associated with PGP |
311 | | | public key |
312 |PGP-Public-Key: | R | base64 encoded PGP |
313 | | | public key |
314 |PGP-Public-Key-URI: | | Uniform Resource |
315 | | | Identifier of public key |
316 +--------------------+--------+----------------------------+
318 RECORD cluster
320 This cluster is used to hold administrative information about a
321 record.
323 +---------------------------------------+--------+-------------------+
324 |Name | Rec. ? | Description |
325 +---------------------------------------+--------+-------------------+
326 |Record-Creation-Contact-(PERSON*) | | Contact |
327 | | | information for |
328 | | | person who |
329 | | | created this |
330 | | | record |
331 |Record-Creation-Date: | | The date this |
332 | | | record was |
333 | | | created |
334 |Record-Last-Modified-Contact-(PERSON*) | | Contact |
335 | | | information for |
336 | | | person who last |
337 | | | modified this |
338 | | | record |
339 |Record-Last-Modified-Date: | R | The date this |
340 | | | record was last |
341 | | | modified |
342 |Record-Last-Verified-Contact-(PERSON*) | | Contact |
343 | | | information for |
344 | | | person who last |
345 | | | verified this |
346 | | | record |
347 |Record-Last-Verified-Date: | | The date this |
348 | | | record was last |
349 | | | verified |
350 +---------------------------------------+--------+-------------------+
352 6. Template definitions
354 DOCUMENT template
356 This template is used to hold information about document-like
357 objects.
359 Note that an expanded set of attributes may be used to fully repre-
360 sent Dublin Core objects, as per Appendix B. At the time of writing
361 these were still under development.
363 +--------------------------+--------+------------------------------------+
364 |Name | Rec. ? | Description |
365 +--------------------------+--------+------------------------------------+
366 |Subject: | | The topic addressed by the work |
367 |Title: | | The name of the object |
368 |Author: | | The person(s) primarily |
369 | | | responsible for the intellectual |
370 | | | content of the object |
371 |Author-(PERSON*) | | See Author: |
372 |Publisher: | | The agent or agency |
373 | | | responsible for |
374 | | | making the object available |
375 |Publisher-(ORGANIZATION*) | | See Publisher: |
376 |Other-Agent | | The person(s), such as editors |
377 | | | and transcribers, who have made |
378 | | | other significant intellectual |
379 | | | contributions to the work |
380 |Other-Agent-(PERSON*) | | See Other-Agent: |
381 |Date: | | The date of publication |
382 |Object-Type: | | The genre of the object, such as |
383 | | | novel, poem, or dictionary |
384 |Form: | | The physical manifestation of the |
385 | | | object, such as Postscript file |
386 | | | or Windows executable file |
387 |Identifier: | | String or number used to uniquely |
388 | | | identify the object |
389 |Relation: | | Relationship to other objects |
390 |Source: | | Objects, either print or |
391 | | | electronic, from which this |
392 | | | object is derived, if |
393 | | | applicable |
394 |Language: | | Language of the intellectual |
395 | | | content |
396 |Coverage: | | The spatial locations and temporal |
397 | | | durations characteristic of the |
398 | | | object |
399 |(RECORD*) | | Record information |
400 +--------------------------+--------+------------------------------------+
402 ORGANIZATION template
404 This template is used to hold details about an organisation.
406 +--------------------------+--------+---------------------------------+
407 |Name | Rec. ? | Description |
408 +--------------------------+--------+---------------------------------+
409 |Keywords: | | Any keywords which might |
410 | | | facilitate finding this |
411 | | | record |
412 |Internet-Domain: | | Organization's Internet |
413 | | | domain name |
414 |Domain-Contact-(PERSON*): | | Admin contact for this |
415 | | | domain |
416 |(ORGANIZATION*) | | Actual organization information |
417 |(RECORD*) | | Record information |
418 +--------------------------+--------+---------------------------------+
420 SERVICE template
422 This template is used to describe an on-line service.
424 +---------------------------+--------+---------------------------------+
425 |Name | Rec. ? | Description |
426 +---------------------------+--------+---------------------------------+
427 |Title: | R | Title of object |
428 |Category: | | Type of object |
429 |Short-Title: | | Summary title |
430 |Alternative-Title: | | An alternative to the Title |
431 | | | or Short-Title fields |
432 |Source: | | Information as to the |
433 | | | definitive version |
434 |Discussion: | | Appropriate discussion forums |
435 |Language: | | The language of the object |
436 |ISSN: | | International Standard Serial |
437 | | | Number if appropriate |
438 |URI: | R | Uniform Resource Identifier |
439 |Admin-(USER*) | | Admin contact information |
440 |Owner-(ORGANIZATION*) | | The organization |
441 | | | sponsoring the service |
442 |Sponsoring-(ORGANIZATION*) | | The |
443 | | | sponsoring organization |
444 |Publisher-(ORGANIZATION*) | | The organisation |
445 | | | publishing the service |
446 |Description: | R | Free text description |
447 |Authentication: | | Authentication information |
448 |Registration: | | How to register for this |
449 | | | service |
450 |Charging-Policy: | | Description of any |
451 | | | charging mechanism in place |
452 |Access-Policy: | | Policies and restrictions |
453 | | | for using this service |
454 |Access-Times: | | Time ranges for mandatory |
455 | | | or preferred access |
456 |Keywords: | R | Keywords appropriate for |
457 | | | describing this service |
458 |Subject-Descriptor-Scheme: | | Name of |
459 | | | classification scheme |
460 |Subject-Descriptor: | | A classification |
461 | | | mark for this resource |
462 |To-Be-Reviewed-Date: | | Date on which the |
463 | | | resource is to be re-assessed |
464 |Comments: | | Comments by the template |
465 | | | creators |
466 |Destination: | | Which database the |
467 | | | template is destined for |
468 |(PGP-PUBLIC-KEY*) | | PGP public key(s) |
469 |(RECORD*) | | Record information |
470 +---------------------------+--------+---------------------------------+
471 USER template
473 This template is used to hold details about a person.
475 +------------------+--------+-------------------------------------+
476 |Name | Rec. ? | Description |
477 +------------------+--------+-------------------------------------+
478 |Keywords: | | Any keywords which might facilitate |
479 | | | finding this record |
480 |(PERSON*) | | Actual user information |
481 |(PGP-PUBLIC-KEY*) | | Their PGP public |
482 | | | key(s) |
483 |(RECORD*) | | Record information |
484 +------------------+--------+-------------------------------------+
486 X509-CERT template
488 This template is used to describe an X.509 [5] certificate.
490 +--------------------+--------+--------------------------------+
491 |Name | Rec. ? | Description |
492 +--------------------+--------+--------------------------------+
493 |X509-Version: | | Certificate version number |
494 |SerialNumber: | R | Certificate serial number |
495 |Signature: | | Signature of issuer |
496 |Issuer-(CERTNAME*) | R | Issuer of certificate |
497 |(CERTVALID*) | | Validity period of certificate |
498 |Subject-(CERTNAME*) | | Subject of certificate |
499 |Subject-PublicKey: | | Public key of subject |
500 |Certificate: | R | The certificate |
501 |(RECORD*) | | Record information |
502 +--------------------+--------+--------------------------------+
504 X509-CRL template.
506 This template is used to describe a Certificate Revocation List.
508 +-------------------+--------+------------------------+
509 |Name | Rec. ? | Description |
510 +-------------------+--------+------------------------+
511 |Signature: | | Signature of issuer |
512 |Issuer-(CERTNAME*) | | Issuer of CRL |
513 |(CERTVALID*) | | Validity period of CRL |
514 |CRL: | R | The CRL |
515 |(RECORD*) | | Record information |
516 +-------------------+--------+------------------------+
518 7. System templates
520 CONSTRAINT template
522 This template is used by the "constraints" command to list valid con-
523 straints supported by the server.
525 +------------+--------+------------------------------------------+
526 |Name | Rec. ? | Description |
527 +------------+--------+------------------------------------------+
528 |Default: | R | The default value for this constraint |
529 |Constraint: | R | The constraint described |
530 |Range: | | A list of values supported by the server |
531 |(RECORD*) | | Record information |
532 +------------+--------+------------------------------------------+
534 HELP template
536 This template is used by the "help" command to access a simple help
537 subsystem giving information about the available commands.
539 +-------------+--------+----------------------------+
540 |Name | Rec. ? | Description |
541 +-------------+--------+----------------------------+
542 |Command: | R | Command name |
543 |Description: | R | Description of the command |
544 |Topic: | R | Command category |
545 |Usage: | R | Command usage |
546 |(RECORD*) | | Record information |
547 +-------------+--------+----------------------------+
549 SERVERHANDLE template
551 This template describes a WHOIS++ server.
553 +-----------------------------+--------+-------------------------------+
554 |Name | Rec. ? | Description |
555 +-----------------------------+--------+-------------------------------+
556 |Administrator-(PERSON*) | | Contact information about |
557 | | | the person administering |
558 | | | the server |
559 |City: | | City where the server resides |
560 |Country: | | Country where the server |
561 | | | resides |
562 |Description: | | Human readable information |
563 | | | about the server |
564 |Host-Name: | R | Host name |
565 |Host-Port: | R | Port name used by server |
566 |Organization-(ORGANIZATION*) | | Organization responsible for |
567 | | | the server |
568 |Server-Handle: | R | Registered server handle |
569 |State: | | State, departement or |
570 | | | province where the server |
571 | | | resides |
572 |(PGP-PUBLIC-KEY*) | | Server's PGP key |
573 |(RECORD*) | | Record information |
574 +-----------------------------+--------+-------------------------------+
576 VERSION template
578 This template is used by the "version" command to obtain the current
579 version of the WHOIS++ protocol supported by the server.
581 +-------------------------+--------+---------------------------------+
582 |Name | Rec. ? | Description |
583 +-------------------------+--------+---------------------------------+
584 |Database-Name: | | Name of the underlying database |
585 | | | program |
586 |Database-Version: | | Version of the underlying |
587 | | | database program |
588 |Program-Author-(PERSON*) | | Information about the server |
589 | | | programmer |
590 |Program-Name: | | Name of the server program |
591 |Program-Version: | | Version of the server program |
592 |Version: | R | Version of the WHOIS++ protocol |
593 |(RECORD*) | | Record information |
594 +-------------------------+--------+---------------------------------+
596 8. Security considerations
598 The proposed common set of WHOIS++ templates does not introduce any
599 new security related issues.
601 One of the main uses to which the WHOIS++ templates are expected to
602 be put is in the cataloguing of on-line information. Implementations
603 which manipulate externally produced cataloguing data should treat it
604 with caution - for example, to avoid buffer overrun problems and
605 unexpected evaluation of metacharacters.
607 9. Conclusions
609 This document has outlined a number of template definitions which it
610 is appropriate to use within a WHOIS++ based system. Whilst it is
611 not going to be possible to satisfy everyone's requirements in a sin-
612 gle schema, we believe that the above templates cater for the major-
613 ity of cases.
615 Further discussion of this work is directed to the WHOIS++ schema
616 mailing list - whoispp-schema@bunyip.com. Send mail to major-
617 domo@bunyip.com with the message body "subscribe whoispp-schema" to
618 join the list.
620 10. Acknowledgements
622 Thanks to Lorcan Dempsey and Rachel Heery for their comments on draft
623 versions of this document.
625 This work was supported by UK Electronic Libraries Programme (eLib)
626 grant 12/39/01, the European Commission's Telematics for Research
627 Programme grant RE 1004, and National Science Foundation grant
628 NCR-9521074.
630 11. References
632 Request for Comments (RFC) documents and Internet Drafts are available
633 from , and numerous mirror sites.
635 [1] P. Deutsch, R. Schoultz, P. Faltstrom and C. Weider. "Archi-
636 tecture of the WHOIS++ service", RFC 1835. August 1995.
638 [2] S. Weibel. "Metadata: The Foundations of Resource Descrip-
639 tion", D-Lib Magazine, July 1995.
640
641
643 [3] P. Deutsch, A. Emtage, M. Koster, and M. Stumpf. "Publishing
644 Information on the Internet with Anonymous FTP", Internet Draft
645 (work in progress), June 1995.
647 [4] D. Atkins, W. Stallings, P. Zimmermann. "PGP Message Exchange
648 Formats", RFC 1991. August 1996.
650 [5] ITU-T Recommendation X.509 (1993) | ISO/IEC 9594-8: 1993,
651 Information Technology - Open Systems Interconnection - The Direc-
652 tory: Authentication Framework.
654 [6] D. Crocker. "Standard for the format of ARPA Internet text
655 messages", RFC 822. August 1982.
657 [7] R. Braden. "Requirements for Internet hosts - application and
658 support", RFC 1123. October 1989.
660 [8] BibTeX(1) Manual Page, Oren Patashnik, June 1984.
662 [9] S. Weibel, E. Miller. Dublin Core Home Page.
663
665 [10] L. Dempsey, S. Weibel. "The Warwick Metadata Workshop: A
666 Framework for the Deployment of Resource Description", D-Lib Maga-
667 zine, July/August 1996.
668
669
671 12. Authors' addresses
673 Patrik Faltstrom
674 Tele2/Swipnet
675 Box 62
676 Borgarfjordsgatan 16
677 S-164 94 Kista
678 Sweden
680 Email: paf@swip.net
682 Leslie L. Daigle
683 Bunyip Information Systems Inc.
684 310 Ste. Catherine St. West
685 Suite 300
686 Montreal, Quebec, Canada
687 H2X 2A1
689 Email: leslie@bunyip.com
691 Martin Hamilton
692 Department of Computer Studies
693 Loughborough University of Technology
694 Leics. LE11 3TU, UK
696 Email: m.t.hamilton@lut.ac.uk
698 Jon Knight
699 Department of Computer Studies
700 Loughborough University of Technology
701 Leics. LE11 3TU, UK
703 Email: j.p.knight@lut.ac.uk
705 APPENDIX A: Description of elementary attribute values
707 The IAFA draft and RFC822 [6] already define formats for:
709 email addresses
710 hostnames
711 IP addresses
712 numeric values
713 dates
714 times
715 time ranges
716 telephone numbers
717 latitude and longitudes
718 person names
720 Here is a reminder of what those elementary data elements should look
721 like according to IAFA:
723 All electronic mail (Email addresses must be as defined in RFC 822,
724 Section 6. Names and comments may be included in the Email address.
725 For example, both "John Doe" and jd@ftp.bar.org are
726 valid email addresses.
728 All hostnames are to be given as Fully Qualified Domain Names as
729 defined in RFC 1034, Section 3. For example: "foo.bar.com"
731 All host IP addresses are given in "dotted-quad" (or "dotted-
732 decimal") notation. For example: "127.0.0.1"
734 All numeric values are in decimal unless otherwise stated.
736 Dates/times must be given as defined in RFC 822, Section 5.1 and mod-
737 ified in RFC 1123 [7], Section 5.2.14:
739 date-time = [ day "," ] date [time]
740 day = "Mon" / "Tue" / "Wed" / "Thu"
741 / "Fri" / "Sat" / "Sun"
742 date = 1*2DIGIT month 2*4DIGIT
743 ; day month year
744 ; e.g. 20 Jun 1982
745 month = "Jan" / "Feb" / "Mar" / "Apr"
746 / "May" / "Jun" / "Jul" / "Aug"
747 / "Sep" / "Oct" / "Nov" / "Dec"
748 time = hour zone ; ANSI
749 hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
750 ; 00:00:00 - 23:59:59
751 zone = "UT" / "GMT" ; Universal Time
752 ; North American : UT
753 / "EST" / "EDT" ; Eastern: - 5/ - 4
754 / "CST" / "CDT" ; Central: - 6/ - 5
755 / "MST" / "MDT" ; Mountain: - 7/ - 6
756 / "PST" / "PDT" ; Pacific: - 8/ - 7
757 ;
758 / ( ("+" / "-") 4DIGIT ) ; Local differential
759 ; hours+min. (HHMM)
761 For example the string "Sat, 18 Jun 1993 12:36:47 -0500" is a valid
762 date, and the string "12:36:47 GMT" is a valid time. Quoting from
763 RFC 1123, Section 5.2.14: "There is a strong trend towards the use of
764 numeric timezone indicators, and implementations SHOULD use numeric
765 timezones instead of timezone names. However, all implementations
766 MUST accept either notation. If timezone names are used, they MUST
767 be exactly as defined in RFC 822."
768 Time ranges (or periods) must be specified as pairs of time values
769 (as defined above in note (5)), separated by a "/". Multiple time
770 ranges are separated by whitespace. All times in a range should be
771 specified with the same timezone. For example 12:00 GMT / 05:45 GMT.
773 "whitespace" is defined as one or more blank (hex 0x20) and/or tab
774 (octal 11) ASCII characters.
776 References to "UT" mean Universal Time (also known as Greenwich Mean
777 Time or "GMT").
779 All telephone numbers are to be given as a minimum in full, with a
780 leading '+' and country and routing codes without non-space separa-
781 tors. The number should be given assuming someone calling interna-
782 tionally (without local access codes). The number given in the local
783 convention may optionally be specified in brackets. For example,
784 Telephone: +44 71 732 8011 or Telephone: +1 514 875 8189
785 (0514-875-8611).
787 Latitude and longitude are specified in that order as
788 CDD.MM.SS/CDD.MM.SS where
790 DD is in degrees
791 MM is in minutes
792 SS is in seconds
793 C is the direction designator which is for latitude
795 "+" is north of the equator and "-" is south of the equator. For lon-
796 gitude "+" is west of the Greenwich meridian and "-" is east of the
797 Greenwich meridian. The double quotes (") are not part of the desig-
798 nator, but are used here to delimit the symbols.
800 Person name fields should conform to a particular format (based on
801 BibTeX [8]), so that they can be parsed into parts. A name can have
802 four parts: first, von, last, junior, each of which can consist of
803 more than one word. For example, "John Paul von Braun, Jr." has
804 "John Paul" as the first part, "von" as the von part, "Braun" as the
805 last part, and "Jr." as the junior part Use one of these formats for
806 a name:
808 First von Last
809 von Last, First
810 von Last, Junior, First
812 The last part is assumed to be one word, or all the words after the
813 von part. Anything in braces will be treated as one word, so use
814 braces to surround last names that contain more than one word. The
815 von part is recognized by looking for words that begin with lowercase
816 letters. When possible, enter the full first name(s). Actually, the
817 rules for isolating the name parts are a bit more complicated, so
818 they do the right thing for names like "de la Grand Round, Chuck".
819 If there are multiple authors or editors, they should all be sepa-
820 rated by the word and.
822 APPENDIX B: Representing Dublin Core in WHOIS++
824 The Dublin Core is a simple resource description format which arose
825 out of a loose grouping of "librarians, archivists, humanities schol-
826 ars and geographers, as well as standards makers in the Internet,
827 Z39.50 and Standard Generalized Markup Language (SGML) communities"
828 [2].
830 This document proposes a mapping from the abstract model of the
831 Dublin Core to WHOIS++. We suggest that the Dublin Core element set
832 [9] (with the above punctuation) be used as WHOIS++ attributes, and
833 that the template type "DOCUMENT" be used to represent a WHOIS++ tem-
834 plate which uses the Dublin Core element set. For example, a "Title"
835 element which had the value "Cities of The Red Night" would be repre-
836 sented within WHOIS++ as the attribute/value pair:
838 Title: Cities of The Red Night
840 One aspect of the Dublin Core does not translate directly to WHOIS++
841 - each element may have additional qualifying sub-elements, such as
842 "scheme" and "type" associated with it. This provides the creator of
843 the record with a way of indicating additional semantics, e.g. the
844 classification scheme being used in the "Subject" element.
846 Since WHOIS++, like most Internet based search and retrieval proto-
847 cols, is attribute/value oriented, it is necessary to find a place to
848 put this extra information. We propose that it be placed in an addi-
849 tional attribute/value pair which precedes the main information about
850 the element. For example, if the subject classification for the
851 above book were 813 in the Dewey Decimal system, the resulting Dublin
852 Core elements expressed via WHOIS++ might look like this:
854 Subject-Scheme: DDC
855 Subject: 813
857 Since the order of the attribute/value pairs in a WHOIS++ record is
858 significant, this provides a simple and easily implemented mechanism
859 for grouping together elements and their qualifying information.
861 Needless to say, scheme information should only appear in the WHOIS++
862 record if the attribute it qualifies also appears!
863 It is important to note that the Dublin Core element set is intended
864 for use in describing document-like objects, and not as a means of
865 describing arbitrary objects. Furthermore, the number of elements is
866 strictly limited in the interests of interoperability.
868 Work is ongoing on the Warwick Framework [10], which attempts to pro-
869 vide a mechanism for packaging together collections of descriptive
870 information. It is envisaged that this would be used in cases where
871 the Dublin Core element set did not provide enough descriptive capa-
872 bility. This is a subject for further study.