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.