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

Versions: 00                                                            
CALENDAR Working Group                                    Darren Shakib
INTERNET DRAFT                                              Ian Ferrell
draft-shakib-mime-prop-00.txt                                 Microsoft
Expire in six months


         A MIME Content-Type for Tagged Property Value Storage


1.  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 learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
Directories  on  ftp.is.co.za  (Africa),  nic.nordu.net  (Europe),
munnari.oz.au  (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).


2.  Abstract

This memo defines a MIME Content-Type and for holding arbitrary item
information.  The definition is independent of any particular item type
or application.  The application/properties Content-Type is defined for
holding a variety of basic textual property information to describe the
item, for example a directory item could contain name, and email
address.  The application/properties Content-Type can also be used as
the root body part in a multipart/related Content-Type for handling more
complicated situations in which non-textual information, for example an
image or sound, must be represented.

The application/properties Content-Type defines a general framework and
format for holding directory information in a "name, datatype: value"
format.  This document also defines the procedure by which particular
formats for carrying the application-specific information within an
application/properties Content-Type may be defined and registered, and
the conventions such formats must follow.  It is expected that other
documents will be produced that define such formats for various
application item types (e.g. white pages, appointments).


3.  Need for a Generic Property MIME Type

For purposes of this document, a directory is a special-purpose database
that contains typed information. A directory usually supports both read
and search of the information it contains, and may support modification
of the information as well.  Directory information is usually accessed
far more often than it is updated.  Directories may be local or global
in scope.  They may be distributed or centralized. The information they
contain may be replicated, with weak or strong consistency requirements.

There are several situations in which users of Internet mail may wish to
exchange directory information: the email analogue of a "business card"
exchange; the conveyance of directory information to a user having only
email access to the Internet; the provision of machine-parseable address
information when purchasing goods or services over the Internet; etc. As
MIME [RFC-1521,RFC-1522] is used increasingly by other protocols, most
notably HTTP, it may be useful for these protocols to be able to carry
directory information in MIME format. Such a format, for example, could
be used to represent URC (uniform resource characteristics) information
about resources on the World Wide Web.

In addition to directory information there are item types that need to
be represented in a similar manner to directory items.  For example,
Calendaring items fall into this category.  Rather than having a unique
MIME Content-Type for each item type for encoding their properties and
values it is desirable to have a single encoding format that could
handle all of the item types.  This allows code to leverage the parsing
and processing code across the item types that need to be supported.

4.  Overview

The scheme defined here for representing the directory information in a
MIME Content-Type has two parts.  First, the application/properties
Content-Type is defined for use in holding simple textual property
information to describe an item, for example name, title, startdate,
location or email address.  The format uses a simple "name, datatype:
value" approach, which should be easily parsable by existing MIME
implementations and understandable by users.  This document defines the
general form the information in the Content-Type should take, and the
procedure by which the specific property names and values for particular
applications may be defined.  The framework is general enough to handle
information for a variety of items types including calendaring item
types and directory information from any number of end directory serves,
including LDAP [RFC-1777, RFC-1778], and WHOIS++ [RFC-1835].

Item types can include far more than just textual information.  Such
information (e.g., an image, HTML text or sound) overlaps with
predefined MIME Content-Types.  In these cases it may be desirable to
include the information in their well-known MIME formats.  This
situation is handled by using the multipart/related Content-Type as
defined in [RFC-1872].  The root component of this type is an
application/properties body part specifying an textual information in-
line and for information contained in other Content-Types, the Content-
Ids of those types.

Each property includes a data type in addition to the name of the
property and its value. Standard property data types include: text,
date/time, date, time, URL, float, long, boolean, binary, and currency.
Because of the wide variety of item types that may be specified,
including the data type as part of each property provides an extra hint
to keep parsing simple and support more generalized applications.  For
example a search engine would not have to know the particular data types
for all of the items that it is searching.  Because the data type is
explicit in the definition it could look for dates in any item type and
provide good results.  Some item types may be very loosely defined to
allow the sending of generic database records.

