idnits 2.17.1 draft-ietf-schema-whoispp-00.txt: ** The Abstract section seems to be numbered 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-19) 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 548 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 an Authors' Addresses Section. ** There are 29 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 62 instances of lines with control characters in the document. ** The abstract seems to contain references ([APPL1], [APPL2], [APPL3], [APPL4], [HOWE1], [FALT1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 168 has weird spacing: '...tly one of wp...' -- 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 (April 21, 1998) is 9495 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) -- Missing reference section? 'HOWE1' on line 511 looks like a reference -- Missing reference section? 'FALT1' on line 502 looks like a reference -- Missing reference section? 'APPL1' on line 480 looks like a reference -- Missing reference section? 'APPL2' on line 484 looks like a reference -- Missing reference section? 'APPL3' on line 487 looks like a reference -- Missing reference section? 'APPL4' on line 490 looks like a reference -- Missing reference section? 'FALT2' on line 507 looks like a reference -- Missing reference section? 'MEAL1' on line 518 looks like a reference -- Missing reference section? 'BRAD1' on line 493 looks like a reference -- Missing reference section? 'CROC1' on line 496 looks like a reference -- Missing reference section? 'LEVI1' on line 515 looks like a reference -- Missing reference section? 'DEUT1' on line 499 looks like a reference -- Missing reference section? 'DEUT95' on line 505 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Leslie L. Daigle 3 draft-ietf-schema-whoispp-00.txt Bunyip Information Systems Inc. 4 Expires in six months April 21, 1998 6 MIME Directory Profiles for Listing Whois++ Schema 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 "work in progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 1. Abstract 31 This document defines two MIME directory profiles [HOWE1] necessary 32 for supporting the definition of Whois++ [FALT1] templates (schemas). 33 It is intended for communication with the Internet schema listing 34 service ([APPL1], [APPL2], [APPL3], [APPL4]). 36 The profiles defined are: 38 schema-whoispp-0 39 whoispp-attr-0 41 Also, 5 MIME directory types are defined: 43 wpp-template-name 44 wpp-template-desc 45 wpp-attr-ptr 46 wpp-attr-name 47 wpp-attr-desc 49 2. Overview 51 Whois++ [FALT1] makes use of typed information templates, which are analogous 52 to schemas as defined by the Internet schema listing service. At its simplest, 53 a Whois++ template definition is the listing and description of attributes 54 that are useful or expected for the template. In use, some attributes may be 55 omitted and others (local additions) may be included in data presented in a 56 particular template. 58 One of the original philosophies of supporting the Whois++ protocol was 59 that there should be as few template and attribute types as possible; 60 standard types can and should be used wherever applicable. This key 61 collection of templates and attributes have been defined elsewhere 62 (see [FALT2]). That document defines the concept of attribute "clusters" 63 -- a construct used solely for the purpose of template definition, and not 64 reflected in the structure of templates as they are transmitted in the 65 Whois++ protocol. In order to preserve some kind of order in the universe 66 of Whois++ templates, these MIME directory profile definitions attempt to 67 capture some of those constructs to maximize the possibility of reuse of 68 attribute definitions. 70 This document therefore defines a MIME directory profile [HOWE1] and the 71 necessary types to express a Whois++ template (schema) definition, in 72 terms of the (expected) attributes it uses (schema-whoispp-0). Also, 73 attribute (collections) are defined in a separate MIME directory profile 74 (whoispp-attr-0). For the purposes of the Internet schema listing 75 service, any listing is constructed of a multipart/related MIME object, 76 where the start object is the text/directory MIME type for the 77 schema-whoispp-0 profile, and related attribute definitions are included in 78 separate text/directory MIME message parts with the whoispp-attr-0 79 profile. This approach is directly inspired by that laid out for 80 RWhois 1.5 in [MEAL1]. 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 84 this document are to be interpreted as described in RFC 2119 [BRAD1]. 86 3. Using the Internet Schema Listing Service for Whois++ Templates 88 The format of the message must be multipart/related, where 90 'boundary' has its standard RFC2046 specified value 91 'start' is the CID of the text/directory 'schema-whoispp-0' profile 92 'type' MUST be 'text/directory' 93 'start-info' MUST be 'schema-whoispp-0' 95 For example, borrowing from the example in [MEAL1]: 97 To: ietf-schema-review@TBD 98 Subject: schema unit listing request 99 MIME-Version: 1.0 100 Message-Id: 101 Content-Type: multipart/related; boundary="boundary"; 102 start=3@foo.com; type="text/directory"; 103 start-info="schema-whoispp-0" 104 Content-ID: top@foo.com 106 --boundary 107 Content-Type: text/directory; profile="schema-whoispp-0" 108 Content-Transfer-Encoding: Quoted-Printable 109 Content-ID: 3@foo.com 111 (schema-whoispp-0 types and values as specified in Section 4 112 which includes a reference to an attribute whose CID is 4@foo.com) 114 --boundary 115 Content-Type: text/directory; profile="whoispp-attr-0" 116 Content-Transfer-Encoding: Quoted-Printable 117 Content-ID: 4@foo.com 119 (a Whois++ attribute definition) 121 --boundary 123 4. schema-whoispp-0 Profile Registration 125 The schema-whoispp-0 profile is generally as simple as a template name, 126 a template description, and one or more attribute names with pointers 127 to their definitions. (Attribute definitions are either expected to 128 be included in an attached whoispp-attr-0 text/directory profile, 129 or in a referenced schema listing). 131 To: ietf-mime-direct@imc.org 132 Subject: Registration of text/directory MIME profile schema-whoispp-0 134 Profile name: schema-whoispp-0 135 Profile purpose: To represent templates defined for use within the Whois++ 136 protocol 137 Profile types: wpp-template-name, wpp-template-desc, wpp-attr-ptr 138 Profile special notes: The profile MUST include exactly one wpp-template-name 139 and associated wpp-template-desc. If the purpose of 140 the registration is to define a collection of generically 141 useful Whois++ attributes, a generic basename may be 142 constructed as follows: 144 generic-template-name = "generic-" numericid 145 numericid = YYYY MM DD digitstring 146 YYYY = <4-digit year identifier of listing date> 147 MM = <2-digit month identifier of listing date> 148 DD = <2-digit day identifier of listing date> 149 numericid = 1*DIGIT 150 DIGIT = "0" / "1" / "2" / "3" / "4" / "5" 151 "6" / "7" / "8" / "9" 153 For example: 155 generic-199804210 157 Intended usage: COMMON 159 5. whoispp-attr-0 Profile Registration 161 To: ietf-mime-direct@imc.org 162 Subject: Registration of text/directory MIME profile whoispp-attr-0 164 Profile name: whoispp-attr-0 165 Profile purpose: To represent attributes defined for use within the Whois++ 166 protocol 167 Profile types: wpp-attr-name, wpp-attr-ptr, wpp-attr-desc 168 Profile special notes: There MUST be exactly one of wpp-attr-name and 169 wpp-attr-ptr, and there MUST be exactly one 170 wpp-attr-desc in the whoispp-attr-0 profile. If 171 the wpp-attr-ptr type is used, the wpp-attr-desc 172 is taken to override or refine the description of the 173 attribute that is referenced by pointer (e.g., to 174 specify the attributes role in this template, etc). 176 Intended usage: COMMON 178 6. MIME Directory type registrations 180 This document also defines the MIME directory types used by the 181 schema-whoispp-0 and whoispp-attr-0 profiles. 183 6.1 The wpp-template-name MIME directory type 185 To: ietf-mime-direct@imc.org 186 Subject: Registration of text/directory MIME type wpp-template-name 188 Type name: wpp-template-name 189 Type purpose: to represent a Whois++ template name 190 Type encoding: 8bit 191 Type valuetype: text, with additional syntax constraints as defined in 192 "type special notes". 193 Type special notes: The syntax of this type MUST conform to the following 194 grammar, expressed using the ABNF defined in [CROC1]. 196 wpp-template-name = 0*restrictedbyte 197 restrictedbyte = <%d33-%d255 except specialbyte> 198 specialbyte = %d58 / %d09/ %d13 %d10 199 ; That is, ":" / / in ascii 201 For example, 203 FREd is a valid template name, although 204 Fred's template is not (the space character, %d32) 206 Intended usage: COMMON 208 6.2 The wpp-template-desc MIME directory type 210 To: ietf-mime-direct@imc.org 211 Subject: Registration of text/directory MIME type wpp-template-desc 213 Type name: wpp-template-desc 214 Type purpose: to contain the textual description of a Whois++ template 215 Type encoding: 8bit 216 Type valuetype: text 217 Type special notes: NONE 218 Intended usage: COMMON 220 6.3 The wpp-attr-ptr MIME directory type 222 To: ietf-mime-direct@imc.org 223 Subject: Registration of text/directory MIME type wpp-attr-ptr 225 Type name: wpp-attr-ptr 226 Type purpose: to contain the pointer to an attribute used in a Whois++ 227 template; the pointer must indicate a part of the current 228 template defininition listing, or some other 229 previously-listed template 230 Type encoding: 8bit 231 Type valuetype: text, with the syntax restrictions as defined in "Type 232 special notes" 233 Type special notes: The syntax for this type is as follows: 235 wpp-attr-ptr = attr-name attr-def 236 attr-def = "." attr-cid / template-defn-uri attr-name [attr-cid] 237 ; "." means this template definition 238 template-defn-uri = 240 attr-cid = 243 attr-name = 0*veryrestrictedbyte 244 veryrestrictedbyte = <%d33-%d127 except specialbyte> 245 specialbyte = %d58 / %d09/ %d13 %d10 246 ; That is, ":" / / in ascii 248 where the semantics are as follows: 250 wpp-attr-ptr = + 251 + 252 + 253 258 For example, 260 wpp-attr-ptr:colourscheme . 4@foo.com 262 or 263 wpp-attr-ptr:kolorskeam ftp://ftp.someorg.com/somefile colourdef 265 (which uses the "colourdef" attribute from the specified template 266 definition). 268 6.4 The wpp-attr-name MIME directory type 270 To: ietf-mime-direct@imc.org 271 Subject: Registration of text/directory MIME type wpp-attr-name 273 Type name: wpp-attr-name 274 Type purpose: to represent a Whois++ attribute name 275 Type encoding: 8bit 276 Type valuetype: text, with additional syntax constraints as defined in 277 "type special notes". 278 Type special notes: The syntax of this type MUST conform to the following 279 grammar, expressed using the ABNF defined in [CROC1]. 281 wpp-attr-name = 0*veryrestrictedbyte 282 veryrestrictedbyte = <%d33-%d127 except specialbyte> 283 specialbyte = %d58 / %d09/ %d13 %d10 284 ; That is, ":" / / in ascii 286 Intended usage: COMMON 288 6.5 The wpp-attr-desc MIME directory type 290 To: ietf-mime-direct@imc.org 291 Subject: Registration of text/directory MIME type wpp-attr-desc 293 Type name: wpp-attr-desc 294 Type purpose: to contain the free-text description description of an 295 attribute, along with any expected uses, restrictions, etc. 296 Type encoding: 8bit 297 Type valuetype: text 298 Type special notes: NONE 299 Intended usage: COMMON 301 7. Examples 303 The following example defines the "address cluster" as defined in 304 [FALT2]. 306 To: ietf-schema-review@TBD 307 Subject: schema unit listing request 308 MIME-Version: 1.0 309 Message-Id: 310 Content-Type: multipart/related; boundary="boundary"; 311 start=3@foo.com; type="text/directory"; 312 start-info="schema-whoispp-0" 313 Content-ID: top@foo.com 315 --boundary 316 Content-Type: text/directory; profile="schema-whoispp-0" 317 Content-Transfer-Encoding: Quoted-Printable 318 Content-ID: 3@foo.com 320 wpp-template-name:generic-199804210 321 wpp-template-desc: Generic collection of useful address attributes. 322 wpp-attr-ptr:address . 4@foo.com 323 wpp-attr-ptr:address-type . 5@foo.com 324 wpp-attr-ptr:address-city . 6@foo.com 325 wpp-attr-ptr:address-country . 7@foo.com 326 wpp-attr-ptr:address-room . 8@foo.com 327 wpp-attr-ptr:address-state . 9@foo.com 328 wpp-attr-ptr:address-street . 10@foo.com 329 wpp-attr-ptr:address-zip-code . 11@foo.com 330 wpp-attr-ptr:address-locality . 12@foo.com 332 --boundary 333 Content-Type: text/directory; profile="whoispp-attr-0" 334 Content-Transfer-Encoding: Quoted-Printable 335 Content-ID: 4@foo.com 337 wpp-attr-name:Address 338 wpp-attr-desc:Full address 339 --boundary 341 Content-Type: text/directory; profile="whoispp-attr-0" 342 Content-Transfer-Encoding: Quoted-Printable 343 Content-ID: 5@foo.com 345 wpp-attr-name:Address-Type 346 wpp-attr-desc:Type of address, e.g., work or home 347 --boundary 349 Content-Type: text/directory; profile="whoispp-attr-0" 350 Content-Transfer-Encoding: Quoted-Printable 351 Content-ID: 6@foo.com 353 wpp-attr-name:Address-City 354 wpp-attr-desc:City 355 --boundary 357 Content-Type: text/directory; profile="whoispp-attr-0" 358 Content-Transfer-Encoding: Quoted-Printable 359 Content-ID: 7@foo.com 361 wpp-attr-name:Address-Country 362 wpp-attr-desc:Country 363 --boundary 365 Content-Type: text/directory; profile="whoispp-attr-0" 366 Content-Transfer-Encoding: Quoted-Printable 367 Content-ID: 8@foo.com 369 wpp-attr-name:Address-Room 370 wpp-attr-desc:Room 371 --boundary 373 Content-Type: text/directory; profile="whoispp-attr-0" 374 Content-Transfer-Encoding: Quoted-Printable 375 Content-ID: 9@foo.com 377 wpp-attr-name:Address-State 378 wpp-attr-desc:State, county or province 379 --boundary 381 Content-Type: text/directory; profile="whoispp-attr-0" 382 Content-Transfer-Encoding: Quoted-Printable 383 Content-ID: 10@foo.com 385 wpp-attr-name:Address-Street 386 wpp-attr-desc:Street address 387 --boundary 389 Content-Type: text/directory; profile="whoispp-attr-0" 390 Content-Transfer-Encoding: Quoted-Printable 391 Content-ID: 11@foo.com 393 wpp-attr-name:Address-Zip-Code 394 wpp-attr-desc:Zip or Postal code 395 --boundary 397 Content-Type: text/directory; profile="whoispp-attr-0" 398 Content-Transfer-Encoding: Quoted-Printable 399 Content-ID: 12@foo.com 401 wpp-attr-name:Address-Locality 402 wpp-attr-desc:Geographic region 403 --boundary 405 Then, the following template definition can make use of the address 406 definitions, assuming the above definition can be found at: 408 ftp://ftp.somewhere.com/addr-defns 410 To: ietf-schema-review@TBD 411 Subject: schema unit listing request 412 MIME-Version: 1.0 413 Message-Id: 414 Content-Type: multipart/related; boundary="boundary"; 415 start=3@foo.com; type="text/directory"; 416 start-info="schema-whoispp-0" 417 Content-ID: top@foo.com 419 --boundary 420 Content-Type: text/directory; profile="schema-whoispp-0" 421 Content-Transfer-Encoding: Quoted-Printable 422 Content-ID: 3@foo.com 424 wpp-template-name:simple-home-user 425 wpp-template-desc: A simplified user template. 426 wpp-attr-ptr:mailing-address . 4@foo.com 427 wpp-attr-ptr:mailing-address-locality ftp://ftp.somewhere.com/addr-defns 428 address-locality 429 wpp-attr-ptr:cust-number . 5@foo.com 431 --boundary 432 Content-Type: text/directory; profile="whoispp-attr-0" 433 Content-Transfer-Encoding: Quoted-Printable 434 Content-ID: 4@foo.com 436 wpp-attr-ptr:mailing-address ftp://ftp.somewhere.com/addr-defns address 437 wpp-attr-desc:This is for the home mailing address of the user 438 --boundary 439 Content-Type: text/directory; profile="whoispp-attr-0" 440 Content-Transfer-Encoding: Quoted-Printable 441 Content-ID: 5@foo.com 443 wpp-attr-name:cust-number 444 wpp-attr-desc:User's customer number; syntax is "any 7 digits" 445 --boundary 447 Note that the address-locality attribute is used as described remotely, 448 but an overriding description is provided for the address attribute. 450 8. Security Considerations 452 This document introduces no new security considerations to those 453 already discussed in the Internet directory schema listing service 454 documentation ([APPL1], [APPL2], [APPL3], [APPL4]). 456 9. Acknowledgements 458 Thanks to Chris Apple for politely poking me into producing this 459 document -- and my apologies for being the last kid on the block to 460 submit a sensible draft. That tardiness also provokes a word of 461 acknowledgement to the authors of the other profile definitions for the 462 Schema listing services, whose documents I read for inspiration in 463 structuring this one -- Micheal Mealling and Ryan Moats in particular will 464 perhaps recognize where I've borrowed structure from their RWhois 1.5 and Whois 465 documents, respectively :-) 467 10. Author's Contact Address 469 Leslie L. Daigle 470 Bunyip Information Systems Inc. 471 310 Ste. Catherine St. West 472 Suite 300 473 Montreal, Quebec, CANADA 474 H2X 2A1 476 email: leslie@bunyip.com 478 11. References: 480 [APPL1] Apple, C. "Requirements for the Initial Release of a Directory 481 Schema Listing Service", (work in progress) January 1998, 482 . 484 [APPL2] Apple, C. "Directory Schema Listing File Names", (work 485 in progress) January 1998, . 487 [APPL3] Apple, C. "Directory Schema Listing Procedures", (work 488 in progress) January 1998, . 490 [APPL4] Apple, C. "Directory Schema Listing Meta Data", (work in progress) 491 January 1998, . 493 [BRAD1] Bradner, S. "Key words for use in RFCs to Indicate Requirement 494 Levels", RFC2119, March 1997. 496 [CROC1] Crocker, D., P. Overell. "Augmented BNF for Syntax 497 Specifications: ABNF", RFC2234, November 1997. 499 [DEUT1] Deutsch, P., R. Schoultz, P. Faltstrom, C. Weider. "Architecture 500 of the WHOIS++ service", RFC1835, August 1995. 502 [FALT1] Faltstrom, Patrik, Leslie L. Daigle, Sima Newell. "Architecture 503 of the Whois++ service", (work in progress) March 1998, 504 This document is a refinement 505 of the protocol specified in [DEUT95]. 507 [FALT2] Faltstrom, Patrik, Martin Hamilton, Leslie L. Daigle, Jon 508 Knight. "WHOIS++ templates" (work in progress) March 1998, 509 . 511 [HOWE1] Howes, Tim, Mark Smith, Frank Dawson. "A MIME Content-Type for 512 Directory Information", (work in progress) March 1998, 513 . 515 [LEVI1] Levinson, E. "Message/External-Body Content-ID Access Type", 516 RFC1873, December 1995. 518 [MEAL1] Mealling, Micheal. "A MIME Directory Profile for RWhois 1.5 519 Schema", (work in progress) March 1998, 520 .