home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_s_z / draft-shakib-mime-prop-00.txt < prev    next >
Text File  |  1996-07-23  |  36KB  |  1,068 lines
  1.  
  2. CALENDAR Working Group                                    Darren Shakib
  3. INTERNET DRAFT                                              Ian Ferrell 
  4. draft-shakib-mime-prop-00.txt                                 Microsoft
  5. Expire in six months
  6.  
  7.  
  8.          A MIME Content-Type for Tagged Property Value Storage
  9.  
  10.  
  11. 1.  Status of this Memo
  12.  
  13. This document is an Internet-Draft. Internet-Drafts are working 
  14. documents of the Internet Engineering Task Force (IETF), its areas, and
  15. its working groups.  Note that other groups may also distribute 
  16. working documents as Internet-Drafts.
  17.  
  18. Internet-Drafts are draft documents valid for a maximum of six months
  19. and may be updated, replaced, or obsoleted by other documents at any
  20. time.  It is inappropriate to use Internet- Drafts as reference material
  21. or to cite them other than as "work in progress."
  22.  
  23. To learn the current status of any Internet-Draft, please check the
  24. "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
  25. Directories  on  ftp.is.co.za  (Africa),  nic.nordu.net  (Europe),
  26. munnari.oz.au  (Pacific Rim), ds.internic.net (US East Coast), or
  27. ftp.isi.edu (US West Coast).
  28.  
  29.  
  30. 2.  Abstract
  31.  
  32. This memo defines a MIME Content-Type and for holding arbitrary item 
  33. information.  The definition is independent of any particular item type 
  34. or application.  The application/properties Content-Type is defined for 
  35. holding a variety of basic textual property information to describe the 
  36. item, for example a directory item could contain name, and email 
  37. address.  The application/properties Content-Type can also be used as 
  38. the root body part in a multipart/related Content-Type for handling more 
  39. complicated situations in which non-textual information, for example an 
  40. image or sound, must be represented.
  41.  
  42. The application/properties Content-Type defines a general framework and 
  43. format for holding directory information in a "name, datatype: value" 
  44. format.  This document also defines the procedure by which particular 
  45. formats for carrying the application-specific information within an 
  46. application/properties Content-Type may be defined and registered, and 
  47. the conventions such formats must follow.  It is expected that other 
  48. documents will be produced that define such formats for various 
  49. application item types (e.g. white pages, appointments).
  50.  
  51.  
  52. 3.  Need for a Generic Property MIME Type
  53.  
  54. For purposes of this document, a directory is a special-purpose database 
  55. that contains typed information. A directory usually supports both read 
  56. and search of the information it contains, and may support modification 
  57. of the information as well.  Directory information is usually accessed 
  58. far more often than it is updated.  Directories may be local or global 
  59. in scope.  They may be distributed or centralized. The information they 
  60. contain may be replicated, with weak or strong consistency requirements.
  61.  
  62. There are several situations in which users of Internet mail may wish to 
  63. exchange directory information: the email analogue of a "business card" 
  64. exchange; the conveyance of directory information to a user having only 
  65. email access to the Internet; the provision of machine-parseable address 
  66. information when purchasing goods or services over the Internet; etc. As 
  67. MIME [RFC-1521,RFC-1522] is used increasingly by other protocols, most 
  68. notably HTTP, it may be useful for these protocols to be able to carry 
  69. directory information in MIME format. Such a format, for example, could 
  70. be used to represent URC (uniform resource characteristics) information 
  71. about resources on the World Wide Web.
  72.  
  73. In addition to directory information there are item types that need to 
  74. be represented in a similar manner to directory items.  For example, 
  75. Calendaring items fall into this category.  Rather than having a unique 
  76. MIME Content-Type for each item type for encoding their properties and 
  77. values it is desirable to have a single encoding format that could 
  78. handle all of the item types.  This allows code to leverage the parsing 
  79. and processing code across the item types that need to be supported.
  80.  
  81. 4.  Overview
  82.  
  83. The scheme defined here for representing the directory information in a 
  84. MIME Content-Type has two parts.  First, the application/properties 
  85. Content-Type is defined for use in holding simple textual property 
  86. information to describe an item, for example name, title, startdate, 
  87. location or email address.  The format uses a simple "name, datatype: 
  88. value" approach, which should be easily parsable by existing MIME 
  89. implementations and understandable by users.  This document defines the 
  90. general form the information in the Content-Type should take, and the 
  91. procedure by which the specific property names and values for particular 
  92. applications may be defined.  The framework is general enough to handle 
  93. information for a variety of items types including calendaring item 
  94. types and directory information from any number of end directory serves, 
  95. including LDAP [RFC-1777, RFC-1778], and WHOIS++ [RFC-1835].
  96.  
  97. Item types can include far more than just textual information.  Such 
  98. information (e.g., an image, HTML text or sound) overlaps with 
  99. predefined MIME Content-Types.  In these cases it may be desirable to 
  100. include the information in their well-known MIME formats.  This 
  101. situation is handled by using the multipart/related Content-Type as 
  102. defined in [RFC-1872].  The root component of this type is an 
  103. application/properties body part specifying an textual information in-
  104. line and for information contained in other Content-Types, the Content-
  105. Ids of those types.
  106.  
  107. Each property includes a data type in addition to the name of the 
  108. property and its value. Standard property data types include: text, 
  109. date/time, date, time, URL, float, long, boolean, binary, and currency. 
  110. Because of the wide variety of item types that may be specified, 
  111. including the data type as part of each property provides an extra hint 
  112. to keep parsing simple and support more generalized applications.  For 
  113. example a search engine would not have to know the particular data types 
  114. for all of the items that it is searching.  Because the data type is 
  115. explicit in the definition it could look for dates in any item type and 
  116. provide good results.  Some item types may be very loosely defined to 
  117. allow the sending of generic database records.
  118.  
  119. In order to reduce confusion some of the terminology has been changed 
  120. from [MIME-DIR].
  121.  
  122.     item
  123.         Generic term used to refer to what the set of properties refers.
  124.         An item may be a directory entry, appointment, or just a row in
  125.         a database.
  126.  
  127.     name
  128.         Name of the property being defined.  The [MIME-DIR] draft
  129.         referred to this as type.  While this is common terminology for
  130.         some directory implementations its meaning can easily be
  131.         confused with the data type of a property.
  132.    
  133.     data type
  134.         The data type for a property.  This is very similar to variable
  135.         types in C or column definitions in many database products.    
  136.  
  137.     profile
  138.         Identifies the base schema for an item.  
  139.  
  140.  
  141. 5.  The application/properties Content-Type
  142.  
  143. The application/properties Content-Type represents generic property data 
  144. used to describe an item and may contain references to other MIME body 
  145. parts holding additional data. It is defined as follows, using the MIME 
  146. content type registration from [MIME-REG], and the spirit of [MIME-DIR].
  147.  
  148. To: ietf-types@uninett.no
  149. Subject: Registration of MIME media type application/properties
  150.  
  151.    MIME media type name: application
  152.  
  153.    MIME subtype name: properties
  154.  
  155.    Required parameters: none
  156.  
  157.    Optional parameters: charset, source, profile
  158.  
  159.    The charset parameter is as defined in [RFC-1521] for other body
  160.    parts.
  161.  
  162.    The source parameter provides a reference back to the source 
  163.    calendar. It contains an URL (defined in [RFC-1738]) referencing the 
  164.    source calendar for the appointment data. Knowledgeable client 
  165.    applications may use the URL to retrieve additional or more up-to-
  166.    date information about the item.
  167.  
  168.  
  169. Encoding considerations:
  170.  
  171.    As specified by the Content-Transfer-Encoding header field.
  172.  
  173. Security considerations:
  174.  
  175.    Generic item information may be public or private. This specification
  176.    does not include any access control mechanism to guarantee data
  177.    privacy on a per-property or per Content-Type basis.
  178.  
  179. Interoperability considerations:
  180.  
  181.    Applications and downstream customers of this data must understand
  182.    the types of information within the Content-Type, as defined in this
  183.    document.
  184.  
  185.    This specification should be able describe the formats described in
  186.    [MIME-DIR].  The default type of string will be used to specify the 
  187.    the values of [MIME-DIR] properties.
  188.  
  189.    Profile authors should attempt to make their properties
  190.    understandable by users reading the body part as text.
  191.  
  192. Published specification:
  193.  
  194. The "application/properties" Content-Type contains textual property 
  195. information. The content consists of one or more CRLF-separated lines in 
  196. the following format. An application/properties content line has the 
  197. same continuation semantics as described in [RFC-822], section 3.1.1 on 
  198. "folding" long header lines (i.e., a single line may be split across 
  199. multiple physical lines by replacing linear-white-space with a CRLF 
  200. immediately followed by at least one LWSP-character). Using [RFC-822]'s 
  201. notation, the context syntax is:
  202.  
  203.       content := propvalue / propcid
  204.  
  205.       propvalue := [name], [datatype] ":" SPACE [value]
  206.  
  207.       propcid := [name], [datatype] "::" SPACE (*text) / string-list 
  208.                   ; strings refer to URLs as defined in [RFC-1738]
  209.                   ; these URLs can refer to other body parts of a
  210.                   ; MIME message according to the MHTML document
  211.  
  212.       name := x-token / iana-token
  213.  
  214.       datatype := x-token / iana-token
  215.  
  216.       x-token := <the two characters "X-" or "x-" followed, with no 
  217.                   intervening white space, by any token>
  218.  
  219.       iana-token := <a publicly-defined extension token, registered with
  220.                      IANA, as specified in Section 10 of this document>
  221.  
  222.       value := *text ; characters whose syntax depends on type
  223.  
  224.       string-list   see definition in section 5.1
  225.  
  226.    Note that the meanings of the various names for a profile are
  227.    defined in Section 10.  Specifications may specify ordering on the
  228.    name constructs within a body part, though none is required by
  229.    default. The x-token name specification is used for bilaterally-
  230.    agreed upon names.
  231.  
  232.    Note that "name" is analogous to "type" in other drafts such as MIME-
  233.    REG and MIME-DIR. This draft adds a second parameter, "datatype" 
  234.    describing the property's data format (e.g. TEXT or LONG). This 
  235.    parameter makes each property self-describing so client applications 
  236.    that do not understand an unknown or custom property's use can still 
  237.    support editing and displaying that property.
  238.  
  239.    Note "name" values MUST NOT be duplicated.  Multi-valued items MUST
  240.    be separated by ',' rather than repeating the property name multiple
  241.    times.
  242.  
  243.    Note that name and datatype are case insensitive (i.e., "startdate" 
  244.    is the same as "StartDate" and "STARTDATE"). Datatype MAY be absent 
  245.    within a body part in that case "text" is assumed.
  246.  
  247.    Note that the "charset" parameter SHOULD be used to identify 
  248.    character sets other than US ASCII. If different information within 
  249.    the same application/properties body component have different 
  250.    character sets, they can both be converted to UTF-7 or another 
  251.    character set which is a superset of both.
  252.  
  253.    Note that if a type name is followed by the two characters "::", the 
  254.    value is assumed to be a URL as defined by [RFC-1738] referencing 
  255.    the actual value typically another body part as defined by [RFC-
  256.    1521], and the application/properties body part must be used in 
  257.    conjunction with the multipart/related Content-Type defined in 
  258.    the next section.
  259.  
  260. NOTE: The definition of property profiles could be defined as a media 
  261. type where the subtype defined the profile of the item.  This would have 
  262. some advantages and some disadvantages over just using the application 
  263. media type with a properties sub-type.
  264.  
  265. Advantages to defining a new media type:
  266. - Each body part would have a different content type which could make 
  267. it easier for messaging clients to just launch a viewer based on the 
  268. content type.  This would be similar to the way that different 
  269. application body parts are handled today.
  270. - When the MIME type was used with an HTTP server the client could 
  271. request a URL formatted as a specific item.  For instance the URL for 
  272. a user's personal information might be accessible in the format of 
  273. contact data or free/busy information.
  274.  
  275. Disadvantages to defining a new media type:
  276. - Current messaging clients would most likely have to change to support 
  277. the new media type.  If the application media type is used then a 
  278. generic viewer for property data could be installed to display the 
  279. property data for any item.  That handler could then invoke an 
  280. appropriate viewer or a default viewer if the profile is unknown.
  281. - The data for the item would not contain the profile for the item.  
  282. The content type would need to be carried to allow a generic viewer 
  283. to know the profile of item being viewed.
  284. - If the body part data is not self defining then viewers for the data 
  285. may not know the correct schema for display.
  286.  
  287. 5.1 String-list Format
  288.  
  289. There are several cases where a single text string or list of text 
  290. strings must be represented.  Because of the combination of encodings 
  291. the normal encodings for strings do not work.  The first problem is that 
  292. since the encodings are using the [RFC-822] encoding for "folding" long 
  293. header lines the standard MIME Quoted-Printable encoding does not work.  
  294. If you were to use Quoted-Printable encoding then each line would have 
  295. to start with a white space character or the parsing would become non-
  296. standard between properties.
  297.  
  298. The suggested solution is to use a derivative of the [HTTP 1.1] 
  299. document's quoted string.  HTTP 1.1 defines a quoted-string type as:
  300.       A string of text is parsed as a single word if it is quoted 
  301.       using double-quote marks. 
  302.  
  303.           quoted-string  = ( <"> *(qdtext) <"> )
  304.  
  305.  
  306.           qdtext         = <any CHAR except <"> and CTLs,
  307.                            but including LWS>
  308.  
  309.       The backslash character ("\") may be used as a single-character
  310.       quoting mechanism only within quoted-string and comment
  311.       constructs. 
  312.  
  313.           quoted-pair    = "\" CHAR
  314.  
  315. The string-list consists of a series of quoted strings.  All characters 
  316. between quoted-strings are ignored accept for ','.  The ',' character is 
  317. used to separate multiple values for the string.  This is analogous to a 
  318. list of text string values.  In order to support line breaks inside of 
  319. the strings a special character for the CHAR in the quoted-pair string 
  320. is supported to indicate a new line, "\n".  The new line refers to a 
  321. <CR><LF>.
  322.  
  323.  
  324.           string-list    = *(quoted-string) [*( <,> *(quoted-string)) ]
  325.  
  326.           quoted-string      = ( <"> *(qdtext) <"> )
  327.  
  328.           qdtext         = <any CHAR except <"> and CTLs,
  329.                            but including LWS>
  330.  
  331. The backslash character ("\") may be used as a single-character
  332. quoting mechanism only within quoted-string constructs. 
  333.  
  334.           quoted-pair    = "\" CHAR
  335.  
  336. The quoted-pair "\n" indicates a <CR><LF>.
  337.  
  338. 5.2 Contacts
  339.  
  340. Person and email address to contact for further information:
  341.  
  342.    Darren Shakib
  343.    Microsoft
  344.    One Microsoft Way
  345.    Redmond, WA  98052
  346.    darrens@microsoft.com
  347.    (206) 936-6405
  348.  
  349. Intended Usage: COMMON
  350.  
  351. Author/Change controller:
  352.  
  353.    Darren Shakib
  354.    Microsoft
  355.    One Microsoft Way
  356.    Redmond, WA  98052
  357.    darrens@microsoft.com
  358.    (206) 936-6405
  359.  
  360.  
  361.  
  362.  
  363. 6. Use of the multipart/related Content-Type
  364.  
  365. The multipart/related Content-Type can hold item property information 
  366. comprised of text and/or non-text information or additional item-related 
  367. information that already has a natural MIME representation. The root 
  368. body part within the multipart/related body part is specified as defined 
  369. in [RFC-1872] by a "start" parameter, or it is the first body part in 
  370. the absence of such a parameter. The root body part must have a Content-
  371. Type of "application/properties". This part holds text information, 
  372. optionally defines the name and source of the information, and makes 
  373. reference to subsequent body parts holding additional text and/or non-
  374. text item property information via their URL Content-IDs as explained in 
  375. Section 6.
  376.  
  377. Body parts referred to do not have to be in any particular order.
  378.  
  379.  
  380. 7. Examples
  381.  
  382. The following examples illustrate possible implementations. Sample 
  383. properties are shown for illustrative purposes only and are not part of 
  384. the definition.
  385.  
  386. Example #1 demonstrates a basic use of the application/properties 
  387. Content-Type. The appointment has a start and end datetime and location. 
  388. Note that Location uses the default data type of text rather than 
  389. explicitly indicating that it is text.
  390.  
  391.    To: Franklin W. Dixon <franklind@sample.com>
  392.    From: Carolyn Keene <carolynk@sample.com>
  393.    Subject: Discuss contract issues 
  394.    MIME-Version: 1.0
  395.    Message-ID: <id1@sample.com>
  396.    Content-Type: application/properties ; profile="appointment"
  397.    Content-ID: <id2@sample.com>
  398.  
  399.    Profile, text: "Appointment"
  400.    Start, datetime: 22 Oct 96 14:00:00 UT
  401.    End, datetime: 22 Oct 96 15:00:00 UT
  402.    Location: "Applegate Building, Suite 410"
  403.  
  404. Example #2 uses the multipart/related Content-Type to add non-textual 
  405. appointment data:
  406.  
  407.    To: Franklin W. Dixon <franklind@sample.com>
  408.    From: Carolyn Keene <carolynk@sample.com>
  409.    Subject: Discuss contract issues
  410.    MIME-Version: 1.0
  411.    Message-ID: <id1@sample.com>
  412.  
  413.    Content-Type: multipart/related;
  414.            boundary=fence;
  415.            type="application/properties";
  416.            start="<id4@sample.com>"
  417.    Content-ID: <id3@sample.com>
  418.  
  419.    --fence
  420.    Content-Type: application/properties
  421.    Content-ID: <id4@sample.com>
  422.  
  423.    Profile, text: "appointment"
  424.    Start, datetime: 22 Oct 96 14:00:00 UT
  425.    End, datetime: 22 Oct 96 15:00:00 UT
  426.    Location, text: "Applegate Building, Suite 410"
  427.    Map, binary:: "id5@sample.com"
  428.  
  429.    --fence
  430.    Content-Type: image/jpeg
  431.    Content-ID: "id5@sample.com"
  432.  
  433.    <...image data goes here...>
  434.  
  435.    --fence--
  436.  
  437.  
  438. 8.  Datatype definitions
  439.  
  440. This section defines data types used in the property/appointment 
  441. Content-Type. Note that all of these types, with the exception of 
  442. BINARY, are transmitted in human-readable form. Backus-Naur Form (BNF) 
  443. notation, as modified in [RFC-822].
  444.  
  445. Each property can also have multiple values.  The schema for a profile 
  446. should indicate if the property should support multiple values.  If an 
  447. application finds items that are multi-valued that should not then the 
  448. first item should be used and the rest should be ignored.
  449.  
  450.  
  451. 8.1. TEXT data type
  452.  
  453.     Name: TEXT
  454.  
  455.     Examples: "The boys made their way cautiously to the boathouse.\n"
  456.               "\"Run you guys!\" yelled Ratchy. \"It's the Hardy Boys!\""
  457.  
  458.     BNF: TEXT = (*text) / string-list        ; see section 5.1
  459.  
  460.     Comments:
  461.     1) Character set is the same as default character set for body-part.
  462.     2) Multi-valued forms of this data type can be described in the
  463.        string-list by separating the strings with ','s.
  464.  
  465. 8.2. BOOLEAN data type
  466.  
  467.     Name: BOOLEAN
  468.  
  469.     Examples: TRUE
  470.               FALSE
  471.  
  472.     BNF: BOOLEAN = flag
  473.  
  474.     where: flag = "TRUE" / "FALSE"
  475.  
  476.     Comments:
  477.     1) Multi-valued forms of this data type are formed by delimiting
  478.        each item with a comma ','.
  479.  
  480.  
  481. 8.3. DATETIME data type
  482.  
  483.     Name: DATETIME
  484.  
  485.     Examples: 22 Oct 96 14:00:00 MST
  486.               11 Aug 96 12:34:56 Z
  487.               Mon, 22 Jul 96 4:30 EST +0030             ; Newfoundland time
  488.  
  489.     BNF: DATETIME = date-time    ; date-time as defined in [RFC-822]
  490.  
  491.     Comments:
  492.     1) This follows [RFC-822] Sections 5.1 and 5.2. The intent here
  493.        is to follow the core message date and time formats to minimize
  494.        translation and parsing requirements.
  495.  
  496.     2) Multi-valued forms of this data type are formed by delimiting
  497.        each value with a comma ','.
  498.  
  499.  
  500. 8.4. TIME data type
  501.  
  502.     Name: TIME
  503.  
  504.     Examples: 10:22
  505.           10:22:33
  506.  
  507.     BNF: TIME = hour        ; as defined in [RFC-822]
  508.  
  509.     Comments:
  510.     1) This follows [RFC-822] Sections 5.1 and 5.2. The intent here
  511.        is to follow the core message date and time formats to minimize
  512.        translation and parsing requirements.
  513.  
  514.     2) Multi-valued forms of this data type are formed by delimiting
  515.        each value with a comma ','.
  516.  
  517.  
  518. 8.5. DATE data type
  519.  
  520.     Name: DATE
  521.  
  522.     Examples: 22 Oct 96
  523.           11 Aug 96
  524.  
  525.     BNF: DATE = date             ; as defined in [RFC-822]
  526.  
  527.     Comments:
  528.     1) This follows [RFC-822] Sections 5.1 and 5.2. The intent here
  529.        is to follow the core message date and time formats to minimize
  530.        translation and parsing requirements.
  531.     2) Multi-valued forms of this data type are formed by delimiting
  532.        each value with a comma ','.
  533.  
  534.  
  535. 8.6. FLOAT data type
  536.  
  537.     Name: FLOAT
  538.  
  539.     Examples: 20.30
  540.           1000000.0000001
  541.  
  542.     BNF: FLOAT = [sign] *digit ["." *digit] 
  543.  
  544.     sign = "+" / "-"
  545.  
  546.     Comments:
  547.     1) If sign is not specified, the value is assumed positive "+".
  548.     2) Multi-valued forms of this data type are formed by delimiting
  549.        each item with a comma ','.
  550.  
  551. 8.7. LONG data type
  552.  
  553.     Name: LONG
  554.  
  555.     Examples:  1234567890
  556.                -1234556790
  557.                +1234556790
  558.  
  559.     BNF: LONG = [sign] 10DIGIT
  560.  
  561.     where: sign = "+" / "-"
  562.  
  563.     Comments:
  564.     1) If sign is not specified, the value is assumed positive "+".
  565.     2) Multi-valued forms of this data type are formed by delimiting
  566.        each value with a comma ','.
  567.  
  568. 8.8. BINARY data type
  569.  
  570.     Name: BINARY
  571.  
  572.     Examples: n/a
  573.  
  574.     BNF: BINARY = NONE; binary can only use propcid notation
  575.  
  576.     Comments:
  577.     1) Binary properties can only be stored in a separate body part
  578.        using multipart related notation.
  579.  
  580. 8.9. CURRENCY data type
  581.  
  582.     Name: CURRENCY
  583.  
  584.     Examples: 54.25
  585.               1.43
  586.               1234567890123.45
  587.            
  588.     BNF: CURRENCY = 18DIGIT "." 2DIGIT
  589.  
  590.     Comments:
  591.     1) Only "." is supported to simplify parsing.
  592.     2) Multi-valued forms of this data type are formed by delimiting
  593.        each value with a comma ','.
  594.  
  595.  
  596. 8.10. URL data type
  597.  
  598.     Name: URL
  599.  
  600.     Examples: "ftp://ds.internic.net/rfcs/rfc1123.txt"
  601.               "HTTP://www.awb.com/drewboard.html"
  602.  
  603.     BNF: URL = string-list    ; see section 5.1 in this document
  604.  
  605.     Comments:
  606.     1) Multi-valued forms of this data type can be described in the
  607.        string-list by separating the strings with ','s.
  608.  
  609.  
  610.  
  611. 9. Common Properties
  612.  
  613. There will be some common properties that MAY appear in all profiles.
  614.  
  615. 9.1 Profile
  616.  
  617.       Name: profile
  618.  
  619.       Data type: Text
  620.  
  621.       Purpose: Indicates the profile schema of the item.
  622.  
  623.       Encoding: Case insensitive.
  624.  
  625.       Special notes (optional):  This should be the first property
  626.                                  listed for the item.  If this is 
  627.                                  not listed some implementations 
  628.                                  may not know how to display the item.
  629.  
  630.       Required: No
  631.  
  632.       Multi-Valued: NEVER
  633.  
  634.       Intended usage: COMMON
  635.  
  636. 9.2 Variant
  637.  
  638.       Name: variant
  639.  
  640.       Data type: Text
  641.  
  642.       Purpose: Indicates a variant of the profile schema.  All 
  643.                variants should support the profile schema and
  644.                may only add to the schema. Encoding:  Case 
  645.                insensitive.
  646.  
  647.       Special notes (optional):  This should be the first property
  648.                                  after the profile property of the
  649.                                  item. Variants can be further 
  650.                                  classified by separating the 
  651.                                  versions in the variant string
  652.                                  with periods ".".  Once again each
  653.                                  sub-variant should only add to 
  654.                                  the schema.  
  655.                                  
  656.                                  Values are case insensitive.
  657.  
  658.       Examples:
  659.  
  660.     profile:"Appointment"
  661.         variant:"Recurring.1"
  662.     
  663.     This could correspond to an recurring appointment variant 1.
  664.  
  665.     profile:"Directory"
  666.     variant:"LDAP"
  667.  
  668.     This could correspond to a directory entry with an LDAP schema.
  669.  
  670.     profile:"Directory"
  671.     variant:"person"
  672.  
  673.     This could correspond to a person directory entry.
  674.  
  675.     profile:"Directory"
  676.     variant:"person.business card"
  677.  
  678.     This could correspond to the business card variant of the 
  679.         person directory entry.
  680.  
  681.       Required: No
  682.  
  683.       Multi-Valued: SOMETIMES
  684.  
  685.       Intended usage: COMMON
  686.  
  687. 9.3 CreatedBy
  688.  
  689.       Name: createdBy
  690.  
  691.       Data type: Text
  692.  
  693.       Purpose: Identifies the creator of the item.
  694.  
  695.       Encoding:  Should correspond to an [RFC-822] formatted recipient.
  696.  
  697.       Required: No
  698.  
  699.       Multi-Valued: SOMETIMES
  700.  
  701.       Intended usage: COMMON
  702.  
  703. 9.4 CreateDate
  704.  
  705.       Name: createDate
  706.  
  707.       Data type: DATETIME
  708.  
  709.       Purpose: Indicates the time that the item was created.
  710.  
  711.       Encoding:
  712.  
  713.       Required: No
  714.  
  715.       Multi-Valued: NEVER
  716.  
  717.       Intended usage: COMMON
  718.  
  719. 9.5 MofifiedBy
  720.  
  721.       Name: modifiedBy
  722.  
  723.       Data type: Text
  724.  
  725.       Purpose: Identifies the person that last modified the item.
  726.  
  727.       Encoding:  [RFC-822] formatted recipient.
  728.  
  729.       Required: No
  730.  
  731.       Multi-Valued: SOMETIMES
  732.  
  733.       Intended usage: COMMON
  734.  
  735. 9.6 LastModified
  736.       
  737.       Name: lastModified
  738.  
  739.       Data type: Text
  740.  
  741.       Purpose: Indicates the profile schema of the item.
  742.  
  743.       Encoding:
  744.  
  745.       Required: No
  746.  
  747.       Multi-Valued: SOMETIMES
  748.  
  749.       Intended usage: COMMON
  750.  
  751.  
  752. 10. Registration of new profiles
  753.  
  754. This section defines procedures by which new profiles are registered
  755. with the IANA and made available to the Internet community. Note that
  756. non-IANA profiles may be used by bilateral agreement, provided the 
  757. associated profile names follow the "X-" convention defined above.
  758.  
  759. The procedures defined here are designed to allow public comment and
  760. review of new profiles, while posing only a small impediment to the
  761. definition of new profiles.
  762.  
  763. Registration of a new profile is accomplished by the following steps.
  764.  
  765. 10.1.  Define the profile
  766.  
  767. A profile is defined by completing the following template.
  768.  
  769.       To: [mailing list TBD]
  770.       Subject: Registration of application/properties MIME profile XXX
  771.  
  772.       Profile name:
  773.  
  774.       Profile purpose:
  775.  
  776.       Profile property names:
  777.  
  778.       Profile special notes (optional):
  779.  
  780.       Profile Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
  781.  
  782.       Property Descriptions: (list of property descriptions in following 
  783. format)
  784.  
  785.         Name:
  786.  
  787.         Data type:
  788.  
  789.         Purpose:
  790.  
  791.         Encoding:
  792.  
  793.         Special notes (optional):
  794.  
  795.         Required: (one of YES, NO) 
  796.  
  797.         Multi-Valued: (one of ALWAYS, NEVER, SOMETIMES)
  798.  
  799.         Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
  800.  
  801.     
  802. The explanation of what goes in each field in the template follows.
  803.  
  804. Profile name: The name of the profile as it will appear in the
  805. application/properties MIME Content-Type "profile" header parameter.
  806.  
  807. Profile purpose: The purpose of the profile (e.g., to represent 
  808. information about people, printers, documents, etc.). Give a short but 
  809. clear
  810. description.
  811.  
  812. Profile property names: The list of property names associated with the 
  813. profile.  This list of names is to be expected but not required in the
  814. profile.  Other names not mentioned in the profile definition may also 
  815. be present.
  816.  
  817. Profile special notes: Any special notes about the profile, how it is to
  818. be used, etc. This section of the template may also be used to define an
  819. ordering on the types that appear in the Content-Type, if such an 
  820. ordering is required.
  821.  
  822. Property Descriptions: Precedes the list of property descriptions for 
  823. the profile.  Each property definition starts with the "Name:" tag.
  824.  
  825. Name: The name of the property, as it will appear in the body
  826. of an application/properties MIME Content-Type "name, datatype: value"
  827. line to the left of the colon ":".
  828.  
  829. Data type:  The expected data type for the property.  Possible values 
  830. listed in section 8.
  831.  
  832. Purpose: The purpose of the property (e.g., to represent a name,
  833. postal address, IP address, etc.). Give a short but clear description.
  834.  
  835. Encoding: The encoding a value of the type must have in the
  836. body of an application/properties MIME Content-Type.  This description
  837. must be precise and must not violate the general encoding rules defined
  838. in section 5 of this document.
  839.  
  840. Special notes: Any special notes about the property, how it is to be
  841. used, etc.
  842.  
  843. Required:  YES indicates that the property MUST be present in the 
  844. property list of a item of an item of this type profile.  No indicates 
  845. that this property MAY appear in the property list.
  846.  
  847. Multi-Valued:  ALWAYS indicates that the property will expected to be 
  848. multi-valued.  NEVER indicates that the property MUST NOT be multi-
  849. valued.  SOMETIMES indicates that the property MAY be multi-valued, but 
  850. that most implementations will not make it multi-valued.
  851.  
  852. Intended usage: COMMON indicates that most items of this profile will 
  853. include this property.  LIMITED USE indicates that this property will 
  854. rarely be included.  OBSOLETE indicates that use of this property SHOULD 
  855. NOT be used.
  856.  
  857. 10.2.  Post the profile definition
  858.  
  859. The profile description must be posted to the new profile discussion
  860. list, [mailing list TBD].
  861.  
  862. 10.3.  Allow a comment period
  863.  
  864. Discussion on the new profile must be allowed to take place on the list
  865. for a minimum of two weeks. Consensus must be reached on the profile
  866. before proceeding to step 4.
  867.  
  868. 10.4.  Submit the profile for approval
  869.  
  870. Once the two-week comment period has elapsed, and the proposer is 
  871. convinced consensus has been reached on the profile, the
  872. registration application should be submitted to the Profile Reviewer
  873. for approval.  The Profile Reviewer is appointed by the Application 
  874. Area Directors and may either accept or reject the profile registration.
  875. An accepted registration should be passed on by the Profile 
  876. Reviewer to the IANA for inclusion in the official IANA profile 
  877. registry. The registration may be rejected for any of the following 
  878. reasons. 1) Insufficient comment period; 2) Consensus not reached; 
  879. 3)  Technical deficiencies raised on the list or elsewhere have not 
  880. been addressed. The Profile Reviewer's decision to reject a profile may 
  881. be appealed by the proposer to the IESG, or the objections raised 
  882. can be addressed by the proposer and the profile resubmitted.
  883.  
  884. 11.  Profile Change Control
  885.  
  886. Existing profiles may be changed using the same process by which they
  887. were registered.
  888.  
  889.      Define the change
  890.  
  891.      Post the change
  892.  
  893.      Allow a comment period
  894.  
  895.      Submit the profile for approval
  896.  
  897. Note that the original author or any other interested party may propose
  898. a change to an existing profile, but that such changes should only be
  899. proposed when there are serious omissions or errors in the published
  900. specification. The Profile Reviewer may object to a change if it is not
  901. backwards compatible, but is not required to do so.
  902.  
  903. Profile definitions can never be deleted from the IANA registry, but
  904. profiles which are no longer believed to be useful can be 
  905. declared OBSOLETE by a change to their "intended use" field.
  906.  
  907. 12.  Registration of new variants
  908.  
  909. Variants are registered in the same manner as profiles except that the 
  910. variant uses the following format:
  911.  
  912.       To: [mailing list TBD]
  913.       Subject: Registration of application/properties MIME profile XXX
  914.  
  915.       Variant name:
  916.  
  917.       Variant profile:
  918.  
  919.       Variant purpose:
  920.  
  921.       Variant property names:
  922.  
  923.       Variant special notes (optional):
  924.  
  925.       Variant Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
  926.  
  927.       Property Descriptions: (list of property descriptions as described 
  928.                              in section 10.1)
  929.  
  930.  
  931. Variant Profile is the name of the profile that this variant is a 
  932. version of.  The complete path for the variant should be listed with the 
  933. intent that all variants should be the same based on their period-
  934. separated root parts.
  935.  
  936. The descriptions for the other values are the same as in Section 10.1 
  937. where variant is replaced with profile.
  938.     
  939. The registration process follows the way that profiles are registered.
  940.  
  941.      Define the change
  942.  
  943.      Post the change
  944.  
  945.      Allow a comment period
  946.  
  947.      Submit the profile for approval
  948.  
  949. 13. Security Considerations
  950.  
  951. Internet mail is subject to many well-known security attacks, including 
  952. monitoring, replay, and forgery. Care should be taken to restrict 
  953. sensitive information from leaving the scope of the service itself, 
  954. where any access controls can no longer be guaranteed.
  955.  
  956. 14.  Acknowledgments
  957.  
  958. Format and some descriptions were borrowed from the MIME Directory 
  959. draft.
  960.  
  961.  
  962. 15.  Author's Address
  963.  
  964. Darren Shakib
  965. Microsoft
  966. One Microsoft Way
  967. Redmond, WA 98052
  968. USA
  969.  
  970. Phone: (206) 936-6405
  971. Email: darrens@microsoft.com
  972.  
  973. Ian Ferrell
  974. Microsoft
  975. One Microsoft Way
  976. Redmond, WA 98052
  977. USA
  978.  
  979. Phone: (206) 936-1086
  980. Email: ianf@microsoft.com
  981.  
  982.  
  983. 16.  References
  984.  
  985. [MIME-DIR]
  986.      Howes, T., Smith, M., "A MIME Content-Type for  Directory  Informa-
  987.      tion", Internet-draft-ietf-asid-mime-direct-01.txt, February, 1996.
  988.  
  989. [MIME-REG]
  990.      Freed, N.,  Postel,  J.,  "Multipurpose  Internet  Mail  Extensions
  991.      (MIME)   Part   Four:   Registration   Procedures," Internet- Draft
  992.      draft-ietf-822ext-mime-reg-02.txt, December 1995.
  993.  
  994. [RFC-822]
  995.      Crocker, D., "Standard for the Format of ARPA  Internet  Text  Mes-
  996.      sages", STD 11, RFC-822, August 1982.
  997.  
  998. [RFC-1521]
  999.      Borenstein, N., Freed, N., "MIME (Multipurpose Internet Mail Exten-
  1000.      sions)  Part One: Mechanisms for Specifying and Describing the For-
  1001.      mat of Internet Message Bodies",  RFC  1521,  September 1993.
  1002.  
  1003. [RFC-1522]
  1004.      Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part  Two:
  1005.      Message  Header Extensions for Non-ASCII Text", RFC 1522, September
  1006.      1993.
  1007.  
  1008. [RFC-1738]
  1009.      Berners-Lee, T., Masinter,  L.,  McCahill,  M.,  "Uniform  Resource
  1010.      Locators (URL)", RFC 1738, December 1994.
  1011.  
  1012. [RFC-1777]
  1013.      Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
  1014.      Protocol", RFC 1777, Performance Systems International,
  1015.      University of Michigan, ISODE Consortium, March 1995.
  1016.  
  1017. [RFC-1778]
  1018.      Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
  1019.      Protocol", RFC 1777, Performance Systems International,
  1020.      University of Michigan, ISODE Consortium, March 1995.
  1021.  
  1022. [RFC-1835]
  1023.      Deutsch, et al., "Architecture of the WHOIS++ service",
  1024.      RFC 1835, August 1995.
  1025.  
  1026. [RFC-1872]
  1027.      Levinson, E., "The MIME Multipart/Related  Content-type," RFC 1872,
  1028.      December 1995.
  1029.  
  1030. Appendix A - Differences from [MIME-DIR]
  1031.  
  1032. While this is defined as an extension to [MIME-DIR] there are some 
  1033. changes.  Most of these changes were designed to clear up ambiguities 
  1034. and either simplify or make the spec clearer.  The extensions are 
  1035. intended to make the property definition items able to describe a wider 
  1036. variety of item types.
  1037.  
  1038. The term "name" is used instead of "type".  Both refer to the name of a 
  1039. property on the item.  While type has a very specific meaning to some 
  1040. people it is easily confused with the data type of a property.
  1041.  
  1042. The defaulttype parameter was removed.  Its definition was ambiguous 
  1043. since it was not clear why the "type" would be duplicated.  Since a 
  1044. specific mechanism is described for multi-valued property values it 
  1045. became obsolete.
  1046.  
  1047. Removed name parameter since its use was vague.  The information may be 
  1048. more appropriate as a property on the item rather than as a parameter, 
  1049. which would allow its definition to be more specific. 
  1050.  
  1051. MIME subtype changed from "directory" to "properties".  This allows for 
  1052. a more generic definition for the items.  The profile should be set to 
  1053. "directory" for directory items and the variant should be used to 
  1054. specify variations on a standard directory item.
  1055.  
  1056.  
  1057. Appendix B - Outstanding Issues
  1058.  
  1059. Requirements for registration have not been finalized.  The details 
  1060. above are subject to change.
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066.  
  1067.  
  1068.