In order to reduce confusion some of the terminology has been changed
from [MIME-DIR].

    item
        Generic term used to refer to what the set of properties refers.
        An item may be a directory entry, appointment, or just a row in
        a database.

    name
        Name of the property being defined.  The [MIME-DIR] draft
        referred to this as type.  While this is common terminology for
        some directory implementations its meaning can easily be
        confused with the data type of a property.

    data type
        The data type for a property.  This is very similar to variable
        types in C or column definitions in many database products.

    profile
        Identifies the base schema for an item.


5.  The application/properties Content-Type

The application/properties Content-Type represents generic property data
used to describe an item and may contain references to other MIME body
parts holding additional data. It is defined as follows, using the MIME
content type registration from [MIME-REG], and the spirit of [MIME-DIR].

To: ietf-types@uninett.no
Subject: Registration of MIME media type application/properties

   MIME media type name: application

   MIME subtype name: properties

   Required parameters: none

   Optional parameters: charset, source, profile

   The charset parameter is as defined in [RFC-1521] for other body
   parts.

   The source parameter provides a reference back to the source
   calendar. It contains an URL (defined in [RFC-1738]) referencing the
   source calendar for the appointment data. Knowledgeable client
   applications may use the URL to retrieve additional or more up-to-
   date information about the item.


Encoding considerations:

   As specified by the Content-Transfer-Encoding header field.

Security considerations:

   Generic item information may be public or private. This specification
   does not include any access control mechanism to guarantee data
   privacy on a per-property or per Content-Type basis.

Interoperability considerations:

   Applications and downstream customers of this data must understand
   the types of information within the Content-Type, as defined in this
   document.

   This specification should be able describe the formats described in
   [MIME-DIR].  The default type of string will be used to specify the
   the values of [MIME-DIR] properties.

   Profile authors should attempt to make their properties
   understandable by users reading the body part as text.

Published specification:

The "application/properties" Content-Type contains textual property
information. The content consists of one or more CRLF-separated lines in
the following format. An application/properties content line has the
same continuation semantics as described in [RFC-822], section 3.1.1 on
"folding" long header lines (i.e., a single line may be split across
multiple physical lines by replacing linear-white-space with a CRLF
immediately followed by at least one LWSP-character). Using [RFC-822]'s
notation, the context syntax is:

      content := propvalue / propcid

      propvalue := [name], [datatype] ":" SPACE [value]

      propcid := [name], [datatype] "::" SPACE (*text) / string-list
                  ; strings refer to URLs as defined in [RFC-1738]
                  ; these URLs can refer to other body parts of a
                  ; MIME message according to the MHTML document

      name := x-token / iana-token

      datatype := x-token / iana-token

      x-token := <the two characters "X-" or "x-" followed, with no
                  intervening white space, by any token>

      iana-token := <a publicly-defined extension token, registered with
                     IANA, as specified in Section 10 of this document>

      value := *text ; characters whose syntax depends on type

      string-list   see definition in section 5.1

   Note that the meanings of the various names for a profile are
   defined in Section 10.  Specifications may specify ordering on the
   name constructs within a body part, though none is required by
   default. The x-token name specification is used for bilaterally-
   agreed upon names.

   Note that "name" is analogous to "type" in other drafts such as MIME-
   REG and MIME-DIR. This draft adds a second parameter, "datatype"
   describing the property's data format (e.g. TEXT or LONG). This
   parameter makes each property self-describing so client applications
   that do not understand an unknown or custom property's use can still
   support editing and displaying that property.

   Note "name" values MUST NOT be duplicated.  Multi-valued items MUST
   be separated by ',' rather than repeating the property name multiple
   times.

   Note that name and datatype are case insensitive (i.e., "startdate"
   is the same as "StartDate" and "STARTDATE"). Datatype MAY be absent
   within a body part in that case "text" is assumed.

   Note that the "charset" parameter SHOULD be used to identify
   character sets other than US ASCII. If different information within
   the same application/properties body component have different
   character sets, they can both be converted to UTF-7 or another
   character set which is a superset of both.

   Note that if a type name is followed by the two characters "::", the
   value is assumed to be a URL as defined by [RFC-1738] referencing
   the actual value typically another body part as defined by [RFC-
   1521], and the application/properties body part must be used in
   conjunction with the multipart/related Content-Type defined in
   the next section.

