idnits 2.17.1 draft-ietf-asid-whois-schema-01.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 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 178 instances of too long lines in the document, the longest one being 4 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 807: '...and implementations SHOULD use numeric...' RFC 2119 keyword, line 809: '... 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 (July 1997) is 9781 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 (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ASID Working Group Patrik Faltstrom 3 INTERNET-DRAFT Tele2/Swipnet 4 Expires January 1998 Martin Hamilton 5 Loughborough University 6 Leslie L. Daigle 7 Bunyip Information Systems, Inc. 8 Jon Knight 9 Loughborough University 10 July 1997 12 WHOIS++ templates 14 Filename: draft-ietf-asid-whois-schema-01.txt 16 Status of this Memo 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its 20 areas, and its working groups. Note that other groups may also 21 distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- 26 Drafts as reference material or to cite them other than as ``work 27 in progress.'' 29 To learn the current status of any Internet-Draft, please check 30 the ``1id-abstracts.txt'' listing contained in the Internet- 31 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 32 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 33 Coast), or ftp.isi.edu (US West Coast). 35 Distribution of this document is unlimited. 37 Abstract 39 WHOIS++ is a simple Internet search and retrieval protocol, 40 specified in RFC 1835, which allows clients and servers to exchange 41 structured data objects known as templates. In the interests of 42 interoperability it is desirable to have a common base schema for 43 these templates. This document suggests a schema drawn from 44 implementation and deployment experience to date with WHOIS++. 46 Table of Contents: 48 1. Purpose and motivation 49 2. Scope of this document 50 3. What we did 51 4. Templates and clusters 52 5. Cluster definitions 53 6. Template definitions 54 7. System templates 55 8. Security considerations 56 9. Conclusions 57 10. Acknowledgements 58 11. References 59 12. Authors' addresses 60 A. APPENDIX A: Description of elementary attribute values 61 B. APPENDIX B: Representing the Dublin Core in WHOIS++ 63 1. Purpose and motivation 65 The goal of this document is to stimulate discussion on the issue of 66 templates for WHOIS++ [1] databases. 68 In particular we would like to recommend a few typical templates and 69 a set of attributes for them. By recommending the use of particular 70 templates, we hope to standardize WHOIS++ databases and thus make 71 them easier to search. 73 Of course we cannot demand that everyone use the same templates, but 74 it is still a good idea to recommend that people derive their own 75 templates from well known exemples. Amongst other things this allows 76 clients to behave rationally for all fields in a "base class". 78 2. Scope of this document 80 Note that we are not trying to describe all possible information that 81 could be put in a database but rather to cover common and useful 82 elements. 84 3. What we did 86 We looked at IETF drafts, the content of deployed WHOIS++ servers, 87 other White and Yellow Pages servers, and at the work of the Dublin 88 Core group [2] on cataloguing on-line document-like objects. 90 The proposed templates are a mix of all these things but are most 91 strongly influenced by the templates defined by the IAFA working 92 group of the IETF [3]. In fact some of the text in this document is 93 taken verbatim from IAFA documents. 95 We should also mention that wherever we thought it was necessary we 96 tried improving on existing ways of doing things, in particular we 97 tried to improve on the consistency of attribute naming and of the 98 general nomenclature. 100 4. Templates and clusters 102 To ease the understanding of how the templates are defined, consider 103 that each template is defined by attributes and clusters. Each 104 cluster is in turn also defined by attributes and clusters. This 105 clustering principle is only used in this specification to make it 106 easier to describe what attributes should be grouped together, and 107 what attributes are required in a template. 109 One can see the clustering principle we use in this document as a 110 sort of grammar. 112 As an example, one can have the following cluster definition: 114 Cluster INGREDIENTS 116 Name: 117 Color: 118 Weight: 119 Volume: 121 If the template definition then is 123 Template DESSERT 125 Dessert: 126 Ingredients-(INGREDIENTS*): 128 Then the following record is legal: 130 Dessert: Chocolate Mousse 131 Ingredients-Name: Chocolate 132 Ingredients-Color: Brown 133 Ingredients-Weight: 150g 134 Ingredients-Name: Cream 135 Ingredients-Color: White 136 Ingredients-Weight: 2.5dl 138 Each attribute may be repeated within one record (as you can see 139 above). 141 It is important to note that the WHOIS++ protocol imposes ordering on 142 the attributes within the templates. For example - if there were two 143 INGREDIENTS clusters included in a DESSERT template, the attributes 144 from each INGREDIENTS cluster would be grouped together. 146 In the tables of attributes which follow, the "Rec. ?" heading is 147 used to indicate whether an attribute is recommended. All attributes 148 are essentially optional, e.g. the Volume attribute in the 149 INGREDIENTS cluster above, but templates will typically need to 150 contain at least the recommended attributes in order to be useful. 152 5. Cluster definitions 154 ADDRESS cluster 156 This cluster describes the physical address of an object. 158 If any of the more detailed Address-* attributes are specified, they 159 should mirror the content of the Address attribute which should 160 always be specified. 162 +------------------+--------+-------------------------------+ 163 |Name | Rec. ? | Description | 164 +------------------+--------+-------------------------------+ 165 |Address: | R | Full address | 166 |Address-Type: | | Type of address, e.g. Work or | 167 | | | Home | 168 |Address-City: | R | City | 169 |Address-Country: | R | Country | 170 |Address-Room: | | Room | 171 |Address-State: | | State, county or province | 172 |Address-Street: | | Street | 173 |Address-Zip-Code: | | Zip code | 174 +------------------+--------+-------------------------------+ 176 CERTNAME cluster 178 This cluster is used to describe the name of an organization issuing 179 a certificate, Certificate Revocation List (CRL) or the name of a 180 certificate holder. 182 +------------+--------+---------------------+ 183 |Name | Rec. ? | Description | 184 +------------+--------+---------------------+ 185 |Country: | R | Country | 186 |Name: | R | Organization name | 187 |Department: | | Organizational unit | 188 |CommonName: | | Common name | 189 +------------+--------+---------------------+ 191 CERTVALID cluster 193 This cluster is used to describe validity period of a certifi- 194 cate/CRL. 196 +----------------------+--------+--------------------------+ 197 |Name | Rec. ? | Description | 198 +----------------------+--------+--------------------------+ 199 |Date-Valid-NotBefore: | R | Start of validity period | 200 |Date-Valid-NotAfter: | R | End of validity period | 201 +----------------------+--------+--------------------------+ 203 EMAIL cluster 205 This cluster describes the email address of an object. 207 Separate forms are given for Internet and X.400/MHS style email 208 addresses, so as to avoid confusion between the two. 210 +------------+--------+-------------------------+ 211 |Name | Rec. ? | Description | 212 +------------+--------+-------------------------+ 213 |Email: | | Electronic mail address | 214 |Email-X400: | | X.400 mail address | 215 +------------+--------+-------------------------+ 217 NAME cluster 219 This cluster may be used to describe a person's name. Several permu- 220 tations are provided, to cater for the various approaches to writing 221 names in different cultures. 223 If any of the more detailed Name-* attributes are specified, they 224 should mirror the content of the Name attribute which should always 225 be specified. 227 +-------------+--------+-----------------------------------+ 228 |Name | Rec. ? | Description | 229 +-------------+--------+-----------------------------------+ 230 |Name: | R | Full name | 231 |Name-First: | | First name | 232 |Name-Last: | | Last name | 233 |Name-Middle: | | Middle name or initial | 234 |Name-Prefix: | | Includes idenfitiers such as Dr., | 235 | | | Ms., Prof. | 236 |Name-Suffix: | | Includes identifiers such as Jr., | 237 | | | Sr., ... | 238 +-------------+--------+-----------------------------------+ 240 ORGANIZATION cluster 242 This cluster is used to describe an organization in a particular tem- 243 plate. 245 +-----------+--------+-------------------------------------+ 246 |Name | Rec. ? | Description | 247 +-----------+--------+-------------------------------------+ 248 |(ADDRESS*) | | Address of organization | 249 |(EMAIL*) | | Electronic mail address(es) of | 250 | | | organization | 251 |Name: | R | Name of organization | 252 |(PHONE*) | | Telephone number(s) of organization | 253 |Type: | | Type of organization (University, | 254 | | | commercial, etc.) | 255 |URI: | | Uniform Resource Identifier of | 256 | | | organization | 257 +-----------+--------+-------------------------------------+ 259 ORG-PERSON cluster 261 This adds information about the organization the person is associated 262 with, for use with the PERSON cluster. 264 +-----------------------------+--------+-----------------------------+ 265 |Name | Rec. ? | Description | 266 +-----------------------------+--------+-----------------------------+ 267 |Department: | R | Department to which person | 268 | | | belongs in organization | 269 |Organization-(ORGANIZATION*) | R | Information about the | 270 | | | organization where person | 271 | | | works | 272 |Title: | | Title of person within | 273 | | | organization | 274 +-----------------------------+--------+-----------------------------+ 276 PERSON cluster 278 This cluster is used to describe Homo Sapiens. 280 +--------------+--------+-------------------------------+ 281 |Name | Rec. ? | Description | 282 +--------------+--------+-------------------------------+ 283 |(EMAIL*) | | Electronic mail address(es) | 284 | | | of person | 285 |(ADDRESS*) | | Address of person | 286 |(PHONE*) | | Telephone contact information | 287 | | | of person | 288 |(NAME*) | R | Name of person | 289 |(ORG-PERSON*) | R | Organization related | 290 | | | personal contact | 291 | | | information | 292 |Homepage-URI: | | Uniform Resource | 293 | | | Identifier of person's | 294 | | | home page | 295 |Picture-URI: | | Uniform Resource | 296 | | | Identifier of person's | 297 | | | picture | 298 +--------------+--------+-------------------------------+ 300 PHONE cluster 302 This cluster is used to hold telephone contact details for an object. 304 +------------+--------+----------------------------------+ 305 |Name | Rec. ? | Description | 306 +------------+--------+----------------------------------+ 307 |Phone-Type: | | Type of phone, e.g. Work or Home | 308 |Cellular: | | Cellular telephone number | 309 |Fax: | | Fax telephone number | 310 |Pager: | | Pager telephone number | 311 |Phone: | | Telephone number | 312 +------------+--------+----------------------------------+ 314 Note that we recommend that full international format be used for 315 telephone numbers for portability - e.g. +44 1509 228237. See 316 Appendix A for more information. 318 PGP-PUBLIC-KEY cluster 320 This cluster is used to include or refer to a PGP [4] public key. 322 If included directly, the PGP public key should be base64 encoded 323 ("ASCII armored") for portability. 325 +--------------------+--------+----------------------------+ 326 |Name | Rec. ? | Description | 327 +--------------------+--------+----------------------------+ 328 |PGP-Version: | | PGP version, e.g. 2.6.3i | 329 |PGP-Key-Length: | R | Public key length, | 330 | | | e.g. 1024 | 331 |PGP-Key-ID: | R | Public key ID, | 332 | | | e.g. FB5E1519 | 333 |PGP-Key-Name: | R | Name associated with key | 334 | | | e.g. Patrik Faltstrom | 335 | | | | 336 |PGP-Fingerprint: | | Public key checksum, | 337 | | | e.g. 2C E2 6F... | 338 |PGP-Public-Key: | R | PGP key in "ASCII Armour" | 339 |PGP-Public-Key-URI: | | Uniform Resource | 340 | | | Identifier of public key | 341 +--------------------+--------+----------------------------+ 343 RECORD cluster 345 This cluster is used to hold administrative information about a 346 record. 348 +---------------------------------------+--------+-------------------+ 349 |Name | Rec. ? | Description | 350 +---------------------------------------+--------+-------------------+ 351 |Record-Creation-Contact-(PERSON*) | | Contact | 352 | | | information for | 353 | | | person who | 354 | | | created this | 355 | | | record | 356 |Record-Creation-Date: | | The date this | 357 | | | record was | 358 | | | created | 359 |Record-Last-Modified-Contact-(PERSON*) | | Contact | 360 | | | information for | 361 | | | person who last | 362 | | | modified this | 363 | | | record | 364 |Record-Last-Modified-Date: | | The date this | 365 | | | record was last | 366 | | | modified | 367 |Record-Last-Verified-Contact-(PERSON*) | | Contact | 368 | | | information for | 369 | | | person who last | 370 | | | verified this | 371 | | | record | 372 |Record-Last-Verified-Date: | | The date this | 373 | | | record was last | 374 | | | verified | 375 +---------------------------------------+--------+-------------------+ 377 6. Template definitions 379 DOCUMENT template 381 This template is used to hold information about document-like 382 objects. 384 Note that an expanded set of attributes may be used to fully repre- 385 sent Dublin Core objects, as per Appendix B. At the time of writing 386 these were still under development. 388 +--------------------------+--------+-------------------------------------+ 389 |Name | Rec. ? | Description | 390 +--------------------------+--------+-------------------------------------+ 391 |Title: | | The name of the resource | 392 |Creator: | | The person(s) primarily | 393 | | | responsible for the intellectual | 394 | | | content of the resource | 395 |Creator-(PERSON*) | | See Creator: | 396 |Subject: | | The topic addressed by the resource | 397 | | | or a set of appropriate keywords | 398 |Description: | | A plain text description or | 399 | | | abstract about the resource | 400 |Publisher: | | The agent or agency responsible for | 401 | | | making the resource available | 402 |Publisher-(ORGANIZATION*) | | See Publisher: | 403 |Contributors: | | The person(s), such as editors | 404 | | | and transcribers, who have made | 405 | | | other significant intellectual | 406 | | | contributions to the work | 407 |Contributors-(PERSON*) | | See Contributors: | 408 |Date: | | The date of publication | 409 |Type: | | The genre of the resource, such as | 410 | | | novel, poem, or dictionary | 411 |Format: | | The physical manifestation of the | 412 | | | resource, such as Postscript file | 413 | | | or Windows executable file | 414 |Identifier: | | String or number used to uniquely | 415 | | | identify the resource | 416 |Source: | | Resources, either print or | 417 | | | electronic, from which this | 418 | | | resource is derived, if | 419 | | | applicable | 420 |Language: | | Language of the intellectual | 421 | | | content | 422 |Relation: | | Relationship to other resources | 423 |Coverage: | | The spatial locations and temporal | 424 | | | durations characteristic of the | 425 | | | resource | 426 |Rights: | | Information concerning the | 427 | | | intellectual property rights that | 428 | | | are being exercised over the | 429 | | | resource (including access terms) | 430 |(RECORD*) | | Record information | 431 +--------------------------+--------+-------------------------------------+ 433 ORGANIZATION template 434 This template is used to hold details about an organization. In 435 practice both spellings - "ORGANISATION" and "ORGANIZATION" - may be 436 in use. We recommend that ORGANIZATION be given preference to avoid 437 confusion. 439 +--------------------------+--------+---------------------------------+ 440 |Name | Rec. ? | Description | 441 +--------------------------+--------+---------------------------------+ 442 |Keywords: | | Any keywords which might | 443 | | | facilitate finding this | 444 | | | record | 445 |Internet-Domain: | | Organization's Internet | 446 | | | domain name | 447 |Domain-Contact-(PERSON*): | | Admin contact for this | 448 | | | domain | 449 |(ORGANIZATION*) | | Actual organization information | 450 |(RECORD*) | | Record information | 451 +--------------------------+--------+---------------------------------+ 453 SERVICE template 455 This template is used to describe an on-line service. 457 +---------------------------+--------+---------------------------------+ 458 |Name | Rec. ? | Description | 459 +---------------------------+--------+---------------------------------+ 460 |Title: | R | Title of object | 461 |Category: | | Type of object | 462 |Short-Title: | | Summary title | 463 |Alternative-Title: | | An alternative to the Title | 464 | | | or Short-Title fields | 465 |Source: | | Information as to the | 466 | | | definitive version | 467 |Discussion: | | Appropriate discussion forums | 468 |Language: | | The language of the object | 469 |ISSN: | | International Standard Serial | 470 | | | Number if appropriate | 471 |URI: | R | Uniform Resource Identifier | 472 |Admin-(USER*) | | Admin contact information | 473 |Owner-(ORGANIZATION*) | | The organization | 474 | | | sponsoring the service | 475 |Sponsoring-(ORGANIZATION*) | | The | 476 | | | sponsoring organization | 477 |Publisher-(ORGANIZATION*) | | The organization | 478 | | | publishing the service | 479 |Description: | R | Free text description | 480 |Authentication: | | Authentication information | 481 |Registration: | | How to register for this | 482 | | | service | 483 |Charging-Policy: | | Description of any | 484 | | | charging mechanism in place | 485 |Access-Policy: | | Policies and restrictions | 486 | | | for using this service | 487 |Access-Times: | | Time ranges for mandatory | 488 | | | or preferred access | 489 |Keywords: | R | Keywords appropriate for | 490 | | | describing this service | 491 |Subject-Descriptor-Scheme: | | Name of | 492 | | | classification scheme | 493 |Subject-Descriptor: | | A classification | 494 | | | mark for this resource | 495 |To-Be-Reviewed-Date: | | Date on which the | 496 | | | resource is to be re-assessed | 497 |Comments: | | Comments by the template | 498 | | | creators | 499 |Destination: | | Which database the | 500 | | | template is destined for | 501 |(PGP-PUBLIC-KEY*) | | PGP public key(s) | 502 |(RECORD*) | | Record information | 503 +---------------------------+--------+---------------------------------+ 504 USER template 506 This template is used to hold details about a person. 508 +------------------+--------+-------------------------------------+ 509 |Name | Rec. ? | Description | 510 +------------------+--------+-------------------------------------+ 511 |Keywords: | | Any keywords which might facilitate | 512 | | | finding this record | 513 |(PERSON*) | | Actual user information | 514 |(PGP-PUBLIC-KEY*) | | Their PGP public | 515 | | | key(s) | 516 |(RECORD*) | | Record information | 517 +------------------+--------+-------------------------------------+ 519 X509-CERT template 521 This template is used to describe an X.509 [5] certificate. 523 +--------------------+--------+--------------------------------+ 524 |Name | Rec. ? | Description | 525 +--------------------+--------+--------------------------------+ 526 |X509-Version: | | Certificate version number | 527 |SerialNumber: | R | Certificate serial number | 528 |Signature: | | Signature of issuer | 529 |Issuer-(CERTNAME*) | R | Issuer of certificate | 530 |(CERTVALID*) | | Validity period of certificate | 531 |Subject-(CERTNAME*) | | Subject of certificate | 532 |Subject-PublicKey: | | Public key of subject | 533 |Certificate: | R | The certificate | 534 |(RECORD*) | | Record information | 535 +--------------------+--------+--------------------------------+ 537 X509-CRL template. 539 This template is used to describe a Certificate Revocation List. 541 +-------------------+--------+------------------------+ 542 |Name | Rec. ? | Description | 543 +-------------------+--------+------------------------+ 544 |Signature: | | Signature of issuer | 545 |Issuer-(CERTNAME*) | | Issuer of CRL | 546 |(CERTVALID*) | | Validity period of CRL | 547 |CRL: | R | The CRL | 548 |(RECORD*) | | Record information | 549 +-------------------+--------+------------------------+ 551 7. System templates 553 CONSTRAINT template 555 This template is used by the "constraints" command to list valid con- 556 straints supported by the server. 558 +------------+--------+------------------------------------------+ 559 |Name | Rec. ? | Description | 560 +------------+--------+------------------------------------------+ 561 |Default: | R | The default value for this constraint | 562 |Constraint: | R | The constraint described | 563 |Range: | | A list of values supported by the server | 564 |(RECORD*) | | Record information | 565 +------------+--------+------------------------------------------+ 567 HELP template 569 This template is used by the "help" command to access a simple help 570 subsystem giving information about the available commands. 572 +-------------+--------+----------------------------+ 573 |Name | Rec. ? | Description | 574 +-------------+--------+----------------------------+ 575 |Command: | R | Command name | 576 |Description: | R | Description of the command | 577 |Topic: | R | Command category | 578 |Usage: | R | Command usage | 579 |(RECORD*) | | Record information | 580 +-------------+--------+----------------------------+ 582 SERVERHANDLE template 584 This template describes a WHOIS++ server. 586 +-----------------------------+--------+-------------------------------+ 587 |Name | Rec. ? | Description | 588 +-----------------------------+--------+-------------------------------+ 589 |Administrator-(PERSON*) | | Contact information about | 590 | | | the person administering | 591 | | | the server | 592 |City: | | City where the server resides | 593 |Country: | | Country where the server | 594 | | | resides | 595 |Description: | | Human readable information | 596 | | | about the server | 597 |Host-Name: | R | Host name | 598 |Host-Port: | R | Port name used by server | 599 |Organization-(ORGANIZATION*) | | Organization responsible for | 600 | | | the server | 601 |Server-Handle: | R | Registered server handle | 602 |State: | | State, or province | 603 | | | where the server resides | 604 |(PGP-PUBLIC-KEY*) | | Server's PGP key | 605 |(RECORD*) | | Record information | 606 +-----------------------------+--------+-------------------------------+ 608 VERSION template 610 This template is used by the "version" command to obtain the current 611 version of the WHOIS++ protocol supported by the server. 613 +-------------------------+--------+---------------------------------+ 614 |Name | Rec. ? | Description | 615 +-------------------------+--------+---------------------------------+ 616 |Database-Name: | | Name of the underlying database | 617 | | | program | 618 |Database-Version: | | Version of the underlying | 619 | | | database program | 620 |Program-Author-(PERSON*) | | Information about the server | 621 | | | programmer | 622 |Program-Name: | | Name of the server program | 623 |Program-Version: | | Version of the server program | 624 |Version: | R | Version of the WHOIS++ protocol | 625 |(RECORD*) | | Record information | 626 +-------------------------+--------+---------------------------------+ 628 8. Security considerations 630 A WHOIS++ server is only serving the data that is stored in the 631 server itself. Neither the storage, the movement into the server nor 632 the fetching of the data can be seen as secure operations. Because of 633 that, data that is stored in a WHOIS++ server have to be controlled 634 for correctness by an out of band mechanism. For example, public 635 keys stored in a WHOIS++ server have to be signed when stored there. 636 A key checksum of a public key when stored in a WHOIS++ server cannot 637 be treated as correct because of this. It is just there for informa- 638 tion. 640 A directory service hands out information, but does not guarantee the 641 correctness of any information. 643 One of the main uses to which WHOIS++ templates are expected to be 644 put is in the cataloguing of externally produced information. Imple- 645 mentations which manipulate this should treat it with caution - for 646 example, to avoid buffer overrun problems and unexpected evaluation 647 of metacharacters. 649 9. Conclusions 651 This document has outlined a number of template definitions which it 652 is appropriate to use within a WHOIS++ based system. Whilst it is 653 not going to be possible to satisfy everyone's requirements in a sin- 654 gle schema, we believe that the above templates cater for the major- 655 ity of cases. 657 Further discussion of this work is directed to the WHOIS++ schema 658 mailing list - whoispp-schema@bunyip.com. Send mail to major- 659 domo@bunyip.com with the message body "subscribe whoispp-schema" to 660 join the list. 662 10. Acknowledgements 664 Thanks to Lorcan Dempsey and Rachel Heery for their comments on draft 665 versions of this document, and to Francois Perrault for initial work 666 on WHOIS++ template usage. 668 This work was supported by UK Electronic Libraries Programme (eLib) 669 grant 12/39/01, the European Commission's Telematics for Research 670 Programme, grant RE 1004, and National Science Foundation grant 671 NCR-9521074. 673 11. References 675 Request for Comments (RFC) documents and Internet Drafts are available 676 from , and numerous mirror sites. 678 [1] P. Deutsch, R. Schoultz, P. Faltstrom and C. Weider. "Archi- 679 tecture of the WHOIS++ service", RFC 1835. August 1995. 681 [2] S. Weibel. "Metadata: The Foundations of Resource Descrip- 682 tion", D-Lib Magazine, July 1995. 683 684 686 [3] P. Deutsch, A. Emtage, M. Koster, and M. Stumpf. "Publishing 687 Information on the Internet with Anonymous FTP", Internet Draft 688 (work in progress), June 1995. 690 [4] D. Atkins, W. Stallings, P. Zimmermann. "PGP Message Exchange 691 Formats", RFC 1991. August 1996. 693 [5] ITU-T Recommendation X.509 (1993) | ISO/IEC 9594-8: 1993, 694 Information Technology - Open Systems Interconnection - The Direc- 695 tory: Authentication Framework. 697 [6] D. Crocker. "Standard for the format of ARPA Internet text 698 messages", RFC 822. August 1982. 700 [7] R. Braden. "Requirements for Internet hosts - application and 701 support", RFC 1123. October 1989. 703 [8] BibTeX(1) Manual Page, Oren Patashnik, June 1984. 705 [9] S. Weibel, E. Miller. Dublin Core Home Page. 706 708 [10] L. Dempsey, S. Weibel. "The Warwick Metadata Workshop: A 709 Framework for the Deployment of Resource Description", D-Lib Maga- 710 zine, July/August 1996. 711 712 714 12. Authors' addresses 716 Patrik Faltstrom 717 Tele2/Swipnet 718 Box 62 719 Borgarfjordsgatan 16 720 S-164 94 Kista 721 Sweden 723 Email: paf@swip.net 725 Leslie L. Daigle 726 Bunyip Information Systems Inc. 727 310 Ste. Catherine St. West 728 Suite 300 729 Montreal, Quebec, Canada 730 H2X 2A1 732 Email: leslie@bunyip.com 734 Martin Hamilton 735 Department of Computer Studies 736 Loughborough University of Technology 737 Leics. LE11 3TU, UK 739 Email: m.t.hamilton@lut.ac.uk 741 Jon Knight 742 Department of Computer Studies 743 Loughborough University of Technology 744 Leics. LE11 3TU, UK 746 Email: j.p.knight@lut.ac.uk 748 APPENDIX A: Description of elementary attribute values 750 The IAFA draft and RFC822 [6] already define formats for: 752 email addresses 753 hostnames 754 IP addresses 755 numeric values 756 dates 757 times 758 time ranges 759 telephone numbers 760 latitude and longitudes 761 person names 763 Here is a reminder of what those elementary data elements should look 764 like according to IAFA: 766 All electronic mail (Email addresses must be as defined in RFC 822, 767 Section 6. Names and comments may be included in the Email address. 768 For example, both "John Doe" and jd@ftp.bar.org are 769 valid email addresses. 771 All hostnames are to be given as Fully Qualified Domain Names as 772 defined in RFC 1034, Section 3. For example: "foo.bar.com" 774 All host IP addresses are given in "dotted-quad" (or "dotted- 775 decimal") notation. For example: "127.0.0.1" 777 All numeric values are in decimal unless otherwise stated. 779 Dates/times must be given as defined in RFC 822, Section 5.1 and mod- 780 ified in RFC 1123 [7], Section 5.2.14: 782 date-time = [ day "," ] date [time] 783 day = "Mon" / "Tue" / "Wed" / "Thu" 784 / "Fri" / "Sat" / "Sun" 785 date = 1*2DIGIT month 2*4DIGIT 786 ; day month year 787 ; e.g. 20 Jun 1982 788 month = "Jan" / "Feb" / "Mar" / "Apr" 789 / "May" / "Jun" / "Jul" / "Aug" 790 / "Sep" / "Oct" / "Nov" / "Dec" 791 time = hour zone ; ANSI 792 hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] 793 ; 00:00:00 - 23:59:59 794 zone = "UT" / "GMT" ; Universal Time 795 ; North American : UT 796 / "EST" / "EDT" ; Eastern: - 5/ - 4 797 / "CST" / "CDT" ; Central: - 6/ - 5 798 / "MST" / "MDT" ; Mountain: - 7/ - 6 799 / "PST" / "PDT" ; Pacific: - 8/ - 7 800 ; 801 / ( ("+" / "-") 4DIGIT ) ; Local differential 802 ; hours+min. (HHMM) 804 For example the string "Sat, 18 Jun 1993 12:36:47 -0500" is a valid 805 date, and the string "12:36:47 GMT" is a valid time. Quoting from 806 RFC 1123, Section 5.2.14: "There is a strong trend towards the use of 807 numeric timezone indicators, and implementations SHOULD use numeric 808 timezones instead of timezone names. However, all implementations 809 MUST accept either notation. If timezone names are used, they MUST 810 be exactly as defined in RFC 822." 811 Time ranges (or periods) must be specified as pairs of time values 812 (as defined above in note (5)), separated by a "/". Multiple time 813 ranges are separated by whitespace. All times in a range should be 814 specified with the same timezone. For example 12:00 GMT / 05:45 GMT. 816 "whitespace" is defined as one or more blank (hex 0x20) and/or tab 817 (octal 11) ASCII characters. 819 References to "UT" mean Universal Time (also known as Greenwich Mean 820 Time or "GMT"). 822 All telephone numbers are to be given as a minimum in full, with a 823 leading '+' and country and routing codes without non-space separa- 824 tors. The number should be given assuming someone calling interna- 825 tionally (without local access codes). The number given in the local 826 convention may optionally be specified in brackets. For example, 827 Telephone: +44 71 732 8011 or Telephone: +1 514 875 8189 828 (0514-875-8611). 830 Latitude and longitude are specified in that order as 831 CDD.MM.SS/CDD.MM.SS where 833 DD is in degrees 834 MM is in minutes 835 SS is in seconds 836 C is the direction designator which is for latitude 838 "+" is north of the equator and "-" is south of the equator. For lon- 839 gitude "+" is west of the Greenwich meridian and "-" is east of the 840 Greenwich meridian. The double quotes (") are not part of the desig- 841 nator, but are used here to delimit the symbols. 843 Person name fields should conform to a particular format (based on 844 BibTeX [8]), so that they can be parsed into parts. A name can have 845 four parts: first, von, last, junior, each of which can consist of 846 more than one word. For example, "John Paul von Braun, Jr." has 847 "John Paul" as the first part, "von" as the von part, "Braun" as the 848 last part, and "Jr." as the junior part Use one of these formats for 849 a name: 851 First von Last 852 von Last, First 853 von Last, Junior, First 855 The last part is assumed to be one word, or all the words after the 856 von part. Anything in braces will be treated as one word, so use 857 braces to surround last names that contain more than one word. The 858 von part is recognized by looking for words that begin with lowercase 859 letters. When possible, enter the full first name(s). Actually, the 860 rules for isolating the name parts are a bit more complicated, so 861 they do the right thing for names like "de la Grand Round, Chuck". 862 If there are multiple authors or editors, they should all be sepa- 863 rated by the word and. 865 APPENDIX B: Representing Dublin Core in WHOIS++ 867 The Dublin Core is a simple resource description format which arose 868 out of a loose grouping of "librarians, archivists, humanities schol- 869 ars and geographers, as well as standards makers in the Internet, 870 Z39.50 and Standard Generalized Markup Language (SGML) communities" 871 [2]. 873 This document proposes a mapping from the abstract model of the 874 Dublin Core to WHOIS++. We suggest that the Dublin Core element set 875 [9] (with the concrete syntax given in the DOCUMENT template above) 876 be used as WHOIS++ attributes, and that the template type "DOCUMENT" 877 be used to represent a WHOIS++ template which uses the Dublin Core 878 element set. For example, a "Title" element which had the value 879 "Cities of The Red Night" would be represented within WHOIS++ as the 880 attribute/value pair: 882 Title: Cities of The Red Night 884 One aspect of the Dublin Core does not translate directly to WHOIS++ 885 - each element may have additional qualifiers such as "scheme" asso- 886 ciated with it. This provides the creator of the record with a way 887 of indicating additional semantics, e.g. the classification scheme 888 being used in the "Subject" element. 890 Since WHOIS++, like most Internet based search and retrieval proto- 891 cols, is attribute/value oriented, it is necessary to find a place to 892 put this extra information. We propose that it be placed in an addi- 893 tional attribute/value pair which precedes the main information about 894 the element. For example, if the subject classification for the 895 above book were 813 in the Dewey Decimal system, the resulting Dublin 896 Core elements expressed via WHOIS++ might look like this: 898 Subject-Scheme: DDC 899 Subject: 813 901 Since the order of the attribute/value pairs in a WHOIS++ record is 902 significant, this provides a simple and easily implemented mechanism 903 for grouping together elements and their qualifying information. 905 Needless to say, scheme information should only appear in the WHOIS++ 906 record if the attribute it qualifies also appears! 908 It is important to note that the Dublin Core element set is intended 909 for use in describing document-like objects, and not as a means of 910 describing arbitrary objects. Furthermore, the number of elements is 911 strictly limited in the interests of interoperability. 913 Work is ongoing on the Warwick Framework [10], which attempts to pro- 914 vide a mechanism for packaging together collections of descriptive 915 information. It is envisaged that this would be used in cases where 916 the Dublin Core element set did not provide enough descriptive capa- 917 bility. This is a subject for further study and is beyond the scope 918 of this specification.