idnits 2.17.1 draft-ietf-asid-whois-schema-02.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-23) 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1099 lines 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 204 instances of too long lines in the document, the longest one being 6 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 849: '...and implementations SHOULD use numeric...' RFC 2119 keyword, line 851: '... MUST accept either notation. If ti...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 968 has weird spacing: '...content and l...' -- 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 (October 1997) is 9687 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' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 9 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 April 1998 Martin Hamilton 5 Loughborough University 6 Leslie L. Daigle 7 Bunyip Information Systems, Inc. 8 Jon Knight 9 Loughborough University 10 October 1997 12 WHOIS++ templates 14 Filename: draft-ietf-asid-whois-schema-02.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++ 62 C. APPENDIX C: Representing the Internet Whitepages Schema (IWPS) in 63 WHOIS++ 65 1. Purpose and motivation 67 The goal of this document is to stimulate discussion on the issue of 68 templates for WHOIS++ [1] databases. 70 In particular we would like to recommend a few typical templates and 71 a set of attributes for them. By recommending the use of particular 72 templates, we hope to standardize WHOIS++ databases and thus make 73 them easier to search. 75 Of course we cannot demand that everyone use the same templates, but 76 it is still a good idea to recommend that people derive their own 77 templates from well known exemples. Amongst other things this allows 78 clients to behave rationally for all fields in a "base class". 80 2. Scope of this document 82 Note that we are not trying to describe all possible information that 83 could be put in a database but rather to cover common and useful 84 elements. 86 3. What we did 88 We looked at IETF drafts, the content of deployed WHOIS++ servers, 89 other White and Yellow Pages servers, and at the work of the Dublin 90 Core group [2] on cataloguing on-line document-like objects. 92 The proposed templates are a mix of all these things but are most 93 strongly influenced by the templates defined by the IAFA working 94 group of the IETF [3]. In fact some of the text in this document is 95 taken verbatim from IAFA documents. 97 We should also mention that wherever we thought it was necessary we 98 tried improving on existing ways of doing things, in particular we 99 tried to improve on the consistency of attribute naming and of the 100 general nomenclature. 102 4. Templates and clusters 104 To ease the understanding of how the templates are defined, consider 105 that each template is defined by attributes and clusters. Each 106 cluster is in turn also defined by attributes and clusters. This 107 clustering principle is only used in this specification to make it 108 easier to describe what attributes should be grouped together, and 109 what attributes are required in a template. 111 One can see the clustering principle we use in this document as a 112 sort of grammar. 114 As an example, one can have the following cluster definition: 116 Cluster INGREDIENTS 118 Name: 119 Color: 120 Weight: 121 Volume: 123 If the template definition then is 125 Template DESSERT 127 Dessert: 128 Ingredients-(INGREDIENTS*): 130 Then the following record is legal: 132 Dessert: Chocolate Mousse 133 Ingredients-Name: Chocolate 134 Ingredients-Color: Brown 135 Ingredients-Weight: 150g 136 Ingredients-Name: Cream 137 Ingredients-Color: White 138 Ingredients-Weight: 2.5dl 140 Each attribute may be repeated within one record (as you can see 141 above). 143 It is important to note that the WHOIS++ protocol imposes ordering on 144 the attributes within the templates. For example - if there were two 145 INGREDIENTS clusters included in a DESSERT template, the attributes 146 from each INGREDIENTS cluster would be grouped together. 148 In the tables of attributes which follow, the "Rec. ?" heading is 149 used to indicate whether an attribute is recommended. All attributes 150 are essentially optional, e.g. the Volume attribute in the 151 INGREDIENTS cluster above, but templates will typically need to 152 contain at least the recommended attributes in order to be useful. 154 5. Cluster definitions 156 ADDRESS cluster 158 This cluster describes the physical address of an object. 160 If any of the more detailed Address-* attributes are specified, they 161 should mirror the content of the Address attribute which should 162 always be specified. 164 +------------------+--------+-------------------------------+ 165 |Name | Rec. ? | Description | 166 +------------------+--------+-------------------------------+ 167 |Address: | R | Full address | 168 |Address-Type: | | Type of address, e.g. Work or | 169 | | | Home | 170 |Address-City: | R | City | 171 |Address-Country: | R | Country | 172 |Address-Room: | | Room | 173 |Address-State: | | State, county or province | 174 |Address-Street: | | Street | 175 |Address-Zip-Code: | | Zip code | 176 |Address-Locality: | | Geographic region | 177 +------------------+--------+-------------------------------+ 179 CERTNAME cluster 181 This cluster is used to describe the name of an organization issuing 182 a certificate, Certificate Revocation List (CRL) or the name of a 183 certificate holder. 185 +------------+--------+---------------------+ 186 |Name | Rec. ? | Description | 187 +------------+--------+---------------------+ 188 |Country: | R | Country | 189 |Name: | R | Organization name | 190 |Department: | | Organizational unit | 191 |CommonName: | | Common name | 192 +------------+--------+---------------------+ 194 CERTVALID cluster 196 This cluster is used to describe validity period of a certifi- 197 cate/CRL. 199 +----------------------+--------+--------------------------+ 200 |Name | Rec. ? | Description | 201 +----------------------+--------+--------------------------+ 202 |Date-Valid-NotBefore: | R | Start of validity period | 203 |Date-Valid-NotAfter: | R | End of validity period | 204 +----------------------+--------+--------------------------+ 206 EMAIL cluster 208 This cluster describes the email address of an object. 210 Separate forms are given for Internet and X.400/MHS style email 211 addresses, so as to avoid confusion between the two. 213 +------------+--------+-------------------------+ 214 |Name | Rec. ? | Description | 215 +------------+--------+-------------------------+ 216 |Email: | | Electronic mail address | 217 |Email-X400: | | X.400 mail address | 218 +------------+--------+-------------------------+ 220 NAME cluster 222 This cluster may be used to describe a person's name. Several permu- 223 tations are provided, to cater for the various approaches to writing 224 names in different cultures. 226 If any of the more detailed Name-* attributes are specified, they 227 should mirror the content of the Name attribute which should always 228 be specified. 230 +-------------+--------+-----------------------------------+ 231 |Name | Rec. ? | Description | 232 +-------------+--------+-----------------------------------+ 233 |Name: | R | Full name | 234 |Name-First: | | First name | 235 |Name-Last: | | Last name | 236 |Name-Middle: | | Middle name or initial | 237 |Name-Prefix: | | Includes idenfitiers such as Dr., | 238 | | | Ms., Prof. | 239 |Name-Suffix: | | Includes identifiers such as Jr., | 240 | | | Sr., ... | 241 +-------------+--------+-----------------------------------+ 243 ORGANIZATION cluster 245 This cluster is used to describe an organization in a particular tem- 246 plate. 248 +-----------+--------+-------------------------------------+ 249 |Name | Rec. ? | Description | 250 +-----------+--------+-------------------------------------+ 251 |(ADDRESS*) | | Address of organization | 252 |(EMAIL*) | | Electronic mail address(es) of | 253 | | | organization | 254 |Name: | R | Name of organization | 255 |(PHONE*) | | Telephone number(s) of organization | 256 |Type: | | Type of organization (University, | 257 | | | commercial, etc.) | 258 |URI: | | Uniform Resource Identifier of | 259 | | | organization | 260 +-----------+--------+-------------------------------------+ 262 ORG-PERSON cluster 264 This adds information about the organization the person is associated 265 with, for use with the PERSON cluster. 267 +-----------------------------+--------+-----------------------------+ 268 |Name | Rec. ? | Description | 269 +-----------------------------+--------+-----------------------------+ 270 |Department: | R | Department to which person | 271 | | | belongs in organization | 272 |Organization-(ORGANIZATION*) | R | Information about the | 273 | | | organization where person | 274 | | | works | 275 |Title: | | Title of person within | 276 | | | organization | 277 +-----------------------------+--------+-----------------------------+ 279 PERSON cluster 281 This cluster is used to describe Homo Sapiens. 283 +--------------+--------+-------------------------------+ 284 |Name | Rec. ? | Description | 285 +--------------+--------+-------------------------------+ 286 |(EMAIL*) | | Electronic mail address(es) | 287 | | | of person | 288 |(ADDRESS*) | | Address of person | 289 |(PHONE*) | | Telephone contact information | 290 | | | of person | 291 |(NAME*) | R | Name of person | 292 |(ORG-PERSON*) | R | Organization related | 293 | | | personal contact | 294 | | | information | 295 |Homepage-URI: | | Uniform Resource | 296 | | | Identifier of person's | 297 | | | home page | 298 |Picture-URI: | | Uniform Resource | 299 | | | Identifier of person's | 300 | | | picture | 301 |Language-pref:| | Person's language of | 302 | | | preference | 303 +--------------+--------+-------------------------------+ 305 PHONE cluster 307 This cluster is used to hold telephone contact details for an object. 309 +------------+--------+----------------------------------+ 310 |Name | Rec. ? | Description | 311 +------------+--------+----------------------------------+ 312 |Phone-Type: | | Type of phone, e.g. Work or Home | 313 |Cellular: | | Cellular telephone number | 314 |Fax: | | Fax telephone number | 315 |Pager: | | Pager telephone number | 316 |Phone: | | Telephone number | 317 +------------+--------+----------------------------------+ 319 Note that we recommend that full international format be used for 320 telephone numbers for portability - e.g. +44 1509 228237. See 321 Appendix A for more information. 323 PGP-PUBLIC-KEY cluster 325 This cluster is used to include or refer to a PGP [4] public key. 327 If included directly, the PGP public key should be base64 encoded 328 ("ASCII armored") for portability. 330 +--------------------+--------+----------------------------+ 331 |Name | Rec. ? | Description | 332 +--------------------+--------+----------------------------+ 333 |PGP-Version: | | PGP version, e.g. 2.6.3i | 334 |PGP-Key-Length: | R | Public key length, | 335 | | | e.g. 1024 | 336 |PGP-Key-ID: | R | Public key ID, | 337 | | | e.g. FB5E1519 | 338 |PGP-Key-Name: | R | Name associated with key | 339 | | | e.g. Patrik Faltstrom | 340 | | | | 341 |PGP-Fingerprint: | | Public key checksum, | 342 | | | e.g. 2C E2 6F... | 343 |PGP-Public-Key: | R | PGP key in "ASCII Armour" | 344 |PGP-Public-Key-URI: | | Uniform Resource | 345 | | | Identifier of public key | 346 +--------------------+--------+----------------------------+ 348 RECORD cluster 350 This cluster is used to hold administrative information about a 351 record. 353 +---------------------------------------+--------+-------------------+ 354 |Name | Rec. ? | Description | 355 +---------------------------------------+--------+-------------------+ 356 |Record-Creation-Contact-(PERSON*) | | Contact | 357 | | | information for | 358 | | | person who | 359 | | | created this | 360 | | | record | 361 |Record-Creation-Date: | | The date this | 362 | | | record was | 363 | | | created | 364 |Record-Last-Modified-Contact-(PERSON*) | | Contact | 365 | | | information for | 366 | | | person who last | 367 | | | modified this | 368 | | | record | 369 |Record-Last-Modified-Date: | | The date this | 370 | | | record was last | 371 | | | modified | 372 |Record-Last-Verified-Contact-(PERSON*) | | Contact | 373 | | | information for | 374 | | | person who last | 375 | | | verified this | 376 | | | record | 377 |Record-Last-Verified-Date: | | The date this | 378 | | | record was last | 379 | | | verified | 380 +---------------------------------------+--------+-------------------+ 382 6. Template definitions 384 DOCUMENT template 386 This template is used to hold information about document-like 387 objects. 389 Note that an expanded set of attributes may be used to fully repre- 390 sent Dublin Core objects, as per Appendix B. At the time of writing 391 these were still under development. 393 +--------------------------+--------+-------------------------------------+ 394 |Name | Rec. ? | Description | 395 +--------------------------+--------+-------------------------------------+ 396 |Title: | | The name of the resource | 397 |Creator: | | The person(s) primarily | 398 | | | responsible for the intellectual | 399 | | | content of the resource | 400 |Creator-(PERSON*) | | See Creator: | 401 |Subject: | | The topic addressed by the resource | 402 | | | or a set of appropriate keywords | 403 |Description: | | A plain text description or | 404 | | | abstract about the resource | 405 |Publisher: | | The agent or agency responsible for | 406 | | | making the resource available | 407 |Publisher-(ORGANIZATION*) | | See Publisher: | 408 |Contributors: | | The person(s), such as editors | 409 | | | and transcribers, who have made | 410 | | | other significant intellectual | 411 | | | contributions to the work | 412 |Contributors-(PERSON*) | | See Contributors: | 413 |Date: | | The date of publication | 414 |Type: | | The genre of the resource, such as | 415 | | | novel, poem, or dictionary | 416 |Format: | | The physical manifestation of the | 417 | | | resource, such as Postscript file | 418 | | | or Windows executable file | 419 |Identifier: | | String or number used to uniquely | 420 | | | identify the resource | 421 |Source: | | Resources, either print or | 422 | | | electronic, from which this | 423 | | | resource is derived, if | 424 | | | applicable | 425 |Language: | | Language of the intellectual | 426 | | | content | 427 |Relation: | | Relationship to other resources | 428 |Coverage: | | The spatial locations and temporal | 429 | | | durations characteristic of the | 430 | | | resource | 431 |Rights: | | Information concerning the | 432 | | | intellectual property rights that | 433 | | | are being exercised over the | 434 | | | resource (including access terms) | 435 |(RECORD*) | | Record information | 436 +--------------------------+--------+-------------------------------------+ 438 ORGANIZATION template 440 This template is used to hold details about an organization. In 441 practice both spellings - "ORGANISATION" and "ORGANIZATION" - may be 442 in use. We recommend that ORGANIZATION be given preference to avoid 443 confusion. 445 +-----------------------------+--------+---------------------------------+ 446 |Name | Rec. ? | Description | 447 +-----------------------------+--------+---------------------------------+ 448 |Keywords: | | Any keywords which might | 449 | | | facilitate finding this | 450 | | | record | 451 |Internet-Domain: | | Organization's Internet | 452 | | | domain name | 453 |Domain-Contact-(PERSON*): | | Admin contact for this | 454 | | | domain | 455 |(ORGANIZATIION*) | | Actual organization information | 456 |(RECORD*) | | Record information | 457 +-----------------------------+--------+---------------------------------+ 459 ORG-ROLE template 461 This template is used to hold details about a particular role within 462 an organization. These roles (like "president", "front desk", 463 "service counter") may or may not be associated with a person or 464 persons. This template will contain necessary contact information 465 for the role irrespective of the (current) incumbent person, if any. 467 +------------------------------+--------+-------------------------------+ 468 |Name | Rec. ? | Description | 469 +------------------------------+--------+-------------------------------+ 470 |Keywords: | | Any keywords which might | 471 | | | facilitate finding this | 472 | | | record | 473 |Org-Role: | R | Name of the role | 474 |(EMAIL*) | | E-mail contact info for role | 475 |(PHONE*) | | Phone contact info for role | 476 |Organization-(ORGANIZATION*) | | The organization to which | 477 | | | this role belongs | 478 |(NAME*) | | Name of person in role | 479 |(PGP-PUBLIC-KEY*) | | The role's PGP public key(s) | 480 |(RECORD*) | | Record information | 481 +------------------------------+--------+-------------------------------+ 483 SERVICE template 485 This template is used to describe an on-line service. 487 +---------------------------+--------+---------------------------------+ 488 |Name | Rec. ? | Description | 489 +---------------------------+--------+---------------------------------+ 490 |Title: | R | Title of object | 491 |Category: | | Type of object | 492 |Short-Title: | | Summary title | 493 |Alternative-Title: | | An alternative to the Title | 494 | | | or Short-Title fields | 495 |Source: | | Information as to the | 496 | | | definitive version | 497 |Discussion: | | Appropriate discussion forums | 498 |Language: | | The language of the object | 499 |ISSN: | | International Standard Serial | 500 | | | Number if appropriate | 501 |URI: | R | Uniform Resource Identifier | 502 |Admin-(USER*) | | Admin contact information | 503 |Owner-(ORGANIZATION*) | | The organization | 504 | | | sponsoring the service | 505 |Sponsoring-(ORGANIZATION*) | | The | 506 | | | sponsoring organization | 507 |Publisher-(ORGANIZATION*) | | The organization | 508 | | | publishing the service | 509 |Description: | R | Free text description | 510 |Authentication: | | Authentication information | 511 |Registration: | | How to register for this | 512 | | | service | 513 |Charging-Policy: | | Description of any | 514 | | | charging mechanism in place | 515 |Access-Policy: | | Policies and restrictions | 516 | | | for using this service | 517 |Access-Times: | | Time ranges for mandatory | 518 | | | or preferred access | 519 |Keywords: | R | Keywords appropriate for | 520 | | | describing this service | 521 |Subject-Descriptor-Scheme: | | Name of | 522 | | | classification scheme | 523 |Subject-Descriptor: | | A classification | 524 | | | mark for this resource | 525 |To-Be-Reviewed-Date: | | Date on which the | 526 | | | resource is to be re-assessed | 527 |Comments: | | Comments by the template | 528 | | | creators | 529 |Destination: | | Which database the | 530 | | | template is destined for | 531 |(PGP-PUBLIC-KEY*) | | PGP public key(s) | 532 |(RECORD*) | | Record information | 533 +---------------------------+--------+---------------------------------+ 535 USER template 537 This template is used to hold details about a person. 539 The IDS Working Group of the IETF has proposed an abstract schema for 540 Internet white pages services [11]; the details of how that abstract schema 541 can be represented in a WHOIS++ USER template are provided in 542 Appendix C. 544 +------------------+--------+-------------------------------------+ 545 |Name | Rec. ? | Description | 546 +------------------+--------+-------------------------------------+ 547 |Keywords: | | Any keywords which might facilitate | 548 | | | finding this record | 549 |(PERSON*) | | Actual user information | 550 |(PGP-PUBLIC-KEY*) | | Their PGP public | 551 | | | key(s) | 552 |X509-CERT-URI | | URI for the USER's X.509 certificate| 553 | | | (May be a Whois++ URI for the | 554 | | | appropriate X509-CERT template) | 555 |(RECORD*) | | Record information | 556 +------------------+--------+-------------------------------------+ 558 X509-CERT template 560 This template is used to describe an X.509 [5] certificate. 562 +--------------------+--------+--------------------------------+ 563 |Name | Rec. ? | Description | 564 +--------------------+--------+--------------------------------+ 565 |X509-Version: | | Certificate version number | 566 |SerialNumber: | R | Certificate serial number | 567 |Signature: | | Signature of issuer | 568 |Issuer-(CERTNAME*) | R | Issuer of certificate | 569 |(CERTVALID*) | | Validity period of certificate | 570 |Subject-(CERTNAME*) | | Subject of certificate | 571 |Subject-PublicKey: | | Public key of subject | 572 |Certificate: | R | The certificate | 573 |(RECORD*) | | Record information | 574 +--------------------+--------+--------------------------------+ 576 X509-CRL template. 578 This template is used to describe a Certificate Revocation List. 580 +-------------------+--------+------------------------+ 581 |Name | Rec. ? | Description | 582 +-------------------+--------+------------------------+ 583 |Signature: | | Signature of issuer | 584 |Issuer-(CERTNAME*) | | Issuer of CRL | 585 |(CERTVALID*) | | Validity period of CRL | 586 |CRL: | R | The CRL | 587 |(RECORD*) | | Record information | 588 +-------------------+--------+------------------------+ 590 7. System templates 592 CONSTRAINT template 594 This template is used by the "constraints" command to list valid con- 595 straints supported by the server. 597 +------------+--------+------------------------------------------+ 598 |Name | Rec. ? | Description | 599 +------------+--------+------------------------------------------+ 600 |Default: | R | The default value for this constraint | 601 |Constraint: | R | The constraint described | 602 |Range: | | A list of values supported by the server | 603 |(RECORD*) | | Record information | 604 +------------+--------+------------------------------------------+ 606 HELP template 608 This template is used by the "help" command to access a simple help 609 subsystem giving information about the available commands. 611 +-------------+--------+----------------------------+ 612 |Name | Rec. ? | Description | 613 +-------------+--------+----------------------------+ 614 |Command: | R | Command name | 615 |Description: | R | Description of the command | 616 |Topic: | R | Command category | 617 |Usage: | R | Command usage | 618 |(RECORD*) | | Record information | 619 +-------------+--------+----------------------------+ 621 SERVERHANDLE template 623 This template describes a WHOIS++ server. 625 +-----------------------------+--------+-------------------------------+ 626 |Name | Rec. ? | Description | 627 +-----------------------------+--------+-------------------------------+ 628 |Administrator-(PERSON*) | | Contact information about | 629 | | | the person administering | 630 | | | the server | 631 |City: | | City where the server resides | 632 |Country: | | Country where the server | 633 | | | resides | 634 |Description: | | Human readable information | 635 | | | about the server | 636 |Host-Name: | R | Host name | 637 |Host-Port: | R | Port name used by server | 638 |Organization-(ORGANIZATION*) | | Organization responsible for | 639 | | | the server | 640 |Server-Handle: | R | Registered server handle | 641 |State: | | State, or province | 642 | | | where the server resides | 643 |(PGP-PUBLIC-KEY*) | | Server's PGP key | 644 |(RECORD*) | | Record information | 645 +-----------------------------+--------+-------------------------------+ 647 VERSION template 649 This template is used by the "version" command to obtain the current 650 version of the WHOIS++ protocol supported by the server. 652 +-------------------------+--------+---------------------------------+ 653 |Name | Rec. ? | Description | 654 +-------------------------+--------+---------------------------------+ 655 |Database-Name: | | Name of the underlying database | 656 | | | program | 657 |Database-Version: | | Version of the underlying | 658 | | | database program | 659 |Program-Author-(PERSON*) | | Information about the server | 660 | | | programmer | 661 |Program-Name: | | Name of the server program | 662 |Program-Version: | | Version of the server program | 663 |Version: | R | Version of the WHOIS++ protocol | 664 |(RECORD*) | | Record information | 665 +-------------------------+--------+---------------------------------+ 667 8. Security considerations 669 A WHOIS++ server is only serving the data that is stored in the 670 server itself. Neither the storage, the movement into the server nor 671 the fetching of the data can be seen as secure operations. Because of 672 that, data that is stored in a WHOIS++ server have to be controlled 673 for correctness by an out of band mechanism. For example, public 674 keys stored in a WHOIS++ server have to be signed when stored there. 675 A key checksum of a public key when stored in a WHOIS++ server cannot 676 be treated as correct because of this. It is just there for informa- 677 tion. 679 A directory service hands out information, but does not guarantee the 680 correctness of any information. 682 One of the main uses to which WHOIS++ templates are expected to be 683 put is in the cataloguing of externally produced information. Imple- 684 mentations which manipulate this should treat it with caution - for 685 example, to avoid buffer overrun problems and unexpected evaluation 686 of metacharacters. 688 9. Conclusions 690 This document has outlined a number of template definitions which it 691 is appropriate to use within a WHOIS++ based system. Whilst it is 692 not going to be possible to satisfy everyone's requirements in a sin- 693 gle schema, we believe that the above templates cater for the major- 694 ity of cases. 696 Further discussion of this work is directed to the WHOIS++ schema 697 mailing list - whoispp-schema@bunyip.com. Send mail to major- 698 domo@bunyip.com with the message body "subscribe whoispp-schema" to 699 join the list. 701 10. Acknowledgements 703 Thanks to Lorcan Dempsey and Rachel Heery for their comments on draft 704 versions of this document, and to Francois Perrault for initial work 705 on WHOIS++ template usage. 707 This work was supported in part by UK Electronic Libraries Programme 708 (eLib) grant 12/39/01, the European Commission's Telematics for Research 709 Programme, grant RE 1004, and National Science Foundation grant 710 NCR-9521074. 712 11. References 714 Request for Comments (RFC) documents and Internet Drafts are available 715 from , and numerous mirror sites. 717 [1] P. Deutsch, R. Schoultz, P. Faltstrom and C. Weider. "Archi- 718 tecture of the WHOIS++ service", RFC 1835. August 1995. 720 [2] S. Weibel. "Metadata: The Foundations of Resource Descrip- 721 tion", D-Lib Magazine, July 1995. 722 723 725 [3] P. Deutsch, A. Emtage, M. Koster, and M. Stumpf. "Publishing 726 Information on the Internet with Anonymous FTP", Internet Draft 727 (work in progress), June 1995. 729 [4] D. Atkins, W. Stallings, P. Zimmermann. "PGP Message Exchange 730 Formats", RFC 1991. August 1996. 732 [5] ITU-T Recommendation X.509 (1993) | ISO/IEC 9594-8: 1993, 733 Information Technology - Open Systems Interconnection - The Direc- 734 tory: Authentication Framework. 736 [6] D. Crocker. "Standard for the format of ARPA Internet text 737 messages", RFC 822. August 1982. 739 [7] R. Braden. "Requirements for Internet hosts - application and 740 support", RFC 1123. October 1989. 742 [8] BibTeX(1) Manual Page, Oren Patashnik, June 1984. 744 [9] S. Weibel, E. Miller. Dublin Core Home Page. 745 747 [10] L. Dempsey, S. Weibel. "The Warwick Metadata Workshop: A 748 Framework for the Deployment of Resource Description", D-Lib Maga- 749 zine, July/August 1996. 750 751 753 [11] T. Genovese, Barbara Jennings, "A Common Schema for the Internet 754 White Pages Service", IETF IDS Working Group draft, June 1997. 756 12. Authors' addresses 758 Patrik Faltstrom 759 Tele2/Swipnet 760 Box 62 761 Borgarfjordsgatan 16 762 S-164 94 Kista 763 Sweden 765 Email: paf@swip.net 767 Leslie L. Daigle 768 Bunyip Information Systems Inc. 769 310 Ste. Catherine St. West 770 Suite 300 771 Montreal, Quebec, Canada 772 H2X 2A1 774 Email: leslie@bunyip.com 776 Martin Hamilton 777 Department of Computer Studies 778 Loughborough University of Technology 779 Leics. LE11 3TU, UK 781 Email: m.t.hamilton@lut.ac.uk 783 Jon Knight 784 Department of Computer Studies 785 Loughborough University of Technology 786 Leics. LE11 3TU, UK 788 Email: j.p.knight@lut.ac.uk 790 APPENDIX A: Description of elementary attribute values 792 The IAFA draft and RFC822 [6] already define formats for: 794 email addresses 795 hostnames 796 IP addresses 797 numeric values 798 dates 799 times 800 time ranges 801 telephone numbers 802 latitude and longitudes 803 person names 805 Here is a reminder of what those elementary data elements should look 806 like according to IAFA: 808 All electronic mail (Email addresses must be as defined in RFC 822, 809 Section 6. Names and comments may be included in the Email address. 810 For example, both "John Doe" and jd@ftp.bar.org are 811 valid email addresses. 813 All hostnames are to be given as Fully Qualified Domain Names as 814 defined in RFC 1034, Section 3. For example: "foo.bar.com" 816 All host IP addresses are given in "dotted-quad" (or "dotted- 817 decimal") notation. For example: "127.0.0.1" 819 All numeric values are in decimal unless otherwise stated. 821 Dates/times must be given as defined in RFC 822, Section 5.1 and mod- 822 ified in RFC 1123 [7], Section 5.2.14: 824 date-time = [ day "," ] date [time] 825 day = "Mon" / "Tue" / "Wed" / "Thu" 826 / "Fri" / "Sat" / "Sun" 827 date = 1*2DIGIT month 2*4DIGIT 828 ; day month year 829 ; e.g. 20 Jun 1982 830 month = "Jan" / "Feb" / "Mar" / "Apr" 831 / "May" / "Jun" / "Jul" / "Aug" 832 / "Sep" / "Oct" / "Nov" / "Dec" 833 time = hour zone ; ANSI 834 hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] 835 ; 00:00:00 - 23:59:59 836 zone = "UT" / "GMT" ; Universal Time 837 ; North American : UT 838 / "EST" / "EDT" ; Eastern: - 5/ - 4 839 / "CST" / "CDT" ; Central: - 6/ - 5 840 / "MST" / "MDT" ; Mountain: - 7/ - 6 841 / "PST" / "PDT" ; Pacific: - 8/ - 7 842 ; 843 / ( ("+" / "-") 4DIGIT ) ; Local differential 844 ; hours+min. (HHMM) 846 For example the string "Sat, 18 Jun 1993 12:36:47 -0500" is a valid 847 date, and the string "12:36:47 GMT" is a valid time. Quoting from 848 RFC 1123, Section 5.2.14: "There is a strong trend towards the use of 849 numeric timezone indicators, and implementations SHOULD use numeric 850 timezones instead of timezone names. However, all implementations 851 MUST accept either notation. If timezone names are used, they MUST 852 be exactly as defined in RFC 822." 854 Time ranges (or periods) must be specified as pairs of time values 855 (as defined above in note (5)), separated by a "/". Multiple time 856 ranges are separated by whitespace. All times in a range should be 857 specified with the same timezone. For example 12:00 GMT / 05:45 GMT. 859 "whitespace" is defined as one or more blank (hex 0x20) and/or tab 860 (octal 11) ASCII characters. 862 References to "UT" mean Universal Time (also known as Greenwich Mean 863 Time or "GMT"). 865 All telephone numbers are to be given as a minimum in full, with a 866 leading '+' and country and routing codes without non-space separa- 867 tors. The number should be given assuming someone calling interna- 868 tionally (without local access codes). The number given in the local 869 convention may optionally be specified in brackets. For example, 870 Telephone: +44 71 732 8011 or Telephone: +1 514 875 8189 871 (0514-875-8611). 873 Latitude and longitude are specified in that order as 874 CDD.MM.SS/CDD.MM.SS where 876 DD is in degrees 877 MM is in minutes 878 SS is in seconds 879 C is the direction designator which is for latitude 881 "+" is north of the equator and "-" is south of the equator. For lon- 882 gitude "+" is west of the Greenwich meridian and "-" is east of the 883 Greenwich meridian. The double quotes (") are not part of the desig- 884 nator, but are used here to delimit the symbols. 886 Person name fields should conform to a particular format (based on 887 BibTeX [8]), so that they can be parsed into parts. A name can have 888 four parts: first, von, last, junior, each of which can consist of 889 more than one word. For example, "John Paul von Braun, Jr." has 890 "John Paul" as the first part, "von" as the von part, "Braun" as the 891 last part, and "Jr." as the junior part Use one of these formats for 892 a name: 894 First von Last 895 von Last, First 896 von Last, Junior, First 898 The last part is assumed to be one word, or all the words after the 899 von part. Anything in braces will be treated as one word, so use 900 braces to surround last names that contain more than one word. The 901 von part is recognized by looking for words that begin with lowercase 902 letters. When possible, enter the full first name(s). Actually, the 903 rules for isolating the name parts are a bit more complicated, so 904 they do the right thing for names like "de la Grand Round, Chuck". 905 If there are multiple authors or editors, they should all be sepa- 906 rated by the word and. 908 APPENDIX B: Representing Dublin Core in WHOIS++ 910 The Dublin Core is a simple resource description format which arose 911 out of a loose grouping of "librarians, archivists, humanities schol- 912 ars and geographers, as well as standards makers in the Internet, 913 Z39.50 and Standard Generalized Markup Language (SGML) communities" 914 [2]. 916 This document proposes a mapping from the abstract model of the 917 Dublin Core to WHOIS++. We suggest that the Dublin Core element set 918 [9] (with the concrete syntax given in the DOCUMENT template above) 919 be used as WHOIS++ attributes, and that the template type "DOCUMENT" 920 be used to represent a WHOIS++ template which uses the Dublin Core 921 element set. For example, a "Title" element which had the value 922 "Cities of The Red Night" would be represented within WHOIS++ as the 923 attribute/value pair: 925 Title: Cities of The Red Night 927 One aspect of the Dublin Core does not translate directly to WHOIS++ 928 - each element may have additional qualifiers such as "scheme" asso- 929 ciated with it. This provides the creator of the record with a way 930 of indicating additional semantics, e.g. the classification scheme 931 being used in the "Subject" element. 933 Since WHOIS++, like most Internet based search and retrieval proto- 934 cols, is attribute/value oriented, it is necessary to find a place to 935 put this extra information. We propose that it be placed in an addi- 936 tional attribute/value pair which precedes the main information about 937 the element. For example, if the subject classification for the 938 above book were 813 in the Dewey Decimal system, the resulting Dublin 939 Core elements expressed via WHOIS++ might look like this: 941 Subject-Scheme: DDC 942 Subject: 813 944 Since the order of the attribute/value pairs in a WHOIS++ record is 945 significant, this provides a simple and easily implemented mechanism 946 for grouping together elements and their qualifying information. 948 Needless to say, scheme information should only appear in the WHOIS++ 949 record if the attribute it qualifies also appears! 951 It is important to note that the Dublin Core element set is intended 952 for use in describing document-like objects, and not as a means of 953 describing arbitrary objects. Furthermore, the number of elements is 954 strictly limited in the interests of interoperability. 956 Work is ongoing on the Warwick Framework [10], which attempts to pro- 957 vide a mechanism for packaging together collections of descriptive 958 information. It is envisaged that this would be used in cases where 959 the Dublin Core element set did not provide enough descriptive capa- 960 bility. This is a subject for further study and is beyond the scope 961 of this specification. 963 APPENDIX C: Representing the Internet Whitepages Schema (IWPS) in WHOIS++ 965 The IETF's IDS working group has defined a standardized abstract schema 966 for "a simple Internet Whitepages Service". The reader is referred to 967 the documentation describing that schema ([11]) for details on the expected 968 syntax, precise content and length limitations for individual attributes. 970 +-------------------------+-----------------------------------+ 971 | IWPS Field | WHOIS++ USER Template Attribute | 972 +-------------------------+-----------------------------------+ 973 | Email | Email or Email-X400 | 974 | Cert | (* see below) | 975 | Home Page | Homepage-URI | 976 | Common Name | Name | 977 | Given Name | Name-First | 978 | Surname | Name-Last | 979 | Organization | Organization-Name | 980 | Locality | Address-Locality | 981 | Country | Address-Country | 982 | Language Spoken | Language-Pref | 983 | Personal Phone | Phone | 984 | Personal Fax | Fax | 985 | Personal Mobile Phone | Cellular | 986 | Personal Pager Number | Pager | 987 | Personal Postal Address | Address | 988 | Description | Picture-URI | 989 | Title | Title | 990 | Office Phone | Organization-Phone | 991 | Office Fax | Organization-Fax | 992 | Office Mobile Phone | Organization-Cellular | 993 | Office Pager | Organization-Page | 994 | Office Postal Address | Organization-Address | 995 | Creation Date | Record-Creation-Date | 996 | Creator Name | Record-Creation-Contact-Name | 997 | Modified Date | Record-Last-Modified-Date | 998 | Modifier Name | Record-Last-Modified-Contact-Name| 999 +-------------------------+-----------------------------------+ 1001 The "Cert" attribute, as described by the IWPS document, is as follows: 1003 "The certificate field is intended to hold any kind of certificate; X.509 1004 certificates are one example. A specific implementation will specify 1005 how to indicate the type of certificate when describing the mapping of 1006 the IWPS schema onto the implementation schema." 1008 As the Whois++ USER certificate is set up to accommodate both PGP 1009 keys and X.509 pointers, this one IWPS field is defined to conditionally 1010 be mapped to the appropriate fields for each technology: 1012 PGP-Version 1013 PGP-Key-Length 1014 PGP-Key-ID 1015 PGP-Fingerprint 1016 PGP-Public-Key 1018 and/or 1020 PGP-Public-Key-URI 1022 and/or 1024 X509-CERT-URI 1026 with appropriate attendant information (e.g. PGP-NAME, etc) as appropriate.