NOTE: The definition of property profiles could be defined as a media
type where the subtype defined the profile of the item.  This would have
some advantages and some disadvantages over just using the application
media type with a properties sub-type.

Advantages to defining a new media type:
- Each body part would have a different content type which could make
it easier for messaging clients to just launch a viewer based on the
content type.  This would be similar to the way that different
application body parts are handled today.
- When the MIME type was used with an HTTP server the client could
request a URL formatted as a specific item.  For instance the URL for
a user's personal information might be accessible in the format of
contact data or free/busy information.

Disadvantages to defining a new media type:
- Current messaging clients would most likely have to change to support
the new media type.  If the application media type is used then a
generic viewer for property data could be installed to display the
property data for any item.  That handler could then invoke an
appropriate viewer or a default viewer if the profile is unknown.
- The data for the item would not contain the profile for the item.
The content type would need to be carried to allow a generic viewer
to know the profile of item being viewed.
- If the body part data is not self defining then viewers for the data
may not know the correct schema for display.

5.1 String-list Format

There are several cases where a single text string or list of text
strings must be represented.  Because of the combination of encodings
the normal encodings for strings do not work.  The first problem is that
since the encodings are using the [RFC-822] encoding for "folding" long
header lines the standard MIME Quoted-Printable encoding does not work.
If you were to use Quoted-Printable encoding then each line would have
to start with a white space character or the parsing would become non-
standard between properties.

The suggested solution is to use a derivative of the [HTTP 1.1]
document's quoted string.  HTTP 1.1 defines a quoted-string type as:
      A string of text is parsed as a single word if it is quoted
      using double-quote marks.

          quoted-string  = ( <"> *(qdtext) <"> )


          qdtext         = <any CHAR except <"> and CTLs,
                           but including LWS>

      The backslash character ("\") may be used as a single-character
      quoting mechanism only within quoted-string and comment
      constructs.

          quoted-pair    = "\" CHAR

The string-list consists of a series of quoted strings.  All characters
between quoted-strings are ignored accept for ','.  The ',' character is
used to separate multiple values for the string.  This is analogous to a
list of text string values.  In order to support line breaks inside of
the strings a special character for the CHAR in the quoted-pair string
is supported to indicate a new line, "\n".  The new line refers to a
<CR><LF>.


          string-list    = *(quoted-string) [*( <,> *(quoted-string)) ]

          quoted-string      = ( <"> *(qdtext) <"> )

          qdtext         = <any CHAR except <"> and CTLs,
                           but including LWS>

The backslash character ("\") may be used as a single-character
quoting mechanism only within quoted-string constructs.

          quoted-pair    = "\" CHAR

The quoted-pair "\n" indicates a <CR><LF>.

5.2 Contacts

Person and email address to contact for further information:

   Darren Shakib
   Microsoft
   One Microsoft Way
   Redmond, WA  98052
   darrens@microsoft.com
   (206) 936-6405

Intended Usage: COMMON

Author/Change controller:

   Darren Shakib
   Microsoft
   One Microsoft Way
   Redmond, WA  98052
   darrens@microsoft.com
   (206) 936-6405




6. Use of the multipart/related Content-Type

The multipart/related Content-Type can hold item property information
comprised of text and/or non-text information or additional item-related
information that already has a natural MIME representation. The root
body part within the multipart/related body part is specified as defined
in [RFC-1872] by a "start" parameter, or it is the first body part in
the absence of such a parameter. The root body part must have a Content-
Type of "application/properties". This part holds text information,
optionally defines the name and source of the information, and makes
reference to subsequent body parts holding additional text and/or non-
text item property information via their URL Content-IDs as explained in
Section 6.

Body parts referred to do not have to be in any particular order.


7. Examples

The following examples illustrate possible implementations. Sample
properties are shown for illustrative purposes only and are not part of
the definition.

Example #1 demonstrates a basic use of the application/properties
Content-Type. The appointment has a start and end datetime and location.
Note that Location uses the default data type of text rather than
explicitly indicating that it is text.

   To: Franklin W. Dixon <franklind@sample.com>
   From: Carolyn Keene <carolynk@sample.com>
   Subject: Discuss contract issues
   MIME-Version: 1.0
   Message-ID: <id1@sample.com>
   Content-Type: application/properties ; profile="appointment"
   Content-ID: <id2@sample.com>

   Profile, text: "Appointment"
   Start, datetime: 22 Oct 96 14:00:00 UT
   End, datetime: 22 Oct 96 15:00:00 UT
   Location: "Applegate Building, Suite 410"

Example #2 uses the multipart/related Content-Type to add non-textual
appointment data:

   To: Franklin W. Dixon <franklind@sample.com>
   From: Carolyn Keene <carolynk@sample.com>
   Subject: Discuss contract issues
   MIME-Version: 1.0
   Message-ID: <id1@sample.com>

   Content-Type: multipart/related;
           boundary=fence;
           type="application/properties";
           start="<id4@sample.com>"
   Content-ID: <id3@sample.com>

   --fence
   Content-Type: application/properties
   Content-ID: <id4@sample.com>

   Profile, text: "appointment"
   Start, datetime: 22 Oct 96 14:00:00 UT
   End, datetime: 22 Oct 96 15:00:00 UT
   Location, text: "Applegate Building, Suite 410"
   Map, binary:: "id5@sample.com"

   --fence
   Content-Type: image/jpeg
   Content-ID: "id5@sample.com"

   <...image data goes here...>

   --fence--


8.  Datatype definitions

This section defines data types used in the property/appointment
Content-Type. Note that all of these types, with the exception of
BINARY, are transmitted in human-readable form. Backus-Naur Form (BNF)
notation, as modified in [RFC-822].

Each property can also have multiple values.  The schema for a profile
should indicate if the property should support multiple values.  If an
application finds items that are multi-valued that should not then the
first item should be used and the rest should be ignored.


8.1. TEXT data type

    Name: TEXT

    Examples: "The boys made their way cautiously to the boathouse.\n"
              "\"Run you guys!\" yelled Ratchy. \"It's the Hardy Boys!\""

    BNF: TEXT = (*text) / string-list           ; see section 5.1

    Comments:
    1) Character set is the same as default character set for body-part.
    2) Multi-valued forms of this data type can be described in the
       string-list by separating the strings with ','s.

