add vcard docs

svn path=/trunk/; revision=20587

4 files changed, 6593 insertions, 0 deletions

diff --git a/addressbook/backend/ebook/docs/rfc2047.txt b/addressbook/backend/ebook/docs/rfc2047.txt
new file mode 100644
index 0000000000..ff9a744bf3
--- /dev/null
+++ b/addressbook/backend/ebook/docs/rfc2047.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                           K. Moore
+Request for Comments: 2047                       University of Tennessee
+Obsoletes: 1521, 1522, 1590                                November 1996
+Category: Standards Track
+
+
+        MIME (Multipurpose Internet Mail Extensions) Part Three:
+              Message Header Extensions for Non-ASCII Text
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   STD 11, RFC 822, defines a message representation protocol specifying
+   considerable detail about US-ASCII message headers, and leaves the
+   message content, or message body, as flat US-ASCII text.  This set of
+   documents, collectively called the Multipurpose Internet Mail
+   Extensions, or MIME, redefines the format of messages to allow for
+
+   (1) textual message bodies in character sets other than US-ASCII,
+
+   (2) an extensible set of different formats for non-textual message
+       bodies,
+
+   (3) multi-part message bodies, and
+
+   (4) textual header information in character sets other than US-ASCII.
+
+   These documents are based on earlier work documented in RFC 934, STD
+   11, and RFC 1049, but extends and revises them.  Because RFC 822 said
+   so little about message bodies, these documents are largely
+   orthogonal to (rather than a revision of) RFC 822.
+
+   This particular document is the third document in the series.  It
+   describes extensions to RFC 822 to allow non-US-ASCII text data in
+   Internet mail header fields.
+
+
+
+
+
+
+
+
+
+Moore                       Standards Track                     [Page 1]
+
+RFC 2047               Message Header Extensions           November 1996
+
+
+   Other documents in this series include:
+
+   + RFC 2045, which specifies the various headers used to describe
+     the structure of MIME messages.
+
+   + RFC 2046, which defines the general structure of the MIME media
+     typing system and defines an initial set of media types,
+
+   + RFC 2048, which specifies various IANA registration procedures
+     for MIME-related facilities, and
+
+   + RFC 2049, which describes MIME conformance criteria and
+     provides some illustrative examples of MIME message formats,
+     acknowledgements, and the bibliography.
+
+   These documents are revisions of RFCs 1521, 1522, and 1590, which
+   themselves were revisions of RFCs 1341 and 1342.  An appendix in RFC
+   2049 describes differences and changes from previous versions.
+
+1. Introduction
+
+   RFC 2045 describes a mechanism for denoting textual body parts which
+   are coded in various character sets, as well as methods for encoding
+   such body parts as sequences of printable US-ASCII characters.  This
+   memo describes similar techniques to allow the encoding of non-ASCII
+   text in various portions of a RFC 822 [2] message header, in a manner
+   which is unlikely to confuse existing message handling software.
+
+   Like the encoding techniques described in RFC 2045, the techniques
+   outlined here were designed to allow the use of non-ASCII characters
+   in message headers in a way which is unlikely to be disturbed by the
+   quirks of existing Internet mail handling programs.  In particular,
+   some mail relaying programs are known to (a) delete some message
+   header fields while retaining others, (b) rearrange the order of
+   addresses in To or Cc fields, (c) rearrange the (vertical) order of
+   header fields, and/or (d) "wrap" message headers at different places
+   than those in the original message.  In addition, some mail reading
+   programs are known to have difficulty correctly parsing message
+   headers which, while legal according to RFC 822, make use of
+   backslash-quoting to "hide" special characters such as "<", ",", or
+   ":", or which exploit other infrequently-used features of that
+   specification.
+
+   While it is unfortunate that these programs do not correctly
+   interpret RFC 822 headers, to "break" these programs would cause
+   severe operational problems for the Internet mail system.  The
+   extensions described in this memo therefore do not rely on little-
+   used features of RFC 822.
+
+
+
+Moore                       Standards Track                     [Page 2]
+
+RFC 2047               Message Header Extensions           November 1996
+
+
+   Instead, certain sequences of "ordinary" printable ASCII characters
+   (known as "encoded-words") are reserved for use as encoded data.  The
+   syntax of encoded-words is such that they are unlikely to
+   "accidentally" appear as normal text in message headers.
+   Furthermore, the characters used in encoded-words are restricted to
+   those which do not have special meanings in the context in which the
+   encoded-word appears.
+
+   Generally, an "encoded-word" is a sequence of printable ASCII
+   characters that begins with "=?", ends with "?=", and has two "?"s in
+   between.  It specifies a character set and an encoding method, and
+   also includes the original text encoded as graphic ASCII characters,
+   according to the rules for that encoding method.
+
+   A mail composer that implements this specification will provide a
+   means of inputting non-ASCII text in header fields, but will
+   translate these fields (or appropriate portions of these fields) into
+   encoded-words before inserting them into the message header.
+
+   A mail reader that implements this specification will recognize
+   encoded-words when they appear in certain portions of the message
+   header.  Instead of displaying the encoded-word "as is", it will
+   reverse the encoding and display the original text in the designated
+   character set.
+
+NOTES
+
+   This memo relies heavily on notation and terms defined RFC 822 and
+   RFC 2045.  In particular, the syntax for the ABNF used in this memo
+   is defined in RFC 822, as well as many of the terminal or nonterminal
+   symbols from RFC 822 are used in the grammar for the header
+   extensions defined here.  Among the symbols defined in RFC 822 and
+   referenced in this memo are: 'addr-spec', 'atom', 'CHAR', 'comment',
+   'CTLs', 'ctext', 'linear-white-space', 'phrase', 'quoted-pair'.
+   'quoted-string', 'SPACE', and 'word'.  Successful implementation of
+   this protocol extension requires careful attention to the RFC 822
+   definitions of these terms.
+
+   When the term "ASCII" appears in this memo, it refers to the "7-Bit
+   American Standard Code for Information Interchange", ANSI X3.4-1986.
+   The MIME charset name for this character set is "US-ASCII".  When not
+   specifically referring to the MIME charset name, this document uses
+   the term "ASCII", both for brevity and for consistency with RFC 822.
+   However, implementors are warned that the character set name must be
+   spelled "US-ASCII" in MIME message and body part headers.
+
+
+
+
+
+
+Moore                       Standards Track                     [Page 3]
+
+RFC 2047               Message Header Extensions           November 1996
+
+
+   This memo specifies a protocol for the representation of non-ASCII
+   text in message headers.  It specifically DOES NOT define any
+   translation between "8-bit headers" and pure ASCII headers, nor is
+   any such translation assumed to be possible.
+
+2. Syntax of encoded-words
+
+   An 'encoded-word' is defined by the following ABNF grammar.  The
+   notation of RFC 822 is used, with the exception that white space
+   characters MUST NOT appear between components of an 'encoded-word'.
+
+   encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
+
+   charset = token    ; see section 3
+
+   encoding = token   ; see section 4
+
+   token = 1*<Any CHAR except SPACE, CTLs, and especials>
+
+   especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
+               <"> / "/" / "[" / "]" / "?" / "." / "="
+
+   encoded-text = 1*<Any printable ASCII character other than "?"
+                     or SPACE>
+                  ; (but see "Use of encoded-words in message
+                  ; headers", section 5)
+
+   Both 'encoding' and 'charset' names are case-independent.  Thus the
+   charset name "ISO-8859-1" is equivalent to "iso-8859-1", and the
+   encoding named "Q" may be spelled either "Q" or "q".
+
+   An 'encoded-word' may not be more than 75 characters long, including
+   'charset', 'encoding', 'encoded-text', and delimiters.  If it is
+   desirable to encode more text than will fit in an 'encoded-word' of
+   75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
+   be used.
+
+   While there is no limit to the length of a multiple-line header
+   field, each line of a header field that contains one or more
+   'encoded-word's is limited to 76 characters.
+
+   The length restrictions are included both to ease interoperability
+   through internetwork mail gateways, and to impose a limit on the
+   amount of lookahead a header parser must employ (while looking for a
+   final ?= delimiter) before it can decide whether a token is an
+   "encoded-word" or something else.
+
+
+
+
+
+Moore                       Standards Track                     [Page 4]
+
+RFC 2047               Message Header Extensions           November 1996
+
+
+   IMPORTANT: 'encoded-word's are designed to be recognized as 'atom's
+   by an RFC 822 parser.  As a consequence, unencoded white space
+   characters (such as SPACE and HTAB) are FORBIDDEN within an
+   'encoded-word'.  For example, the character sequence
+
+      =?iso-8859-1?q?this is some text?=
+
+   would be parsed as four 'atom's, rather than as a single 'atom' (by
+   an RFC 822 parser) or 'encoded-word' (by a parser which understands
+   'encoded-words').  The correct way to encode the string "this is some
+   text" is to encode the SPACE characters as well, e.g.
+
+      =?iso-8859-1?q?this=20is=20some=20text?=
+
+   The characters which may appear in 'encoded-text' are further
+   restricted by the rules in section 5.
+
+3. Character sets
+
+   The 'charset' portion of an 'encoded-word' specifies the character
+   set associated with the unencoded text.  A 'charset' can be any of
+   the character set names allowed in an MIME "charset" parameter of a
+   "text/plain" body part, or any character set name registered with
+   IANA for use with the MIME text/plain content-type.
+
+   Some character sets use code-switching techniques to switch between
+   "ASCII mode" and other modes.  If unencoded text in an 'encoded-word'
+   contains a sequence which causes the charset interpreter to switch
+   out of ASCII mode, it MUST contain additional control codes such that
+   ASCII mode is again selected at the end of the 'encoded-word'.  (This
+   rule applies separately to each 'encoded-word', including adjacent
+   'encoded-word's within a single header field.)
+
+   When there is a possibility of using more than one character set to
+   represent the text in an 'encoded-word', and in the absence of
+   private agreements between sender and recipients of a message, it is
+   recommended that members of the ISO-8859-* series be used in
+   preference to other character sets.
+
+4. Encodings
+
+   Initially, the legal values for "encoding" are "Q" and "B".  These
+   encodings are described below.  The "Q" encoding is recommended for
+   use when most of the characters to be encoded are in the ASCII
+   character set; otherwise, the "B" encoding should be used.
+   Nevertheless, a mail reader which claims to recognize 'encoded-word's
+   MUST be able to accept either encoding for any character set which it
+   supports.
+
+
+
+Moore                       Standards Track                     [Page 5]
+
+RFC 2047               Message Header Extensions           November 1996
+
+
+   Only a subset of the printable ASCII characters may be used in
+   'encoded-text'.  Space and tab characters are not allowed, so that
+   the beginning and end of an 'encoded-word' are obvious.  The "?"
+   character is used within an 'encoded-word' to separate the various
+   portions of the 'encoded-word' from one another, and thus cannot
+   appear in the 'encoded-text' portion.  Other characters are also
+   illegal in certain contexts.  For example, an 'encoded-word' in a
+   'phrase' preceding an address in a From header field may not contain
+   any of the "specials" defined in RFC 822.  Finally, certain other
+   characters are disallowed in some contexts, to ensure reliability for
+   messages that pass through internetwork mail gateways.
+
+   The "B" encoding automatically meets these requirements.  The "Q"
+   encoding allows a wide range of printable characters to be used in
+   non-critical locations in the message header (e.g., Subject), with
+   fewer characters available for use in other locations.
+
+4.1. The "B" encoding
+
+   The "B" encoding is identical to the "BASE64" encoding defined by RFC
+   2045.
+
+4.2. The "Q" encoding
+
+   The "Q" encoding is similar to the "Quoted-Printable" content-
+   transfer-encoding defined in RFC 2045.  It is designed to allow text
+   containing mostly ASCII characters to be decipherable on an ASCII
+   terminal without decoding.
+
+   (1) Any 8-bit value may be represented by a "=" followed by two
+       hexadecimal digits.  For example, if the character set in use
+       were ISO-8859-1, the "=" character would thus be encoded as
+       "=3D", and a SPACE by "=20".  (Upper case should be used for
+       hexadecimal digits "A" through "F".)
+
+   (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be
+       represented as "_" (underscore, ASCII 95.).  (This character may
+       not pass through some internetwork mail gateways, but its use
+       will greatly enhance readability of "Q" encoded data with mail
+       readers that do not support this encoding.)  Note that the "_"
+       always represents hexadecimal 20, even if the SPACE character
+       occupies a different code position in the character set in use.
+
+   (3) 8-bit values which correspond to printable ASCII characters other
+       than "=", "?", and "_" (underscore), MAY be represented as those
+       characters.  (But see section 5 for restrictions.)  In
+       particular, SPACE and TAB MUST NOT be represented as themselves
+       within encoded words.
+
+
+
+Moore                       Standards Track                     [Page 6]
+
+RFC 2047               Message Header Extensions           November 1996
+
+
+5. Use of encoded-words in message headers
+
+   An 'encoded-word' may appear in a message header or body part header
+   according to the following rules:
+
+(1) An 'encoded-word' may replace a 'text' token (as defined by RFC 822)
+    in any Subject or Comments header field, any extension message
+    header field, or any MIME body part field for which the field body
+    is defined as '*text'.  An 'encoded-word' may also appear in any
+    user-defined ("X-") message or body part header field.
+
+    Ordinary ASCII text and 'encoded-word's may appear together in the
+    same header field.  However, an 'encoded-word' that appears in a
+    header field defined as '*text' MUST be separated from any adjacent
+    'encoded-word' or 'text' by 'linear-white-space'.
+
+(2) An 'encoded-word' may appear within a 'comment' delimited by "(" and
+    ")", i.e., wherever a 'ctext' is allowed.  More precisely, the RFC
+    822 ABNF definition for 'comment' is amended as follows:
+
+    comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"
+
+    A "Q"-encoded 'encoded-word' which appears in a 'comment' MUST NOT
+    contain the characters "(", ")" or "
+    'encoded-word' that appears in a 'comment' MUST be separated from
+    any adjacent 'encoded-word' or 'ctext' by 'linear-white-space'.
+
+    It is important to note that 'comment's are only recognized inside
+    "structured" field bodies.  In fields whose bodies are defined as
+    '*text', "(" and ")" are treated as ordinary characters rather than
+    comment delimiters, and rule (1) of this section applies.  (See RFC
+    822, sections 3.1.2 and 3.1.3)
+
+(3) As a replacement for a 'word' entity within a 'phrase', for example,
+    one that precedes an address in a From, To, or Cc header.  The ABNF
+    definition for 'phrase' from RFC 822 thus becomes:
+
+    phrase = 1*( encoded-word / word )
+
+    In this case the set of characters that may be used in a "Q"-encoded
+    'encoded-word' is restricted to: <upper and lower case ASCII
+    letters, decimal digits, "!", "*", "+", "-", "/", "=", and "_"
+    (underscore, ASCII 95.)>.  An 'encoded-word' that appears within a
+    'phrase' MUST be separated from any adjacent 'word', 'text' or
+    'special' by 'linear-white-space'.
+
+
+
+
+
+
+Moore                       Standards Track                     [Page 7]
+
+RFC 2047               Message Header Extensions           November 1996
+
+
+   These are the ONLY locations where an 'encoded-word' may appear.  In
+   particular:
+
+   + An 'encoded-word' MUST NOT appear in any portion of an 'addr-spec'.
+
+   + An 'encoded-word' MUST NOT appear within a 'quoted-string'.
+
+   + An 'encoded-word' MUST NOT be used in a Received header field.
+
+   + An 'encoded-word' MUST NOT be used in parameter of a MIME
+     Content-Type or Content-Disposition field, or in any structured
+     field body except within a 'comment' or 'phrase'.
+
+   The 'encoded-text' in an 'encoded-word' must be self-contained;
+   'encoded-text' MUST NOT be continued from one 'encoded-word' to
+   another.  This implies that the 'encoded-text' portion of a "B"
+   'encoded-word' will be a multiple of 4 characters long; for a "Q"
+   'encoded-word', any "=" character that appears in the 'encoded-text'
+   portion will be followed by two hexadecimal characters.
+
+   Each 'encoded-word' MUST encode an integral number of octets.  The
+   'encoded-text' in each 'encoded-word' must be well-formed according
+   to the encoding specified; the 'encoded-text' may not be continued in
+   the next 'encoded-word'.  (For example, "=?charset?Q?=?=
+   =?charset?Q?AB?=" would be illegal, because the two hex digits "AB"
+   must follow the "=" in the same 'encoded-word'.)
+
+   Each 'encoded-word' MUST represent an integral number of characters.
+   A multi-octet character may not be split across adjacent 'encoded-
+   word's.
+
+   Only printable and white space character data should be encoded using
+   this scheme.  However, since these encoding schemes allow the
+   encoding of arbitrary octet values, mail readers that implement this
+   decoding should also ensure that display of the decoded data on the
+   recipient's terminal will not cause unwanted side-effects.
+
+   Use of these methods to encode non-textual data (e.g., pictures or
+   sounds) is not defined by this memo.  Use of 'encoded-word's to
+   represent strings of purely ASCII characters is allowed, but
+   discouraged.  In rare cases it may be necessary to encode ordinary
+   text that looks like an 'encoded-word'.
+
+
+
+
+
+
+
+
+
+Moore                       Standards Track                     [Page 8]
+
+RFC 2047               Message Header Extensions           November 1996
+
+
+6. Support of 'encoded-word's by mail readers
+
+6.1. Recognition of 'encoded-word's in message headers
+
+   A mail reader must parse the message and body part headers according
+   to the rules in RFC 822 to correctly recognize 'encoded-word's.
+
+   'encoded-word's are to be recognized as follows:
+
+   (1) Any message or body part header field defined as '*text', or any
+       user-defined header field, should be parsed as follows: Beginning
+       at the start of the field-body and immediately following each
+       occurrence of 'linear-white-space', each sequence of up to 75
+       printable characters (not containing any 'linear-white-space')
+       should be examined to see if it is an 'encoded-word' according to
+       the syntax rules in section 2.  Any other sequence of printable
+       characters should be treated as ordinary ASCII text.
+
+   (2) Any header field not defined as '*text' should be parsed
+       according to the syntax rules for that header field.  However,
+       any 'word' that appears within a 'phrase' should be treated as an
+       'encoded-word' if it meets the syntax rules in section 2.
+       Otherwise it should be treated as an ordinary 'word'.
+
+   (3) Within a 'comment', any sequence of up to 75 printable characters
+       (not containing 'linear-white-space'), that meets the syntax
+       rules in section 2, should be treated as an 'encoded-word'.
+       Otherwise it should be treated as normal comment text.
+
+   (4) A MIME-Version header field is NOT required to be present for
+       'encoded-word's to be interpreted according to this
+       specification.  One reason for this is that the mail reader is
+       not expected to parse the entire message header before displaying
+       lines that may contain 'encoded-word's.
+
+6.2. Display of 'encoded-word's
+
+   Any 'encoded-word's so recognized are decoded, and if possible, the
+   resulting unencoded text is displayed in the original character set.
+
+   NOTE: Decoding and display of encoded-words occurs *after* a
+   structured field body is parsed into tokens.  It is therefore
+   possible to hide 'special' characters in encoded-words which, when
+   displayed, will be indistinguishable from 'special' characters in the
+   surrounding text.  For this and other reasons, it is NOT generally
+   possible to translate a message header containing 'encoded-word's to
+   an unencoded form which can be parsed by an RFC 822 mail reader.
+
+
+
+
+Moore                       Standards Track                     [Page 9]
+
+RFC 2047               Message Header Extensions           November 1996
+
+
+   When displaying a particular header field that contains multiple
+   'encoded-word's, any 'linear-white-space' that separates a pair of
+   adjacent 'encoded-word's is ignored.  (This is to allow the use of
+   multiple 'encoded-word's to represent long strings of unencoded text,
+   without having to separate 'encoded-word's where spaces occur in the
+   unencoded text.)
+
+   In the event other encodings are defined in the future, and the mail
+   reader does not support the encoding used, it may either (a) display
+   the 'encoded-word' as ordinary text, or (b) substitute an appropriate
+   message indicating that the text could not be decoded.
+
+   If the mail reader does not support the character set used, it may
+   (a) display the 'encoded-word' as ordinary text (i.e., as it appears
+   in the header), (b) make a "best effort" to display using such
+   characters as are available, or (c) substitute an appropriate message
+   indicating that the decoded text could not be displayed.
+
+   If the character set being used employs code-switching techniques,
+   display of the encoded text implicitly begins in "ASCII mode".  In
+   addition, the mail reader must ensure that the output device is once
+   again in "ASCII mode" after the 'encoded-word' is displayed.
+
+6.3. Mail reader handling of incorrectly formed 'encoded-word's
+
+   It is possible that an 'encoded-word' that is legal according to the
+   syntax defined in section 2, is incorrectly formed according to the
+   rules for the encoding being used.   For example:
+
+   (1) An 'encoded-word' which contains characters which are not legal
+       for a particular encoding (for example, a "-" in the "B"
+       encoding, or a SPACE or HTAB in either the "B" or "Q" encoding),
+       is incorrectly formed.
+
+   (2) Any 'encoded-word' which encodes a non-integral number of
+       characters or octets is incorrectly formed.
+
+   A mail reader need not attempt to display the text associated with an
+   'encoded-word' that is incorrectly formed.  However, a mail reader
+   MUST NOT prevent the display or handling of a message because an
+   'encoded-word' is incorrectly formed.
+
+7. Conformance
+
+   A mail composing program claiming compliance with this specification
+   MUST ensure that any string of non-white-space printable ASCII
+   characters within a '*text' or '*ctext' that begins with "=?" and
+   ends with "?=" be a valid 'encoded-word'.  ("begins" means: at the
+
+
+
+Moore                       Standards Track                    [Page 10]
+
+RFC 2047               Message Header Extensions           November 1996
+
+
+   start of the field-body, immediately following 'linear-white-space',
+   or immediately following a "(" for an 'encoded-word' within '*ctext';
+   "ends" means: at the end of the field-body, immediately preceding
+   'linear-white-space', or immediately preceding a ")" for an
+   'encoded-word' within '*ctext'.)  In addition, any 'word' within a
+   'phrase' that begins with "=?" and ends with "?=" must be a valid
+   'encoded-word'.
+
+   A mail reading program claiming compliance with this specification
+   must be able to distinguish 'encoded-word's from 'text', 'ctext', or
+   'word's, according to the rules in section 6, anytime they appear in
+   appropriate places in message headers.  It must support both the "B"
+   and "Q" encodings for any character set which it supports.  The
+   program must be able to display the unencoded text if the character
+   set is "US-ASCII".  For the ISO-8859-* character sets, the mail
+   reading program must at least be able to display the characters which
+   are also in the ASCII set.
+
+8. Examples
+
+   The following are examples of message headers containing 'encoded-
+   word's:
+
+   From: =?US-ASCII?Q?Keith_Moore?= <moore@cs.utk.edu>
+   To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <keld@dkuug.dk>
+   CC: =?ISO-8859-1?Q?Andr=E9?= Pirard <PIRARD@vm1.ulg.ac.be>
+   Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
+    =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=
+
+      Note: In the first 'encoded-word' of the Subject field above, the
+      last "=" at the end of the 'encoded-text' is necessary because each
+      'encoded-word' must be self-contained (the "=" character completes a
+      group of 4 base64 characters representing 2 octets).  An additional
+      octet could have been encoded in the first 'encoded-word' (so that
+      the encoded-word would contain an exact multiple of 3 encoded
+      octets), except that the second 'encoded-word' uses a different
+      'charset' than the first one.
+
+   From: =?ISO-8859-1?Q?Olle_J=E4rnefors?= <ojarnef@admin.kth.se>
+   To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se
+   Subject: Time for ISO 10646?
+
+   To: Dave Crocker <dcrocker@mordor.stanford.edu>
+   Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se
+   From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@nada.kth.se>
+   Subject: Re: RFC-HDR care and feeding
+
+
+
+
+
+Moore                       Standards Track                    [Page 11]
+
+RFC 2047               Message Header Extensions           November 1996
+
+
+   From: Nathaniel Borenstein <nsb@thumper.bellcore.com>
+         (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=)
+   To: Greg Vaudreuil <gvaudre@NRI.Reston.VA.US>, Ned Freed
+      <ned@innosoft.com>, Keith Moore <moore@cs.utk.edu>
+   Subject: Test of new header generator
+   MIME-Version: 1.0
+   Content-type: text/plain; charset=ISO-8859-1
+
+   The following examples illustrate how text containing 'encoded-word's
+   which appear in a structured field body.  The rules are slightly
+   different for fields defined as '*text' because "(" and ")" are not
+   recognized as 'comment' delimiters.  [Section 5, paragraph (1)].
+
+   In each of the following examples, if the same sequence were to occur
+   in a '*text' field, the "displayed as" form would NOT be treated as
+   encoded words, but be identical to the "encoded form".  This is
+   because each of the encoded-words in the following examples is
+   adjacent to a "(" or ")" character.
+
+   encoded form                                displayed as
+   ---------------------------------------------------------------------
+   (=?ISO-8859-1?Q?a?=)                        (a)
+
+   (=?ISO-8859-1?Q?a?= b)                      (a b)
+
+           Within a 'comment', white space MUST appear between an
+           'encoded-word' and surrounding text.  [Section 5,
+           paragraph (2)].  However, white space is not needed between
+           the initial "(" that begins the 'comment', and the
+           'encoded-word'.
+
+
+   (=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=)     (ab)
+
+           White space between adjacent 'encoded-word's is not
+           displayed.
+
+   (=?ISO-8859-1?Q?a?=  =?ISO-8859-1?Q?b?=)    (ab)
+
+        Even multiple SPACEs between 'encoded-word's are ignored
+        for the purpose of display.
+
+   (=?ISO-8859-1?Q?a?=                         (ab)
+       =?ISO-8859-1?Q?b?=)
+
+           Any amount of linear-space-white between 'encoded-word's,
+           even if it includes a CRLF followed by one or more SPACEs,
+           is ignored for the purposes of display.
+
+
+
+Moore                       Standards Track                    [Page 12]
+
+RFC 2047               Message Header Extensions           November 1996
+
+
+   (=?ISO-8859-1?Q?a_b?=)                      (a b)
+
+           In order to cause a SPACE to be displayed within a portion
+           of encoded text, the SPACE MUST be encoded as part of the
+           'encoded-word'.
+
+   (=?ISO-8859-1?Q?a?= =?ISO-8859-2?Q?_b?=)    (a b)
+
+           In order to cause a SPACE to be displayed between two strings
+           of encoded text, the SPACE MAY be encoded as part of one of
+           the 'encoded-word's.
+
+9. References
+
+   [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text
+       Messages", STD 11, RFC 822, UDEL, August 1982.
+
+   [RFC 2049] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
+       Extensions (MIME) Part Five: Conformance Criteria and Examples",
+       RFC 2049, November 1996.
+
+   [RFC 2045] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
+       Extensions (MIME) Part One: Format of Internet Message Bodies",
+       RFC 2045, November 1996.
+
+   [RFC 2046] Borenstein N., and N. Freed, "Multipurpose Internet Mail
+       Extensions (MIME) Part Two: Media Types", RFC 2046,
+       November 1996.
+
+   [RFC 2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose
+       Internet Mail Extensions (MIME) Part Four: Registration
+       Procedures", RFC 2048, November 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore                       Standards Track                    [Page 13]
+
+RFC 2047               Message Header Extensions           November 1996
+
+
+10. Security Considerations
+
+   Security issues are not discussed in this memo.
+
+11. Acknowledgements
+
+   The author wishes to thank Nathaniel Borenstein, Issac Chan, Lutz
+   Donnerhacke, Paul Eggert, Ned Freed, Andreas M. Kirchwitz, Olle
+   Jarnefors, Mike Rosin, Yutaka Sato, Bart Schaefer, and Kazuhiko
+   Yamamoto, for their helpful advice, insightful comments, and
+   illuminating questions in response to earlier versions of this
+   specification.
+
+12. Author's Address
+
+   Keith Moore
+   University of Tennessee
+   107 Ayres Hall
+   Knoxville TN 37996-1301
+
+   EMail: moore@cs.utk.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore                       Standards Track                    [Page 14]
+
+RFC 2047               Message Header Extensions           November 1996
+
+
+Appendix - changes since RFC 1522 (in no particular order)
+
+   + explicitly state that the MIME-Version is not requried to use
+     'encoded-word's.
+
+   + add explicit note that SPACEs and TABs are not allowed within
+     'encoded-word's, explaining that an 'encoded-word' must look like an
+     'atom' to an RFC822 parser.values, to be precise).
+
+   + add examples from Olle Jarnefors (thanks!) which illustrate how
+     encoded-words with adjacent linear-white-space are displayed.
+
+   + explicitly list terms defined in RFC822 and referenced in this memo
+
+   + fix transcription typos that caused one or two lines and a couple of
+     characters to disappear in the resulting text, due to nroff quirks.
+
+   + clarify that encoded-words are allowed in '*text' fields in both
+     RFC822 headers and MIME body part headers, but NOT as parameter
+     values.
+
+   + clarify the requirement to switch back to ASCII within the encoded
+     portion of an 'encoded-word', for any charset that uses code switching
+     sequences.
+
+   + add a note about 'encoded-word's being delimited by "(" and ")"
+     within a comment, but not in a *text (how bizarre!).
+
+   + fix the Andre Pirard example to get rid of the trailing "_" after
+     the =E9.  (no longer needed post-1342).
+
+   + clarification: an 'encoded-word' may appear immediately following
+     the initial "(" or immediately before the final ")" that delimits a
+     comment, not just adjacent to "(" and ")" *within* *ctext.
+
+   + add a note to explain that a "B" 'encoded-word' will always have a
+     multiple of 4 characters in the 'encoded-text' portion.
+
+   + add note about the "=" in the examples
+
+   + note that processing of 'encoded-word's occurs *after* parsing, and
+     some of the implications thereof.
+
+   + explicitly state that you can't expect to translate between
+     1522 and either vanilla 822 or so-called "8-bit headers".
+
+   + explicitly state that 'encoded-word's are not valid within a
+     'quoted-string'.
+
+
+
+Moore                       Standards Track                    [Page 15]
+
diff --git a/addressbook/backend/ebook/docs/rfc2425.txt b/addressbook/backend/ebook/docs/rfc2425.txt
new file mode 100644
index 0000000000..30fed9bc07
--- /dev/null
+++ b/addressbook/backend/ebook/docs/rfc2425.txt
@@ -0,0 +1,1851 @@
+
+
+
+
+
+
+Network Working Group                                         T. Howes
+Request for Comments: 2425                                    M. Smith
+Category: Standards Track                Netscape Communications Corp.
+                                                             F. Dawson
+                                         Lotus Development Corporation
+                                                        September 1998
+
+
+             A MIME Content-Type for Directory Information
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+1.  Abstract
+
+   This document defines a MIME Content-Type for holding directory
+   information.  The definition is independent of any particular
+   directory service or protocol.  The text/directory Content-Type is
+   defined for holding a variety of directory information, for example,
+   name, or email address, or logo. The text/directory Content-Type can
+   also be used as the root body part in a multipart/related Content-
+   Type for handling more complicated situations, especially those in
+   which non-textual information that already has a natural MIME
+   representation, for example, a photograph or sound, is to be
+   represented.
+
+   The text/directory Content-Type defines a general framework and
+   format for holding directory information in a simple "type:value"
+   form. We refer to "type" in this context meaning a property or
+   attribute with which the value is associated. Mechanisms are defined
+   to specify alternate languages, encodings and other meta-information.
+   This document also defines the procedure by which particular formats,
+   called profiles, for carrying application-specific information within
+   a text/directory Content-Type can 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
+   applications (e.g., white pages).
+
+
+
+
+
+Howes, et. al.              Standards Track                     [Page 1]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC-2119].
+
+2.  Table of Contents
+
+   Status of the Memo................................................ 1
+   Copyright Notice.................................................. 1
+   1.  Abstract...................................................... 1
+   2.  Table of Contents............................................. 2
+   3.  Need for a MIME Directory Type................................ 3
+   4.  Overview...................................................... 4
+   5.  The text/directory Content-Type............................... 4
+   5.1.  MIME media type name........................................ 4
+   5.2.  MIME subtype name........................................... 5
+   5.3.  Required parameters......................................... 5
+   5.4.  Optional parameters......................................... 5
+   5.5.  Encoding considerations..................................... 5
+   5.6.  Security considerations..................................... 6
+   5.7.  Interoperability considerations............................. 6
+   5.8.  Published specification..................................... 6
+   5.8.1.  Line delimiting and folding............................... 6
+   5.8.2.  ABNF content-type definition.............................. 7
+   5.8.3.  Pre-defined Parameters.................................... 9
+   5.8.4.  Pre-defined Value Types...................................11
+   5.9.  Applications which use this media type......................14
+   5.10.  Additional information.....................................14
+   5.11.  Person & email address to contact for further information..14
+   5.12.  Intended usage.............................................14
+   5.13.  Author/Change controller...................................15
+   6.  Predefined Types..............................................15
+   6.1.  SOURCE Type Definition......................................15
+   6.2.  NAME Type Definition........................................16
+   6.3.  PROFILE Type Definition.....................................16
+   6.4.  BEGIN Type Definition.......................................17
+   6.5.  END Type Definition.........................................17
+   7.  Use of the multipart/related Content-Type.....................18
+   8. Examples.......................................................18
+   8.1.  Example 1...................................................19
+   8.2.  Example 2...................................................19
+   8.3.  Example 3...................................................20
+   8.4.  Example 4...................................................21
+   9.  Registration of new profiles..................................22
+   9.1.  Define the profile..........................................22
+   9.2.  Post the profile definition.................................23
+   9.3.  Allow a comment period......................................23
+   9.4.  Submit the profile for approval.............................23
+   10.  Profile Change Control.......................................23
+
+
+
+Howes, et. al.              Standards Track                     [Page 2]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+   11.  Registration of new types....................................24
+   11.1.  Define the type............................................24
+   11.2.  Post the type definition...................................25
+   11.3.  Allow a comment period.....................................25
+   11.4.  Submit the type for approval...............................25
+   12.  Type Change Control..........................................25
+   13.  Registration of new parameters...............................26
+   13.1.  Define the parameter.......................................26
+   13.2.  Post the parameter definition..............................27
+   13.3.  Allow a comment period.....................................27
+   13.4.  Submit the parameter for approval..........................27
+   14.  Parameter Change Control.....................................28
+   15.  Registration of new value types..............................28
+   15.1.  Define the value type......................................28
+   15.2.  Post the value type definition.............................29
+   15.3.  Allow a comment period.....................................29
+   15.4.  Submit the value type for approval.........................29
+   16.  Security Considerations......................................30
+   17. Acknowledgements..............................................30
+   18. References....................................................30
+   19.  Authors' Addresses...........................................32
+   20. Full Copyright Statement......................................33
+
+3.  Need for a MIME Directory 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 can
+   support creation and modification of the information as well.
+   Directory information is usually accessed far more often than it is
+   updated.  Directories can be local or global in scope. They can be
+   distributed or centralized. The information they contain can be
+   replicated, with weak or strong consistency requirements.
+
+   There are several situations in which users of Internet mail might
+   wish to exchange directory information: the email analogy 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-2045, RFC-2046] is
+   used increasingly by other protocols, most notably HTTP, it can also
+   be useful for these protocols 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, or to provide a rudimentary directory service over
+   HTTP.
+
+
+
+
+
+Howes, et. al.              Standards Track                     [Page 3]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+4.  Overview
+
+   The scheme defined here for representing directory information in a
+   MIME Content-Type has two parts. First, the text/directory Content-
+   Type is defined for use in holding directory information within a
+   single body part, for example name, title, or email address. In its
+   simplest form, the format uses a "type:value" approach, which should
+   be easily parseable by existing MIME implementations and
+   understandable by users. More complicated situations can be
+   represented also.  This document defines the general form the
+   information in the Content-Type should have, and the procedure by
+   which specific types and values (properties) for particular
+   applications can be defined. The framework is general enough to
+   handle information from any number of end directory services,
+   including LDAP [RFC-1777, RFC-1778], WHOIS++ [RFC-1835], and X.500
+   [X500].
+
+   Directory entries can include far more than just textual information.
+   Some such information (e.g., an image or sound) overlaps with
+   predefined MIME Content-Types. In these cases it can be desirable to
+   include the information in its well-known MIME format. This situation
+   is handled by using a multipart/related Content-Type as defined in
+   [RFC-2112].  The root component of this type is a text/directory body
+   part specifying any in-line information, and for information
+   contained in other Content-Types, the Content-IDs (in URI form) of
+   those parts.
+
+   In some applications, it can be useful to include a pointer (e.g, a
+   URI) to some directory information rather than the information
+   itself.  This document defines a general mechanism for accomplishing
+   this.
+
+5.  The text/directory Content-Type
+
+   The text/directory Content-Type is used to hold basic directory
+   information and URIs referencing other information, including other
+   MIME body parts holding supplementary or non-textual directory
+   information, such as an image or sound. It is defined as follows,
+   using the MIME media type registration template from [RFC-2048].
+
+   To: ietf-types@uninett.no
+   Subject: Registration of MIME media type text/directory
+
+5.1.  MIME media type name
+
+   MIME media type name: text
+
+
+
+
+
+Howes, et. al.              Standards Track                     [Page 4]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+5.2.  MIME subtype name
+
+   MIME subtype name: directory
+
+5.3.  Required parameters
+
+   Required parameters: charset
+
+   The "charset" parameter is as defined in [RFC-2046] for other body
+   parts.  It is used to identify the default character set used within
+   the body part.
+
+5.4.  Optional parameters
+
+   Optional parameters: profile
+
+   The "profile" parameter is used to convey the type(s) of entity(ies)
+   to which the directory information pertains and the likely set of
+   information associated with the entity(ies). It is intended only as a
+   guide to applications interpreting the information contained within
+   the body part. It 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 particular
+   profile definition, a text/directory content type can contain
+   arbitrary attribute/value pairs.
+
+   The value of the "profile" parameter is defined as follows.  Profile
+   names are case insensitive (i.e., the profile name "vCard" is the
+   same as "VCARD" and "vcard" and "vcArD").
+
+         profile = x-name / iana-token
+
+         x-name = "x-" 1*(ALPHA / DIGIT / "-")
+             ; Names beginning with "x-" or "X-" are
+             ; reserved for experimental use not intended for released
+             ; products, or for use in bilateral agreements.
+
+         iana-token = <a publicly-defined extension token, registered
+                        with IANA, as specified in Section 9 of this
+                        document>
+
+5.5.  Encoding considerations
+
+   The default encoding is 8bit. Otherwise, as specified by the
+   Content-Transfer-Encoding header field.
+
+
+
+
+
+
+Howes, et. al.              Standards Track                     [Page 5]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+5.6.  Security considerations
+
+   Directory information can be public or it can be protected from
+   unauthorized access by the directory service in which it resides.
+   Once the information leaves its native service, there can be no
+   guarantee that the same care will be taken by all services handling
+   the information.  Furthermore, this specification defines no access
+   control mechanism by which information can be protected, or by which
+   access control information can be conveyed.  Note that the integrity
+   and privacy of a text/directory body part can be protected by
+   enclosing it within an appropriate MIME-based security mechanism.
+
+5.7.  Interoperability considerations
+
+   In order to make sense of directory information, applications must
+   share a common understanding of the types of information contained
+   within the Content-Type (the directory schema).  This schema
+   information is not defined in this document, but rather in companion
+   documents (e.g., [MIME-VCARD]) that follow the requirements specified
+   in this document, or in bilateral agreements between communicating
+   parties.
+
+5.8.  Published specification
+
+   The text/directory Content-Type contains directory information,
+   typically pertaining to a single directory entity or group of
+   entities.  The content consists of one or more lines in the format
+   given below.
+
+5.8.1.  Line delimiting and folding
+
+   Individual lines within the MIME text/directory Content Type body are
+   delimited by the [RFC-822] line break, which is a CRLF sequence
+   (ASCII decimal 13, followed by ASCII decimal 10). Long logical lines
+   of text can be split into a multiple-physical-line representation
+   using the following folding technique.
+
+   A logical line MAY be continued on the next physical line anywhere
+   between two characters by inserting a CRLF immediately followed by a
+   single white space character (space, ASCII decimal 32, or horizontal
+   tab, ASCII decimal 9).  At least one character must be present on the
+   folded line. Any sequence of CRLF followed immediately by a single
+   white space character is ignored (removed) when processing the
+   content type.  For example the line:
+
+   DESCRIPTION:This is a long description that exists on a long line.
+
+   Can be represented as:
+
+
+
+Howes, et. al.              Standards Track                     [Page 6]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+   DESCRIPTION:This is a long description
+     that exists on a long line.
+
+   It could also be represented as:
+
+   DESCRIPTION:This is a long descrip
+    tion that exists o
+    n a long line.
+
+   The process of moving from this folded multiple-line representation
+   of a type definition to its single line representation is called
+   unfolding.  Unfolding is accomplished by regarding CRLF immediately
+   followed by a white space character (namely HTAB ASCII decimal 9 or
+   SPACE ASCII decimal 32) as equivalent to no characters at all (i.e.,
+   the CRLF and single white space character are removed).
+
+5.8.2.  ABNF content-type definition
+
+   The following ABNF uses the notation of RFC 2234, which also defines
+   CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT.  After the unfolding of
+   any folded lines as described above, the syntax for a line of this
+   content type is as follows:
+
+   contentline  = [group "."] name *(";" param) ":" value CRLF
+      ; When parsing a content line, folded lines MUST first
+      ; be unfolded according to the unfolding procedure
+      ; described above.
+      ; When generating a content line, lines longer than 75
+      ; characters SHOULD be folded according to the folding
+      ; procedure described above.
+
+   group        = 1*(ALPHA / DIGIT / "-")
+
+   name         = x-name / iana-token
+
+   iana-token   = 1*(ALPHA / DIGIT / "-")
+      ; identifier registered with IANA
+
+   x-name       = "x-" 1*(ALPHA / DIGIT / "-")
+      ; Names that begin with "x-" or "X-" are
+      ; reserved for experimental use, not intended for released
+      ; products, or for use in bilateral agreements.
+
+   param        = param-name "=" param-value *("," param-value)
+
+   param-name   = x-name / iana-token
+
+   param-value  = ptext / quoted-string
+
+
+
+Howes, et. al.              Standards Track                     [Page 7]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+   ptext  = *SAFE-CHAR
+
+   value = *VALUE-CHAR
+         / valuespec      ; valuespec defined in section 5.8.4
+
+   quoted-string = DQUOTE *QSAFE-CHAR DQUOTE
+
+   NON-ASCII    = %x80-FF
+      ; use restricted by charset parameter
+      ; on outer MIME object (UTF-8 preferred)
+
+   QSAFE-CHAR   = WSP / %x21 / %x23-7E / NON-ASCII
+      ; Any character except CTLs, DQUOTE
+
+   SAFE-CHAR    = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-ASCII
+      ; Any character except CTLs, DQUOTE, ";", ":", ","
+
+   VALUE-CHAR   = WSP / VCHAR / NON-ASCII
+      ; any textual character
+
+   A line that begins with a white space character is a continuation of
+   the previous line, as described above. The white space character and
+   immediately preceeding CRLF should be discarded when reconstructing
+   the original line. Note that this line-folding convention differs
+   from that found in RFC 822, in that the sequence <CRLF><WSP> found
+   anywhere in the content indicates a continued line and should be
+   removed.
+
+   Various type names and the format of the corresponding values are
+   defined as specified in Section 11.  Specifications MAY impose
+   ordering on the type constructs within a body part, though none is
+   required by default.  The various x-name constructs are used for
+   bilaterally-agreed upon type names, parameter names and parameter
+   values, or for use in experimental settings.
+
+   Type names and parameter names are case insensitive (e.g., the type
+   name "fn" is the same as "FN" and "Fn"). Parameter values MAY be case
+   sensitive or case insensitive, depending on their definition.
+
+   The group construct is used to group related attributes together.
+   The group name is a syntactic convention used to indicate that all
+   type names prefaced with the same group name SHOULD be grouped
+   together when displayed by an application. It has no other
+   significance.  Implementations that do not understand or support
+   grouping MAY simply strip off any text before a "." to the left of
+   the type name and present the types and values as normal.
+
+
+
+
+
+Howes, et. al.              Standards Track                     [Page 8]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+   Each attribute defined in the text/directory body MAY have multiple
+   values, if allowed in the definition of the profile in which the
+   attribute is used. The general rule for encoding multi-valued items
+   is to simply create a new content line for each value (including the
+   type name).  However, it should be noted that some value types
+   support encoding multiple values in a single content line by
+   separating the values with a comma ",".  This approach has been taken
+   for several of the content types defined below (date, time, integer,
+   float), for space-saving reasons.
+
+5.8.3.  Pre-defined Parameters
+
+   The following parameters and value types are defined for general use.
+
+         predefined-param = encodingparm
+                          / valuetypeparm
+                          / languageparm
+                          / contextparm
+
+         encodingparm = "encoding" "=" encodingtype
+
+         encodingtype = "b"       ; from RFC 2047
+                    / iana-token  ; registered as described in
+                                  ; section 15 of this document
+
+         valuetypeparm = "value" "=" valuetype
+
+         valuetype = "uri"        ; genericurl from secion 5 of RFC 1738
+                    / "text"
+                    / "date"
+                    / "time"
+                    / "date-time" ; date time
+                    / "integer"
+                    / "boolean"
+                    / "float"
+                    / x-name
+                    / iana-token  ; registered as described in
+                                  ; section 15 of this document
+
+         languageparm = "language" "=" Language-Tag
+             ; Language-Tag is defined in section 2 of RFC 1766
+
+         contextparm = "context" "=" context
+
+         context = x-name
+                 / iana-token
+
+
+
+
+
+Howes, et. al.              Standards Track                     [Page 9]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+   The "language" type parameter is used to identify data in multiple
+   languages.  There is no concept of "default" language, except as
+   specified by any "Content-Language" MIME header parameter that is
+   present.  The value of the "language" type parameter is a language
+   tag as defined in Section 2 of [RFC-1766].
+
+   The "context" type parameter is used to identify a context (e.g., a
+   protocol) used in interpreting the value. This is used, for example,
+   in the "source" type, defined below.
+
+   The "encoding" type parameter is used to specify an alternate
+   encoding for a value.  If the value contains a CRLF, it must be
+   encoded, since CRLF is used to separate lines in the content-type
+   itself.  Currently, only the "b" encoding is supported.
+
+   The "b" encoding can also be useful for binary values that are mixed
+   with other text information in the body part (e.g., a certificate).
+   Using a per-value "b" encoding in this case leaves the other
+   information in a more readable form. The encoded base 64 value can be
+   split across multiple physical lines in the content type by using the
+   line folding technique described above.
+
+   The Content-Transfer-Encoding header field is used to specify the
+   encoding used for the body part as a whole. The "encoding" type
+   parameter is used to specify an encoding for a particular value
+   (e.g., a certificate).  In this case, the Content-Transfer-Encoding
+   header might specify "8bit", while the one certificate value might
+   specify an encoding of "b" via an "encoding=b" type parameter.
+
+   The Content-Transfer-Encoding and the encodings of individual types
+   given by the "encoding" type parameter are independent of one
+   another.  When encoding a text/directory body part for transmission,
+   individual type encodings are performed first, then the entire body
+   part is encoded according to the Content-Transfer-Encoding.  When
+   decoding a text/directory body part, the Content-Transfer-Encoding is
+   decoded first, and then any individual types with an "encoding" type
+   parameter are decoded.
+
+   The "value" parameter is optional, and is used to identify the value
+   type (data type) and format of the value.  The use of these
+   predefined formats is encouraged even if the value parameter is not
+   explicity used.  By defining a standard set of value types and their
+   formats, existing parsing and processing code can be leveraged.
+
+   Including the value type explicitly 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 value types for all of the items for which it is
+
+
+
+Howes, et. al.              Standards Track                    [Page 10]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+   searching.  Because the value type is explicit in the definition, the
+   search engine could look for dates in any item type and provide
+   results that can still be interpreted.
+
+5.8.4.  Pre-defined Value Types
+
+   The format for values corresponding to the predefined valuetype
+   specifications given above are defined.
+
+   valuespec =  text-list
+              / genericurl       ; from section 5 of RFC 1738
+              / date-list
+              / time-list
+              / date-time-list
+              / boolean
+              / integer-list
+              / float-list
+              / iana-valuespec
+
+   text-list = *TEXT-LIST-CHAR *("," *TEXT-LIST-CHAR)
+
+   TEXT-LIST-CHAR = "\\" / "\," / "\n"
+                  / <any VALUE-CHAR except , or \ or newline>
+       ; Backslashes, newlines, and commas must be encoded.
+       ; \n or \N can be used to encode a newline.
+
+   date-list = date *("," date)
+
+   time-list = time *("," time)
+
+   date-time-list = date "T" time *("," date "T" time)
+
+   boolean = "TRUE" / "FALSE"
+
+   integer-list = integer *("," integer)
+
+   integer = [sign] 1*DIGIT
+
+   float-list = float *("," float)
+
+   float = [sign] 1*DIGIT ["." 1*DIGIT]
+
+   sign = "+" / "-"
+
+   date = date-fullyear ["-"] date-month ["-"] date-mday
+
+   date-fullyear = 4 DIGIT
+
+
+
+
+Howes, et. al.              Standards Track                    [Page 11]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+   date-month = 2 DIGIT     ;01-12
+
+   date-mday = 2 DIGIT      ;01-28, 01-29, 01-30, 01-31
+                            ;based on month/year
+
+   time = time-hour [":"] time-minute [":"] time-second [time-secfrac]
+           [time-zone]
+
+   time-hour = 2 DIGIT      ;00-23
+
+   time-minute = 2 DIGIT    ;00-59
+
+   time-second = 2 DIGIT    ;00-60 (leap second)
+
+   time-secfrac = "," 1*DIGIT
+
+   time-zone = "Z" / time-numzone
+
+   time-numzome = sign time-hour [":"] time-minute
+
+   iana-valuespec = <a publicly-defined valuetype format, registered
+                     with IANA, as defined in section 15 of this
+                     document>
+
+   Some specific notes on the value types and formats:
+
+   "text": The "text" value type should be used to identify values that
+   contain human-readable text. The character set and language in which
+   the text is represented is controlled by the charset content-header
+   and the language type parameter and content-header.
+
+         Examples for "text":
+                    this is a text value
+                    this is one value,this is another
+                    this is a single value\, with a comma encoded
+
+   A formatted text line break in a text value type MUST be represented
+   as the character sequence backslash (ASCII decimal 92) followed by a
+   Latin small letter n (ASCII decimal 110) or a Latin capital letter N
+   (ASCII decimal 78), that is "\n" or "\N".
+
+   For example a multiple line DESCRIPTION value of:
+
+   Mythical Manager
+   Hyjinx Software Division
+   BabsCo, Inc.
+
+   could be represented as:
+
+
+
+Howes, et. al.              Standards Track                    [Page 12]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+   DESCRIPTION:Mythical Manager\nHyjinx Software Division\n
+    BabsCo\, Inc.\n
+
+   demonstrating the \n literal formatted line break technique, the
+   CRLF-followed-by-space line folding technique, and the backslash
+   escape technique.
+
+   "uri": The "uri" value type should be used to identify values that
+   are referenced by a URI (including a Content-ID URI), instead of
+   encoded in-line. These value references might be used if the value is
+   too large, or otherwise undesirable to include directly. The format
+   for the URI is as defined in RFC 1738.
+
+       Examples for "uri":
+                  http://www.foobar.com/my/picture.jpg
+                  ldap://ldap.foobar.com/cn=babs%20jensen
+
+   "date", "time", and "date-time": Each of these value types is based
+   on a subset of the definitions in ISO 8601 standard. Profiles MAY
+   place further restrictions on "date" and "time" values.  Multiple
+   "date" and "time" values can be specified using the comma-separated
+   notation, unless restricted by a profile.
+
+       Examples for "date":
+                   1985-04-12
+                   1996-08-05,1996-11-11
+                   19850412
+
+       Examples for "time":
+                   10:22:00
+                   102200
+                   10:22:00.33
+                   10:22:00.33Z
+                   10:22:33,11:22:00
+                   10:22:00-08:00
+
+       Examples for "date-time":
+                   1996-10-22T14:00:00Z
+                   1996-08-11T12:34:56Z
+                   19960811T123456Z
+                   1996-10-22T14:00:00Z,1996-08-11T12:34:56Z
+
+   "boolean": The "boolean" value type is used to express boolen values.
+   These values are case insensitive.
+
+       Examples: TRUE
+                 false
+                 True
+
+
+
+Howes, et. al.              Standards Track                    [Page 13]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+   "integer": The "integer" value type is used to express signed
+   integers in decimal format. If sign is not specified, the value is
+   assumed positive "+". Multiple "integer" values can be specified
+   using the comma-separated notation, unless restricted by a profile.
+
+       Examples: 1234567890
+                 -1234556790
+                 +1234556790,432109876
+
+   "float": The "float" value type is used to express real numbers.  If
+   sign is not specified, the value is assumed positive "+". Multiple
+   "float" values can be specified using the comma-separated notation,
+   unless restricted by a profile.
+
+       Examples: 20.30
+                 1000000.0000001
+                 1.333,3.14
+
+5.9.  Applications which use this media type
+
+   Applications which use this media type: Various
+
+5.10.  Additional information
+
+   Additional information: None
+
+5.11.  Person & email address to contact for further information
+
+   Tim Howes
+   Netscape Communications Corp.
+   501 East Middlefield Rd.
+   Mountain View, CA 94041
+   USA
+   howes@netscape.com
+   +1 415 937 3419
+
+5.12.  Intended usage
+
+   Intended usage: COMMON
+
+
+
+
+
+
+
+
+
+
+
+
+Howes, et. al.              Standards Track                    [Page 14]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+5.13.  Author/Change controller
+
+   Tim Howes
+   Netscape Communications Corp.
+   501 East Middlefield Rd.
+   Mountain View, CA 94041
+   USA
+   howes@netscape.com
+   +1 415 937 3419
+
+   Mark Smith
+   Netscape Communications Corp.
+   501 East Middlefield Rd.
+   Mountain View, CA 94041
+   USA
+   mcs@netscape.com
+   +1 415 937 3477
+
+   Frank Dawson
+   Lotus Development Corporation
+   6544 Battleford Drive
+   Raleigh, NC 27613-3502
+   USA
+   frank_dawson@lotus.com
+   +1-919-676-9515
+
+6.  Predefined Types
+
+   The following types are generally useful regardless of the profile
+   being carried and are defined below using the text/directory MIME
+   type registration template defined in Section 11.1 of this document.
+   These types MAY be included in any profile, unless explicitly
+   forbidden in the profile definition.
+
+6.1.  SOURCE Type Definition
+
+   To: ietf-mime-direct@imc.org
+   Subject: Registration of text/directory MIME type SOURCE
+
+   Type name: SOURCE
+
+   Type purpose: To identify the source of directory information
+   contained in the content type.
+
+   Type encoding: 8bit
+
+   Type valuetype: uri
+
+
+
+
+Howes, et. al.              Standards Track                    [Page 15]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+   Type special notes: The SOURCE type is used to provide the means by
+   which applications knowledgable in the given directory service
+   protocol can obtain additional or more up-to-date information from
+   the directory service. It contains a URI as defined in [RFC-1738]
+   and/or other information referencing the directory entity or entities
+   to which the information pertains. When directory information is
+   available from more than one source, the sending entity can pick what
+   it considers to be the best source, or multiple SOURCE types can be
+   included. The interpretation of the value for a SOURCE type can
+   depend on the setting of the CONTEXT type parameter. The value of the
+   CONTEXT type parameter MUST be compatible with the value of the uri
+   prefix.
+
+   Type example:
+           SOURCE;CONTEXT=LDAP:ldap://ldap.host/cn=Babs%20Jensen,
+            %20o=Babsco,%20c=US
+
+6.2.  NAME Type Definition
+
+   To: ietf-mime-direct@imc.org
+   Subject: Registration of text/directory MIME type NAME
+
+   Type name: NAME
+
+   Type purpose: To identify the displayable name of the directory
+   entity to which information in the content type pertains.
+
+   Type encoding: 8bit
+
+   Type valuetype: text
+
+   Type special notes: The NAME type is used to convey the display name
+   of the entity to which the directory information pertains.
+
+   Type example:
+           NAME:Babs Jensen's Contact Information
+
+6.3.  PROFILE Type Definition
+
+   To: ietf-mime-direct@imc.org
+   Subject: Registration of text/directory MIME type PROFILE
+
+   Type name: PROFILE
+
+   Type purpose: To identify the type of directory entity to which
+   information in the content type pertains.
+
+   Type encoding: 8bit
+
+
+
+Howes, et. al.              Standards Track                    [Page 16]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+   Type valuetype: A profile name, registered as described in Section 9
+   of this document or bilaterally agreed upon as described in Section
+   5.
+
+   Type special notes: The PROFILE type is used to convey the type of
+   the entity to which the directory information in the rest of the body
+   part pertains. It should be the same as the "profile" header
+   parameter, if present.
+
+   Type example:
+           PROFILE:vCard
+
+6.4.  BEGIN Type Definition
+
+   To: ietf-mime-direct@imc.org
+   Subject: Registration of text/directory MIME type BEGIN
+
+   Type name: BEGIN
+
+   Type purpose: To denote the beginning of a syntactic entity within a
+   text/directory content-type.
+
+   Type encoding: 8bit
+
+   Type valuetype: text, containing a profile name, registered as
+   described in Section 9 of this document or bilaterally-agreed upon as
+   described in Section 5.
+
+   Type special notes: The BEGIN type is used in conjunction with the
+   END type to delimit a profile containing a related set of properties
+   within an text/directory content-type. This construct can be used
+   instead of or in addition to wrapping separate sets of information
+   inside additional MIME headers. It is provided for applications that
+   wish to define content that can contain multiple entities within the
+   same text/directory content-type or to define content that can be
+   identifiable outside of a MIME environment.
+
+   Type example:
+           BEGIN:VCARD
+
+6.5.  END Type Definition
+
+   To: ietf-mime-direct@imc.org
+   Subject: Registration of text/directory MIME type END
+
+   Type name: END
+
+
+
+
+
+Howes, et. al.              Standards Track                    [Page 17]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+   Type purpose: To denote the end of a syntactic entity within a
+   text/directory content-type.
+
+   Type encoding: 8bit
+
+   Type valuetype: text, containing a profile name, registered as
+   described in Section 9 of this document or bilaterally-agreed upon as
+   described in Section 5.
+
+   Type special notes: The END type is used in conjunction with the
+   BEGIN type to delimit a profile containing a related set of
+   properties within an text/directory content-type.  This construct can
+   be used instead of or in addition to wrapping separate sets of
+   information inside additional MIME headers. It is provided for
+   applications that wish to define content that can contain multiple
+   entities within the same text/directory content-type or to define
+   content that can be identifiable outside of a MIME environment.
+
+   Type example:
+           END: VCARD
+
+7.  Use of the multipart/related Content-Type
+
+   The multipart/related Content-Type can be used to hold directory
+   information comprised of both text and non-text information or
+   directory information that already has a natural MIME representation.
+   The root body part within the multipart/related body part is
+   specified as defined in [RFC-2112] 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 "text/directory".  This part
+   holds inline information and makes reference to subsequent body parts
+   holding additional text or non-text directory information via their
+   Content-ID URIs as explained in Section 5.
+
+   The body parts referred to do not have to be in any particular order,
+   except as noted above for the root body part.
+
+8.  Examples
+
+   The following examples are for illustrative purposes only and are not
+   part of the definition.
+
+
+
+
+
+
+
+
+
+
+Howes, et. al.              Standards Track                    [Page 18]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+8.1.  Example 1
+
+   The first example illustrates simple use of the text/directory
+   Content-Type.  Note that no "profile" parameter is given, so an
+   application may not know what kind of directory entity the
+   information applies to.  Note also the use of both hypothetical
+   official and bilaterally agreed upon types.
+
+      From: Whomever@wherever.com
+      To: Someone@somewhere.com
+      Subject: whatever
+      MIME-Version: 1.0
+      Message-ID: <id1@host.net>
+      Content-Type: text/directory
+      Content-ID: <id2@host.com>
+
+      cn:Babs Jensen
+      cn:Barbara J Jensen
+      sn:Jensen
+      email:babs@umich.edu
+      phone:+1 313 747-4454
+      x-id:1234567890
+
+8.2.  Example 2
+
+   The next example illustrates the use of the Quoted-Printable transfer
+   encoding defined in [RFC 2045] to include non-ASCII character in some
+   of the information returned, and the use of the optional "name" and
+   "source" types. It also illustrates the use of an "encoding" type
+   parameter to encode a certificate value in "b".  A "vCard" profile
+   [MIME- VCARD] is used for the example.
+
+Content-Type: text/directory;
+        charset="iso-8859-1";
+        profile="vCard"
+Content-ID: <id3@host.com>
+Content-Transfer-Encoding: Quoted-Printable
+
+begin:VCARD
+source:ldap://cn=3Dbjorn%20Jensen, o=3Duniversity%20of%20Michigan, c=3DUS
+name:Bjorn Jensen
+fn:Bj=F8rn Jensen
+n:Jensen;Bj=F8rn
+email;type=3Dinternet:bjorn@umich.edu
+tel;type=3Dwork,voice,msg:+1 313 747-4454
+key;type=3Dx509;encoding=3DB:dGhpcyBjb3VsZCBiZSAKbXkgY2VydGlmaWNhdGUK
+end:VCARD
+
+
+
+
+Howes, et. al.              Standards Track                    [Page 19]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+8.3.  Example 3
+
+   The next example illustrates the use of multi-valued type parameters,
+   the "language" type parameter, the "value" type parameter, folding of
+   long lines, the \n encoding for formatted lines, attribute grouping,
+   and the inline "b" encoding.  A "vCard" profile [MIME-VCARD] is used
+   for the example.
+
+Content-Type: text/directory; profile="vcard"; charset=iso-8859-1
+Content-ID: <id3@host.com>
+Content-Transfer-Encoding: Quoted-Printable
+
+begin:vcard
+source:ldap://cn=3DMeister%20Berger,o=3DUniversitaet%20Goerlitz,c=3DDE
+name:Meister Berger
+fn:Meister Berger
+n:Berger;Meister
+bday;value=3Ddate:1963-09-21
+o:Universit=E6t G=F6rlitz
+title:Mayor
+title;language=3Dde;value=3Dtext:Burgermeister
+note:The Mayor of the great city of
+  Goerlitz in the great country of Germany.
+email;internet:mb@goerlitz.de
+home.tel;type=3Dfax,voice,msg:+49 3581 123456
+home.label:Hufenshlagel 1234\n
+ 02828 Goerlitz\n
+ Deutschland
+key;type=3DX509;encoding=3Db:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQ
+ AwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zI
+ ENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQD
+ ExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNjE5NDc1OVoXDTk3MTIwMzE5NDc
+ 1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYDVQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW
+ 9ucyBDb3JwLjEYMBYGA1UEAxMPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBF
+ hJob3dlc0BuZXRzY2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqG
+ SIb3DQEBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2dXc
+ oX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MBEGCWCGSAGG+E
+ IBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9
+ w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIPmx93HGp0Kgyx1jIVMyNgsemeAwBM+M
+ SlhMfcpbTrONwNjZYW8vJDSoi//yrZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8V
+ UMk1U7jt8LYpo4YULU7UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ=3D=3D
+end:vcard
+
+
+
+
+
+
+
+
+
+Howes, et. al.              Standards Track                    [Page 20]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+8.4.  Example 4
+
+   The final example illustrates the use of the multipart/related
+   Content-Type to include non-textual directory data via the "uri"
+   encoding to refer to other body parts within the same message, or to
+   external values.  Note that no "profile" parameter is given, so an
+   application may not know what kind of directory entity the
+   information applies to.  Note also the use of both hypothetical
+   official and bilaterally agreed upon types.
+
+Content-Type: multipart/related;
+        boundary=woof;
+        type="text/directory";
+        start="<id5@host.com>"
+Content-ID: <id4@host.com>
+
+--woof
+Content-Type: text/directory; charset="iso-8859-1"
+Content-ID: <id5@host.com>
+Content-Transfer-Encoding: Quoted-Printable
+
+source:ldap://cn=3DBjorn%20Jensen,o=3DUniversity%20of%20Michigan,c=3DUS
+cn:Bj=F8rn Jensen
+sn:Jensen
+email:bjorn@umich.edu
+image;value=3Duri:cid:id6@host.com
+image;value=3Duri;format=3Djpeg:ftp://some.host/some/path.jpg
+sound;value=3Duri:cid:id7@host.com
+phone:+1 313 747-4454
+
+--woof
+Content-Type: image/jpeg
+Content-ID: <id6@host.com>
+
+<...image data...>
+
+--woof
+Content-Type: message/external-body;
+        name="myvoice.au";
+        site="myhost.com";
+        access-type=ANON-FTP;
+        directory="pub/myname";
+        mode="image"
+
+Content-Type: audio/basic
+Content-ID: <id7@host.com>
+
+--woof--
+
+
+
+Howes, et. al.              Standards Track                    [Page 21]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+9.  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 can 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.
+
+9.1.  Define the profile
+
+   A profile is defined by completing the following template.
+
+      To: ietf-mime-direct@imc.org
+      Subject: Registration of text/directory MIME profile XXX
+
+      Profile name:
+
+      Profile purpose:
+
+      Profile types:
+
+      Profile special notes (optional):
+
+      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
+   text/directory MIME Content-Type "profile" header parameter, or the
+   predefined "profile" type name.
+
+   Profile purpose: The purpose of the profile (e.g., to represent
+   information about people, printers, documents, etc.). Give a short
+   but clear description.
+
+   Profile types: The list of types associated with the profile.  This
+   list of types is to be expected but not required in the profile,
+   unless otherwise noted in the profile definition.  Other types not
+   mentioned in the profile definition MAY also be present.  Note that
+   any new types referenced by the profile MUST be defined separately as
+   described in Section 10.
+
+
+
+
+
+Howes, et. al.              Standards Track                    [Page 22]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+   Profile special notes: Any special notes about the profile, how it is
+   to be used, etc. This section of the template can also be used to
+   define an ordering on the types that appear in the Content-Type, if
+   such an ordering is required.
+
+9.2.  Post the profile definition
+
+   The profile description must be posted to the new profile discussion
+   list, ietf-mime-direct@imc.org
+
+9.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.
+
+9.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 can either accept or reject the profile registration. An accepted
+   registration is 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 can be appealed by the proposer to the
+   IESG, or the objections raised can be addressed by the proposer and
+   the profile resubmitted.
+
+10.  Profile Change Control
+
+   Existing profiles can be changed using the same process by which they
+   were registered.
+
+         Define the change
+
+         Post the change
+
+         Allow a comment period
+
+         Submit the changed profile for approval
+
+
+
+
+
+
+
+Howes, et. al.              Standards Track                    [Page 23]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+   Note that the original author or any other interested party can
+   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 can 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.
+
+11.  Registration of new types
+
+   This section defines procedures by which new types are registered
+   with the IANA.  Note that non-IANA types can be used by bilateral
+   agreement, provided the associated types names follow the "X-"
+   convention defined above.
+
+   The procedures defined here are designed to allow public comment and
+   review of new types, while posing only a small impediment to the
+   definition of new types.
+
+   Registration of a new type is accomplished by the following steps.
+
+11.1.  Define the type
+
+   A type is defined by completing the following template.
+
+      To: ietf-mime-direct@imc.org
+      Subject: Registration of text/directory MIME type XXX
+
+      Type name:
+
+      Type purpose:
+
+      Type encoding:
+
+      Type valuetype:
+
+      Type special notes (optional):
+
+      Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
+
+   The meaning of each field in the template is as follows.
+
+   Type name: The name of the type, as it will appear in the body of an
+   text/directory MIME Content-Type "type: value" line to the left of
+   the colon ":".
+
+
+
+
+Howes, et. al.              Standards Track                    [Page 24]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+   Type purpose: The purpose of the type (e.g., to represent a name,
+   postal address, IP address, etc.). Give a short but clear
+   description.
+
+   Type encoding: The default encoding a value of the type must have in
+   the body of a text/directory MIME Content-Type.
+
+   Type valuetype: The format a value of the type must have in the body
+   of a text/directory MIME Content-Type. This description must be
+   precise and must not violate the general encoding rules defined in
+   section 5 of this document.
+
+   Type special notes: Any special notes about the type, how it is to be
+   used, etc.
+
+11.2.  Post the type definition
+
+   The type description must be posted to the new type discussion list,
+   ietf-mime-direct@imc.org
+
+11.3.  Allow a comment period
+
+   Discussion on the new type must be allowed to take place on the list
+   for a minimum of two weeks. Consensus must be reached on the type
+   before proceeding to step 4.
+
+11.4.  Submit the type for approval
+
+   Once the two-week comment period has elapsed, and the proposer is
+   convinced consensus has been reached on the type, the registration
+   application should be submitted to the Profile Reviewer for approval.
+   The Profile Reviewer is appointed by the Application Area Directors
+   and can either accept or reject the type registration. An accepted
+   registration is passed on by the Profile Reviewer to the IANA for
+   inclusion in the official IANA profile registry. The registration can
+   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 type can be appealed by the proposer
+   to the IESG, or the objections raised can be addressed by the
+   proposer and the type resubmitted.
+
+
+
+
+
+
+
+
+
+
+Howes, et. al.              Standards Track                    [Page 25]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+12.  Type Change Control
+
+   Existing types can be changed using the same process by which they
+   were registered.
+
+         Define the change
+
+         Post the change
+
+         Allow a comment period
+
+         Submit the type for approval
+
+   Note that the original author or any other interested party can
+   propose a change to an existing type, but that such changes should
+   only be proposed when there are serious omissions or errors in the
+   published specification.  The Profile Reviewer can object to a change
+   if it is not backwards compatible, but is not required to do so.
+
+   Type definitions can never be deleted from the IANA registry, but
+   types which are nolonger believed to be useful can be declared
+   OBSOLETE by a change to their "intended use" field.
+
+13.  Registration of new parameters
+
+   This section defines procedures by which new parameters are
+   registered with the IANA and made available to the Internet
+   community. Note that non-IANA parameters can be used by bilateral
+   agreement, provided the associated parameters names follow the "X-"
+   convention defined above.
+
+   The procedures defined here are designed to allow public comment and
+   review of new parameters, while posing only a small impediment to the
+   definition of new parameters.
+
+   Registration of a new parameter is accomplished by the following
+   steps.
+
+13.1.  Define the parameter
+
+   A parameter is defined by completing the following template.
+
+      To: ietf-mime-direct@imc.org
+      Subject: Registration of text/directory MIME type parameter XXX
+
+      Parameter name:
+
+      Parameter purpose:
+
+
+
+Howes, et. al.              Standards Track                    [Page 26]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+      Parameter values:
+
+      Parameter special notes (optional):
+
+      Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
+
+   The explanation of what goes in each field in the template follows.
+
+   Parameter name: The name of the parameter as it will appear in the
+   text/directory MIME Content-Type.
+
+   Parameter purpose: The purpose of the parameter (e.g., to represent
+   the format of an image, type of a phone number, etc.). Give a short
+   but clear description. If defining a general paramemter like "format"
+   or "type" keep in mind that other applications might wish to extend
+   its use.
+
+   Parameter values: The list or description of values associated with
+   the parameter.
+
+   Parameter special notes: Any special notes about the parameter, how
+   it is to be used, etc.
+
+13.2.  Post the parameter definition
+
+   The parameter description must be posted to the new parameter
+   discussion list, ietf-mime-direct@imc.org
+
+13.3.  Allow a comment period
+
+   Discussion on the new parameter must be allowed to take place on the
+   list for a minimum of two weeks. Consensus must be reached on the
+   parameter before proceeding to step 4.
+
+13.4.  Submit the parameter for approval
+
+   Once the two-week comment period has elapsed, and the proposer is
+   convinced consensus has been reached on the parameter, the
+   registration application should be submitted to the Profile Reviewer
+   for approval.  The Profile Reviewer is appointed by the Application
+   Area Directors and can either accept or reject the parameter
+   registration.  An accepted registration is passed on by the Profile
+   Reviewer to the IANA for inclusion in the official IANA parameter
+   registry. The registration can 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 can be
+   appealed by the proposer to the IESG, or the objections raised can be
+
+
+
+Howes, et. al.              Standards Track                    [Page 27]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+   addressed by the proposer and the parameter registration resubmitted.
+
+14.  Parameter Change Control
+
+   Existing parameters can be changed using the same process by which
+   they were registered.
+
+         Define the change
+
+         Post the change
+
+         Allow a comment period
+
+         Submit the parameter for approval
+
+   Note that the original author or any other interested party can
+   propose a change to an existing parameter, but that such changes
+   should only be proposed when there are serious omissions or errors in
+   the published specification.  The Profile Reviewer can object to a
+   change if it is not backwards compatible, but is not required to do
+   so.
+
+   Parameter definitions can never be deleted from the IANA registry,
+   but parameters which are nolonger believed to be useful can be
+   declared OBSOLETE by a change to their "intended use" field.
+
+15.  Registration of new value types
+
+   This section defines procedures by which new value types are
+   registered with the IANA and made available to the Internet
+   community. Note that non-IANA value types can be used by bilateral
+   agreement, provided the associated value types names follow the "X-"
+   convention defined above.
+
+   The procedures defined here are designed to allow public comment and
+   review of new value types, while posing only a small impediment to
+   the definition of new value types.
+
+   Registration of a new value types is accomplished by the following
+   steps.
+
+15.1.  Define the value type
+
+   A value type is defined by completing the following template.
+
+      To: ietf-mime-direct@imc.org
+      Subject: Registration of text/directory MIME value type XXX
+
+
+
+
+Howes, et. al.              Standards Track                    [Page 28]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+      value type name:
+
+      value type purpose:
+
+      value type format:
+
+      value type special notes (optional):
+
+      Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
+
+   The explanation of what goes in each field in the template follows.
+
+   value type name: The name of the value type as it will appear in the
+   text/directory MIME Content-Type.
+
+   value type purpose: The purpose of the value type.  Give a short but
+   clear description.
+
+   value type format: The definition of the format for the value,
+   usually using ABNF grammar.
+
+   value type special notes: Any special notes about the value type, how
+   it is to be used, etc.
+
+15.2.  Post the value type definition
+
+   The value type description must be posted to the new value type
+   discussion list, ietf-mime-direct@imc.org
+
+15.3.  Allow a comment period
+
+   Discussion on the new value type must be allowed to take place on the
+   list for a minimum of two weeks.  Consensus must be reached before
+   proceeding to step 4.
+
+15.4.  Submit the value type for approval
+
+   Once the two-week comment period has elapsed, and the proposer is
+   convinced consensus has been reached on the value type, the
+   registration application should be submitted to the Profile Reviewer
+   for approval.  The Profile Reviewer is appointed by the Application
+   Area Directors and can either accept or reject the value type
+   registration.  An accepted registration should be passed on by the
+   Profile Reviewer to the IANA for inclusion in the official IANA value
+   type registry.  The registration can 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
+
+
+
+Howes, et. al.              Standards Track                    [Page 29]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+   profile can be appealed by the proposer to the IESG, or the
+   objections raised can be addressed by the proposer and the value type
+   registration resubmitted.
+
+16.  Security Considerations
+
+   Internet mail is subject to many well known security attacks,
+   including monitoring, replay, and forgery. Care should be taken by
+   any directory service in allowing information to leave the scope of
+   the service itself, where any access controls can no longer be
+   guaranteed.  Applications should also take care to display directory
+   data in a "safe" environment (e.g., PostScript-valued types).
+
+17.  Acknowledgements
+
+   The registration procedures defined here were shamelessly lifted from
+   the MIME registration RFC.
+
+   The many valuable comments contributed by members of the IETF ASID
+   working group are gratefully acknowledged, as are the contributions
+   of the Versit Consortium. Chris Newman was especially helpful in
+   navigating the intricacies of ABNF lore.
+
+18.  References
+
+   [RFC-1777]   Yeong, W., Howes, T., and S. Kille, "Lightweight
+                Directory Access Protocol", RFC 1777, March 1995.
+
+   [RFC-1778]   Howes, T., Kille, S., Yeong, W., and C. Robbins, "The
+                String Representation of Standard Attribute Syntaxes",
+                RFC 1778, March 1995.
+
+   [RFC-822]    Crocker, D., "Standard for the Format of ARPA Internet
+                Text Messages", STD 11, RFC 822, August 1982.
+
+   [RFC-2045]   Borenstein, N., and N. Freed, "Multipurpose Internet
+                Mail Extensions (MIME) Part One: Format of Internet
+                Message Bodies", RFC 2045, November 1996.
+
+   [RFC-2046]   Moore, K., "Multipurpose Internet Mail Extensions (MIME)
+                Part Two:  Media Types", RFC 2046, November 1996.
+
+   [RFC-2048]   Freed, N., Klensin, J., and J. Postel, "Multipurpose
+                Internet Mail Extensions (MIME) Part Four: Registration
+                Procedures", RFC 2048, November 1996.
+
+   [RFC-1766]   Alvestrand, H., "Tags for the Identification of
+                Languages", RFC 1766, March 1995.
+
+
+
+Howes, et. al.              Standards Track                    [Page 30]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+   [RFC-2112]   Levinson, E., "The MIME Multipart/Related Content-type",
+                RFC 2112, March 1997.
+
+   [X500]       "Information Processing Systems - Open Systems
+                Interconnection - The Directory: Overview of Concepts,
+                Models and Services", ISO/IEC JTC 1/SC21, International
+                Standard 9594-1, 1988.
+
+   [RFC-1835]   Deutsch, P., Schoultz, R., Faltstrom, P., and C. Weider,
+                "Architecture of the WHOIS++ service", RFC 1835, August
+                1995.
+
+   [RFC-1738]   Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
+                Resource Locators (URL)", RFC 1738, December 1994.
+
+   [MIME-VCARD] Dawson, F., and T. Howes, "VCard MIME Directory
+                Profile", RFC 2426, September 1998.
+
+   [VCARD]      Internet Mail Consortium, "vCard - The Electronic
+                Business Card", Version 2.1,
+                http://www.imc.com/pdi/vcard-21.txt, September, 1996.
+
+   [RFC-2119]   Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement  Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC-2234]   Crocker, D., and P. Overell, "Augmented BNF for Syntax
+                Specifications: ABNF", RFC 2234, November 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes, et. al.              Standards Track                    [Page 31]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+19.  Authors' Addresses
+
+   Tim Howes
+   Netscape Communications Corp.
+   501 East Middlefield Rd.
+   Mountain View, CA 94041
+   USA
+
+   Phone: +1.415.937.3419
+   EMail: howes@netscape.com
+
+
+   Mark Smith
+   Netscape Communications Corp.
+   501 East Middlefield Rd.
+   Mountain View, CA 94041
+   USA
+
+   Phone: +1.415.937.3477
+   EMail: mcs@netscape.com
+
+
+   Frank Dawson
+   Lotus Development Corporation
+   6544 Battleford Drive
+   Raleigh, NC 27613
+   USA
+
+   Phone: +1-919-676-9515
+   EMail: frank_dawson@lotus.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes, et. al.              Standards Track                    [Page 32]
+
+RFC 2425      MIME Content-Type for Directory Information September 1998
+
+
+20.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes, et. al.              Standards Track                    [Page 33]
+
diff --git a/addressbook/backend/ebook/docs/rfc2426.txt b/addressbook/backend/ebook/docs/rfc2426.txt
new file mode 100644
index 0000000000..a393a67c98
--- /dev/null
+++ b/addressbook/backend/ebook/docs/rfc2426.txt
@@ -0,0 +1,2355 @@
+
+
+
+
+
+
+Network Working Group                                         F. Dawson
+Request for Comments: 2426                Lotus Development Corporation
+Category: Standards Track                                      T. Howes
+                                                Netscape Communications
+                                                         September 1998
+
+
+                      vCard MIME Directory Profile
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Abstract
+
+   This memo defines the profile of the MIME Content-Type [MIME-DIR] for
+   directory information for a white-pages person object, based on a
+   vCard electronic business card. The profile definition is independent
+   of any particular directory service or protocol. The profile is
+   defined for representing and exchanging a variety of information
+   about an individual (e.g., formatted and structured name and delivery
+   addresses, email address, multiple telephone numbers, photograph,
+   logo, audio clips, etc.). The directory information used by this
+   profile is based on the attributes for the person object defined in
+   the X.520 and X.521 directory services recommendations. The profile
+   also provides the method for including a [VCARD] representation of a
+   white-pages directory entry within the MIME Content-Type defined by
+   the [MIME-DIR] document.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+
+
+
+
+
+
+
+
+
+
+Dawson & Howes              Standards Track                     [Page 1]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+Table of Contents
+
+   Overview.........................................................3
+   1. THE VCARD MIME DIRECTORY PROFILE REGISTRATION.................4
+   2. MIME DIRECTORY FEATURES.......................................5
+    2.1 PREDEFINED TYPE USAGE ......................................5
+     2.1.1 BEGIN and END Type ......................................5
+     2.1.2 NAME Type ...............................................5
+     2.1.3 PROFILE Type ............................................5
+     2.1.4 SOURCE Type .............................................5
+    2.2 PREDEFINED TYPE PARAMETER USAGE ............................6
+    2.3 PREDEFINED VALUE TYPE USAGE ................................6
+    2.4 EXTENSIONS TO THE PREDEFINED VALUE TYPES ...................6
+     2.4.1 BINARY ..................................................6
+     2.4.2 VCARD ...................................................6
+     2.4.3 PHONE-NUMBER ............................................7
+     2.4.4 UTC-OFFSET ..............................................7
+    2.5 STRUCTURED TYPE VALUES .....................................7
+    2.6 LINE DELIMITING AND FOLDING ................................8
+   3. VCARD PROFILE FEATURES........................................8
+    3.1 IDENTIFICATION TYPES .......................................8
+     3.1.1 FN Type Definition ......................................8
+     3.1.2 N Type Definition .......................................9
+     3.1.3 NICKNAME Type Definition ................................9
+     3.1.4 PHOTO Type Definition ..................................10
+     3.1.5 BDAY Type Definition ...................................11
+    3.2 DELIVERY ADDRESSING TYPES .................................11
+     3.2.1 ADR Type Definition ....................................11
+     3.2.2 LABEL Type Definition ..................................13
+    3.3 TELECOMMUNICATIONS ADDRESSING TYPES .......................13
+     3.3.1 TEL Type Definition ....................................14
+     3.3.2 EMAIL Type Definition ..................................15
+     3.3.3 MAILER Type Definition .................................15
+    3.4 GEOGRAPHICAL TYPES ........................................16
+     3.4.1 TZ Type Definition .....................................16
+     3.4.2 GEO Type Definition ....................................16
+    3.5 ORGANIZATIONAL TYPES ......................................17
+     3.5.1 TITLE Type Definition ..................................17
+     3.5.2 ROLE Type Definition ...................................18
+     3.5.3 LOGO Type Definition ...................................18
+     3.5.4 AGENT Type Definition ..................................19
+     3.5.5 ORG Type Definition ....................................20
+    3.6 EXPLANATORY TYPES .........................................20
+     3.6.1 CATEGORIES Type Definition .............................20
+     3.6.2 NOTE Type Definition ...................................21
+     3.6.3 PRODID Type Definition .................................21
+     3.6.4 REV Type Definition ....................................22
+     3.6.5 SORT-STRING Type Definition ............................22
+
+
+
+Dawson & Howes              Standards Track                     [Page 2]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+     3.6.6 SOUND Type Definition ..................................23
+     3.6.7 UID Type Definition ....................................24
+     3.6.8 URL Type Definition ....................................25
+     3.6.9 VERSION Type Definition ................................25
+    3.7 SECURITY TYPES ............................................25
+     3.7.1 CLASS Type Definition ..................................26
+     3.7.2 KEY Type Definition ....................................26
+    3.8 EXTENDED TYPES ............................................27
+   4. FORMAL GRAMMAR...............................................27
+   5. DIFFERENCES FROM VCARD V2.1..................................37
+   6. ACKNOWLEDGEMENTS.............................................39
+   7. AUTHORS' ADDRESSES...........................................39
+   8. SECURITY CONSIDERATIONS......................................39
+   9. REFERENCES...................................................40
+   10. FULL COPYRIGHT STATEMENT....................................42
+
+Overview
+
+   The [MIME-DIR] document defines a MIME Content-Type for holding
+   different kinds of directory information. The directory information
+   can be based on any of a number of directory schemas. This document
+   defines a [MIME-DIR] usage profile for conveying directory
+   information based on one such schema; that of the white-pages type of
+   person object.
+
+   The schema is based on the attributes for the person object defined
+   in the X.520 and X.521 directory services recommendations. The schema
+   has augmented the basic attributes defined in the X.500 series
+   recommendation in order to provide for an electronic representation
+   of the information commonly found on a paper business card. This
+   schema was first defined in the [VCARD] document. Hence, this [MIME-
+   DIR] profile is referred to as the vCard MIME Directory Profile.
+
+   A directory entry based on this usage profile can include traditional
+   directory, white-pages information such as the distinguished name
+   used to uniquely identify the entry, a formatted representation of
+   the name used for user-interface or presentation purposes, both the
+   structured and presentation form of the delivery address, various
+   telephone numbers and organizational information associated with the
+   entry. In addition, traditional paper business card information such
+   as an image of an organizational logo or identify photograph can be
+   included in this person object.
+
+   The vCard MIME Directory Profile also provides support for
+   representing other important information about the person associated
+   with the directory entry. For instance, the date of birth of the
+   person; an audio clip describing the pronunciation of the name
+   associated with the directory entry, or some other application of the
+
+
+
+Dawson & Howes              Standards Track                     [Page 3]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   digital sound; longitude and latitude geo-positioning information
+   related to the person associated with the directory entry; date and
+   time that the directory information was last updated; annotations
+   often written on a business card; Uniform Resource Locators (URL) for
+   a website; public key information. The profile also provides support
+   for non-standard extensions to the schema. This provides the
+   flexibility for implementations to augment the current capabilities
+   of the profile in a standardized way. More information about this
+   electronic business card format can be found in [VCARD].
+
+1.  The vCard Mime Directory Profile Registration
+
+   This profile is identified by the following [MIME-DIR] registration
+   template information. Subsequent sections define the profile
+   definition.
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME profile VCARD
+
+   Profile name: VCARD
+
+   Profile purpose: To hold person object or white-pages type of
+   directory information. The person schema captured in the directory
+   entries is that commonly found in an electronic business card.
+
+   Predefined MIME Directory value specifications used: uri, date,
+   date-time, float
+
+   New value specifications: This profile places further constraints on
+   the [MIME-DIR] text value specification. In addition, it adds a
+   binary, phone-number, utc-offset and vcard value specifications.
+
+   Predefined MIME Directory types used: SOURCE, NAME, PROFILE, BEGIN,
+   END.
+
+   Predefined MIME Directory parameters used: ENCODING, VALUE, CHARSET,
+   LANGUAGE, CONTEXT.
+
+   New types: FN, N, NICKNAME, PHOTO, BDAY, ADR, LABEL, TEL, EMAIL,
+   MAILER, TZ, GEO, TITLE, ROLE, LOGO, AGENT, ORG, CATEGORIES, NOTE,
+   PRODID, REV, SORT-STRING, SOUND, URL, UID, VERSION, CLASS, KEY
+
+   New parameters: TYPE
+
+   Profile special notes: The vCard object MUST contain the FN, N and
+   VERSION types. The type-grouping feature of [MIME-DIR] is supported
+   by this profile to group related vCard properties about a directory
+
+
+
+Dawson & Howes              Standards Track                     [Page 4]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   entry. For example, vCard properties describing WORK or HOME related
+   characteristics can be grouped with a unique group label.
+
+   The profile permits the use of non-standard types (i.e., those
+   identified with the prefix string "X-") as a flexible method for
+   implementations to extend the functionality currently defined within
+   this profile.
+
+2.  MIME Directory Features
+
+   The vCard MIME Directory Profile makes use of many of the features
+   defined by [MIME-DIR]. The following sections either clarify or
+   extend the content-type definition of [MIME-DIR].
+
+2.1 Predefined Type Usage
+
+   The vCard MIME Directory Profile uses the following predefined types
+   from [MIME-DIR].
+
+2.1.1 BEGIN and END Type
+
+   The content entity MUST begin with the BEGIN type with a value of
+   "VCARD". The content entity MUST end with the END type with a value
+   of "VCARD".
+
+2.1.2 NAME Type
+
+   If the NAME type is present, then its value is the displayable,
+   presentation text associated with the source for the vCard, as
+   specified in the SOURCE type.
+
+2.1.3 PROFILE Type
+
+   If the PROFILE type is present, then its value MUST be "VCARD".
+
+2.1.4 SOURCE Type
+
+   If the SOURCE type is present, then its value provides information
+   how to find the source for the vCard.
+
+
+
+
+
+
+
+
+
+
+
+
+Dawson & Howes              Standards Track                     [Page 5]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+2.2 Predefined Type Parameter Usage
+
+   The vCard MIME Directory Profile uses the following predefined type
+   parameters as defined by [MIME-DIR].
+
+        - LANGUAGE
+
+        - ENCODING
+
+        - VALUE
+
+2.3 Predefined VALUE Type Usage
+
+   The predefined data type values specified in [MIME-DIR] MUST NOT be
+   repeated in COMMA separated value lists except within the N,
+   NICKNAME, ADR and CATEGORIES value types.
+
+   The text value type defined in [MIME-DIR] is further restricted such
+   that any SEMI-COLON character (ASCII decimal 59) in the value MUST be
+   escaped with the BACKSLASH character (ASCII decimal 92).
+
+2.4 Extensions To The Predefined VALUE Types
+
+   The predefined data type values specified in [MIME-DIR] have been
+   extended by the vCard profile to include a number of value types that
+   are specific to this profile.
+
+2.4.1 BINARY
+
+   The "binary" value type specifies that the type value is inline,
+   encoded binary data. This value type can be specified in the PHOTO,
+   LOGO, SOUND, and KEY types.
+
+   If inline encoded binary data is specified, the ENCODING type
+   parameter MUST be used to specify the encoding format. The binary
+   data MUST be encoded using the "B" encoding format. Long lines of
+   encoded binary data SHOULD BE folded to 75 characters using the
+   folding method defined in [MIME-DIR].
+
+   The value type is defined by the following notation:
+
+   binary = <A "B" binary encoded string as defined by [RFC 2047].>
+
+2.4.2 VCARD
+
+   The "vcard" value type specifies that the type value is another
+   vCard. This value type can be specified in the AGENT type. The value
+   type is defined by this specification. Since each of the type
+
+
+
+Dawson & Howes              Standards Track                     [Page 6]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   declarations with in the vcard value type are being specified within
+   a text value themselves, they MUST be terminated with the backslash
+   escape sequence "\n" or "\N", instead of the normal newline character
+   sequence CRLF. In addition, any COMMA character (ASCII decimal 44),
+   SEMI-COLON character (ASCII decimal 59) and COLON character (ASCII
+   decimal 58) MUST be escaped with the BACKSLASH character (ASCII
+   decimal 92). For example, with the AGENT type a value would be
+   specified as:
+
+        AGENT:BEGIN:VCARD\nFN:Joe Friday\nTEL:+1-919-555-7878\n
+         TITLE:Area Administrator\, Assistant\n EMAIL\;TYPE=INTERN\n
+         ET:jfriday@host.com\nEND:VCARD\n
+
+2.4.3 PHONE-NUMBER
+
+   The "phone-number" value type specifies that the type value is a
+   telephone number. This value type can be specified in the TEL type.
+   The value type is a text value that has the special semantics of a
+   telephone number as defined in [CCITT E.163] and [CCITT X.121].
+
+2.4.4 UTC-OFFSET
+
+   The "utc-offset" value type specifies that the type value is a signed
+   offset from UTC. This value type can be specified in the TZ type.
+
+   The value type is an offset from Coordinated Universal Time (UTC). It
+   is specified as a positive or negative difference in units of hours
+   and minutes (e.g., +hh:mm). The time is specified as a 24-hour clock.
+   Hour values are from 00 to 23, and minute values are from 00 to 59.
+   Hour and minutes are 2-digits with high order zeroes required to
+   maintain digit count. The extended format for ISO 8601 UTC offsets
+   MUST be used. The extended format makes use of a colon character as a
+   separator of the hour and minute text fields.
+
+   The value is defined by the following notation:
+
+        time-hour       = 2DIGIT        ;00-23
+        time-minute     = 2DIGIT        ;00-59
+        utc-offset      = ("+" / "-") time-hour ":" time-minute
+
+2.5 Structured Type Values
+
+   Compound type values are delimited by a field delimiter, specified by
+   the SEMI-COLON character (ASCII decimal 59). A SEMI-COLON in a
+   component of a compound property value MUST be escaped with a
+   BACKSLASH character (ASCII decimal 92).
+
+
+
+
+
+Dawson & Howes              Standards Track                     [Page 7]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   Lists of values are delimited by a list delimiter, specified by the
+   COMMA character (ASCII decimal 44). A COMMA character in a value MUST
+   be escaped with a BACKSLASH character (ASCII decimal 92).
+
+   This profile supports the type grouping mechanism defined in [MIME-
+   DIR]. Grouping of related types is a useful technique to communicate
+   common semantics concerning the properties of a vCard.
+
+2.6 Line Delimiting and Folding
+
+   This profile supports the same line delimiting and folding methods
+   defined in [MIME-DIR]. Specifically, when parsing a content line,
+   folded lines must first be unfolded according to the unfolding
+   procedure described in [MIME-DIR]. After generating a content line,
+   lines longer than 75 characters SHOULD be folded according to the
+   folding procedure described in [MIME DIR].
+
+   Folding is done after any content encoding of a type value. Unfolding
+   is done before any decoding of a type value in a content line.
+
+3.  vCard Profile Features
+
+   The vCard MIME Directory Profile Type contains directory information,
+   typically pertaining to a single directory entry. The information is
+   described using an attribute schema that is tailored for capturing
+   personal contact information. The vCard can include attributes that
+   describe identification, delivery addressing, telecommunications
+   addressing, geographical, organizational, general explanatory and
+   security and access information about the particular object
+   associated with the vCard.
+
+3.1 Identification Types
+
+   These types are used in the vCard profile to capture information
+   associated with the identification and naming of the person or
+   resource associated with the vCard.
+
+3.1.1 FN Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type FN
+
+   Type name:FN
+
+   Type purpose: To specify the formatted text corresponding to the name
+   of the object the vCard represents.
+
+
+
+
+Dawson & Howes              Standards Track                     [Page 8]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   Type encoding: 8bit
+
+   Type value: A single text value.
+
+   Type special notes: This type is based on the semantics of the X.520
+   Common Name attribute. The property MUST be present in the vCard
+   object.
+
+   Type example:
+
+        FN:Mr. John Q. Public\, Esq.
+
+3.1.2 N Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type N
+
+   Type name: N
+
+   Type purpose: To specify the components of the name of the object the
+   vCard represents.
+
+   Type encoding: 8bit
+
+   Type value: A single structured text value. Each component can have
+   multiple values.
+
+   Type special note: The structured type value corresponds, in
+   sequence, to the Family Name, Given Name, Additional Names, Honorific
+   Prefixes, and Honorific Suffixes. The text components are separated
+   by the SEMI-COLON character (ASCII decimal 59). Individual text
+   components can include multiple text values (e.g., multiple
+   Additional Names) separated by the COMMA character (ASCII decimal
+   44). This type is based on the semantics of the X.520 individual name
+   attributes. The property MUST be present in the vCard object.
+
+   Type example:
+
+        N:Public;John;Quinlan;Mr.;Esq.
+
+        N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.
+
+3.1.3 NICKNAME Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type NICKNAME
+
+
+
+Dawson & Howes              Standards Track                     [Page 9]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   Type name: NICKNAME
+
+   Type purpose: To specify the text corresponding to the nickname of
+   the object the vCard represents.
+
+   Type encoding: 8bit
+
+   Type value: One or more text values separated by a COMMA character
+   (ASCII decimal 44).
+
+   Type special note: The nickname is the descriptive name given instead
+   of or in addition to the one belonging to a person, place, or thing.
+   It can also be used to specify a familiar form of a proper name
+   specified by the FN or N types.
+
+   Type example:
+
+        NICKNAME:Robbie
+
+        NICKNAME:Jim,Jimmie
+
+3.1.4 PHOTO Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type PHOTO
+
+   Type name: PHOTO
+
+   Type purpose: To specify an image or photograph information that
+   annotates some aspect of the object the vCard represents.
+
+   Type encoding: The encoding MUST be reset to "b" using the ENCODING
+   parameter in order to specify inline, encoded binary data. If the
+   value is referenced by a URI value, then the default encoding of 8bit
+   is used and no explicit ENCODING parameter is needed.
+
+   Type value: A single value. The default is binary value. It can also
+   be reset to uri value. The uri value can be used to specify a value
+   outside of this MIME entity.
+
+   Type special notes: The type can include the type parameter "TYPE" to
+   specify the graphic image format type. The TYPE parameter values MUST
+   be one of the IANA registered image formats or a non-standard image
+   format.
+
+
+
+
+
+
+Dawson & Howes              Standards Track                    [Page 10]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   Type example:
+
+        PHOTO;VALUE=uri:http://www.abc.com/pub/photos
+         /jqpublic.gif
+
+
+        PHOTO;ENCODING=b;TYPE=JPEG:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
+         AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
+         ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
+         <...remainder of "B" encoded binary data...>
+
+3.1.5 BDAY Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type BDAY
+
+   Type name: BDAY
+
+   Type purpose: To specify the birth date of the object the vCard
+   represents.
+
+   Type encoding: 8bit
+
+   Type value: The default is a single date value. It can also be reset
+   to a single date-time value.
+
+   Type examples:
+
+        BDAY:1996-04-15
+
+        BDAY:1953-10-15T23:10:00Z
+
+        BDAY:1987-09-27T08:30:00-06:00
+
+3.2 Delivery Addressing Types
+
+   These types are concerned with information related to the delivery
+   addressing or label for the vCard object.
+
+3.2.1 ADR Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type ADR
+
+   Type name: ADR
+
+
+
+
+Dawson & Howes              Standards Track                    [Page 11]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   Type purpose: To specify the components of the delivery address for
+   the vCard object.
+
+   Type encoding: 8bit
+
+   Type value: A single structured text value, separated by the
+   SEMI-COLON character (ASCII decimal 59).
+
+   Type special notes: The structured type value consists of a sequence
+   of address components. The component values MUST be specified in
+   their corresponding position. The structured type value corresponds,
+   in sequence, to the post office box; the extended address; the street
+   address; the locality (e.g., city); the region (e.g., state or
+   province); the postal code; the country name. When a component value
+   is missing, the associated component separator MUST still be
+   specified.
+
+   The text components are separated by the SEMI-COLON character (ASCII
+   decimal 59). Where it makes semantic sense, individual text
+   components can include multiple text values (e.g., a "street"
+   component with multiple lines) separated by the COMMA character
+   (ASCII decimal 44).
+
+   The type can include the type parameter "TYPE" to specify the
+   delivery address type. The TYPE parameter values can include "dom" to
+   indicate a domestic delivery address; "intl" to indicate an
+   international delivery address; "postal" to indicate a postal
+   delivery address; "parcel" to indicate a parcel delivery address;
+   "home" to indicate a delivery address for a residence; "work" to
+   indicate delivery address for a place of work; and "pref" to indicate
+   the preferred delivery address when more than one address is
+   specified. These type parameter values can be specified as a
+   parameter list (i.e., "TYPE=dom;TYPE=postal") or as a value list
+   (i.e., "TYPE=dom,postal"). This type is based on semantics of the
+   X.520 geographical and postal addressing attributes. The default is
+   "TYPE=intl,postal,parcel,work". The default can be overridden to some
+   other set of values by specifying one or more alternate values. For
+   example, the default can be reset to "TYPE=dom,postal,work,home" to
+   specify a domestic delivery address for postal delivery to a
+   residence that is also used for work.
+
+   Type example: In this example the post office box and the extended
+   address are absent.
+
+        ADR;TYPE=dom,home,postal,parcel:;;123 Main
+          Street;Any Town;CA;91921-1234
+
+
+
+
+
+Dawson & Howes              Standards Track                    [Page 12]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+3.2.2 LABEL Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type LABEL
+
+   Type name: LABEL
+
+   Type purpose: To specify the formatted text corresponding to delivery
+   address of the object the vCard represents.
+
+   Type encoding: 8bit
+
+   Type value: A single text value.
+
+   Type special notes: The type value is formatted text that can be used
+   to present a delivery address label for the vCard object. The type
+   can include the type parameter "TYPE" to specify delivery label type.
+   The TYPE parameter values can include "dom" to indicate a domestic
+   delivery label; "intl" to indicate an international delivery label;
+   "postal" to indicate a postal delivery label; "parcel" to indicate a
+   parcel delivery label; "home" to indicate a delivery label for a
+   residence; "work" to indicate delivery label for a place of work; and
+   "pref" to indicate the preferred delivery label when more than one
+   label is specified. These type parameter values can be specified as a
+   parameter list (i.e., "TYPE=dom;TYPE=postal") or as a value list
+   (i.e., "TYPE=dom,postal"). This type is based on semantics of the
+   X.520 geographical and postal addressing attributes. The default is
+   "TYPE=intl,postal,parcel,work". The default can be overridden to some
+   other set of values by specifying one or more alternate values. For
+   example, the default can be reset to "TYPE=intl,post,parcel,home" to
+   specify an international delivery label for both postal and parcel
+   delivery to a residential location.
+
+   Type example: A multi-line address label.
+
+        LABEL;TYPE=dom,home,postal,parcel:Mr.John Q. Public\, Esq.\n
+         Mail Drop: TNE QB\n123 Main Street\nAny Town\, CA  91921-1234
+         \nU.S.A.
+
+3.3 Telecommunications Addressing Types
+
+   These types are concerned with information associated with the
+   telecommunications addressing of the object the vCard represents.
+
+
+
+
+
+
+
+Dawson & Howes              Standards Track                    [Page 13]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+3.3.1 TEL Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type TEL
+
+   Type name: TEL
+
+   Type purpose: To specify the telephone number for telephony
+   communication with the object the vCard represents.
+
+   Type encoding: 8bit
+
+   Type value: A single phone-number value.
+
+   Type special notes: The value of this type is specified in a
+   canonical form in order to specify an unambiguous representation of
+   the globally unique telephone endpoint. This type is based on the
+   X.500 Telephone Number attribute.
+
+   The type can include the type parameter "TYPE" to specify intended
+   use for the telephone number. The TYPE parameter values can include:
+   "home" to indicate a telephone number associated with a residence,
+   "msg" to indicate the telephone number has voice messaging support,
+   "work" to indicate a telephone number associated with a place of
+   work, "pref" to indicate a preferred-use telephone number, "voice" to
+   indicate a voice telephone number, "fax" to indicate a facsimile
+   telephone number, "cell" to indicate a cellular telephone number,
+   "video" to indicate a video conferencing telephone number, "pager" to
+   indicate a paging device telephone number, "bbs" to indicate a
+   bulletin board system telephone number, "modem" to indicate a MODEM
+   connected telephone number, "car" to indicate a car-phone telephone
+   number, "isdn" to indicate an ISDN service telephone number, "pcs" to
+   indicate a personal communication services telephone number. The
+   default type is "voice". These type parameter values can be specified
+   as a parameter list (i.e., "TYPE=work;TYPE=voice") or as a value list
+   (i.e., "TYPE=work,voice"). The default can be overridden to another
+   set of values by specifying one or more alternate values. For
+   example, the default TYPE of "voice" can be reset to a WORK and HOME,
+   VOICE and FAX telephone number by the value list
+   "TYPE=work,home,voice,fax".
+
+   Type example:
+
+        TEL;TYPE=work,voice,pref,msg:+1-213-555-1234
+
+
+
+
+
+
+Dawson & Howes              Standards Track                    [Page 14]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+3.3.2 EMAIL Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type EMAIL
+
+   Type name: EMAIL
+
+   Type purpose: To specify the electronic mail address for
+   communication with the object the vCard represents.
+
+   Type encoding: 8bit
+
+   Type value: A single text value.
+
+   Type special notes: The type can include the type parameter "TYPE" to
+   specify the format or preference of the electronic mail address. The
+   TYPE parameter values can include: "internet" to indicate an Internet
+   addressing type, "x400" to indicate a X.400 addressing type or "pref"
+   to indicate a preferred-use email address when more than one is
+   specified. Another IANA registered address type can also be
+   specified. The default email type is "internet". A non-standard value
+   can also be specified.
+
+   Type example:
+
+        EMAIL;TYPE=internet:jqpublic@xyz.dom1.com
+
+        EMAIL;TYPE=internet:jdoe@isp.net
+
+        EMAIL;TYPE=internet,pref:jane_doe@abc.com
+
+3.3.3 MAILER Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type MAILER
+
+   Type name: MAILER
+
+   Type purpose: To specify the type of electronic mail software that is
+   used by the individual associated with the vCard.
+
+   Type encoding: 8bit
+
+   Type value: A single text value.
+
+
+
+
+
+Dawson & Howes              Standards Track                    [Page 15]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   Type special notes: This information can provide assistance to a
+   correspondent regarding the type of data representation which can be
+   used, and how they can be packaged. This property is based on the
+   private MIME type X-Mailer that is generally implemented by MIME user
+   agent products.
+
+   Type example:
+
+        MAILER:PigeonMail 2.1
+
+3.4 Geographical Types
+
+   These types are concerned with information associated with
+   geographical positions or regions associated with the object the
+   vCard represents.
+
+3.4.1 TZ Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type TZ
+
+   Type name: TZ
+
+   Type purpose: To specify information related to the time zone of the
+   object the vCard represents.
+
+   Type encoding: 8bit
+
+   Type value: The default is a single utc-offset value. It can also be
+   reset to a single text value.
+
+   Type special notes: The type value consists of a single value.
+
+   Type examples:
+
+        TZ:-05:00
+
+        TZ;VALUE=text:-05:00; EST; Raleigh/North America
+        ;This example has a single value, not a structure text value.
+
+3.4.2 GEO Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type GEO
+
+   Type name: GEO
+
+
+
+Dawson & Howes              Standards Track                    [Page 16]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   Type purpose: To specify information related to the global
+   positioning of the object the vCard represents.
+
+   Type encoding: 8bit
+
+   Type value: A single structured value consisting of two float values
+   separated by the SEMI-COLON character (ASCII decimal 59).
+
+   Type special notes: This type specifies information related to the
+   global position of the object associated with the vCard. The value
+   specifies latitude and longitude, in that order (i.e., "LAT LON"
+   ordering). The longitude represents the location east and west of the
+   prime meridian as a positive or negative real number, respectively.
+   The latitude represents the location north and south of the equator
+   as a positive or negative real number, respectively. The longitude
+   and latitude values MUST be specified as decimal degrees and should
+   be specified to six decimal places. This will allow for granularity
+   within a meter of the geographical position. The text components are
+   separated by the SEMI-COLON character (ASCII decimal 59). The simple
+   formula for converting degrees-minutes-seconds into decimal degrees
+   is:
+
+        decimal = degrees + minutes/60 + seconds/3600.
+
+   Type example:
+
+        GEO:37.386013;-122.082932
+
+3.5 Organizational Types
+
+   These types are concerned with information associated with
+   characteristics of the organization or organizational units of the
+   object the vCard represents.
+
+3.5.1 TITLE Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type TITLE
+
+   Type name: TITLE
+
+   Type purpose: To specify the job title, functional position or
+   function of the object the vCard represents.
+
+   Type encoding: 8bit
+
+   Type value: A single text value.
+
+
+
+Dawson & Howes              Standards Track                    [Page 17]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   Type special notes: This type is based on the X.520 Title attribute.
+
+   Type example:
+
+        TITLE:Director\, Research and Development
+
+3.5.2 ROLE Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type ROLE
+
+   Type name: ROLE
+
+   Type purpose: To specify information concerning the role, occupation,
+   or business category of the object the vCard represents.
+
+   Type encoding: 8bit
+
+   Type value: A single text value.
+
+   Type special notes: This type is based on the X.520 Business Category
+   explanatory attribute. This property is included as an organizational
+   type to avoid confusion with the semantics of the TITLE type and
+   incorrect usage of that type when the semantics of this type is
+   intended.
+
+   Type example:
+
+        ROLE:Programmer
+
+3.5.3 LOGO Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type LOGO
+
+   Type name: LOGO
+
+   Type purpose: To specify a graphic image of a logo associated with
+   the object the vCard represents.
+
+   Type encoding: The encoding MUST be reset to "b" using the ENCODING
+   parameter in order to specify inline, encoded binary data. If the
+   value is referenced by a URI value, then the default encoding of 8bit
+   is used and no explicit ENCODING parameter is needed.
+
+
+
+
+
+Dawson & Howes              Standards Track                    [Page 18]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   Type value: A single value. The default is binary value. It can also
+   be reset to uri value. The uri value can be used to specify a value
+   outside of this MIME entity.
+
+   Type special notes: The type can include the type parameter "TYPE" to
+   specify the graphic image format type. The TYPE parameter values MUST
+   be one of the IANA registered image formats or a non-standard image
+   format.
+
+   Type example:
+
+        LOGO;VALUE=uri:http://www.abc.com/pub/logos/abccorp.jpg
+
+        LOGO;ENCODING=b;TYPE=JPEG:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
+         AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
+         ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
+         <...the remainder of "B" encoded binary data...>
+
+3.5.4 AGENT Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type AGENT
+
+   Type name: AGENT
+
+   Type purpose: To specify information about another person who will
+   act on behalf of the individual or resource associated with the
+   vCard.
+
+   Type encoding: 8-bit
+
+   Type value: The default is a single vcard value. It can also be reset
+   to either a single text or uri value. The text value can be used to
+   specify textual information. The uri value can be used to specify
+   information outside of this MIME entity.
+
+   Type special notes: This type typically is used to specify an area
+   administrator, assistant, or secretary for the individual associated
+   with the vCard. A key characteristic of the Agent type is that it
+   represents somebody or something that is separately addressable.
+
+   Type example:
+
+        AGENT;VALUE=uri:
+         CID:JQPUBLIC.part3.960129T083020.xyzMail@host3.com
+
+
+
+
+
+Dawson & Howes              Standards Track                    [Page 19]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+        AGENT:BEGIN:VCARD\nFN:Susan Thomas\nTEL:+1-919-555-
+         1234\nEMAIL\;INTERNET:sthomas@host.com\nEND:VCARD\n
+
+3.5.5 ORG Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type ORG
+
+   Type name: ORG
+
+   Type purpose: To specify the organizational name and units associated
+   with the vCard.
+
+   Type encoding: 8bit
+
+   Type value: A single structured text value consisting of components
+   separated the SEMI-COLON character (ASCII decimal 59).
+
+   Type special notes: The type is based on the X.520 Organization Name
+   and Organization Unit attributes. The type value is a structured type
+   consisting of the organization name, followed by one or more levels
+   of organizational unit names.
+
+   Type example: A type value consisting of an organizational name,
+   organizational unit #1 name and organizational unit #2 name.
+
+        ORG:ABC\, Inc.;North American Division;Marketing
+
+3.6 Explanatory Types
+
+   These types are concerned with additional explanations, such as that
+   related to informational notes or revisions specific to the vCard.
+
+3.6.1 CATEGORIES Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type CATEGORIES
+
+   Type name: CATEGORIES
+
+   Type purpose: To specify application category information about the
+   vCard.
+
+   Type encoding: 8bit
+
+
+
+
+
+Dawson & Howes              Standards Track                    [Page 20]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   Type value: One or more text values separated by a COMMA character
+   (ASCII decimal 44).
+
+   Type example:
+
+        CATEGORIES:TRAVEL AGENT
+
+        CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY
+
+3.6.2 NOTE Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type NOTE
+
+   Type name: NOTE
+
+   Type purpose: To specify supplemental information or a comment that
+   is associated with the vCard.
+
+   Type encoding: 8bit
+
+   Type value: A single text value.
+
+   Type special notes: The type is based on the X.520 Description
+   attribute.
+
+   Type example:
+
+        NOTE:This fax number is operational 0800 to 1715
+          EST\, Mon-Fri.
+
+3.6.3 PRODID Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type PRODID
+
+   Type name: PRODID
+
+   Type purpose: To specify the identifier for the product that created
+   the vCard object.
+
+   Type encoding: 8-bit
+
+   Type value: A single text value.
+
+
+
+
+
+Dawson & Howes              Standards Track                    [Page 21]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   Type special notes: Implementations SHOULD use a method such as that
+   specified for Formal Public Identifiers in ISO 9070 to assure that
+   the text value is unique.
+
+   Type example:
+
+        PRODID:-//ONLINE DIRECTORY//NONSGML Version 1//EN
+
+3.6.4 REV Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type REV
+
+   Type name: REV
+
+   Type purpose: To specify revision information about the current
+   vCard.
+
+   Type encoding: 8-bit
+
+   Type value: The default is a single date-time value. Can also be
+   reset to a single date value.
+
+   Type special notes: The value distinguishes the current revision of
+   the information in this vCard for other renditions of the
+   information.
+
+   Type example:
+
+        REV:1995-10-31T22:27:10Z
+
+        REV:1997-11-15
+
+3.6.5 SORT-STRING Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type SORT-STRING
+
+   Type Name: SORT-STRING
+
+   Type purpose: To specify the family name or given name text to be
+   used for national-language-specific sorting of the FN and N types.
+
+   Type encoding: 8bit
+
+   Type value: A single text value.
+
+
+
+Dawson & Howes              Standards Track                    [Page 22]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   Type special notes: The sort string is used to provide family name or
+   given name text that is to be used in locale- or national-language-
+   specific sorting of the formatted name and structured name types.
+   Without this information, sorting algorithms could incorrectly sort
+   this vCard within a sequence of sorted vCards.  When this type is
+   present in a vCard, then this family name or given name value is used
+   for sorting the vCard.
+
+   Type examples: For the case of family name sorting, the following
+   examples define common sort string usage with the FN and N types.
+
+        FN:Rene van der Harten
+        N:van der Harten;Rene;J.;Sir;R.D.O.N.
+        SORT-STRING:Harten
+
+        FN:Robert Pau Shou Chang
+        N:Pau;Shou Chang;Robert
+        SORT-STRING:Pau
+
+        FN:Osamu Koura
+        N:Koura;Osamu
+        SORT-STRING:Koura
+
+        FN:Oscar del Pozo
+        N:del Pozo Triscon;Oscar
+        SORT-STRING:Pozo
+
+        FN:Chistine d'Aboville
+        N:d'Aboville;Christine
+        SORT-STRING:Aboville
+
+3.6.6 SOUND Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type SOUND
+
+   Type name: SOUND
+
+   Type purpose: To specify a digital sound content information that
+   annotates some aspect of the vCard. By default this type is used to
+   specify the proper pronunciation of the name type value of the vCard.
+
+   Type encoding: The encoding MUST be reset to "b" using the ENCODING
+   parameter in order to specify inline, encoded binary data. If the
+   value is referenced by a URI value, then the default encoding of 8bit
+   is used and no explicit ENCODING parameter is needed.
+
+
+
+
+Dawson & Howes              Standards Track                    [Page 23]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   Type value: A single value. The default is binary value. It can also
+   be reset to uri value. The uri value can be used to specify a value
+   outside of this MIME entity.
+
+   Type special notes: The type can include the type parameter "TYPE" to
+   specify the audio format type. The TYPE parameter values MUST be one
+   of the IANA registered audio formats or a non-standard audio format.
+
+   Type example:
+
+        SOUND;TYPE=BASIC;VALUE=uri:CID:JOHNQPUBLIC.part8.
+         19960229T080000.xyzMail@host1.com
+
+        SOUND;TYPE=BASIC;ENCODING=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
+         AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
+         ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
+         <...the remainder of "B" encoded binary data...>
+
+3.6.7 UID Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type UID
+
+   Type name: UID
+
+   Type purpose: To specify a value that represents a globally unique
+   identifier corresponding to the individual or resource associated
+   with the vCard.
+
+   Type encoding: 8bit
+
+   Type value: A single text value.
+
+   Type special notes: The type is used to uniquely identify the object
+   that the vCard represents.
+
+   The type can include the type parameter "TYPE" to specify the format
+   of the identifier. The TYPE parameter value should be an IANA
+   registered identifier format. The value can also be a non-standard
+   format.
+
+   Type example:
+
+        UID:19950401-080045-40000F192713-0052
+
+
+
+
+
+
+Dawson & Howes              Standards Track                    [Page 24]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+3.6.8 URL Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type URL
+
+   Type name: URL
+
+   Type purpose: To specify a uniform resource locator associated with
+   the object that the vCard refers to.
+
+   Type encoding: 8bit
+
+   Type value: A single uri value.
+
+   Type example:
+
+        URL:http://www.swbyps.restaurant.french/~chezchic.html
+
+3.6.9 VERSION Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type VERSION
+
+   Type name: VERSION
+
+   Type purpose: To specify the version of the vCard specification used
+   to format this vCard.
+
+   Type encoding: 8bit
+
+   Type value: A single text value.
+
+   Type special notes: The property MUST be present in the vCard object.
+   The value MUST be "3.0" if the vCard corresponds to this
+   specification.
+
+   Type example:
+
+        VERSION:3.0
+
+3.7 Security Types
+
+   These types are concerned with the security of communication pathways
+   or access to the vCard.
+
+
+
+
+
+Dawson & Howes              Standards Track                    [Page 25]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+3.7.1 CLASS Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type CLASS
+
+   Type name: CLASS
+
+   Type purpose: To specify the access classification for a vCard
+   object.
+
+   Type encoding: 8bit
+
+   Type value: A single text value.
+
+   Type special notes: An access classification is only one component of
+   the general security model for a directory service. The
+   classification attribute provides a method of capturing the intent of
+   the owner for general access to information described by the vCard
+   object.
+
+   Type examples:
+
+        CLASS:PUBLIC
+
+        CLASS:PRIVATE
+
+        CLASS:CONFIDENTIAL
+
+3.7.2 KEY Type Definition
+
+   To: ietf-mime-directory@imc.org
+
+   Subject: Registration of text/directory MIME type KEY
+
+   Type name: KEY
+
+   Type purpose: To specify a public key or authentication certificate
+   associated with the object that the vCard represents.
+
+   Type encoding: The encoding MUST be reset to "b" using the ENCODING
+   parameter in order to specify inline, encoded binary data. If the
+   value is a text value, then the default encoding of 8bit is used and
+   no explicit ENCODING parameter is needed.
+
+   Type value: A single value. The default is binary. It can also be
+   reset to text value. The text value can be used to specify a text
+   key.
+
+
+
+Dawson & Howes              Standards Track                    [Page 26]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   Type special notes: The type can also include the type parameter TYPE
+   to specify the public key or authentication certificate format. The
+   parameter type should specify an IANA registered public key or
+   authentication certificate format. The parameter type can also
+   specify a non-standard format.
+
+   Type example:
+
+        KEY;ENCODING=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQA
+         wdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENbW11bmljYX
+         Rpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
+         ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNj
+         E5NDc1OVoXDTk3MTIwMzE5NDc1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYD
+         VQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3JwLjEYMBYGA1UEAx
+         MPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBFhJob3dlc0BuZXRz
+         Y2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqGSIb3DQ
+         EBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2
+         dXcoX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MB
+         EGCWCGSAGG+EIBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau
+         +hUMbsQukjANBgkqhkiG9w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIP
+         mx93HGp0Kgyx1jIVMyNgsemeAwBM+MSlhMfcpbTrONwNjZYW8vJDSoi//y
+         rZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8VUMk1U7jt8LYpo4YULU7
+         UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ==
+
+3.8 Extended Types
+
+   The types defined by this document can be extended with private types
+   using the non-standard, private values mechanism defined in [RFC
+   2045]. Non-standard, private types with a name starting with "X-" may
+   be defined bilaterally between two cooperating agents without outside
+   registration or standardization.
+
+4.  Formal Grammar
+
+   The following formal grammar is provided to assist developers in
+   building parsers for the vCard.
+
+   This syntax is written according to the form described in RFC 2234,
+   but it references just this small subset of RFC 2234 literals:
+
+   ;*******************************************
+   ; Commonly Used Literal Definition
+   ;*******************************************
+
+   ALPHA        = %x41-5A / %x61-7A
+        ; Latin Capital Letter A-Latin Capital Letter Z /
+        ; Latin Small Letter a-Latin Small Letter z
+
+
+
+
+Dawson & Howes              Standards Track                    [Page 27]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   CHAR         = %x01-7F
+        ; Any C0 Controls and Basic Latin, excluding NULL from
+        ; Code Charts, pages 7-6 through 7-9 in [UNICODE]
+
+   CR           = %x0D
+        ; Carriage Return
+
+   LF           = %0A
+        ; Line Feed
+
+   CRLF         = CR LF
+        ; Internet standard newline
+
+   ;CTL         = %x00-1F / %x7F
+        ; Controls. Not used, but referenced in comments.
+
+   DIGIT        = %x30-39
+        ; Digit Zero-Digit Nine
+
+   DQUOTE       = %x22
+        ; Quotation Mark
+
+   HTAB         = %x09
+        ; Horizontal Tabulation
+
+   SP           = %x20
+        ; space
+
+   VCHAR        = %x21-7E
+        ; Visible (printing) characters
+
+   WSP          = SP / HTAB
+        ; White Space
+
+   ;*******************************************
+   ; Basic vCard Definition
+   ;*******************************************
+
+   vcard_entity = 1*(vcard)
+
+   vcard        = [group "."] "BEGIN" ":" "VCARD" 1*CRLF
+                  1*(contentline)
+        ;A vCard object MUST include the VERSION, FN and N types.
+                  [group "."] "END" ":" "VCARD" 1*CRLF
+
+   contentline  = [group "."] name *(";" param ) ":" value CRLF
+        ; When parsing a content line, folded lines must first
+        ; be unfolded according to the unfolding procedure
+
+
+
+Dawson & Howes              Standards Track                    [Page 28]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+        ; described above. When generating a content line, lines
+        ; longer than 75 characters SHOULD be folded according to
+        ; the folding procedure described in [MIME DIR].
+
+   group        = 1*(ALPHA / DIGIT / "-")
+
+   name         = iana-token / x-name
+        ; Parsing of the param and value is
+        ; based on the "name" or type identifier
+        ; as defined in ABNF sections below
+
+   iana-token   = 1*(ALPHA / DIGIT / "-")
+        ; vCard type or parameter identifier registered with IANA
+
+   x-name       = "X-" 1*(ALPHA / DIGIT / "-")
+        ; Reserved for non-standard use
+
+   param        = param-name "=" param-value *("," param-value)
+
+   param-name   = iana-token / x-name
+
+   param-value  = ptext / quoted-string
+
+   ptext        = *SAFE-CHAR
+
+   value        = *VALUE-CHAR
+
+   quoted-string = DQUOTE QSAFE-CHAR DQUOTE
+
+   NON-ASCII    = %x80-FF
+        ; Use is restricted by CHARSET parameter
+        ; on outer MIME object (UTF-8 preferred)
+
+   QSAFE-CHAR   = WSP / %x21 / %x23-7E / NON-ASCII
+        ; Any character except CTLs, DQUOTE
+
+   SAFE-CHAR    = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-ASCII
+        ; Any character except CTLs, DQUOTE, ";", ":", ","
+
+   VALUE-CHAR   = WSP / VCHAR / NON-ASCII
+        ; Any textual character
+
+   ;*******************************************
+   ; vCard Type Definition
+   ;
+   ; Provides type-specific definitions for how the
+   ; "value" and "param" are defined.
+   ;*******************************************
+
+
+
+Dawson & Howes              Standards Track                    [Page 29]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   ;For name="NAME"
+   param        = ""
+        ; No parameters allowed
+
+   value        = text-value
+
+   ;For name="PROFILE"
+   param        = ""
+        ; No parameters allowed
+
+   value        = text-value
+        ; Value MUST be the case insensitive value "VCARD
+
+   ;For name="SOURCE"
+   param        = source-param
+        ; No parameters allowed
+
+   value        = uri
+
+   source-param = ("VALUE" "=" "uri")
+                / ("CONTEXT" "=" "word")
+        ; Parameter value specifies the protocol context
+        ; for the uri value.
+                / (x-name "=" *SAFE-CHAR)
+
+   ;For name="FN"
+   ;This type MUST be included in a vCard object.
+   param        = text-param
+        ; Text parameters allowed
+
+   value        = text-value
+
+   ;For name="N"
+   ;This type MUST be included in a vCard object.
+
+   param        = text-param
+        ; Text parameters allowed
+
+   value        = n-value
+
+   n-value      = 0*4(text-value *("," text-value) ";")
+                  text-value *("," text-value)
+        ; Family; Given; Middle; Prefix; Suffix.
+        ; Example: Public;John;Quincy,Adams;Reverend Dr. III
+
+   ;For name="NICKNAME"
+   param        = text-param
+        ; Text parameters allowed
+
+
+
+Dawson & Howes              Standards Track                    [Page 30]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   value        = text-list
+
+   ;For name="PHOTO"
+   param        = img-inline-param
+        ; Only image parameters allowed
+
+   param        =/ img-refer-param
+        ; Only image parameters allowed
+
+   value        = img-inline-value
+        ; Value and parameter MUST match
+
+   value        =/ img-refer-value
+        ; Value and parameter MUST match
+
+   ;For name="BDAY"
+   param        = ("VALUE" "=" "date")
+        ; Only value parameter allowed
+
+   param        =/ ("VALUE" "=" "date-time")
+        ; Only value parameter allowed
+
+   value        = date-value
+        ; Value MUST match value type
+
+   value        =/ date-time-value
+        ; Value MUST match value type
+
+   ;For name="ADR"
+   param        = adr-param / text-param
+        ; Only adr and text parameters allowed
+
+   value        = adr-value
+
+   ;For name="LABEL"
+   param        = adr-param / text-param
+        ; Only adr and text parameters allowed
+
+   value        = text-value
+
+   ;For name="TEL"
+   param        = tel-param
+        ; Only tel parameters allowed
+
+   value        = phone-number-value
+
+   tel-param    = "TYPE" "=" tel-type *("," tel-type)
+
+
+
+
+Dawson & Howes              Standards Track                    [Page 31]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   tel-type     = "HOME" / "WORK" / "PREF" / "VOICE" / "FAX" / "MSG"
+                / "CELL" / "PAGER" / "BBS" / "MODEM" / "CAR" / "ISDN"
+                / "VIDEO" / "PCS" / iana-token / x-name
+        ; Values are case insensitive
+
+   ;For name="EMAIL"
+   param        = email-param
+        ; Only email parameters allowed
+
+   value        = text-value
+
+   email-param  = "TYPE" "=" email-type ["," "PREF"]
+        ; Value is case insensitive
+
+   email-type   = "INTERNET" / "X400" / iana-token / "X-" word
+        ; Values are case insensitive
+
+   ;For name="MAILER"
+   param        = text-param
+        ; Only text parameters allowed
+
+   value        = text-value
+
+   ;For name="TZ"
+   param        = ""
+        ; No parameters allowed
+
+   value        = utc-offset-value
+
+   ;For name="GEO"
+   param        = ""
+        ; No parameters allowed
+
+   value        = float-value ";" float-value
+
+   ;For name="TITLE"
+   param        = text-param
+        ; Only text parameters allowed
+
+   value        = text-value
+
+   ;For name="ROLE"
+   param        = text-param
+        ; Only text parameters allowed
+
+   value        = text-value
+
+   ;For name="LOGO"
+
+
+
+Dawson & Howes              Standards Track                    [Page 32]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   param        = img-inline-param / img-refer-param
+        ; Only image parameters allowed
+
+   value        = img-inline-value / img-refer-value
+        ; Value and parameter MUST match
+
+   ;For name="AGENT"
+   param        = agent-inline-param
+
+   param        =/ agent-refer-param
+
+   value        = agent-inline-value
+        ; Value and parameter MUST match
+
+   value        =/ agent-refer-value
+        ; Value and parameter MUST match
+
+   agent-inline-param = ""
+        ; No parameters allowed
+
+   agent-refer-param = "VALUE" "=" "uri"
+        ; Only value parameter allowed
+
+   agent-inline-value = text-value
+        ; Value MUST be a valid vCard object
+
+   agent-refer-value = uri
+        ; URI MUST refer to image content of given type
+
+   ;For name="ORG"
+
+   param        = text-param
+        ; Only text parameters allowed
+
+   value        = org-value
+
+   org-value    = *(text-value ";") text-value
+        ; First is Organization Name, remainder are Organization Units.
+
+   ;For name="CATEGORIES"
+   param        = text-param
+        ; Only text parameters allowed
+
+   value        = text-list
+
+   ;For name="NOTE"
+   param        = text-param
+        ; Only text parameters allowed
+
+
+
+Dawson & Howes              Standards Track                    [Page 33]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   value        = text-value
+
+   ;For name="PRODID"
+   param        = ""
+        ; No parameters allowed
+
+   value        = text-value
+
+   ;For name="REV"
+   param        = ["VALUE" =" "date-time"]
+        ; Only value parameters allowed. Values are case insensitive.
+
+   param        =/ "VALUE" =" "date"
+        ; Only value parameters allowed. Values are case insensitive.
+
+   value        = date-time-value
+
+   value        =/ date-value
+
+   ;For name="SORT-STRING"
+   param        = text-param
+        ; Only text parameters allowed
+
+   value        = text-value
+
+   ;For name="SOUND"
+   param        = snd-inline-param
+        ; Only sound parameters allowed
+
+   param        =/ snd-refer-param
+        ; Only sound parameters allowed
+
+   value        = snd-line-value
+        ; Value MUST match value type
+
+   value        =/ snd-refer-value
+        ; Value MUST match value type
+
+   snd-inline-value     = binary-value CRLF
+        ; Value MUST be "b" encoded audio content
+
+   snd-inline-param     = ("VALUE" "=" "binary"])
+                        / ("ENCODING" "=" "b")
+                        / ("TYPE" "=" *SAFE-CHAR)
+        ; Value MUST be an IANA registered audio type
+
+   snd-refer-value      = uri
+        ; URI MUST refer to audio content of given type
+
+
+
+Dawson & Howes              Standards Track                    [Page 34]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   snd-refer-param      = ("VALUE" "=" "uri")
+                        / ("TYPE" "=" word)
+        ; Value MUST be an IANA registered audio type
+
+   ;For name="UID"
+   param        = ""
+        ; No parameters allowed
+
+   value        = text-value
+
+   ;For name="URL"
+   param        = ""
+        ; No parameters allowed
+
+   value        = uri
+
+   ;For name="VERSION"
+   ;This type MUST be included in a vCard object.
+   param        = ""
+        ; No parameters allowed
+
+   value        = text-value
+        ; Value MUST be "3.0"
+
+   ;For name="CLASS"
+   param        = ""
+        ; No parameters allowed
+
+   value        = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL"
+                / iana-token / x-name
+        ; Value are case insensitive
+
+   ;For name="KEY"
+   param        = key-txt-param
+        ; Only value and type parameters allowed
+
+   param        =/ key-bin-param
+        ; Only value and type parameters allowed
+
+   value        = text-value
+
+   value        =/ binary-value
+
+   key-txt-param = "TYPE" "=" keytype
+
+   key-bin-param = ("TYPE" "=" keytype)
+                 / ("ENCODING" "=" "b")
+        ; Value MUST be a "b" encoded key or certificate
+
+
+
+Dawson & Howes              Standards Track                    [Page 35]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   keytype      = "X509" / "PGP" / iana-token / x-name
+        ; Values are case insensitive
+
+   ;For name="X-" non-standard type
+   param        = text-param / (x-name "=" param-value)
+        ; Only text or non-standard parameters allowed
+
+   value        = text-value
+
+   ;*******************************************
+   ; vCard Commonly Used Parameter Definition
+   ;*******************************************
+
+   text-param   = ("VALUE" "=" "ptext")
+                / ("LANGUAGE" "=" langval)
+                / (x-name "=" param-value)
+
+   langval      = <a language string as defined in RFC 1766>
+
+   img-inline-value     = binary-value
+        ;Value MUST be "b" encoded image content
+
+   img-inline-param
+
+   img-inline-param     = ("VALUE" "=" "binary")
+                        / ("ENCODING" "=" "b")
+                        / ("TYPE" "=" param-value
+        ;TYPE value MUST be an IANA registered image type
+
+   img-refer-value = uri
+        ;URI MUST refer to image content of given type
+
+   img-refer-param      = ("VALUE" "=" "uri")
+                        / ("TYPE" "=" param-value)
+        ;TYPE value MUST be an IANA registered image type
+
+   adr-param    = ("TYPE" "=" adr-type *("," adr-type))
+                / (text-param)
+
+   adr-type     = "dom" / "intl" / "postal" / "parcel" / "home"
+                / "work" / "pref" / iana-type / x-name
+
+   adr-value    = 0*6(text-value ";") text-value
+        ; PO Box, Extended Address, Street, Locality, Region, Postal
+        ; Code, Country Name
+
+
+
+
+
+
+Dawson & Howes              Standards Track                    [Page 36]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   ;*******************************************
+   ; vCard Type Value Definition
+   ;*******************************************
+
+   text-value-list      = 1*text-value *("," 1*text-value)
+
+   text-value   = *(SAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR)
+
+   ESCAPED-CHAR = "\\" / "\;" / "\," / "\n" / "\N")
+        ; \\ encodes \, \n or \N encodes newline
+        ; \; encodes ;, \, encodes ,
+
+   binary-value = <A "b" encoded text value as defined in [RFC 2047]>
+
+   date-value   = <A single date value as defined in [MIME-DIR]>
+
+   time-value   = <A single time value as defined in [MIME-DIR]>
+
+   date-time-value = <A single date-time value as defined in [MIME-DIR]
+
+   float-value  = <A single float value as defined in [MIME-DIR]>
+
+   phone-number-value = <A single text  value as defined in [CCITT
+                         E.163] and [CCITT X.121]>
+
+   uri-value    = <A uri value as defined in [MIME-DIR]>
+
+   utc-offset-value = ("+" / "-") time-hour ":" time-minute
+   time-hour    = 2DIGIT                ;00-23
+   time-minute  = 2DIGIT                ;00-59
+
+5.  Differences From vCard v2.1
+
+   This specification has been reviewed by the IETF community. The
+   review process introduced a number of differences from the [VCARD]
+   version 2.1. These differences require that vCard objects conforming
+   to this specification have a different version number than a vCard
+   conforming to [VCARD]. The differences include the following:
+
+        . The QUOTED-PRINTABLE inline encoding has been eliminated.
+          Only the "B" encoding of [RFC 2047] is an allowed value for
+          the ENCODING parameter.
+
+        . The method for specifying CRLF character sequences in text
+          type values has been changed. The CRLF character sequence in
+          a text type value is specified with the backslash character
+          sequence "\n" or "\N".
+
+
+
+
+Dawson & Howes              Standards Track                    [Page 37]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+        . Any COMMA or SEMICOLON in a text type value must be backslash
+          escaped.
+
+        . VERSION value corresponding to this specification MUST be
+          "3.0".
+
+        . The [MIME-DIR] predefined types of SOURCE, NAME and PROFILE
+          are allowed.
+
+        . The [MIME-DIR] VALUE type parameter for value data typing is
+          allowed. In addition, there are extensions made to these type
+          values for additional value types used in this specification.
+
+        . The [VCARD] CHARSET type parameter has been eliminated.
+          Character set can only be specified on the CHARSET parameter
+          on the Content-Type MIME header field.
+
+        . The [VCARD] support for non-significant WSP character has
+          been eliminated.
+
+        . The "TYPE=" prefix to parameter values is required. In
+          [VCARD] this was optional.
+
+        . LOGO, PHOTO and SOUND multimedia formats MUST be either IANA
+          registered types or non-standard types.
+
+        . Inline binary content must be "B" encoded and folded. A blank
+          line after the encoded binary content is no longer required.
+
+        . TEL values can be identified as personal communication
+          services telephone numbers with the PCS type parameter value.
+
+        . The CATEGORIES, CLASS, NICKNAME, PRODID and SORT-STRING types
+          have been added.
+
+        . The VERSION, N and FN types MUST be specified in a vCard.
+          This identifies the version of the specification that the
+          object was formatted to. It also assures that every vCard
+          will include both a structured and formatted name that can be
+          used to identify the object.
+
+
+
+
+
+
+
+
+
+
+
+Dawson & Howes              Standards Track                    [Page 38]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+6.  Acknowledgements
+
+   The many valuable comments contributed by members of the IETF ASID
+   working group are gratefully acknowledged, as are the contributions
+   by Roland Alden, Stephen Bartlett, Alec Dun, Patrik Faltstrom, Daniel
+   Gurney, Bruce Johnston, Daniel Klaussen, Pete Miller, Keith Moore,
+   Vinod Seraphin, Michelle Watkins. Chris Newman was especially helpful
+   in navigating the intricacies of ABNF lore.
+
+7.  Authors' Addresses
+
+   BEGIN:vCard
+   VERSION:3.0
+   FN:Frank Dawson
+   ORG:Lotus Development Corporation
+   ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive
+    ;Raleigh;NC;27613-3502;U.S.A.
+   TEL;TYPE=VOICE,MSG,WORK:+1-919-676-9515
+   TEL;TYPE=FAX,WORK:+1-919-676-9564
+   EMAIL;TYPE=INTERNET,PREF:Frank_Dawson@Lotus.com
+   EMAIL;TYPE=INTERNET:fdawson@earthlink.net
+   URL:http://home.earthlink.net/~fdawson
+   END:vCard
+
+
+   BEGIN:vCard
+   VERSION:3.0
+   FN:Tim Howes
+   ORG:Netscape Communications Corp.
+   ADR;TYPE=WORK:;;501 E. Middlefield Rd.;Mountain View;
+    CA; 94043;U.S.A.
+   TEL;TYPE=VOICE,MSG,WORK:+1-415-937-3419
+   TEL;TYPE=FAX,WORK:+1-415-528-4164
+   EMAIL;TYPE=INTERNET:howes@netscape.com
+   END:vCard
+
+8.  Security Considerations
+
+   vCards can carry cryptographic keys or certificates, as described in
+   Section 3.7.2.
+
+   Section 3.7.1 specifies a desired security classification policy for
+   a particular vCard. That policy is not enforced in any way.
+
+   The vCard objects have no inherent authentication or privacy, but can
+   easily be carried by any security mechanism that transfers MIME
+   objects with authentication or privacy. In cases where threats of
+   "spoofed" vCard information is a concern, the vCard SHOULD BE
+
+
+
+Dawson & Howes              Standards Track                    [Page 39]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   transported using one of these secure mechanisms.
+
+   The information in a vCard may become out of date. In cases where the
+   vitality of data is important to an originator of a vCard, the "URL"
+   type described in section 3.6.8 SHOULD BE specified. In addition, the
+   "REV" type described in section 3.6.4 can be specified to indicate
+   the last time that the vCard data was updated.
+
+9.  References
+
+   [ISO 8601]    ISO 8601:1988 - Data elements and interchange formats -
+                 Information interchange - Representation of dates and
+                 times - The International Organization for
+                 Standardization, June, 1988.
+
+   [ISO 8601 TC] ISO 8601, Technical Corrigendum 1 - Data elements and
+                 interchange formats - Information interchange -
+                 Representation of dates and times - The International
+                 Organization for Standardization, May, 1991.
+
+   [ISO 9070]    ISO 9070, Information Processing - SGML support
+                 facilities - Registration Procedures for Public Text
+                 Owner Identifiers, April, 1991.
+
+   [CCITT E.163] Recommendation E.163 - Numbering Plan for The
+                 International Telephone Service, CCITT Blue Book,
+                 Fascicle II.2, pp.  128-134, November, 1988.
+
+   [CCITT X.121] Recommendation X.121 - International Numbering Plan for
+                 Public Data Networks, CCITT Blue Book, Fascicle VIII.3,
+                 pp. 317-332, November, 1988.
+
+   [CCITT X.520] Recommendation X.520 - The Directory - Selected
+                 Attribute Types, November 1988.
+
+   [CCITT X.521] Recommendation X.521 - The Directory - Selected Object
+                 Classes, November 1988.
+
+   [MIME-DIR]    Howes, T., Smith, M., and F. Dawson, "A MIME Content-
+                 Type for Directory Information", RFC 2425, September
+                 1998.
+
+   [RFC 1738]    Berners-Lee, T., Masinter, L., and M. McCahill,
+                 "Uniform Resource Locators (URL)", RFC 1738, December
+                 1994.
+
+   [RFC 1766]    Alvestrand, H., "Tags for the Identification of
+                 Languages", RFC 1766, March 1995.
+
+
+
+Dawson & Howes              Standards Track                    [Page 40]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+   [RFC 1872]    Levinson, E., "The MIME Multipart/Related Content-
+                 type", RFC 1872, December 1995.
+
+   [RFC 2045]    Freed, N., and N. Borenstein, "Multipurpose Internet
+                 Mail Extensions (MIME) - Part One: Format of Internet
+                 Message Bodies", RFC 2045, November 1996.
+
+   [RFC 2046]    Freed, N., and N. Borenstein, "Multipurpose Internet
+                 Mail Extensions (MIME) - Part Two: Media Types", RFC
+                 2046, November 1996.
+
+   [RFC 2047]    Moore, K., "Multipurpose Internet Mail Extensions
+                 (MIME) - Part Three: Message Header Extensions for
+                 Non-ASCII Text", RFC 2047, November 1996.
+
+   [RFC 2048]    Freed, N., Klensin, J., and J. Postel, "Multipurpose
+                 Internet Mail Extensions (MIME) - Part Four:
+                 Registration Procedures", RFC 2048, January 1997.
+
+   [RFC 2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC 2234]    Crocker, D., and P. Overell, "Augmented BNF for Syntax
+                 Specifications: ABNF", RFC 2234, November 1997.
+
+   [UNICODE]     "The Unicode Standard - Version 2.0", The Unicode
+                 Consortium, July 1996.
+
+   [VCARD]       Internet Mail Consortium, "vCard - The Electronic
+                 Business Card Version 2.1",
+                 http://www.imc.org/pdi/vcard-21.txt, September 18,
+                 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dawson & Howes              Standards Track                    [Page 41]
+
+RFC 2426              vCard MIME Directory Profile        September 1998
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dawson & Howes              Standards Track                    [Page 42]
+
diff --git a/addressbook/backend/ebook/docs/vcard-21.txt b/addressbook/backend/ebook/docs/vcard-21.txt
new file mode 100644
index 0000000000..64716ebf15
--- /dev/null
+++ b/addressbook/backend/ebook/docs/vcard-21.txt
@@ -0,0 +1,1544 @@
+vCard
+The Electronic Business Card
+Version 2.1
+
+A versit Consortium Specification
+September 18, 1996
+
+
+Copyrights
+© 1996, International Business Machines Corp., Lucent Technologies, Inc., and Siemens. All rights reserved. 
+Permission is granted to copy and distribute this publication provided that it is reproduced in its entirety without modification and includes the above copyright notice and this permission notice.
+No licenses, express or implied, are granted with respect to any of the technology described in this publication. International Business Machines Corp., Lucent Technologies, Inc., and Siemens retain all their intellectual property rights in the technology described in this publication. 
+Even though International Business Machines Corp., Lucent Technologies, Inc., and Siemens have reviewed this specification, INTERNATIONAL BUSINESS MACHINES CORP., LUCENT TECHNOLOGIES, INC, AND SIEMENS, MAKE NO WARRANTY OR REPRESENTATION, EITHER EXPRESS OR IMPLIED, WITH RESPECT TO THIS PUBLICATION, ITS QUALITY OR ACCURACY, NONINFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE. AS A RESULT, THIS SPECIFICATION IS DELIVERED "AS IS" AND THE READER ASSUMES THE ENTIRE RISK AS TO ITS QUALITY, ACCURACY OR SUITABILITY FOR ANY PARTICULAR PURPOSE..
+IN NO EVENT WILL INTERNATIONAL BUSINESS MACHINES CORP., LUCENT TECHNOLOGIES, INC, AND SIEMENS, BE LIABLE FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES RESULTING FROM ANY DEFECT OR INACCURACY IN THIS PUBLICATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
+This publication is provided with RESTRICTED RIGHTS. Use, duplication, or disclosure by the Government are subject to restrictions set forth in DFARS 252.227-7013 or 48 CFR 52.227-19, as applicable.
+
+
+Trademarks
+versit, the versit  logo, versitcard, vCard, and vCalendar are trademarks of Apple Computer, Inc., AT&T Corp., International Business Machines Corp., and Siemens.
+Apple, is a trademarks of Apple Computer, Inc. registered in the U.S. and other countries.
+AT&T and ATTMail are registered trademarks of AT&T Corp.
+IBM, IBM Mail, and OS/2 are registered trademarks of International Business Machines Corporation.
+America Online is a registered trademark of America Online, Inc.
+CompuServe, CompuServe Information Services are registered trademarks of Compuserve Incorporated.
+MCIMail is a registered trademark of MCI Communications Corporation.
+Microsoft is a registered trademark, and Microsoft Windows is a trademark of Microsoft Corporation.
+Prodigy is a registered trademark of Prodigy Services Company.
+Unicode is a registered trademark of Unicode, Inc.
+
+
+Contributors
+Roland Alden
+Greg Ames, Ames & Associates
+Masanari Arai, Puma Technologies
+Stephen W. Bartlett
+Donal Carroll
+Liang-Jye Chang, Starfish Software
+Frank Dawson, IBM Corporation
+Ken Dobson, IntelliLink Inc.
+Scott Feldstein, Nimble Software, Inc.
+Anik Ganguly, OnTime/Division of FTP Software.
+Beijing Goo, Microsoft
+Arvind K. Goyal, Lotus Development Corporation
+Gary Hand, IBM Corporation
+Tim Howes, Netscape Communications Corporation
+Mark Joseph, Attachmate Corporation
+Kerry Kelly, Now Software, Inc.
+Phac Letuan, Apple Computer, Inc.
+Pat Megowan, Counterpoint Sytems Foundry Inc.
+Tohri Mori, IBM Japan/Salutation Consortium
+Ravi Pandya, NetManage, Inc.
+Geoff Ralston, Four11 Corporation
+Steven Rummel, Lucent Technologies
+Michael Santullo, Four11 Corporation
+Vinod Seraphin, Lotus Development Corporation
+Dexter Seely, Corex Technologies, Inc.
+Vlad Shmunis, Ring Zero Systems Inc.
+Dean Stevens, Now Software, Inc.
+Michelle Watkins, Netscape Communications Corporation
+Horst Widlewski, Siemens
+
+
+Reference Information
+The cited references contain provisions which, through reference in this specification, constitute provisions of this specification. At the time of publication, the indicated versions in the following references were valid. Parties to agreements based on this specification are encouraged to research the possibility of revised standards.
+*	ANSI X3.4-1977, Code for Information Interchange, American National Standards Institute, 1977.
+*	CCITT (ITU) Recommendation E.163, Numbering Plan for The International Telephone Service, CCITT Blue Book, Fascicle II.2, pp. 128-134, November, 1988.
+*	CCITT (ITU) Recommendation G.721, 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM), CCITT Red Book, Fascicle III.4, November, 1988.
+*	CCITT (ITU) Recommendation X.121, International Numbering Plan for Public Data Networks, CCITT Blue Book, Fascicle VIII.3, pp. 317-332, November, 1988.
+*	CCITT (ITU) Recommendations X.500-X.521, Data Communication Networks: Directory, CCITT Blue Book, Fascicle VIII.8, November, 1988.
+*	CCITT Recommendation X.520, The Directory-Selected Attribute Types, 1988.
+*	CCITT Recommendation X.521, The Directory-Selected Object Classes, 1988.
+*	IETF RFC 1738, Universal Resource Locator, December 1994.
+*	IETF Network Working Group RFC 1766, Tags for the Identification of Languages, March 1995.
+*	IETF Network Working Group Draft, A MIME Content-Type for Directory Information, January 1996. Available from the University of Michigan, 535 W. William St., Ann Arbor, MI 48103-4943, FTP://ds.internic.net/Internet-Drafts/draft-ietf-asid-mime-direct-01.txt.
+*	IETF Network Working Group Draft, An Application/Directory MIME Content-Type Electronic Business Card Profile, May 1996. Available FTP://ds.internic.net/Internet-Drafts/draft-ietf-asid-mime-vcard-00.txt.
+*	IETF Network Working Group Draft, UTF-8, A Transformation Format of UNICODE and ISO 10646, July 1996. Available from FTP://ds.internic.net/Internet-Drafts/draft-yergeau-utf8-01.txt.
+*	ISO 639, Code for The Representation of names of languages, International Organization for Standardization, April, 1988.
+*	ISO 3166, Codes for The Representation of names of countries, International Organization for Standardization, December, 1993.
+*	ISO 8601, Data elements and interchange formats-Information interchange-Representation of dates and times, International Organization for Standardization, June, 1988.
+*	ISO 8601, Technical Corrigendum 1, Data elements and interchange formats-Information interchange-Representation of dates and times, International Organization for Standardization, May, 1991.
+*	ISO 8859-1, Information Processing-8-Bit single-byte coded graphic character sets-Part 1: Latin Alphabet No. 1, International Organization for Standardization, February, 1987.
+*	ISO 9070, Information Processing-SGML support facilities-Registration Procedures for Public Text Owner Identifiers, 1990-02-01.[DS1]
+ï	ISO/IEC 9070, Information TechnologyóSGML Support FacilitiesóRegistration Procedures for Public Text Owner Identifiers, Second Edition, International Organization for Standardization, April, 1991.
+ï	ISO/IEC 11180, Postal addressing, International Organization for Standardization, 1993.
+ï	Appleís Representation of a Canonical Static DeviceID in The Telephony Suite, version 1.0, Apple Computer, Inc., 1993.
+*	Microsoft TAPI in Microsoft Windows 3.1 Telephony Programmers' Guide, version 1.0, Microsoft Corporation, 1993.
+*	RFC1521, MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies, Network Working Group, September, 1993.
+*	The Unicode Standard, Version 1.1: Version 1.0, Volume 1 (ISBN 0-201-56788-1), version 1.0, volume 2 (ISBN 0-20-60845-6) and Unicode Technical Report #4, The Unicode Standard, version 1.1, The Unicode Consortium, October, 1991. Both references to be published by Addison-Wesley.
+
+
+versit Update
+versit  is a multivendor development initiative of the communication and computer industries, founded by Apple, AT&T, IBM and Siemens. The versit parties believe that great potential exists in improving the nature of communications in the business world-permitting companies to better manage their quality, productivity, customer satisfaction and cost of operations, while expanding the market opportunities for a variety of product and service vendors. versit parties will jointly define and support open specifications that facilitate and promote the interoperability of advanced personal information and communication devices, networks and services.
+The versit vision is to enable diverse communication and computing devices, applications and services from competing vendors to interoperate in all environments. Through developing a series of specifications for interoperability among diverse communications and computing devices, applications, networks and services, versit 's vision will become a reality.
+versit 's primary development areas are in:
+*	Personal Data Interchange (PDI)
+*	Computer Telephone Integration (CTI)
+*	Conferencing and Messaging (C&M)
+*	Wired and Wireless connectivity
+versit specifications are directed at both the decision makers and the implementation teams of: 
+*	Equipment Manufacturers
+*	Independent Software Vendors
+*	Information Service Providers
+*	Online Service Providers
+*	Software Houses
+*	Users
+versit specifications are made available to any interested party. In turn, versit encourages the support of our goals by soliciting feedback on versit specifications.
+
+All comments relating to versit or the material within this specification should be submitted to:
+versit  
+(800) 803-6240
++1 (201) 327-2803 (Outside USA)
+pdi@versit.com
+http://www.versit.com/pdi
+
+
+Contents
+Section 1 : Introduction	
+1.1 Overview	
+1.2 Scope	
+1.3 Contents	
+1.4 Definitions and Abbreviations	
+Section 2 : vCard Specificiation	
+2.1 Encoding Characteristics	
+2.1.1 vCard Object	
+2.1.2 Property	
+2.1.3 Delimiters	
+2.1.4 Grouping	
+2.1.4.1 vCard Grouping	
+2.1.4.2 Property Grouping	
+2.1.5 Encodings	
+2.1.6 Character Set	
+2.1.7 Language	
+2.1.8 Value Location	
+2.1.9 Binary Values	
+2.2 Identification Properties	
+2.2.1 Formatted Name	
+2.2.2 Name	
+2.2.3 Photograph	
+2.2.3.1 Photo Format Type	
+2.2.4 Birthdate	
+2.3 Delivery Addressing Properties	
+2.3.1 Delivery Address	
+2.3.1.1 Delivery Address Type	
+2.3.2 Delivery Label	
+2.3.2.1 Delivery Label Type	
+2.4 Telecommunications Addressing Properties	
+2.4.1 Telephone Number	
+2.4.1.1 Telephone Type	
+2.4.2 Electronic Mail	
+2.4.2.1 Electronic Mail Type	
+2.4.3 Mailer	
+2.4.4 Geographical Properties	
+2.4.5 Time Zone	
+2.4.6 Geographic Position	
+2.5 Organizational Properties	
+2.5.1 Title	
+2.5.2 Business Category	
+2.5.3 Logo	
+2.5.3.1 Logo Format Type	
+2.5.4 Agent	
+2.5.5 Organization Name and Organizational Unit	
+2.6 Explanatory Properties	
+2.6.1 Comment	
+2.6.2 Last Revision	
+2.6.3 Sound	
+2.6.3.1 Sound Digital Audio Type	
+2.6.4 Uniform Resource Locator	
+2.6.5 Unique Identifier	
+2.6.6 Version	
+2.7 Security Properties	
+2.7.1 Public Key	
+2.7.2 Key Type	
+2.8 Miscellaneous Properties	
+2.8.1 Extensions	
+2.9 Formal Definition	
+Section 3 : Internet Recommendations	
+3.1 Recommended Practice with SMTP/MIME	
+3.1.1 Text/Plain Content Type	
+3.1.2 Text/X-vCard Content Type	
+3.1.3 Application/Directory Content Type	
+3.2 Recommended Practice with HTTP/HTML	
+3.2.1 Form Element Usage	
+3.2.2 Mapping To INPUT Element Attribute Names	
+3.2.3 Example HTML Code	
+Section 4 : UI Support Recommendations	
+4.1 File System	
+4.2 Clipboard	
+4.3 Drag/Drop	
+Section 5 : Conformance	
+
+
+
+Section 1 : Introduction
+[DS2]		
+Personal Data Interchange (PDI) occurs every time two or more individuals communicate, in either a business or personal context, face-to-face, or across space and time. Such interchanges frequently include the exchange of informal information, such as business cards, telephone numbers, addresses, dates and times of appointments, etc. Augmenting PDI with electronics and telecommunications can help ensure that information is quickly and reliably communicated, stored, organized and easily located when needed.
+Personal information, by nature, is complex and diverse. Currently, proprietary standards exist to structure some types of PDI information, but no single, open specification comprehensively addresses the needs of collecting and communicating PDI information across many common communication channels such as telephones, voice-mail, e-mail, and face-to-face meetings. versit  is developing a comprehensive family of PDI technologies based on open specifications and interoperability agreements to help meet this technology need.
+Overview
+This specification defines a format for an electronic business card, or vCard. The format is suitable as an interchange format between applications or systems. The format is defined independent of the particular method used to transport it. The transport for this exchange might be a file system, point-to-point asynchronous communication, wired-network transport, or some form of unwired transport.
+A vCard is a data stream consisting of one or more vCard objects. The individual vCard definitions can be identified and parsed within the datastream. The vCard data stream may exist as a persistent form in a file system, document management system, network connection between two network endpoints, or in any other digital transport that has an abstraction of a stream of bytes.
+Conceptually, a vCard Writer creates vCard data streams and a vCard Reader interprets vCard data streams. The vCard Reader and Writer may be implemented as a single application or as separate applications. It is not the intent of this specification to define the implementation of these processes beyond some fundamental capabilities related to the format of the vCard data stream and a common set of conformance requirements .
+This specification provides for a clear-text encoding that is intended to be based on the syntax used by the MIME specification (RFC 1521).
+The encoding of this specification can be used in environments which are constrained to 7-bit transfer encodings, short line lengths, and low bandwidth. In addition, the encoding is simple in order to facilitate the implementation of reader and writer applications on small platforms, such as Personal Digital Assistants (PDA), cellular telephones, or alphanumeric pagers.
+Scope
+The vCard is intended to be used for exchanging information about people and resources. In today's business environment, this information is typically exchanged on business cards. It is appropriate, then that this specification define this information in terms of a paradigm based on an electronic business card object.
+The ultimate destination for this information is often a collection of business cards, Rolodex® file, or electronic contact manager. Prior to the introduction of the vCard specification, users of such applications typically had to re-key the original information, often transcribing it from paper business cards. With the advent of the vCard specification, this information can be exchanged in an automated fashion.
+The basis for the data types supported by this specification have their origin in openly defined, international standards and in additional capabilities based on enhancements suggested by the demonstration of the exchange of prototypical vCards using the Internet based World-Wide-Web, Infra-red data transport, and simultaneous voice and data (SVD) modems.
+The "person" object defined by the CCITT X.500 Series Recommendation for Directory Services was the primary reference for the properties that are defined by this specification. Every attempt was made to make it possible to map the X.520/X.521 attributes and objects into and out of an instance of a vCard. The vCard specification has extended the capabilities that have been defined within the CCITT X.500 Series Recommendation to allow the exchange of additional information often recorded on business cards and electronic contact managers. For example, this specification provides support for exchanging graphic images representing company logos, photographs of individuals, geo-positioning information, and other extensions to properties defined by the X.500 Recommendation.
+The specification of all date and time values are defined in terms of the ISO 8601 standard for representation of dates and times. ISO 8601 supersedes all other international standards defined at the time this specification was drafted.
+The paradigm of an electronic business card is related to the concepts of an entry in a LAN/WAN directory or an electronic mail address book or distribution list. However, the requirements of the electronic business card go beyond the definitions of a "person" object found in either the CCITT X.500 Series Recommendation, network directory services, or electronic mail address book products. The vCard specification is needed to address the requirements for an interchange format for the "person" personal data type or object.
+Personal data applications such as Personal Information Managers (PIM) often provide an import/export capability using Comma Separated Value (CSV) or Tab Delimited Files (TDF) formats. However, these solutions do not preserve the intent of the originating application. When a CSV and TDF format is used by a PIM, the meta-data or semantics of the originating object are only apparent to a similar version of the originating application. Exchange of data between such applications is another important application of an industry-standard specification for an electronic business card interchange format, such as the vCard specification.
+Contents
+This specification is separated into eight sections:
+*	"Section 1 : Introduction" introduces PDI and the vCard specification with an overview, scope statement and section on definitions and abbreviations.
+*	"Section 2 : vCard Specification" defines the semantics and syntax for the vCard.
+*	"Section 3 : Internet Recommendations" specifies a set of guidelines to facilitate the exchange of vCard objects over Internet protocols such as HTTP using HTML and SMTP using MIME.
+*	"Section 4 : UI Support Recommendations" specifies a set of guidelines to facilitate the exchange of vCard objects at the desktop user interface using the file system, clipboard and drag/drop capabilities of the operating system.
+*	"Section 5 : Conformance" defines minimum conformance requirements to consider while developing support for this vCard specification.
+Definitions and Abbreviations
+Definitions and abbreviations used within this specification follow.
+Electronic Business Card: Also known as vCard.
+FPI: Formal Public Identifier. A string expression that represents a public identifier for an object. FPI syntax is defined by ISO 9070.
+GUID: Globally Unique IDentifier
+Internet: A WAN connecting thousands of disparate networks in industry, education, government, and research. The Internet uses TCP/IP as the standard for transmitting information.
+ISO: Organization for International Standardization; a worldwide federation of national standards bodies (ISO Member bodies).
+MIME: Multipurpose Internet Mail Extensions, as defined in RFC1521.
+PDA: Personal Digital Assistant computing device
+PDI: Personal Data Interchange, a collaborative application area which involves the communication of data between people who have a business or personal relationship, but do not necessarily share a common computing infrastructure.
+PIM: Personal Information Manager
+RFC#### documents: Internet "Request For Comment" documents (i.e., RFC822, RFC1521, etc.).
+URL: Uniform Resource Locator; a string expression that can represent any resource on the Internet or local system. RFC 1738 defines the syntax for an URL.
+UTC: Universal Time Coordinated; also known as UCT, for Universal Coordinated Time.
+vCard: The generic term for an electronic, virtual information card that can be transferred between computers, PDAs, or other electronic devices through telephone lines, or e-mail networks, or infrared links. How, when, why, and where vCard are used depends on the applications developed utilizing a vCard.
+versitcard: a vCard.
+WAN: Wide-Area Network
+
+
+Section 2 : vCard Specificiation
+[DS3]		
+This section defines the semantics and syntax for the vCard.
+A vCard is a collection of one or more properties. A property is a uniquely named value. A set of properties can be grouped within a vCard. For example, the properties for a telephone number and comment can be grouped in order to preserve the coupling of the annotation with the telephone number. In addition to property groupings, a vC. versit  is developing a comprehensive family of PDI technologies based on open specifications and interoperability agreements to help meet this technology need.
+Overview
+This specification defines a format for an electronic business card, or vCard. The format is suitable as an interchange format between applications or systems. The format is defined independent of the particular method used to transport it. The transport for this exchange might be a file system, point-to-point asynchronous communication, wired-network transport, or some form of unwired transport.
+A vCard is a data stream consisting of one or more vCard objects. The individual vCard definitions can be identified and parsed within the datastream. The vCard data stream may exist as a persistent form in a file system, document management system, network connection between two network endpoints, or in any other digital transport that has an abstraction of a stream of bytes.
+Conceptually, a vCard Writer creates vCard data streams and a vCard Reader interprets vCard data streams. The vCard Reader and Writer may be implemented as a single application or as separate applications. It is not the intent of this specification to define the implementation of these processes beyond some fundamental capabilities related to the format of the vCard data stream and a common set of conformance requirements .
+This specification provides for a clear-text encoding that is intended to be based on the syntax used by the MIME specification (RFC 1521).
+The encoding of this specification can be used in environments which are constrained to 7-bit transfer encodings, short line lengths, and low bandwidth. In addition, the encoding is simple in order to facilitate the implementation of reader and writer applications on small platforms, such as Personal Digital Assistants (PDA), cellular telephones, or alphanumeric pagers.
+Scope
+The vCard is intended to be used for exchanging information about people and resources. In today's business environment, this information is typically exchanged on business cards. It is appropriate, then that this specification define this information in terms of a paradigm based on an electronic business card object.
+The ultimate destination for this information is often a collection of business cards, Rolodex® file, or electronic contact manager. Prior to the introduction of the vCard specification, users of such applications typically had to re-key the original information, often transcribing it from paper business cards. With the advent of the vCard specification, this information can be exchanged in an automated fashion.
+The basis for the data types supported by this specification have their origin in openly defined, international standards and in additional capabilities based on enhancements suggested by the demonstration of the exchange of prototypical vCards using the Internet based World-Wide-Web, Infra-red data transport, and simultaneous voice and data (SVD) modems.
+The "person" object defined by the CCITT X.500 Series Recommendation for Directory Services was the primary reference for the properties that are defined by this specification. Every attempt was made to make it possible to map the X.520/X.521 attributes and objects into and out of an instance of a vCard. The vCard specification has extended the capabilities that have been defined within the CCITT X.500 Series Recommendation to allow the exchange of additional information often recorded on business cards and electronic contact managers. For example, this specification provides support for exchanging graphic images representing company logos, photographs of individuals, geo-positioning information, and other extensions to properties defined by the X.500 Recommendation.
+The specification of all date and time values are defined in terms of the ISO 8601 standard for representation of dates and times. ISO 8601 supersedes all other international standards defined at the time this specification was drafted.
+The paradigm of an electronic business card is related to the concepts of aQuoted-Printable lines of text must also be limited to less than 76 characters. The 76 characters does not include the CRLF (RFC 822) line break sequence. For example a multiple line LABEL property value of:
+123 Winding Way
+Any Town, CA 12345
+USA
+Would be represented in a Quoted-Printable encoding as:
+LABEL;ENCODING=QUOTED-PRINTABLE:123 Winding Way=0D=0A=
+  Any Town, CA 12345=0D=0A=
+  USA
+Property parameter substrings are delimited by a field delimiter, specified by the Semi-colon character (ASCII decimal 59). A Semi-colon in a property parameter value must be escaped with a Backslash character (ASCII 92).
+Compound property values are property values that also make use of the Semi-colon, field delimiter to separate positional components of the value. For example, the Name property is made up of the Family Name, Given Name, etc. components. A Semi-colon in a component of a compound property value must be escaped with a Backslash character (ASCII 92).
+Grouping
+There are two forms of grouping or collections supported within the vCard. A collection of vCard objects can be grouped and a collection of properties within an individual vCard can be grouped.
+vCard Grouping
+The vCard data stream can consist of multiple vCard objects. The vCard data stream can, sequentially, contain one or more vCard objects.,  In addition, the vCard data stream can contain a property whose value is a nested vCard. In both of these cases, each vCard object will be delimited by the vCard Delimiters. The vCard Reader conforming to this specification must be able to parse and process any of these combinations of vCard Groupings. The support for vCard Grouping is optional for a vCard Writer conforming to this specification.
+Property Grouping
+A Property Grouping is the definition of a method for specifying a collection of related properties within a vCard object. There is no requirement on a vCard reader that it preserve the property group name. However, the vCard reader is required to preserve the grouping of the properties.
+The Property Grouping is identified by a character string prefix to the property name; separated by the Period character (ASCII decimal 46).
+The grouping of a comment property with a telephone property is shown in the following example:
+A.TEL;HOME:+1-213-555-1234
+A.NOTE:This is my vacation home.
+The vCard Reader conforming to this specification must be able to parse and process the property grouping. The support for Property Grouping is optional for a vCard Writer conforming to this specification.
+Encodings
+The default encoding for the vCard object is 7-Bit. The default encoding can be overridden for an individual property value by using the "ENCODING" property parameter. This parameter value can be either "BASE64", "QUOTED-PRINTABLE", or "8BIT". This parameter may be used on any property.
+Some transports (e.g., MIME based electronic mail) may also provide an encoding property at the transport wrapper level. This property can be used in these cases for transporting a vCard data stream that has been defined using a default encoding other than 7-bit (e.g., 8-bit).
+Character Set
+The default character set is ASCII. The default character set can be overridden for an individual property value by using the "CHARSET" property parameter. This property parameter may be used on any property. However, the use of this parameter on some properties may not make sense.
+Any character set registered with the Internet Assigned Numbers Authority (IANA) can be specified by this property parameter. For example, ISO 8859-8 or the Latin/Hebrew character set is specified by:
+ADR;CHARSET=ISO-8859-8:...
+Some transports (e.g., MIME based electronic mail) may also provide a character set property at the transport wrapper level. This property can be used in these cases for transporting a vCard data stream that has been defined using a default character set other than ASCII (e.g., UTF-8).
+Language
+The default language is "en-US" (US English). The default language can be overridden for an individual property value by using the "LANGUAGE" property parameter. The values for this property are a string consistent with RFC 1766, Tags for the Identification of Languages. This property parameter may be used on any property. However, the use of this parameter on some properties, such as PHOTO, LOGO, SOUND, TEL, may not make sense. Canadian French would be specified by this parameter by the following:
+ADR;LANGUAGE=fr-CA:...
+Value Location
+The default location of the property value is inline with the property. However, for some properties, such as those that specify multimedia values, it is efficient to organize the property value as a separate entity (e.g., a file out on the network). The property parameter "VALUE" can be specified to override the "INLINE" location of the property value. In the case of the vCard being transported within a MIME email message, the property value can be specified as being located in a separate MIME entity with the "Content-ID" value, or "CID" for short. In this case, the property value is the Content-ID for the MIME entity containing the property value. In addition, the property value can be specified as being located out on the network within some Internet resource with the "URL" value. In this case, the property value is the Uniform Resource Locator for the Internet resource containing the property value. This property parameter may be used on any property. However, the use of this parameter on some properties may not make sense; for example the Version, Time Zone, Comment, Unique Identifier, properties . The following specifies a value not located inline with the vCard but out in the Internet:
+PHOTO;VALUE=URL;TYPE=GIF:http://www.abc.com/dir_photos/my_photo.gif
+SOUND;VALUE=CONTENT-ID:<jsmith.part3.960817T083000.xyzMail@host1.com
+Binary Values
+The vCard format supports inclusion of binary information, such as computer graphic images, digital audio, or video graphic images. The binary information may either be referenced with a Uniform Reference Locator (URL) or  placed inline in the vCard as the value of a property. Inline binary information is included as a property value after being encoded into clear-text with a Base 64 (default) or Quoted-Printable encoding
+Identification Properties
+These property types are concerned with information associated with the identification and naming of the individual or resource associated with the vCard object.
+Formatted Name
+This property specifies the formatted name string associated with the vCard object. This is the way that the name is to be displayed. It can contain desired honorific prefixes, suffixes, titles, etc. For example, "Mr. John Q. Public, Jr.", Dr. Ann Tyler, or Hon. Judge Blackwell. This property is based on the semantics of the X.520 Common Name attribute.
+This property is identified by the property name FN. The following is an example of the Formatted Name property:
+FN:Mr. John Q. Public, Esq.
+Support for this property is optional for vCard Writers conforming to this specification.
+Name
+This property specifies a structured representation of the name of the person, place or thing associated with the vCard object.
+This property is identified by the property name N. This property is defined to encapsulate the individual components of an object's name. The property value consists of the components of the name specified as positional fields separated by the Field Delimiter character (ASCII decimal 59). The property value is a concatenation of the Family Name (first field), Given Name (second field), Additional Names (third field), Name Prefix (fourth field), and Name Suffix (fifth field) strings. The following is an example of the Name property for a person:
+N:Public;John;Quinlan;Mr.;Esq.
+The following is an example of the Name property for a resource or place:
+N:Veni, Vidi, Vici;The Restaurant.
+Support for this property is mandatory for vCard Writers conforming to this specification. All vCard data streams should include this property to facilitate a common property for collating and sorting of vCard objects.
+Photograph
+This property specifies an image or photograph of the individual associated with the vCard.
+The property is identified by the property name PHOTO. For example, the following syntax is an example of a referenced image file:
+PHOTO;VALUE=URL:file:///jqpublic.gif
+ The following example is the syntax for including an inline GIF image file, using the Base 64 encoding:
+PHOTO;ENCODING=BASE64;TYPE=GIF:
+    R0lGODdhfgA4AOYAAAAAAK+vr62trVIxa6WlpZ+fnzEpCEpzlAha/0Kc74+PjyGM
+    SuecKRhrtX9/fzExORBSjCEYCGtra2NjYyF7nDGE50JrhAg51qWtOTl7vee1MWu1
+    50o5e3PO/3sxcwAx/4R7GBgQOcDAwFoAQt61hJyMGHuUSpRKIf8A/wAY54yMjHtz
+...
+Support for this property is optional for vCard Writers conforming to this specification.
+Photo Format Type
+This property parameter is provided to specify the graphics format for the Photo property value. The property parameter includes the following values:
+
+Description
+Property Parameter Value
+
+TYPE=
+
+
+Indicates Graphics Interchange Format
+GIF
+
+Indicates ISO Computer Graphics Metafile
+CGM
+
+Indicates MS Windows Metafile
+WMF
+
+Indicates MS Windows Bitmap
+BMP
+
+Indicates IBM PM Metafile
+MET
+
+Indicates IBM PM Bitmap
+PMB
+
+Indicates MS Windows DIB
+DIB
+
+Indicates an Apple Picture format
+PICT
+
+Indicates a Tagged Image File Format
+TIFF
+
+Indicates Adobe PostScript format
+PS
+
+Indicates Adobe Page Description Format
+PDF
+
+Indicates ISO JPEG format
+JPEG
+
+Indicates ISO MPEG format
+MPEG
+
+Indicates ISO MPEG version 2 format
+MPEG2
+
+Indicates Intel AVI format
+AVI
+
+Indicates Apple QuickTime format
+QTIME
+
+
+Birthdate
+This property specifies the date of birth of the individual associated with the vCard. The value for this property is a calendar date in a complete representation consistent with ISO 8601.
+This property is identified by the property name BDAY. The property value is a string conforming to the ISO 8601 calendar date, complete representation, in either basic or extended format. The following example is in the basic format of ISO 8601:
+BDAY:19950415
+The following example is in the extended format of ISO 8601:
+BDAY:1995-04-15
+Support for this property is optional for vCard Writers conforming to this specification.
+Delivery Addressing Properties
+Delivery Address
+This property specifies a structured representation of the physical delivery address for the vCard object. The property is made up of components that are based on the X.500 Post Office Box attribute, the X.520 Street Address geographical attribute, the X.520 Locality Name geographical attribute, the X.520 State or Province Name geographical attribute, the X.520 Postal Code attribute, and the X.520 Country Name geographical attribute.
+This property is identified by the property name ADR. The property value consists of components of the address specified as positional fields separated by the Field Delimiter character (ASCII decimal 59). The property value is a concatenation of the Post Office Address (first field) Extended Address (second field), Street (third field), Locality (fourth field), Region (fifth field), Postal Code (six field), and Country (seventh field) strings. An example of this property follows:
+ADR;DOM;HOME:P.O. Box 101;Suite 101;123 Main Street;Any Town;CA;91921-1234;
+Support for this property is optional for vCard Writers conforming to this specification.
+Delivery Address Type
+This property parameter specifies the sub-types of physical delivery that is associated with the delivery address. For example, the label may need to be differentiated for Home, Work, Parcel, Postal, Domestic, and International physical delivery. One or more sub-types can be specified for a given delivery address.
+The property parameter can have one or more of the following values:
+
+Description
+Property Parameter Value
+
+TYPE=
+
+
+Indicates a domestic address
+DOM
+
+Indicates an international address (Default)
+INTL
+
+Indicates a postal delivery address  (Default)
+POSTAL
+
+Indicates a parcel delivery address  (Default)
+PARCEL
+
+Indicates a home delivery address
+HOME
+
+Indicates a work delivery address  (Default)
+WORK
+
+
+The default property parameter is overridden to some other set of values by specifying one or more alternate values. For example, the default of a delivery for INTL, WORK, POSTAL and PARCEL can be reset to DOM, POSTAL, WORK and HOME in the following example:
+ADR;DOM;WORK;HOME;POSTAL:P.O. Box 101;;;Any Town;CA;91921-1234;
+Delivery Label
+This property specifies the addressing label for physical delivery to the person/object associated with the vCard. The property is intended to include the information necessary to create a formatted delivery address label. Typical information includes the name, street address, possibly a Post Office or mail drop, city, state or province, zip or postal code. An international delivery label would also include the country name. 
+This property is based on the semantics of the X.520 Postal Address attribute. This specification has added semantics to those defined by the X.500 Series standard for differentiating Home, Work, Parcel, Postal, Domestic, and International delivery label types.
+This property is identified by the property name LABEL. This property specifies the formatted delivery address label for the vCard object. An example of a domestic delivery label follows:
+LABEL;DOM;POSTAL;ENCODING=QUOTED-PRINTABLE:P. O. Box 456=0D=0A=
+123 Main Street=0D=0A=
+Any Town, CA 91921-1234
+An example of an international delivery label follows:
+LABEL;INTL;PARCEL,ENCODING=QUOTED-PRINTABLE:Suite 101=0D=0A=
+123 Main Street=0D=0A=
+Any Town, CA 91921-1234=0D=0A=
+U.S.A.
+Support for this property is optional for vCard Writers conforming to this specification. A vCard Reader supporting this property and conforming to this specification should support a minimum of four lines of text for this property.
+Delivery Label Type
+This property parameter specifies the sub-types of physical delivery that is associated with the delivery label. For example, the label may need to be differentiated for Home, Work, Parcel, Postal, Domestic, and International physical delivery. One or more sub-types can be specified for a given delivery label.
+The property parameter can have one or more of the following values:
+
+Description
+Property Parameter Value
+
+TYPE=
+
+
+Indicates a domestic address
+DOM
+
+Indicates an international address  (Default)
+INTL
+
+Indicates a postal delivery address  (Default)
+POSTAL
+
+Indicates a parcel delivery address  (Default)
+PARCEL
+
+Indicates a home delivery address
+HOME
+
+Indicates a work delivery address  (Default)
+WORK
+
+
+The default property parameter is overridden to some other set of values by specifying one or more alternate values. For example, the default of a delivery for INTL, WORK, POSTAL and PARCEL can be reset to DOM and HOME in the following example:
+LABEL;DOM;HOME,ENCODING=QUOTED-PRINTABLE:Suite 101=0D=0A=
+123 Main Street=0D=0A=
+Any Town, CA 91921-1234
+Telecommunications Addressing Properties
+These property types are concerned with information associated with the telecommunications addressing of the vCard object.
+Telephone Number
+This property specifies the canonical number string for a telephone number for telephony communication with the vCard object. The value of this property is specified in a canonical form in order to specify an unambiguous representation of the globally unique telephony endpoint. This property is based on the X.520 Telephone Number attribute.
+The canonical form cannot be dialed without first being transformed by a dialing algorithm. The dialing algorithm combines the canonical number string with knowledge of the local dialing procedures, in effect at the time of call placement to produce actual dialing instructions. The actual dialing algorithm is outside the scope of this specification.
+Two important canonical forms allowed by this specification are:
+*	Apple Computer's Representation of a Canonical Static DeviceID in The Telephony Suite, version 1.0,
+*	Microsoft TAPI in the Microsoft Windows 3.1 Telephony Programmer's Guide, version 1.0.
+Software which creates this property can store a string in these allowed formats. Dialing software should be prepared to parse numbers from either of the supported formats; as neither format is considered to be technically costly to support.
+This property is identified by the property name TEL. An example of this property follows:
+TEL;PREF;WORK;MSG;FAX:+1-800-555-1234
+Support for this property is optional for vCard Writers conforming to this specification.
+Telephone Type
+This property parameter specifies the sub-type of telephone that is associated with the telephone number (e.g., Home, Work, Cellular, Facsimile, Video, Modem, Message Service, or Preferred). One or more sub-type values can be specified for a given telephone number.
+The property parameter can have one or more of the following values:
+
+Description
+Property Parameter Value
+
+TYPE=
+
+
+Indicates preferred number
+PREF
+
+Indicates a work number
+WORK
+
+Indicates a home number
+HOME
+
+Indicates a voice number (Default)
+VOICE
+
+Indicates a facsimile number
+FAX
+
+Indicates a messaging service on the number
+MSG
+
+Indicates a cellular number
+CELL
+
+Indicates a pager number
+PAGER
+
+Indicates a bulletin board service number
+BBS
+
+Indicates a MODEM number
+MODEM
+
+Indicates a car-phone number
+CAR
+
+Indicates an ISDN number
+ISDN
+
+Indicates a video-phone number
+VIDEO
+
+The default property parameter is overridden to some other set of values by specifying one or more alternate values. For example, the default of a VOICE telephone number can be reset to a WORK and HOME, VOICE and FAX telephone number in the following example:
+TEL;WORK;HOME;VOICE;FAX:+1-800-555-1234
+Electronic Mail
+This property specifies the address for electronic mail communication with the vCard object. The address is in the form of a specific addressing type. For example, the Internet mail address for John Public might be "John.Public@abc.com" or the CompuServe Information Service address might be "71234,5678".This property is identified by the property name EMAIL.
+An example of this property follows:
+EMAIL;INTERNET:john.public@abc.com
+Support for this property is optional for vCard Writers conforming to this specification.
+Electronic Mail Type
+This property parameter specifies the type of electronic mail address. The following are some example values for this property parameter:
+
+Description
+Property Parameter Value
+
+TYPE=
+
+
+Indicates America On-Line
+AOL
+
+Indicates AppleLink
+AppleLink
+
+Indicates AT&T Mail
+ATTMail
+
+Indicates CompuServe Information Service
+CIS
+
+Indicates eWorld
+eWorld
+
+Indicates Internet SMTP (default)
+INTERNET
+
+Indicates IBM Mail
+IBMMail
+
+Indicates MCI Mail
+MCIMail
+
+Indicates PowerShare
+POWERSHARE
+
+Indicates Prodigy information service
+PRODIGY
+
+Indicates Telex number
+TLX
+
+Indicates X.400 service
+X400
+
+
+Mailer
+This property parameter specifies the type of electronic mail software that is in use by the individual associated with the vCard object. This information may provide assistance to a correspondent regarding the type of data representation which can be used, and how they may be packaged. This property parameter is based on currently accepted practices within the Internet MIME community with the "X-Mailer" header field.
+This property is identified by the property name MAILER. Support for this property is optional for vCard Writers conforming to this specification. An example of this property follows:
+MAILER:ccMail 2.2
+Geographical Properties
+These property types are concerned with geographical positions or region information associated with the vCard object.
+Time Zone
+This property specifies information related to the standard time zone of the vCard object. The time zone is a string as specified in a manner consistent with ISO 8601. It is an offset from Coordinated Universal Time (UTC). An ISO 8601 UTC offset, in basic format, is specified as a positive or negative difference in units of hours and minutes (e.g., +hhmm). If minutes are zero, then they may be omitted and the format would be specified in units of hours (e.g., +hh). The time is specified as a 24-hour clock. Hour valult property parameter is overridden to some other set of values by specifying one or more alternate values. For example, the default of a delivery for INTL, WORK, POSTAL and PARCEL can be reset to DOM, POSTAL, WORK and HOME in the following example:
+ADR;DOM;WORK;HOME;POSTAL:P.O. Box 101;;;Any Town;CA;91921-1234;
+Delivery Label
+This property specifies the addressing label for physical delivery to the person/object associated with the vCard. The property is intended to include the information necessary to create a formatted delivery address label. Typical information includes the name, street address, possibly a Post Office or mail drop, city, state or province, zip or postal code. An international delivery label would also include the country name. 
+This property is based on the semantics of the X.520 Postal Address attribute. This specification has added semantics to those defined by the X.500 Series standard for differentiating Home, Work, Parcel, Postal, Domestic, and International delivery label types.
+This property is identified by the property name LABEL. This property specifies the formatted delivery address label for the vCard object. An example of a domestic delivery label follows:
+LABEL;DOM;POSTAL;ENCODING=QUOTED-PRINTABLE:P. O. Box 456=0D=0A=
+123 Main Street=0D=0A=
+Any Town, CA 91921-1234
+An example of an international delivery label follows:
+LABEL;INTL;PARCEL,ENCODING=QUOTED-PRINTABLE:Suite 101=0D=0A=
+123 Main Street=0D=0A=
+Any Town, CA 91921-1234=0D=0A=
+U.S.A.
+Support for this property is optional for vCard Writers conforming to this specification. A vCard Reader supporting this property and conforming to this specification should support a minimum of four lines of text for this property.
+Delivery Label Type
+This property parameter specifies the sub-types of physical delivery that is associated with the delivery label. For example, the label may need to be differentiated for Home, Work, Parcel, Postal, Domestic, and International physical delivery. One or more sub-types can be specified for a given delivery label.
+The property parameter can have one or more of the following values:
+
+Description
+Property Parameter Value
+
+TYPE=
+
+
+Indicates a domestic address
+DOM
+
+Indicates an international address  (Default)
+INTL
+
+Indicates a postal delivery address  (Default)
+POSTAL
+
+Indicates a parcel delivery address  (Default)
+PARCEL
+
+Indicates a home delivery address
+HOME
+
+Indicates a work delivery address  (Default)
+WORK
+
+
+The default property parameter is overridden to some other set of values by specifying one or more alternate values. For example, the default of a delivery for INTL, WORK, POSTAL and PARCEL can be reset to DOM and HOME in the following example:
+LABEL;DOM;HOME,ENCODING=QUOTED-PRINTABLE:Suite 101=0D=0A=
+123 Main Street=0D=0A=
+Any Town, CA 91921-1234
+Telecommunications Addressing Properties
+These property types are concerned with information associated with the telecommunications addressing of the vCard object.
+Telephone Number
+This property specifies the canonical number string for a telephone number for telephony communication with the vCard object. The value of this property is specified in a canonical form in order to specify an unambiguous representation of the globally unique telephony endpoint. This property is based on the X.520 Telephone Number attribute.
+The canonical form cannot be dialed without first being transformed by a dialing algorithm. The dialing algorithm combines the canonical number string with knowledge of the local dialing procedures, in effect at the time of call placement to produce actual dialing instructions. The actual dialing algorithm is outside the scope of this specification.
+Two important canonical forms allowed by this specification are:
+*	Apple Computer's Representation of a Canonical Static DeviceID in The Telephony Suite, version 1.0,
+*	Microsoft TAPI in the Microsoft Windows 3.1 Telephony Programmer's Guide, version 1.0.
+Software which creates this property can store a string in these allowed formats. Dialing s
+
+Description
+Property Parameter Value
+
+TYPE=
+
+
+Indicates Graphics Interchange Format
+GIF
+
+Indicates ISO Computer Graphics Metafile
+CGM
+
+Indicates MS Windows Metafile
+WMF
+
+Indicates MS Windows Bitmap
+BMP
+
+Indicates IBM PM Metafile
+MET
+
+Indicates IBM PM Bitmap
+PMB
+
+Indicates MS Windows DIB
+DIB
+
+Indicates an Apple Picture format
+PICT
+
+Indicates Tagged Image File Format
+TIFF
+
+Indicates Adobe Page Description Format
+PDF
+
+Indicates Adobe PostScript
+PS
+
+Indicates ISO JPEG format
+JPEG
+
+Indicates ISO MPEG format
+MPEG
+
+Indicates ISO MPEG version 2 format
+MPEG2
+
+Indicates Intel AVI format
+AVI
+
+Indicates Apple QuickTime format
+QTIME
+
+
+Agent
+This property specifies information about another person who will act on behalf of the vCard object. Typically this would be an area administrator, assistant, or secretary for the individual. A key characteristic of the Agent property is that it represents somebody or something which is separately addressable. For example, if all phone calls or e-mail messages are normally screened by an agent, this property may not be needed. On the other hand, if an agent can act as a proxy, and may otherwise need to be contacted separately, then an Agent property is useful.
+This property is equivalent to nesting another vCard with the specified vCard.
+This property is identified by the property name AGENT. The value of this property is a string containing another vCard object. An example of this property follows:
+AGENT:
+BEGIN:VCARD
+VERSION:2.1
+N:Friday;Fred
+TEL;WORK;VOICE:+1-213-555-1234
+TEL;WORK;FAX:+1-213-555-5678
+END:VCARD
+Support for this property is optional for vCard Writers conforming to this specification.
+Organization Name and Organizational Unit
+This property specifies the name and optionally the unit(s) of the organization associated with the vCard object. This property is based on the X.520 Organization Name attribute and the X.520 Organization Unit attribute. For example, "The AB Corporation" and the "North American Division".
+This property is identified by the property name ORG. This property is defined to encapsulate the Organization Name and Organization Unit properties as sub-properties. The property value consists of the components of the organization specified as positional fields separated by the Field Delimiter (ASCII decimal 59). The property value is a concatenation of the Organization Name (first field), Organizational Unit (second field) strings. Additional positional fields, if specified, contain additional Organizational Units. The following is an example of the Organization property:
+ORG:ABC, Inc.;North American Division;Marketing
+Support for this property is optional for vCard Writers conforming to this specification.
+Explanatory Properties
+These property types are concerned with additional explanations, such as that related to national language support, annotation, or encoding of binary information about the vCard object.
+Comment
+This property specifies supplemental information or a comment that is associated with the vCard. With the use of property grouping, the association can be limited to a group of properties. The property is based on the X.520 Description attribute.
+This property is identified by the property name NOTE. An example of this property follows:
+NOTE;ENCODING=QUOTED-PRINTABLE:This facsimile machine if operational=
+ 0830 to 1715 hours=0D=0A=
+Monday through Friday. Call +1-213-555-1234 if you have problems=0D=0A=
+with access to the machine.
+Support for this property is optional for vCard Writers conforming to this specification.
+Last Revision
+This property specifies the combination of the calendar date and time of day of the last update to the vCard object. The property value is a character string conforming to the basic or extended format of ISO 8601. The value can either be in terms of local time or UTC.
+This property is identified by the property name REV. Valid values for this property are a character string representing a combination of the calendar date and time of day conforming to the basic or extended format of ISO 8601. The time of day can be either local time or UTC. The following example is in the basic format and local time of ISO 8601:
+REV:19951031T222710
+The following example is in the extended format and UTC time of ISO 8601:
+REV:1995-10-31T22:27:10Z
+Support for this property is optional for vCard Writers conforming to this specification.
+Sound
+This property specifies a sound annotation for the vCard object. By default, if this property is not grouped with other properties it specifies the pronunciation of the Formatted Name property of the vCard object. Such information may be in the form of a string of characters representing a phonetic sound or in the form of a digitized sound, or both; subject to the limitations imposed by the encoding used to communicate the vCard.
+This property is identified by the property name SOUND. Valid values for this property are either a string representation, a reference to a digital audio representation, or an inline digital audio representation of the phonetic pronunciation of the Formatted Name property. The following example shows the string based phonetic representation:
+SOUND:JON Q PUBLIK
+The following example shows the digtial sound representation and URL based value:
+SOUND;VALUE=URL:file///multimed/audio/jqpublic.wav
+The following example shows the digtial sound representation and INLINE value:
+SOUND;WAVE;BASE64:	
+    UklGRhAsAABXQVZFZm10IBAAAAABAAEAESsAABErAAABAAgAZGF0YesrAACAg4eC
+    eXR4e3uAhoiIiYmKjIiDfnx5eX6CgoKEhYWDenV5fH6BhISGiIiDfHZ2eXt/hIiK
+    jY2IhH12d3Vyc3uDiIiFf3l7fn18eXl+houFf319fnyAgHl5eoCIiISChIeAfnt2
+...
+Support for this property is optional for vCard Writers conforming to this specification.
+Sound Digital Audio Type
+This property parameteris provided to specify the type of the digital audio Pronunciation for the vCard object. The property parameter can have the following values:
+
+Description
+Property Parameter Value
+
+TYPE=
+
+
+Indicates Wave format
+WAVE
+
+Indicates MIME basic audio type
+PCM
+
+Indicates AIFF format
+AIFF
+
+
+Uniform Resource Locator
+This property specifies a value that represents a Uniform Resource Locator (URL). An URL is a representation of an Internet location that can be used to obtain real-time information about the vCard object. Application of this property might be to specify the location of a publicly accessible directory where up-to-date or additional information on the individual or resource associated with a vCard can be found.
+This property is identified by the property name URL. Valid values for this property are a string conforming to the IETF RFC 1738, Uniform Resource Locators. The following is an example of this property:
+URL:http://abc.com/pub/directory/northam/jpublic.ecd
+Support for this property is optional for vCard Writers conforming to this specification.
+Unique Identifier
+This property specifies a value that represents a persistent, globally unique identifier associated with the object. The property can be used as a mechanism to relate different vCard objects. Some examples of valid forms of unique identifiers would include ISO 9070 formal public identifiers (FPI), X.500 distinguished names, machine-generated "random" numbers with a statistically high likelihood of being globally unique and Uniform Resource Locators (URL). If an URL is specified, it is suggested that the URL reference a service which will produce an updated version of the vCard.
+This property is identified by the property name UID. This property is provided to enable a vCard Reader and Writer to uniquely identify either a vCard object instance or properties within a vCard object. Valid values for this property are a unique character string. The following is an example of this property:
+UID:19950401-080045-40000F192713-0052
+Support for this property is optional for vCard Writers conforming to this specification.
+Version
+This property specifies the identifier corresponding to the highest version number of the vCard Specification supported by the implementation that created the vCard object. The value of this property must be 2.1 to correspond to this specification.. 
+This property is identified by the property name VERSION. The following is an example of this property:
+VERSION:2.1
+Support for this property is mandatory for implementations conforming to this specification. This property must appear within the vCard data stream.
+Security Properties
+These property types are concerned with the security of the information in the vCard object.
+Public Key
+This property specifies the public encryption key associated with the vCard object.
+This property is identified by the property name KEY. Valid values for this property are a public key that conforms to a bilaterally agreed to representation. If the representation is a binary format, then the public key must be further encoded. The default format is clear-text. If a binary format is used, then it is specified by the property parameter. Support for this property is optional for vCard Writers conforming to this specification.
+Key Type
+This property parameter is provided to specify the type of the public key for the vCard object. The property parameter can have the following values:
+
+Description
+Property Parameter Value
+
+TYPE=
+
+
+Indicates a X.509 public key certificate type of key
+X509
+
+Indicates an IETF PGP type of key
+PGP
+
+Miscellaneous Properties
+Extensions
+The vCard provides a ìstandard mechanism for doing non-standard thingsî. This extension support is provided for implementers to "push the envelope" on the existing version of the specification. Extension properties are specified by property and/or property parameter names that have the initial sub-string of X- (the two character sequence: Capital X character followed by the Dash character. It is recommended that vendors concatenate onto this sentinel an added short sub-string to identify the vendor. This will facilitate readability of the extensions and minimize possible collision of names between different vendors. For example, the following might be the ABC vendor's extension for a video-clip form of identification property:
+X-ABC-VIDEO;MPEG2:http://lonestar.bubbas.org/billibob.mpg
+or, the following example might be an extension for grouping vCard objects into a distribution list for the Design Work Group. 
+BEGIN:VCARD
+VERSION:2.1
+X-DL;Design Work Group:List Item 1;List Item 2;List Item 3
+BEGIN:VCARD
+UID:List Item 1
+N:John Smith
+TEL:+1-213-555-1111
+END:VCARD
+BEGIN:VCARD
+UID:List Item 2
+N:I. M. Big
+TEL:+1-213-555-9999
+END:VCARD
+BEGIN:VCARD
+UID:List Item 3
+N:Jane Doe
+TEL:+1-213-555-5555
+END:VCARD
+END:VCARD
+At present, there is no registration authority for names of extension properties.
+Support for this property is mandatory for implementations conforming to this specification. However, an implementation may not be able to act on the extension property. Conformance only requires that an implementation be able to parse vCard data streams with extensions. The implementation need not act on them.
+Formal Definition
+The following modified Backus-Naur Notation (BNF) is provided to assist developers in building parsers for the vCard.
+This syntax is written according to the form described in RFC 822, but it references just this small subset of RFC 822 literals:
+  CR			=  <ASCII CR, carriage return>  ; (     15,      13.)
+  LF			=  <ASCII LF, linefeed>         ; (     12,      10.)
+  CRLF		=  CR LF
+  SPACE		=  <ASCII SP, space>            ; (     40,      32.)
+  HTAB		=  <ASCII HT, horizontal-tab>   ; (     11,       9.)
+All literal property names are valid as upper, lower, or mixed case.
+ws		= 1*(SPACE / HTAB)
+	; "whitespace," one or more spaces or tabs
+wsls		= 1*(SPACE / HTAB / CRLF)
+	; whitespace with line separators
+word		= <any printable 7bit us-ascii except []=:., >
+groups		= groups "." word
+		/ word
+vcard_file	= [wsls] vcard [wsls]
+vcard		= "BEGIN" [ws] ":" [ws] "VCARD" [ws] 1*CRLF
+		 items *CRLF "END" [ws] ":" [ws] "VCARD"
+items		= items *CRLF item
+		/ item
+	; these may be "folded"
+item		= [groups "."] name
+		  [params] ":" value CRLF
+		/ [groups "."] "ADR"
+		  [params] ":" addressparts CRLF
+		/ [groups "."] "ORG"
+		  [params] ":" orgparts CRLF
+		/ [groups "."] "N"
+		  [params] ":" nameparts CRLF
+		/ [groups "."] "AGENT"
+		  [params] ":" vcard CRLF
+	; these may be "folded"
+name		= "LOGO" / "PHOTO" / "LABEL" / "FN" / "TITLE"
+		/ "SOUND" / "VERSION" / "TEL" / "EMAIL" / "TZ" / "GEO" / "NOTE"
+		/ "URL" / "BDAY" / "ROLE" / "REV" / "UID" / "KEY"
+		/ "MAILER" / "X-" word 
+	; these may be "folded"
+value		= 7bit / quoted-printable / base64
+7bit		= <7bit us-ascii printable chars, excluding CR LF>
+8bit		= <MIME RFC 1521 8-bit text>
+quoted-printable = <MIME RFC 1521 quoted-printable text>
+base64		= <MIME RFC 1521 base64 text>
+	; the end of the text is marked with two CRLF sequences
+	; this results in one blank line before the start of the next property
+params		= ";" [ws] paramlist
+paramlist	= paramlist [ws] ";" [ws] param
+		/ param
+param		= "TYPE" [ws] "=" [ws] ptypeval
+		/ "VALUE" [ws] "=" [ws] pvalueval
+		/ "ENCODING" [ws] "=" [ws] pencodingval
+		/ "CHARSET" [ws] "=" [ws] charsetval
+		/ "LANGUAGE" [ws] "=" [ws] langval
+		/ "X-" word [ws] "=" [ws] word
+		/ knowntype
+ptypeval	= knowntype / "X-" word
+pvalueval	= "INLINE" / "URL" / "CONTENT-ID" / "CID" / "X-" word
+pencodingval 	= "7BIT" / "8BIT" / "QUOTED-PRINTABLE" / "BASE64" / "X-" word
+charsetval	= <a character set string as defined in Section 7.1 of 
+		RFC 1521>
+langval		= <a language string as defined in RFC 1766>
+addressparts	= 0*6(strnosemi ";") strnosemi
+	; PO Box, Extended Addr, Street, Locality, Region, Postal Code,
+	Country Name
+orgparts	= *(strnosemi ";") strnosemi
+	; First is Organization Name, remainder are Organization Units.
+nameparts	= 0*4(strnosemi ";") strnosemi
+	; Family, Given, Middle, Prefix, Suffix.
+	; Example:Public;John;Q.;Reverend Dr.;III, Esq.
+strnosemi	= *(*nonsemi ("\;" / "\" CRLF)) *nonsemi
+	; To include a semicolon in this string, it must be escaped
+	; with a "\" character.
+nonsemi		= <any non-control ASCII except ";">
+knowntype	= "DOM" / "INTL" / "POSTAL" / "PARCEL" / "HOME" / "WORK"
+		/ "PREF" / "VOICE" / "FAX" / "MSG" / "CELL" / "PAGER"
+		/ "BBS" / "MODEM" / "CAR" / "ISDN" / "VIDEO"
+		/ "AOL" / "APPLELINK" / "ATTMAIL" / "CIS" / "EWORLD"
+		/ "INTERNET" / "IBMMAIL" / "MCIMAIL"
+		/ "POWERSHARE" / "PRODIGY" / "TLX" / "X400"
+		/ "GIF" / "CGM" / "WMF" / "BMP" / "MET" / "PMB" / "DIB"
+		/ "PICT" / "TIFF" / "PDF" / "PS" / "JPEG" / "QTIME"
+		/ "MPEG" / "MPEG2" / "AVI"
+		/ "WAVE" / "AIFF" / "PCM"
+		/ "X509" / "PGP"
+
+
+Section 3 : Internet Recommendations
+[DS4]	1	
+Recommended Practice with SMTP/MIME
+The vCard information can be transported through SMTP/MIME based electronic mail services. Interoperability of vCard information over SMTP/MIME transports can be better assured by following a common set of recommended practices for encapsulation of the vCard.
+Text/Plain Content Type
+Without any change to existing SMTP or MIME compliant user agents, a vCard can be included within Internet email messages. This might be the case for an existing, simple user agent such as a legacy SMTP mail system. While this approach provides for transport of vCards over SMTP services, it does not allow for the end user to take advantage of the full capabilities of either the vCard or Internet email (i.e., MIME) functionality.
+The following demonstrates how a vCard can be included as an epilog to a SMTP message made up of a RFC 822 message. This may be an initial method for incorporating vCard objects into SMTP messages.
+Date: Thr, 25 Jan 96 0932 EDT
+From: john.smith@host.com
+Subject: Re: RFC822 vCard Example
+Sender: john.smith@host.com
+To: smartin@host2.com
+Message-ID: <JOHNSMITH.960125T091020.xyzMail@host3.com>
+
+Steve:  Thanks for the call earlier today. I am unable to
+use your material at this time. Please feel free to contact
+me in the future.
+BEGIN:VCARD
+VERSION:2.1
+N:Smith;John;M.;Mr.;Esq.
+TEL;WORK;VOICE;MSG:+1 (919) 555-1234
+TEL;WORK;FAX:+1 (919) 555-9876
+ADR;WORK;PARCEL;POSTAL;DOM:Suite 101;1 Central St.;Any Town;NC;27654
+END:VCARD
+The following example demonstrates how a vCard can be included as a separate text/plain content portion within current MIME user agents.
+Date: Fri, 26 Jan 1996 07:53:00 -0500
+From: smartin@host2.com
+Subject: RE: Text/Plain MIME vCard Example
+To: fdawson@VNET.IBM.COM
+Mime-Version: 1.0
+Content-Type: multipart/mixed; boundary=vcard
+Message-ID: <ABC-1.00-Note-martin-steve-0824475754>
+
+--vcard
+Content-Type:text/plain; charset=us-ascii
+Content-Transfer-Encoding: 7bit
+John:  I have looked over my material and feel that you may
+have over looked a couple of appropriate pieces. Please give
+me a call so that we can discuss further.
+--vcard
+Content-Type:text/plain; charset=us-ascii; name="MARTIN.VCF"
+
+BEGIN:VCARD
+VERSION:2.1
+N:Martin;Stephen
+TEL;HOME;VOICE:+1 (210) 555-1357
+TEL;HOME;FAX:+1 (210) 555-0864
+ADR;WORK;PARCEL;POSTAL;DOM:123 Cliff Ave.;Big Town;CA;97531
+END:VCARD
+--vcard--
+Text/X-vCard Content Type
+A vCard object may also be transferred in a (RFC 1521) MIME entity as a non-standard "text/x-vCard" content-type. This (RFC 1521) MIME type maybe useful in those cases where the MIME compliant messaging service does not yet support the "application/directory" and "multipart/related" MIME content-types and yet the specificity of a calendaring and scheduling media type is required.
+The following example demonstrates how a vCard can be included as a separate non-standard text/x-vCard content portion within current MIME user agents.
+Date: Fri, 26 Jan 1996 07:53:00 +0000
+From: smartin@host2.com
+Subject: RE: Text/x-vCard MIME vCard Example
+To: fdawson@VNET.IBM.COM
+Mime-Version: 1.0
+Content-Type: multipart/mixed; boundary=vcard
+Message-ID: <ABC-1.00-Note-martin-steve-0824475754>
+
+--vcard
+Content-Type:text/plain; charset=us-ascii
+Content-Transfer-Encoding: 7bit
+John:  I have looked over my material and feel that you may
+have over looked a couple of appropriate pieces. Please give
+me a call so that we can discuss further.
+--vcard
+Content-Type:text/x-vCard; charset=us-ascii; name="MARTIN.VCF"
+
+BEGIN:VCARD
+VERSION:2.1N:Martin;Stephen
+TEL;HOME;VOICE:+1 (210) 555-1357
+TEL;HOME;FAX:+1 (210) 555-0864
+ADR;WORK;PARCEL;POSTAL;DOM:123 Cliff Ave.;Big Town;CA;97531
+END:VCARD
+--vcard--
+Application/Directory Content Type
+The Internet Engineering Task Force (IETF) Access and Searching of Internet Directories (ASID) working group has produced an Internet Draft defining the "application/directory" MIME content type. The current draft name is draft-ietf-asid-mime-direct-01.txt. This specification is intended to be aligned with this work. Internet Drafts are working documents of an IETF working group, valid for at most six months, and should be considered "works in progress". 
+This MIME content type was designed to be used to transport directory information across MIME based electronic mail services. The internet draft is directly applicable to the exchange of business card data, such as that defined by the vCard specification.
+The versit PDI Team has worked within the IETF ASID Working Group to draft an application/directory profile that registers the method for transporting a vCard as an application/directory Content-Type. The current draft name is draft-ietf-asid-mime-vcard-00.txt. This work is expected to be progressed to a Request For Comment after the publication of this version of the vCard specification. In the interim, the following guidelines are provided to describe how a vCard might be conveyed using the application/directory draft specification.
+A vCard should be included in a MIME message that has a Content-Type header field value of "multipart/related". The vCard is included in the message as the primary body part. The position of the body part entity can also be specified with the "start=" parameter. This MIME body part entity has a Content-Type body part header field value of "application/directory" with a "profile" parameter value of "vcard". Any vCard binary information, such as a logo, picture, or digital audio pronunciation can be included inline within the vCard, as is specified by the vCard specification. Preferably, the binary information should be extracted from the vCard object and contained in the MIME message as secondary body part entities. The binary content in the secondary body part entities can be referenced from within the vCard object through the use of the "VALUE=" property parameter. In this latter case, the binary information should be transformed into a content type nominally supported by MIME user agents. For image content, this would be the Graphics Image Format (GIF) or Joint Picture Encoding Group (JPEG) formats. For audio content, this would be the 8-bit mu-law (PCM) format specified by the MIME specification.
+The following example defines how this might be specified:
+Date: Mon, 29 Jan 96 0830 EDT
+From: john.smith@host.com
+Subject: Re: MIME application/directory vCard Example
+Sender: john.smith@host.com
+To: smartin@host2.com
+Message-ID: <JOHNSMITH.960129T083020.xyzMail@host3.com>
+Content-Type: multipart/related; boundary="vcard"; 
+			type=application/directory;
+			start=<JOHNSMITH.part1.960129T083020.xyzMail@host3.com>
+--vcard
+Content-Type: application/directory; charset=us-ascii;
+			source="file://versit.or2"; profile="vcard"
+Content-ID: <<JOHNSMITH.part1.960129T083020.xyzMail@host3.com>
+BEGIN:VCARD
+VERSION:2.1
+N:Smith;John;M.;Mr.;Esq.
+TEL;WORK;VOICE;MSG:+1 (919) 555-1234
+TEL;CELL:+1 (919) 554-6758
+TEL;WORK;FAX:+1 (919) 555-9876
+PHOTO;GIF;MIME:<<JOHNSMITH.part3.960129T083020.xyzMail@host3.com>
+ADR;WORK;PARCEL;POSTAL;DOM:Suite 101;1 Central St.;Any Town;NC;27654
+END:VCARD
+--vcard
+Content-Type: text/plain; charset=us-ascii
+Content-ID: <<JOHNSMITH.part2.960129T083020.xyzMail@host3.com>
+Steve:
+I am not in the office today. You may want to try
+reaching me either on my cellular telephone or fax your
+new ideas to my office.
+Let's setup a face-to-face meeting later this week, after I review
+your updated material. I am including a picture in my business card
+data, since we have not met yet.
+-- John
+--vcard
+Content-Type: image/gif
+Content-ID: <<JOHNSMITH.part3.960129T083020.xyzMail@host3.com>
+...image data would go here...
+--vcard--
+Recommended Practice with HTTP/HTML
+A vCard object should be transferred over HTTP with the non-standard  MIME type/subtype value of "text/x-vCard". The non-standard subtype should be used because the vCard has not been registered as a MIME media type with the IANA.
+The vCard information can be captured with a FORM type of HTML document. Interoperability of of vCard information can be better assured by following a common set of recommended practices for mapping vCard information into and out of HTML documents.
+Form Element Usage
+The HTML FORM element is a useful method for capturing data intended for input into individual vCard property values. The following recommended practices are provided for such use.
+Mapping To INPUT Element Attribute Names
+An HTML form data set is a useful mechanism for capturing vCard data within the Internet WWW. The use of a consistent naming scheme for the name attributes within a form element will permit implementations to support automatic fill-in of forms with existing vCard data. In addition, such a consistent naming scheme will provide a greater assurance of interoperability between HTML based applications that use vCard data.
+The following table provides a recommended mapping of vCard properties and name attributes within a form element.
+Identification Properties
+Description
+Attribute Name
+Comment
+
+Formatted Name
+FN
+
+
+Name
+N
+Individual components of name property are captured as separate input elements with the names N.Family, N.First, N.Middle, N.Prefix, N.Suffix.
+
+Photograph
+PHOTO
+Only the URL based specification is supported by this mapping. Value is the URL for the graphic.
+
+Photograph Format Type
+PHOTO.Type
+Where the value is one of the enumerated strings defined by the vCard specification. 
+
+Birthdate
+BDAY
+
+
+
+Delivery Addressing Properties
+Description
+Attribute Name
+Comment
+
+Delivery Address
+ADR
+TYPE=TEXTAREA
+
+Address Type
+ADR.x
+TYPE=CHECKBOX. Separate input elements are used to capture the possible delivery types. The elements are named ADR.x, where x is one of the enumerated strings defined by the vCard specification.
+
+Delivery Label
+LABEL
+
+
+Label Type
+LABEL.x
+TYPE=CHECKBOX. Separate input elements are used to capture the possible delivery types. The elements are named LABEL.x, where x is one of the enumerated strings defined by the vCard specification.
+
+
+Telecommunications Addressing Properties
+Description
+Attribute Name
+Comment
+
+Telephone Number
+TEL
+
+
+Telephone Type
+TEL.x
+TYPE=CHECKBOX. Separate input elements are used to capture the possible telephone types. The elements are named TEL.x, where x is one of the enumerated strings defined by the vCard specification.
+
+Electronic Mail Address
+EMAIL
+
+
+Electronic Mail Address Type
+EMAIL.Type
+Selection option from a list of alternatives.
+
+Mailer
+MAILER
+
+
+
+Geographical Properties
+Description
+Attribute Name
+Comment
+
+Time Zone
+TZ
+
+
+Geographic Position
+GEO
+
+
+
+Organizational Properties
+Description
+Attribute Name
+Comment
+
+Title
+TITLE
+
+
+Business Category
+ROLE
+
+
+Logo
+LOGO
+Only the URL based specification is supported by this mapping. Value is the URL for the graphic.
+
+Logo Format Type
+LOGO.Type
+Where the value is one of the enumerated strings defined by the vCard specification. 
+
+Agent
+
+Captured through a separate form element using the mapping defined in these tables.
+
+Organization
+ORG
+TYPE=TEXT. Separate input elements for the organizational name and unit. The name ORG.Name is used to capture the organizational name. The name ORG.UNIT is used to capture the organizational unit. If there are multiple organizational units, it is captured in a form with name attributes ORG.UNIT1, ORG.UNIT2, etc.
+
+
+Explanatory Properties
+Description
+Attribute Name
+Comment
+
+Comment
+NOTE
+TYPE=TEXT
+
+Last Revision
+REV
+A hidden field.
+
+Version
+VERSION
+A hidden field with the value set to the string ì2.1î.
+
+Language
+LANG
+A hidden field with the value set to the string associated with the default language used in the form (e.g., US-eng).
+
+Sound
+SOUND
+TYPE=TEXT
+
+Sound Type
+N/A
+
+
+Uniform Resource Locator
+URL
+TYPE=TEXT
+
+Unique Identifier
+UID
+TYPE=TEXT
+
+Binary Encoding
+BE.x
+Where x is one of the enumerated encoding types defined by the vCard specification.
+
+
+Security Properties
+Description
+Attribute Name
+Comment
+
+Public Key
+KEY
+
+
+Key Type
+KEY.Type.x
+Where x is one of the enumerated encoding types defined by the vCard specification.
+
+MISCELLANEOUS PROPERTIES
+
+
+
+Extensions
+X-x
+Where x is a string defined by the extension author.
+
+
+Where multiple properties (e.g., telephone numbers) appear, a label prefix should be used. For example, telephone #1 might have a name attribute of ìA.TELî, telephone #2 might have a name attribute of ìB.TELî, etc.
+Example HTML Code
+The following HTML code is an example of the use of the mapping of INPUT element attributes names to vCard property names. The code can be used to capture input data for creating a vCard on a Web homepage.
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
+<head>
+<title>Create Your Own Versitcard</title>
+</head>
+<IMG src="versit.gif">
+<h1>Create Your Own Versitcard</h1>
+<P> Fill out this form and we'll
+create a <b>Versitcard</b> for you and send it to the email address of your choice,
+along with more information on the Versitcard format.</P>
+<hr><!-- Identification And Organizational Properties -->
+<FORM METHOD="POST" ACTION="/cgi-bin/vcard-maker">
+Formatted Name:<INPUT name="FN" type=text size=32 maxlength=64
+value=""><br>
+Phoenetic Pronunciation:<INPUT name="SOUND" type=text size=32 maxlength=128 value=""><br>
+Company Name:<INPUT name="ORG.Name" type=text  size=32 maxlength=64
+value=""><br>
+Company Unit:<INPUT name="ORG.Unit" type=text size=32
+maxlength=64 value=""><br>
+Title:<INPUT name="TITLE" type=text size=32 maxlength=64
+value="">
+<hr><!-- Name Property Component Values -->
+Family Name:<INPUT name="N.Family" type=text size=32 maxlength=64
+value=""><br>
+Given Name:<INPUT name="N.Given" type=text size=32
+maxlength=64 value=""><br>
+Middle Name:<INPUT name="N.Middle" type=type size=32
+maxlength=64 value=""><br>
+Name Prefix:<INPUT name="N.Prefix" type=type size=32
+maxlength=64 value=""><br>
+Name Suffix:<INPUT name="N.Suffix" type=type size=32
+maxlength=64 value=""><br>
+<hr><!-- Delivery Addressing Properties -->
+Delivery Label:<TEXTAREA name="LABEL" cols=64 ROWS=5>
+</TEXTAREA><br><br>
+Post Office Address:<INPUT name="ADR.POAddr" type=text size=32
+maxlength=64 value=""><br>
+Extended Address:<INPUT name="ADR.ExtAddr" type=text size=32
+maxlength=64 value=""><br>
+Street Address:<INPUT name="ADR.Street" type=text size=62
+maxlength=128 value=""><br>
+City:<INPUT name="ADR.Locality" type=text size=16 maxlength=32
+value="">
+Region:<INPUT name="ADR.Region" type=text size=16 maxlength=32
+value="">
+Postal Code:<INPUT name="ADR.PostalCode" type=text size=16 maxlength=32
+value=""><br>
+Country Name:<INPUT name="ADR.CountryName" type=text size=16 maxlength=32 value="USA">
+<INPUT type=checkbox name="ADR.Work" value=WORK checked>Work
+<INPUT type=checkbox name="ADR.Home" value=HOME>Home
+<INPUT type=checkbox name="ADR.Parcel" value=PARCEL checked>Parcel <INPUT type=checkbox name="ADR.Postal" value=POSTAL checked>Postal<br>
+<hr><!-- Geographical Properties -->
+TimeZone:<INPUT name="TZ" type=text size=3 maxlength=8
+value="-06">
+Location:<INPUT name="GEO" type=text size=16 maxlength=32 value=""><br>
+<hr><!-- Telephony Addressing Properties -->
+<!-- Telephone #1 -->
+Telephone #1:<INPUT type=text name="A.TEL" size=20 maxlength=40 value="+1 (000) 000-0000"><br>
+<INPUT type=checkbox name="A.TEL.Work" value=WORK checked>Work
+<INPUT type=checkbox name="A.TEL.Home" value=HOME>Home
+<INPUT type=checkbox name="A.TEL.Voice" value=VOICE checked>Voice
+<INPUT type=checkbox name="A.TEL.Msg" value=MSG checked>Msg <INPUT type=checkbox name="A.TEL.Fax" value=FAX>Fax <INPUT type=checkbox name="A.TEL.Prefer" value=PREFER checked>Preferred<br>
+<hr><!-- Telephone #2 -->
+Telephone #2:<INPUT type=text name="B.TEL" size=20 maxlength=40 value="+1 (000) 000-0000"><br>
+<INPUT type=checkbox name="B.TEL.Work" value=WORK checked>Work <INPUT type=checkbox name="B.TEL.Home" value=HOME>Home
+<INPUT type=checkbox name="B.TEL.Voice" value=VOICE>Voice <INPUT type=checkbox name="B.TEL.Msg" value=MSG>Msg 
+<INPUT type=checkbox name="B.TEL.Fax" value=FAX checked>Fax
+<INPUT type=checkbox name="B.TEL.Prefer" value=PREFER>Preferred<br>
+<hr><!-- Telephone #3 -->
+Telephone #3:<INPUT type=text name= "C.TEL" size=20 maxlength=40 value="+1 (000) 000-0000"><br>
+<INPUT type=checkbox name="C.TEL.Work" value=WORK>Work
+<INPUT type=checkbox name="C.TEL.Home" value=HOME checked>Home <INPUT type=checkbox name="C.TEL.Voice" value=VOICE checked>Voice <INPUT type=checkbox name="C.TEL.Msg" value=MSG checked>Msg
+<INPUT type=checkbox name="C.TEL.Fax" value=FAX checked>Fax <INPUT type=checkbox name="D.Prefer" value=PREFER>Preferred<br>
+<hr><!-- Email D -->
+EmailAddress: <select name="D.EMAILTYPE">
+<option selected>INTERNET:
+<option>CompuServe:
+<option>AOL:
+<option>Prodigy:
+<option>eWorld:
+<option>AppleLink:
+<option>AppleTalk:
+<option>PowerShare:
+<option>IBMMail:
+<option>ATTMail:
+<option>MCIMail:
+<option>X.400:
+<option>TLX:
+</select><INPUT type=text name="D.EMAIL" size=32 maxlength=64 value="">
+<INPUT type=checkbox name="D.EMAIL.Work" value=WORK checked>Work <INPUT type=checkbox name="D.EMAIL.Home" value=HOME checked>Home<br>
+<hr><!-- End of vCard Input -->
+Send my Versitcard to this <b>internet</b> email address: 
+<INPUT type=text name="SENDTOADDR" size=32 maxlength=64 value=""><br> Press <INPUT TYPE=SUBMIT value="Send"> to send the form now. Or, press <INPUT TYPE=RESET value="Reset"> to reset values to the form defaults.
+</form>
+</body>
+
+
+Section 4 : UI Support Recommendations
+[DS5]		
+When  integrating vCard support into an application, an implementor needs to consider a number of user interface (UI) implications. Most appliss Type
+ADR.x
+TYPE=CHECKBOX. Separate input elements are used to capture the possible delivery types. The elements are named ADR.x, where x is one of the enumerated strings defined by the vCard specification.
+
+Delivery Label
+LABEL
+
+
+Label Type
+LABEL.x
+TYPE=CHECKBOX. Separate input elements are used to capture the possible delivery types. The elements are named LABEL.x, where x is one of the enumerated strings defined by the vCard specification.
+
+
+Telecommunications Addressing Properties
+Description
+Attribute Name
+Comment
+
+Telephone Number
+TEL
+
+
+Telephone Type
+TEL.x
+TYPE=CHECKBOX. Separate input elements are used to capture the possible telephone types. The elements are named TEL.x, where x is one of the enumerated strings defined by the vCard specification.
+
+Electronic Mail Address
+EMAIL
+
+
+Electronic Mail Address Type
+EMAIL.Type
+Selection option from a list of alternatives.
+
+Mailer
+MAILER
+
+
+
+Geographical Properties
+Description
+Attribute Name
+Comment
+
+Time Zone
+TZ
+
+
+Geographic Position
+GEO
+
+
+
+Organizational Properties
+Description
+Attribute Name
+Comment
+
+Title
+TITLE
+
+
+Business Category
+ROLE
+
+
+Logo
+LOGO
+Only the URL based specification is supported by this mapping. Value is the URL for the graphic.
+
+Logo Format Type
+LOGO.Type
+Where the value is one of the enumerated strings defined by the vCard specification. 
+
+Agent
+
+Captured through a separate form element using the mapping defined in these tables.
+
+Organization
+ORG
+TYPE=TEXT. Separate input elements for the organizational name and unit. The name ORG.Name is used to capture the organizational name. The name ORG.UNIT is used to capture the organizational unit. If there are multiple organizational units, it is captured in a form with name attributes ORG.UNIT1, ORG.UNIT2, etc.
+
+
+Explanatory Properties
+Description
+Attribute Name
+Comment
+
+Comment
+NOTE
+TYPE=TEXT
+
+Last Revision
+REV
+A hidden field.
+
+Version
+VERSION
+A hidden field with the value set to the string ì2.1î.
+
+Language
+LANG
+A hidden field with the value set to the string associated with the default language used in the form (e.g., US-eng).
+
+Sound
+SOUND
+TYPE=TEXT
+
+Sound Type
+N/A
+
+
+Uniform Resource Locator
+URL
+TYPE=TEXT
+
+Unique Identifier
+UID
+TYPE=TEXT
+
+Binary Encoding
+BE.x
+Where x is one of the enumerated encoding types defined by the vCard specification.
+
+
+Security Properties
+Description
+Attribute Name
+Comment
+
+Public Key
+KEY
+
+
+Key Type
+KEY.Type.x
+Where x is one of the enumerated encoding types defined by the vCard specification.
+
+MISCELLANEOUS PROPERTIES
+
+
+
+Extensions
+X-x
+Where x is a string defined by the extension author.
+
+
+Where multiple properties (e.g., telephone numbers) appear, a label prefix should be used. For example, telephone #1 might have a name attribute of ìA.TELî, telephone #2 might have a name attribute of ìB.TELî, etc.
+Example HTML Code
+The following HTML code is an example of the use of the mapping of INPUT element attributes names to vCard property names. The code can be used to capture input data for creating a vCard on a Web homepage.
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
+<head>
+<title>Create Your Own Versitcard</title>
+</head>
+<IMG src="versit.gif">
+<h1>Create Your Own Versitcard</h1>
+<P> Fill out this form and we'll
+create a <b>Versitcard</b> for you and send it to the email address of your choice,
+along with more information on the Versitcard format.</P>
+<hr><!-- Identification And Organizational Properties -->
+<FORM METHOD="POST" ACTION="/cgi-bin/vcard-maker">
+Formatted Name:<INPUT name="FN" type=text size=32 maxlength=64
+value=""><br>
+Phoenetic Pronunciation:<INPUT name="SOUND" type=text size=32 maxlength=128 value=""><br>
+Company Name:<INPUT name="ORG.Name" type=text  size=32 maxlength=64
+value=""><br>
+Company Unit:<INPUT name="ORG.Unit" type=text size=32
+maxlength=64 value=""><br>
+Title:<INPUT name="TITLE" type=text size=32 maxlength=64
+value="">
+<hr><!-- Name Property Component Values -->
+Family Name:<INPUT nies.
+All forms of vCard Grouping must be able to be parsed and processed.
+Property Grouping must be able to be parsed and processed.
+Additionally, in order for a vCard Writer to conform to this specification it must meet the following additional criteria:
+Must be able to send at least the Version, Formatted Name, Name, Address,  Telephone, Email, and Mailer properties.
+
+
+[DS1]This entry (merged from the ìTRIAL USE (TU)î document) appears to be a duplicate of the already-existing entry that follows, except for the publicaton/edition date. I would assume that itís OK to delete this item, but, Ö
+[DS2]This entry/line in the section is assigned the style for the level 1 heading. This is done so that a section number can be given in the chapter title (style "chptr_title") and so that "heading 1" (more specifically, the format/heading numbering of the form "1. Overview") can be "skipped," and the appropriate form for the next-level of heading can be properly displayed (eg., "1.1   Overview"). It is, and must be, formatted as "hidden text" prior to pagination and/or printing.
+[DS3]This entry/line in the section is assigned the style for the level 1 heading. This is done so that a section number can be given in the chapter title (style "chptr_title") and so that "heading 1" (more specifically, the format/heading numbering of the form "1. Overview") can be "skipped," and the appropriate form for the next-level of heading can be properly displayed (eg., "1.1   Overview"). It is, and must be, formatted as "hidden text" prior to pagination and/or printing.
+[DS4]This entry/line in the section is assigned the style for the level 1 heading. This is done so that a section number can be given in the chapter title (style "chptr_title") and so that "heading 1" (more specifically, the format/heading numbering of the form "1. Overview") can be "skipped," and the appropriate form for the next-level of heading can be properly displayed (eg., "1.1   Overview"). It is, and must be, formatted as "hidden text" prior to pagination and/or printing.
+[DS5]This entry/line in the section is assigned the style for the level 1 heading. This is done so that a section number can be given in the chapter title (style ìchptr_title") and so that "heading 1" (more specifically, the format/heading numbering of the form "1. Overview") can be "skipped," and the appropriate form for the next-level of heading can be properly displayed (eg., "1.1   Overview"). It is, and must be, formatted as "hidden text" prior to pagination and/or printing.
+[DS6]This entry/line in the section is assigned the style for the level 1 heading. This is done so that a section number can be given in the chapter title (style ìchptr_title") and so that "heading 1" (more specifically, the format/heading numbering of the form "1. Overview") can be "skipped," and the appropriate form for the next-level of heading can be properly displayed (eg., "1.1   Overview"). It is, and must be, formatted as "hidden text" prior to pagination and/or printing.
+
+
+
+
+
+
+
+$paratext[Pr.Preface]		
+
+
+
+
+
+
+
+		
+vi		vCard Specification, Version 2.1
+
+		v
+
+versit Update	vii
+
+
+
+
+
+
+
+36		vCard Specification, Version 2.1
+
+		xi
+
+
+
+
+		39
+
+