A MIME Content-Type for Directory Information
obsoleted by
- rfc-6350 — vCard Format Specification
Extracted elements (29)
Multi-valued attributes are generally represented by creating a new content line for each value. However, some value types (date, time, integer, float) support comma-separated encoding of multiple values in a single line for space-saving reasons.
Non-IANA profiles, types, parameters, and value types can be used by bilateral agreement provided their names follow the 'X-' or 'x-' prefix convention, reserving the rest of the namespace for IANA-registered extensions.
The 'value' parameter is optional but its use is encouraged even when omitted: by defining a standard set of value types and formats, existing parsing code can be reused and generalized applications (e.g., search engines) can process typed data without knowing the schema of every property.
The line-folding convention in text/directory differs from RFC 822: any CRLF immediately followed by whitespace anywhere in the content indicates a continued line and must be removed, not just at the start of a header.
To interpret directory information, applications must share a common understanding of the types (the directory schema). Schema information is not defined in this document but in companion profile documents (e.g., RFC 2426 for vCard) or bilateral agreements.
The 'charset' parameter is required for text/directory body parts, as defined in RFC 2046, to identify the default character set used within the body part.
The 'profile' parameter SHOULD NOT be used to exclude or require particular pieces of information unless a profile definition specifically calls for this behavior. Unless specifically forbidden by a profile, a text/directory content type can contain arbitrary attribute/value pairs.
When parsing a content line, folded lines MUST first be unfolded. When generating a content line, lines longer than 75 characters SHOULD be folded according to the folding procedure.
For non-textual directory information (e.g., images, sounds) already having natural MIME representations, a multipart/related Content-Type is used. The root body part must be text/directory; non-text parts are referenced by Content-ID URIs from within the root part.
The BEGIN and END types delimit a profile block within a text/directory body, enabling multiple entities within one body part and identifiability outside a MIME environment. Their value is the profile name (e.g., BEGIN:VCARD / END:VCARD).
The 'context' type parameter identifies the protocol or context used to interpret a value (e.g., LDAP for the SOURCE type). The value of CONTEXT MUST be compatible with the URI scheme prefix used.
The 'encoding' type parameter specifies per-value encoding. Currently only the 'b' encoding (base 64 from RFC 2047) is supported. Content-Transfer-Encoding (body-level) and the 'encoding' parameter (value-level) are independent; individual type encodings are performed first, then the whole body part is encoded.
The group construct (a dot-prefixed label before the type name) is used to group related attributes together for display purposes. Implementations that do not support grouping MAY strip off any text before the '.' and present types and values as normal.
The 'language' type parameter identifies the language of a value using a Language-Tag as defined in RFC 1766. There is no concept of a default language except as specified by any Content-Language MIME header.
The predefined NAME type (value type: text) conveys the display name of the directory entity to which the information pertains.
The predefined PROFILE type identifies the type of directory entity (e.g., vCard). Its value should match the 'profile' MIME header parameter if present.
The predefined SOURCE type (value type: uri) provides a URI by which applications knowledgeable in a given directory service protocol can obtain additional or more up-to-date information. Multiple SOURCE types may be included. The CONTEXT parameter MUST be compatible with the URI prefix.
The text/directory MIME Content-Type is defined for holding directory information in a 'type:value' form. It uses MIME media type 'text' and subtype 'directory', with a required 'charset' parameter and an optional 'profile' parameter.
The 'value' type parameter identifies the value type and format of a property value. Predefined value types include: uri, text, date, time, date-time, integer, boolean, float, and extensible iana-token or x-name types.
IANA maintains a registry of text/directory parameters. Registration follows the same four-step process (define, post, comment period, approval). Parameter definitions can never be deleted from the IANA registry.
IANA maintains a registry of text/directory profiles. New profiles are registered via a formal process: define using a template, post to ietf-mime-direct@imc.org, minimum two-week comment period, submission to the Profile Reviewer (appointed by Application Area Directors) for approval.
IANA maintains a registry of text/directory types. New types require the same template-and-review process: post to ietf-mime-direct@imc.org, two-week comment period, and Profile Reviewer approval. Type definitions are never deleted; obsolete types are marked OBSOLETE.
IANA maintains a registry of text/directory value types. Registration requires the same process. Value type format must be defined in ABNF grammar. Value type definitions can never be deleted; unused ones are declared OBSOLETE.
Once directory information leaves its native service, access controls can no longer be guaranteed. This specification defines no access control mechanism. Integrity and privacy of a text/directory body part can be protected by enclosing it within an appropriate MIME-based security mechanism. Applications should display directory data in a safe environment (e.g., PostScript-valued types require care).
Individual lines are delimited by CRLF (ASCII 13 followed by ASCII 10). Long logical lines MAY be folded by inserting CRLF followed by a single whitespace character (space or horizontal tab) anywhere between two characters; the CRLF and whitespace are removed during unfolding.
The content line format is: [group "."] name *(";", param) ":" value CRLF. The 'group' is alphanumeric, 'name' is an IANA token or x-name, and 'param' is param-name "=" param-value *(, param-value). Type names and parameter names are case insensitive.
The 'date' value type is based on ISO 8601: YYYY[-MM[-DD]]. The 'time' type is HH[:MM[:SS[,frac][Z|±HH[:MM]]]. The 'date-time' type combines these with a 'T' separator. Multiple values can be comma-separated unless restricted by a profile.
The 'integer' value type is a signed decimal integer; if sign is omitted the value is assumed positive. The 'float' value type is a signed real number with optional decimal fraction. Multiple values may be comma-separated.
The 'text' value type uses backslash escaping: commas and backslashes must be escaped as '\,' and '\\'; a formatted line break within a text value MUST be represented as '\n' or '\N' (backslash followed by 'n' or 'N').