8.2. BOOLEAN data type

    Name: BOOLEAN

    Examples: TRUE
              FALSE

    BNF: BOOLEAN = flag

    where: flag = "TRUE" / "FALSE"

    Comments:
    1) Multi-valued forms of this data type are formed by delimiting
       each item with a comma ','.


8.3. DATETIME data type

    Name: DATETIME

    Examples: 22 Oct 96 14:00:00 MST
              11 Aug 96 12:34:56 Z
              Mon, 22 Jul 96 4:30 EST +0030             ; Newfoundland time

    BNF: DATETIME = date-time   ; date-time as defined in [RFC-822]

    Comments:
    1) This follows [RFC-822] Sections 5.1 and 5.2. The intent here
       is to follow the core message date and time formats to minimize
       translation and parsing requirements.

    2) Multi-valued forms of this data type are formed by delimiting
       each value with a comma ','.


8.4. TIME data type

    Name: TIME

    Examples: 10:22
          10:22:33

    BNF: TIME = hour            ; as defined in [RFC-822]

    Comments:
    1) This follows [RFC-822] Sections 5.1 and 5.2. The intent here
       is to follow the core message date and time formats to minimize
       translation and parsing requirements.

    2) Multi-valued forms of this data type are formed by delimiting
       each value with a comma ','.


8.5. DATE data type

    Name: DATE

    Examples: 22 Oct 96
          11 Aug 96

    BNF: DATE = date             ; as defined in [RFC-822]

    Comments:
    1) This follows [RFC-822] Sections 5.1 and 5.2. The intent here
       is to follow the core message date and time formats to minimize
       translation and parsing requirements.
    2) Multi-valued forms of this data type are formed by delimiting
       each value with a comma ','.


