Internet-Draft Leslie L. Daigle draft-ietf-schema-whoispp-00.txt Bunyip Information Systems Inc. Expires in six months April 21, 1998 MIME Directory Profiles for Listing Whois++ Schema Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 1. Abstract This document defines two MIME directory profiles [HOWE1] necessary for supporting the definition of Whois++ [FALT1] templates (schemas). It is intended for communication with the Internet schema listing service ([APPL1], [APPL2], [APPL3], [APPL4]). The profiles defined are: schema-whoispp-0 whoispp-attr-0 Also, 5 MIME directory types are defined: wpp-template-name wpp-template-desc wpp-attr-ptr wpp-attr-name wpp-attr-desc 2. Overview Whois++ [FALT1] makes use of typed information templates, which are analogous to schemas as defined by the Internet schema listing service. At its simplest, a Whois++ template definition is the listing and description of attributes that are useful or expected for the template. In use, some attributes may be omitted and others (local additions) may be included in data presented in a particular template. One of the original philosophies of supporting the Whois++ protocol was that there should be as few template and attribute types as possible; standard types can and should be used wherever applicable. This key collection of templates and attributes have been defined elsewhere (see [FALT2]). That document defines the concept of attribute "clusters" -- a construct used solely for the purpose of template definition, and not reflected in the structure of templates as they are transmitted in the Whois++ protocol. In order to preserve some kind of order in the universe of Whois++ templates, these MIME directory profile definitions attempt to capture some of those constructs to maximize the possibility of reuse of attribute definitions. This document therefore defines a MIME directory profile [HOWE1] and the necessary types to express a Whois++ template (schema) definition, in terms of the (expected) attributes it uses (schema-whoispp-0). Also, attribute (collections) are defined in a separate MIME directory profile (whoispp-attr-0). For the purposes of the Internet schema listing service, any listing is constructed of a multipart/related MIME object, where the start object is the text/directory MIME type for the schema-whoispp-0 profile, and related attribute definitions are included in separate text/directory MIME message parts with the whoispp-attr-0 profile. This approach is directly inspired by that laid out for RWhois 1.5 in [MEAL1]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [BRAD1]. 3. Using the Internet Schema Listing Service for Whois++ Templates The format of the message must be multipart/related, where 'boundary' has its standard RFC2046 specified value 'start' is the CID of the text/directory 'schema-whoispp-0' profile 'type' MUST be 'text/directory' 'start-info' MUST be 'schema-whoispp-0' For example, borrowing from the example in [MEAL1]: To: ietf-schema-review@TBD Subject: schema unit listing request MIME-Version: 1.0 Message-Id: Content-Type: multipart/related; boundary="boundary"; start=3@foo.com; type="text/directory"; start-info="schema-whoispp-0" Content-ID: top@foo.com --boundary Content-Type: text/directory; profile="schema-whoispp-0" Content-Transfer-Encoding: Quoted-Printable Content-ID: 3@foo.com (schema-whoispp-0 types and values as specified in Section 4 which includes a reference to an attribute whose CID is 4@foo.com) --boundary Content-Type: text/directory; profile="whoispp-attr-0" Content-Transfer-Encoding: Quoted-Printable Content-ID: 4@foo.com (a Whois++ attribute definition) --boundary 4. schema-whoispp-0 Profile Registration The schema-whoispp-0 profile is generally as simple as a template name, a template description, and one or more attribute names with pointers to their definitions. (Attribute definitions are either expected to be included in an attached whoispp-attr-0 text/directory profile, or in a referenced schema listing). To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME profile schema-whoispp-0 Profile name: schema-whoispp-0 Profile purpose: To represent templates defined for use within the Whois++ protocol Profile types: wpp-template-name, wpp-template-desc, wpp-attr-ptr Profile special notes: The profile MUST include exactly one wpp-template-name and associated wpp-template-desc. If the purpose of the registration is to define a collection of generically useful Whois++ attributes, a generic basename may be constructed as follows: generic-template-name = "generic-" numericid numericid = YYYY MM DD digitstring YYYY = <4-digit year identifier of listing date> MM = <2-digit month identifier of listing date> DD = <2-digit day identifier of listing date> numericid = 1*DIGIT DIGIT = "0" / "1" / "2" / "3" / "4" / "5" "6" / "7" / "8" / "9" For example: generic-199804210 Intended usage: COMMON 5. whoispp-attr-0 Profile Registration To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME profile whoispp-attr-0 Profile name: whoispp-attr-0 Profile purpose: To represent attributes defined for use within the Whois++ protocol Profile types: wpp-attr-name, wpp-attr-ptr, wpp-attr-desc Profile special notes: There MUST be exactly one of wpp-attr-name and wpp-attr-ptr, and there MUST be exactly one wpp-attr-desc in the whoispp-attr-0 profile. If the wpp-attr-ptr type is used, the wpp-attr-desc is taken to override or refine the description of the attribute that is referenced by pointer (e.g., to specify the attributes role in this template, etc). Intended usage: COMMON 6. MIME Directory type registrations This document also defines the MIME directory types used by the schema-whoispp-0 and whoispp-attr-0 profiles. 6.1 The wpp-template-name MIME directory type To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type wpp-template-name Type name: wpp-template-name Type purpose: to represent a Whois++ template name Type encoding: 8bit Type valuetype: text, with additional syntax constraints as defined in "type special notes". Type special notes: The syntax of this type MUST conform to the following grammar, expressed using the ABNF defined in [CROC1]. wpp-template-name = 0*restrictedbyte restrictedbyte = <%d33-%d255 except specialbyte> specialbyte = %d58 / %d09/ %d13 %d10 ; That is, ":" / / in ascii For example, FREd is a valid template name, although Fred's template is not (the space character, %d32) Intended usage: COMMON 6.2 The wpp-template-desc MIME directory type To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type wpp-template-desc Type name: wpp-template-desc Type purpose: to contain the textual description of a Whois++ template Type encoding: 8bit Type valuetype: text Type special notes: NONE Intended usage: COMMON 6.3 The wpp-attr-ptr MIME directory type To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type wpp-attr-ptr Type name: wpp-attr-ptr Type purpose: to contain the pointer to an attribute used in a Whois++ template; the pointer must indicate a part of the current template defininition listing, or some other previously-listed template Type encoding: 8bit Type valuetype: text, with the syntax restrictions as defined in "Type special notes" Type special notes: The syntax for this type is as follows: wpp-attr-ptr = attr-name attr-def attr-def = "." attr-cid / template-defn-uri attr-name [attr-cid] ; "." means this template definition template-defn-uri = attr-cid = attr-name = 0*veryrestrictedbyte veryrestrictedbyte = <%d33-%d127 except specialbyte> specialbyte = %d58 / %d09/ %d13 %d10 ; That is, ":" / / in ascii where the semantics are as follows: wpp-attr-ptr = + + + For example, wpp-attr-ptr:colourscheme . 4@foo.com or wpp-attr-ptr:kolorskeam ftp://ftp.someorg.com/somefile colourdef (which uses the "colourdef" attribute from the specified template definition). 6.4 The wpp-attr-name MIME directory type To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type wpp-attr-name Type name: wpp-attr-name Type purpose: to represent a Whois++ attribute name Type encoding: 8bit Type valuetype: text, with additional syntax constraints as defined in "type special notes". Type special notes: The syntax of this type MUST conform to the following grammar, expressed using the ABNF defined in [CROC1]. wpp-attr-name = 0*veryrestrictedbyte veryrestrictedbyte = <%d33-%d127 except specialbyte> specialbyte = %d58 / %d09/ %d13 %d10 ; That is, ":" / / in ascii Intended usage: COMMON 6.5 The wpp-attr-desc MIME directory type To: ietf-mime-direct@imc.org Subject: Registration of text/directory MIME type wpp-attr-desc Type name: wpp-attr-desc Type purpose: to contain the free-text description description of an attribute, along with any expected uses, restrictions, etc. Type encoding: 8bit Type valuetype: text Type special notes: NONE Intended usage: COMMON 7. Examples The following example defines the "address cluster" as defined in [FALT2]. To: ietf-schema-review@TBD Subject: schema unit listing request MIME-Version: 1.0 Message-Id: Content-Type: multipart/related; boundary="boundary"; start=3@foo.com; type="text/directory"; start-info="schema-whoispp-0" Content-ID: top@foo.com --boundary Content-Type: text/directory; profile="schema-whoispp-0" Content-Transfer-Encoding: Quoted-Printable Content-ID: 3@foo.com wpp-template-name:generic-199804210 wpp-template-desc: Generic collection of useful address attributes. wpp-attr-ptr:address . 4@foo.com wpp-attr-ptr:address-type . 5@foo.com wpp-attr-ptr:address-city . 6@foo.com wpp-attr-ptr:address-country . 7@foo.com wpp-attr-ptr:address-room . 8@foo.com wpp-attr-ptr:address-state . 9@foo.com wpp-attr-ptr:address-street . 10@foo.com wpp-attr-ptr:address-zip-code . 11@foo.com wpp-attr-ptr:address-locality . 12@foo.com --boundary Content-Type: text/directory; profile="whoispp-attr-0" Content-Transfer-Encoding: Quoted-Printable Content-ID: 4@foo.com wpp-attr-name:Address wpp-attr-desc:Full address --boundary Content-Type: text/directory; profile="whoispp-attr-0" Content-Transfer-Encoding: Quoted-Printable Content-ID: 5@foo.com wpp-attr-name:Address-Type wpp-attr-desc:Type of address, e.g., work or home --boundary Content-Type: text/directory; profile="whoispp-attr-0" Content-Transfer-Encoding: Quoted-Printable Content-ID: 6@foo.com wpp-attr-name:Address-City wpp-attr-desc:City --boundary Content-Type: text/directory; profile="whoispp-attr-0" Content-Transfer-Encoding: Quoted-Printable Content-ID: 7@foo.com wpp-attr-name:Address-Country wpp-attr-desc:Country --boundary Content-Type: text/directory; profile="whoispp-attr-0" Content-Transfer-Encoding: Quoted-Printable Content-ID: 8@foo.com wpp-attr-name:Address-Room wpp-attr-desc:Room --boundary Content-Type: text/directory; profile="whoispp-attr-0" Content-Transfer-Encoding: Quoted-Printable Content-ID: 9@foo.com wpp-attr-name:Address-State wpp-attr-desc:State, county or province --boundary Content-Type: text/directory; profile="whoispp-attr-0" Content-Transfer-Encoding: Quoted-Printable Content-ID: 10@foo.com wpp-attr-name:Address-Street wpp-attr-desc:Street address --boundary Content-Type: text/directory; profile="whoispp-attr-0" Content-Transfer-Encoding: Quoted-Printable Content-ID: 11@foo.com wpp-attr-name:Address-Zip-Code wpp-attr-desc:Zip or Postal code --boundary Content-Type: text/directory; profile="whoispp-attr-0" Content-Transfer-Encoding: Quoted-Printable Content-ID: 12@foo.com wpp-attr-name:Address-Locality wpp-attr-desc:Geographic region --boundary Then, the following template definition can make use of the address definitions, assuming the above definition can be found at: ftp://ftp.somewhere.com/addr-defns To: ietf-schema-review@TBD Subject: schema unit listing request MIME-Version: 1.0 Message-Id: Content-Type: multipart/related; boundary="boundary"; start=3@foo.com; type="text/directory"; start-info="schema-whoispp-0" Content-ID: top@foo.com --boundary Content-Type: text/directory; profile="schema-whoispp-0" Content-Transfer-Encoding: Quoted-Printable Content-ID: 3@foo.com wpp-template-name:simple-home-user wpp-template-desc: A simplified user template. wpp-attr-ptr:mailing-address . 4@foo.com wpp-attr-ptr:mailing-address-locality ftp://ftp.somewhere.com/addr-defns address-locality wpp-attr-ptr:cust-number . 5@foo.com --boundary Content-Type: text/directory; profile="whoispp-attr-0" Content-Transfer-Encoding: Quoted-Printable Content-ID: 4@foo.com wpp-attr-ptr:mailing-address ftp://ftp.somewhere.com/addr-defns address wpp-attr-desc:This is for the home mailing address of the user --boundary Content-Type: text/directory; profile="whoispp-attr-0" Content-Transfer-Encoding: Quoted-Printable Content-ID: 5@foo.com wpp-attr-name:cust-number wpp-attr-desc:User's customer number; syntax is "any 7 digits" --boundary Note that the address-locality attribute is used as described remotely, but an overriding description is provided for the address attribute. 8. Security Considerations This document introduces no new security considerations to those already discussed in the Internet directory schema listing service documentation ([APPL1], [APPL2], [APPL3], [APPL4]). 9. Acknowledgements Thanks to Chris Apple for politely poking me into producing this document -- and my apologies for being the last kid on the block to submit a sensible draft. That tardiness also provokes a word of acknowledgement to the authors of the other profile definitions for the Schema listing services, whose documents I read for inspiration in structuring this one -- Micheal Mealling and Ryan Moats in particular will perhaps recognize where I've borrowed structure from their RWhois 1.5 and Whois documents, respectively :-) 10. Author's Contact Address Leslie L. Daigle Bunyip Information Systems Inc. 310 Ste. Catherine St. West Suite 300 Montreal, Quebec, CANADA H2X 2A1 email: leslie@bunyip.com 11. References: [APPL1] Apple, C. "Requirements for the Initial Release of a Directory Schema Listing Service", (work in progress) January 1998, . [APPL2] Apple, C. "Directory Schema Listing File Names", (work in progress) January 1998, . [APPL3] Apple, C. "Directory Schema Listing Procedures", (work in progress) January 1998, . [APPL4] Apple, C. "Directory Schema Listing Meta Data", (work in progress) January 1998, . [BRAD1] Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", RFC2119, March 1997. [CROC1] Crocker, D., P. Overell. "Augmented BNF for Syntax Specifications: ABNF", RFC2234, November 1997. [DEUT1] Deutsch, P., R. Schoultz, P. Faltstrom, C. Weider. "Architecture of the WHOIS++ service", RFC1835, August 1995. [FALT1] Faltstrom, Patrik, Leslie L. Daigle, Sima Newell. "Architecture of the Whois++ service", (work in progress) March 1998, This document is a refinement of the protocol specified in [DEUT95]. [FALT2] Faltstrom, Patrik, Martin Hamilton, Leslie L. Daigle, Jon Knight. "WHOIS++ templates" (work in progress) March 1998, . [HOWE1] Howes, Tim, Mark Smith, Frank Dawson. "A MIME Content-Type for Directory Information", (work in progress) March 1998, . [LEVI1] Levinson, E. "Message/External-Body Content-ID Access Type", RFC1873, December 1995. [MEAL1] Mealling, Micheal. "A MIME Directory Profile for RWhois 1.5 Schema", (work in progress) March 1998, .