[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
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
                     <draft-ietf-schema-whoispp-00.txt>

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: <ids1@wherever.com>
   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,  ":" / <tab> / <CR><LF> 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 = <URI to retrieve a template definition
                             that includes the necessary attribute def'n>
        attr-cid  = <CID of MIME object defining the attribute;
                     Content-ID as defined as used in [LEVI1]; required if
                     the attribute is defined locally>
        attr-name = 0*veryrestrictedbyte
        veryrestrictedbyte  =   <%d33-%d127 except specialbyte>
        specialbyte     =   %d58 / %d09/ %d13 %d10
                            ; That is,  ":" / <tab> / <CR><LF> in ascii

   where the semantics are as follows:

        wpp-attr-ptr = <attribute name as used in this template>  +
                       <id of template where the attribute is defined> +
                       <attribute name as it appears in defining template> +
                       <optional CID of portion of MIME object defining
                        the attribute in that template definition.  Required
                        if the definition is contained in this template's
                        registration>

   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,  ":" / <tab> / <CR><LF> 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: <ids1@wherever.com>
   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: <ids1@wherever.com>
   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,
           <draft-ietf-schema-rqmts-list-00.txt>.

   [APPL2] Apple, C. "Directory Schema Listing File Names", (work
           in progress) January 1998, <draft-ietf-schema-file-list-00.txt>.

   [APPL3] Apple, C. "Directory Schema Listing Procedures", (work
           in progress) January 1998, <draft-ietf-schema-proc-list-00.txt>.

   [APPL4] Apple, C. "Directory Schema Listing Meta Data", (work in progress)
           January 1998, <draft-ietf-schema-mime-metadata-00.txt>.

   [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,
           <draft-ietf-asid-whoispp-02.txt>  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,
           <draft-ietf-asid-whois-schema-03.txt>.

   [HOWE1] Howes, Tim, Mark Smith, Frank Dawson. "A MIME Content-Type for
           Directory Information", (work in progress) March 1998,
           <draft-ietf-asid-mime-direct-06.txt>.

   [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,
           <draft-ietf-schema-rwhois-00.txt>.