8.6. FLOAT data type

    Name: FLOAT

    Examples: 20.30
              1000000.0000001

    BNF: FLOAT = [sign] *digit ["." *digit]

    sign = "+" / "-"

    Comments:
    1) If sign is not specified, the value is assumed positive "+".
    2) Multi-valued forms of this data type are formed by delimiting
       each item with a comma ','.

8.7. LONG data type

    Name: LONG

    Examples:  1234567890
               -1234556790
               +1234556790

    BNF: LONG = [sign] 10DIGIT

    where: sign = "+" / "-"

    Comments:
    1) If sign is not specified, the value is assumed positive "+".
    2) Multi-valued forms of this data type are formed by delimiting
       each value with a comma ','.

8.8. BINARY data type

    Name: BINARY

    Examples: n/a

    BNF: BINARY = NONE; binary can only use propcid notation

    Comments:
    1) Binary properties can only be stored in a separate body part
       using multipart related notation.

8.9. CURRENCY data type

    Name: CURRENCY

    Examples: 54.25
              1.43
              1234567890123.45

    BNF: CURRENCY = 18DIGIT "." 2DIGIT

    Comments:
    1) Only "." is supported to simplify parsing.
    2) Multi-valued forms of this data type are formed by delimiting
       each value with a comma ','.


8.10. URL data type

    Name: URL

    Examples: "ftp://ds.internic.net/rfcs/rfc1123.txt"
              "HTTP://www.awb.com/drewboard.html"

    BNF: URL = string-list      ; see section 5.1 in this document

    Comments:
    1) Multi-valued forms of this data type can be described in the
       string-list by separating the strings with ','s.



9. Common Properties

There will be some common properties that MAY appear in all profiles.

9.1 Profile

      Name: profile

      Data type: Text

      Purpose: Indicates the profile schema of the item.

      Encoding: Case insensitive.

      Special notes (optional):  This should be the first property
                                 listed for the item.  If this is
                                 not listed some implementations
                                 may not know how to display the item.

      Required: No

      Multi-Valued: NEVER

      Intended usage: COMMON

9.2 Variant

      Name: variant

      Data type: Text

      Purpose: Indicates a variant of the profile schema.  All
               variants should support the profile schema and
               may only add to the schema. Encoding:  Case
               insensitive.

      Special notes (optional):  This should be the first property
                                 after the profile property of the
                                 item. Variants can be further
                                 classified by separating the
                                 versions in the variant string
                                 with periods ".".  Once again each
                                 sub-variant should only add to
                                 the schema.

                                 Values are case insensitive.

      Examples:

        profile:"Appointment"
        variant:"Recurring.1"

        This could correspond to an recurring appointment variant 1.

        profile:"Directory"
        variant:"LDAP"

        This could correspond to a directory entry with an LDAP schema.

        profile:"Directory"
        variant:"person"

        This could correspond to a person directory entry.

        profile:"Directory"
        variant:"person.business card"

        This could correspond to the business card variant of the
        person directory entry.

      Required: No

      Multi-Valued: SOMETIMES

      Intended usage: COMMON

9.3 CreatedBy

      Name: createdBy

      Data type: Text

      Purpose: Identifies the creator of the item.

      Encoding:  Should correspond to an [RFC-822] formatted recipient.

      Required: No

      Multi-Valued: SOMETIMES

      Intended usage: COMMON

9.4 CreateDate

      Name: createDate

      Data type: DATETIME

      Purpose: Indicates the time that the item was created.

      Encoding:

      Required: No

      Multi-Valued: NEVER

      Intended usage: COMMON

9.5 MofifiedBy

      Name: modifiedBy

      Data type: Text

      Purpose: Identifies the person that last modified the item.

      Encoding:  [RFC-822] formatted recipient.

      Required: No

      Multi-Valued: SOMETIMES

      Intended usage: COMMON

9.6 LastModified

      Name: lastModified

      Data type: Text

      Purpose: Indicates the profile schema of the item.

      Encoding:

      Required: No

      Multi-Valued: SOMETIMES

      Intended usage: COMMON


10. Registration of new profiles

This section defines procedures by which new profiles are registered
with the IANA and made available to the Internet community. Note that
non-IANA profiles may be used by bilateral agreement, provided the
associated profile names follow the "X-" convention defined above.

The procedures defined here are designed to allow public comment and
review of new profiles, while posing only a small impediment to the
definition of new profiles.

Registration of a new profile is accomplished by the following steps.

10.1.  Define the profile

A profile is defined by completing the following template.

      To: [mailing list TBD]
      Subject: Registration of application/properties MIME profile XXX

      Profile name:

      Profile purpose:

      Profile property names:

      Profile special notes (optional):

      Profile Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)

      Property Descriptions: (list of property descriptions in following
format)

        Name:

        Data type:

        Purpose:

        Encoding:

        Special notes (optional):

        Required: (one of YES, NO)

        Multi-Valued: (one of ALWAYS, NEVER, SOMETIMES)

        Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)


The explanation of what goes in each field in the template follows.

Profile name: The name of the profile as it will appear in the
application/properties MIME Content-Type "profile" header parameter.

Profile purpose: The purpose of the profile (e.g., to represent
information about people, printers, documents, etc.). Give a short but
clear
description.

Profile property names: The list of property names associated with the
profile.  This list of names is to be expected but not required in the
profile.  Other names not mentioned in the profile definition may also
be present.

Profile special notes: Any special notes about the profile, how it is to
be used, etc. This section of the template may also be used to define an
ordering on the types that appear in the Content-Type, if such an
ordering is required.

Property Descriptions: Precedes the list of property descriptions for
the profile.  Each property definition starts with the "Name:" tag.

Name: The name of the property, as it will appear in the body
of an application/properties MIME Content-Type "name, datatype: value"
line to the left of the colon ":".

Data type:  The expected data type for the property.  Possible values
listed in section 8.

Purpose: The purpose of the property (e.g., to represent a name,
postal address, IP address, etc.). Give a short but clear description.

Encoding: The encoding a value of the type must have in the
body of an application/properties MIME Content-Type.  This description
must be precise and must not violate the general encoding rules defined
in section 5 of this document.

Special notes: Any special notes about the property, how it is to be
used, etc.

Required:  YES indicates that the property MUST be present in the
property list of a item of an item of this type profile.  No indicates
that this property MAY appear in the property list.

Multi-Valued:  ALWAYS indicates that the property will expected to be
multi-valued.  NEVER indicates that the property MUST NOT be multi-
valued.  SOMETIMES indicates that the property MAY be multi-valued, but
that most implementations will not make it multi-valued.

Intended usage: COMMON indicates that most items of this profile will
include this property.  LIMITED USE indicates that this property will
rarely be included.  OBSOLETE indicates that use of this property SHOULD
NOT be used.

10.2.  Post the profile definition

The profile description must be posted to the new profile discussion
list, [mailing list TBD].

10.3.  Allow a comment period

Discussion on the new profile must be allowed to take place on the list
for a minimum of two weeks. Consensus must be reached on the profile
before proceeding to step 4.

10.4.  Submit the profile for approval

Once the two-week comment period has elapsed, and the proposer is
convinced consensus has been reached on the profile, the
registration application should be submitted to the Profile Reviewer
for approval.  The Profile Reviewer is appointed by the Application
Area Directors and may either accept or reject the profile registration.
An accepted registration should be passed on by the Profile
Reviewer to the IANA for inclusion in the official IANA profile
registry. The registration may be rejected for any of the following
reasons. 1) Insufficient comment period; 2) Consensus not reached;
3)  Technical deficiencies raised on the list or elsewhere have not
been addressed. The Profile Reviewer's decision to reject a profile may
be appealed by the proposer to the IESG, or the objections raised
can be addressed by the proposer and the profile resubmitted.

11.  Profile Change Control

Existing profiles may be changed using the same process by which they
were registered.

     Define the change

     Post the change

     Allow a comment period

     Submit the profile for approval

Note that the original author or any other interested party may propose
a change to an existing profile, but that such changes should only be
proposed when there are serious omissions or errors in the published
specification. The Profile Reviewer may object to a change if it is not
backwards compatible, but is not required to do so.

Profile definitions can never be deleted from the IANA registry, but
profiles which are no longer believed to be useful can be
declared OBSOLETE by a change to their "intended use" field.

12.  Registration of new variants

Variants are registered in the same manner as profiles except that the
variant uses the following format:

      To: [mailing list TBD]
      Subject: Registration of application/properties MIME profile XXX

      Variant name:

      Variant profile:

      Variant purpose:

      Variant property names:

      Variant special notes (optional):

      Variant Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)

      Property Descriptions: (list of property descriptions as described
                             in section 10.1)


Variant Profile is the name of the profile that this variant is a
version of.  The complete path for the variant should be listed with the
intent that all variants should be the same based on their period-
separated root parts.

The descriptions for the other values are the same as in Section 10.1
where variant is replaced with profile.

The registration process follows the way that profiles are registered.

     Define the change

     Post the change

     Allow a comment period

     Submit the profile for approval

13. Security Considerations

Internet mail is subject to many well-known security attacks, including
monitoring, replay, and forgery. Care should be taken to restrict
sensitive information from leaving the scope of the service itself,
where any access controls can no longer be guaranteed.

14.  Acknowledgments

Format and some descriptions were borrowed from the MIME Directory
draft.


15.  Author's Address

Darren Shakib
Microsoft
One Microsoft Way
Redmond, WA 98052
USA

Phone: (206) 936-6405
Email: darrens@microsoft.com

Ian Ferrell
Microsoft
One Microsoft Way
Redmond, WA 98052
USA

Phone: (206) 936-1086
Email: ianf@microsoft.com


16.  References

[MIME-DIR]
     Howes, T., Smith, M., "A MIME Content-Type for  Directory  Informa-
     tion", Internet-draft-ietf-asid-mime-direct-01.txt, February, 1996.

[MIME-REG]
     Freed, N.,  Postel,  J.,  "Multipurpose  Internet  Mail  Extensions
     (MIME)   Part   Four:   Registration   Procedures," Internet- Draft
     draft-ietf-822ext-mime-reg-02.txt, December 1995.

[RFC-822]
     Crocker, D., "Standard for the Format of ARPA  Internet  Text  Mes-
     sages", STD 11, RFC-822, August 1982.

[RFC-1521]
     Borenstein, N., Freed, N., "MIME (Multipurpose Internet Mail Exten-
     sions)  Part One: Mechanisms for Specifying and Describing the For-
     mat of Internet Message Bodies",  RFC  1521,  September 1993.

[RFC-1522]
     Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part  Two:
     Message  Header Extensions for Non-ASCII Text", RFC 1522, September
     1993.

[RFC-1738]
     Berners-Lee, T., Masinter,  L.,  McCahill,  M.,  "Uniform  Resource
     Locators (URL)", RFC 1738, December 1994.

[RFC-1777]
     Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
     Protocol", RFC 1777, Performance Systems International,
     University of Michigan, ISODE Consortium, March 1995.

[RFC-1778]
     Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
     Protocol", RFC 1777, Performance Systems International,
     University of Michigan, ISODE Consortium, March 1995.

[RFC-1835]
     Deutsch, et al., "Architecture of the WHOIS++ service",
     RFC 1835, August 1995.

[RFC-1872]
     Levinson, E., "The MIME Multipart/Related  Content-type," RFC 1872,
     December 1995.

Appendix A - Differences from [MIME-DIR]

While this is defined as an extension to [MIME-DIR] there are some
changes.  Most of these changes were designed to clear up ambiguities
and either simplify or make the spec clearer.  The extensions are
intended to make the property definition items able to describe a wider
variety of item types.

The term "name" is used instead of "type".  Both refer to the name of a
property on the item.  While type has a very specific meaning to some
people it is easily confused with the data type of a property.

The defaulttype parameter was removed.  Its definition was ambiguous
since it was not clear why the "type" would be duplicated.  Since a
specific mechanism is described for multi-valued property values it
became obsolete.

Removed name parameter since its use was vague.  The information may be
more appropriate as a property on the item rather than as a parameter,
which would allow its definition to be more specific.

MIME subtype changed from "directory" to "properties".  This allows for
a more generic definition for the items.  The profile should be set to
"directory" for directory items and the variant should be used to
specify variations on a standard directory item.


Appendix B - Outstanding Issues

Requirements for registration have not been finalized.  The details
above are subject to change.