Internet Draft                                               R. Gellens
Document: draft-ietf-acap-email-06.txt                         QUALCOMM
Expires: August 2003                                      February 2003


                    ACAP Email Account Dataset Class


Status of this Memo:

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as
    Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other documents
    at any time.  It is inappropriate to use Internet- Drafts as
    reference material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    <http://www.ietf.org/ietf/1id-abstracts.txt>

    The list of Internet-Draft Shadow Directories can be accessed at
    <http://www.ietf.org/shadow.html>.

    A version of this draft document is intended for submission to the
    RFC editor as a Proposed Standard for the Internet Community.
    Discussion and suggestions for improvement are requested.


Copyright Notice

    Copyright (C) The Internet Society 2003.  All Rights Reserved.


Abstract

    It has become common for Internet mail users to have more than one
    account where mail is received, to access multiple accounts from the
    same machine, to access the same accounts from different machines,
    and to use multiple programs which require email account
    configuration information.

    The Application Configuration Access Protocol [ACAP] provides an
    ideal mechanism for storage of email account data.



Gellens                   Expires August 2003                   [Page 1]


Internet Draft      ACAP Email Account Dataset Class      February 2003


    This specification defines an interoperable ACAP dataset class for
    email accounts, and a common option for indicating a default email
    account.
















































Gellens                   Expires August 2003                   [Page 2]


Internet Draft      ACAP Email Account Dataset Class      February 2003


Table of Contents

    1.  Conventions Used in this Document . . . . . . . . . . . . . .  3
    2.  Changes Since the Previous Version . . . . . . . . . . . . .   3
    3.  Comments  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
    4.  ACAP Standard Options  . . . . . . . . . . . . . . . . . . .   3
    5.  ACAP Email Account Dataset Class  . . . . . . . . . . . . . .  4
      5.1.  ACAP Email Account Dataset Class Prefix  . . . . . . . .   4
      5.2.  ACAP Email Account Dataset Hierarchy  . . . . . . . . . .  4
    6.  ACAP Email Account Dataset Attributes  . . . . . . . . . . .   4
      6.1.  Basic Attributes  . . . . . . . . . . . . . . . . . . . .  5
      6.2.  Specific Attributes  . . . . . . . . . . . . . . . . . .   5
    7.  Dataset Class Capabilities  . . . . . . . . . . . . . . . . . 10
    8.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  10
    9.  Normative References  . . . . . . . . . . . . . . . . . . . . 11
     10.  Informative References . . . . . . . . . . . . . . . . . .  12
     11.  Security Considerations . . . . . . . . . . . . . . . . . . 12
     12.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . .  12
     13.  Author's Address  . . . . . . . . . . . . . . . . . . . . . 12
      Intellectual Property Statement  . . . . . . . . . . . . . . .  12
      Full Copyright Statement  . . . . . . . . . . . . . . . . . . . 13


1.  Conventions Used in this 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 [KEYWORDS].


2.  Changes Since the Previous Version

    - Minor text clarifications.
    - Updated boilerplate.


3.  Comments

    Public comments can be sent to the IETF ACAP mailing list,
    <ietf-acap+@andrew.cmu.edu>.  To subscribe, send a message to
    <ietf-acap-request+@andrew.cmu.edu> with the word SUBSCRIBE as the
    body.  Private comments should be sent to the author.


4.  ACAP Standard Options

    This specification defines the Message User Agent (MUA) Default
    Account standard option.  This is a scaler option in the ACAP
    Standard Option ("/option") dataset.  The entry name is


Gellens                   Expires August 2003                   [Page 3]


Internet Draft      ACAP Email Account Dataset Class      February 2003


    "mua.default.account".  The "option.value" attribute contains the
    value, which is a URL.  Generally, this will be an ACAP URL pointing
    to an entry in an Email Account dataset.

    The standard option dataset class is specified in [ACAP-OPTIONS].
    ACAP URLs are defined in [ACAP].


5.  ACAP Email Account Dataset Class

    The ACAP Email Account dataset class defines a set of attributes
    which specify an email account; that is, configuration information
    used for access to mail on a POP [POP3] or IMAP [IMAP4] server.

    Configuration information related to composing and sending mail is
    stored in the ACAP Email Personality Dataset Class
    [ACAP-PERSONALITY].


5.1.  ACAP Email Account Dataset Class Prefix

    Datasets whose names begin with "/email" are assumed to contain
    email account entries as defined in this specification.


5.2.  ACAP Email Account Dataset Hierarchy

    Each user may have a set of named email accounts.  The default is
    pointed at by the "mua.default.account" standard option. (See
    section 4, ACAP Standard Options, for more information.)

    Inheritance is likely to be useful both for inheriting site or group
    defaults (for example, POP or IMAP servers, and initial client
    configuration in general) as well as for inheriting user-specific
    configuration when using different machines.


6.  ACAP Email Account Dataset Attributes

    An email account entry MUST have an "entry" attribute.  All other
    attributes are OPTIONAL.

    Attributes are specified using Augmented Backus-Naur Form [ABNF].
    All attributes are single-valued and textual (non-binary) unless
    otherwise stated.

    The ABNF defines the content of the attribute values prior to their
    encoding as an ACAP string.  Clients MUST conform to the syntax when
    generating these attributes, but MUST NOT assume that the attribute


Gellens                   Expires August 2003                   [Page 4]


Internet Draft      ACAP Email Account Dataset Class      February 2003


    values will conform to this syntax on access.  Servers MUST NOT
    enforce the syntax.


6.1.  Basic Attributes

    These attributes are defined in ACAP [ACAP] and have meaning in all
    dataset classes.  The section describes how they are used in an
    email account dataset.

    entry
        The "entry" attribute is used to hold a unique name for the
        email account.  This name is used for inheritance, so when
        customizing an account which has an entry in an inherited
        dataset, the entry name needs to remain the same.  The name
        should also be descriptive, as it is suitable for user display.

    subdataset
        The "subdataset" attribute indicates that there is a subdataset
        of this entry.  The value of this attribute specifies the actual
        location of the subdataset, per [ACAP] section 3.1.1.


6.2.  Specific Attributes

    These attributes are specific to the Email Account dataset class.

    email.boring-headers
        This multi-valued attribute is a list of header prefixes.  If
        the client has a mode where it suppresses display of certain
        headers and/or properties of messages, headers which start with
        a prefix included in this attribute are candidates for
        suppression.  Prefix strings are case-insensitive.

        email-boring         = 1*VCHAR

    email.check-interval
        This specifies the interval, in seconds, between checks (polls)
        for new mail.  A value of 0 indicates that automatic mail checks
        SHOULD NOT be done.

        email-check-int      = 1*DIGIT

    email.connection-type
        This contains a token indicating the type of connection used for
        this email account.  Clients might use this information to
        modify their use of bandwidth.

        email-conn           = "LAN" / "cable-modem" / "phone-modem" /


Gellens                   Expires August 2003                   [Page 5]


Internet Draft      ACAP Email Account Dataset Class      February 2003


                               "mobile-phone"

    email.imap.download-type
        This specifies which elements of messages are to be downloaded
        when populating or resynchronizing a mailbox.  This is only
        useful when accessing messages via IMAP [IMAP4]. "Headers"
        indicates only minimal message information, such as sender,
        recipient, and subject. "Structure" specifies important headers
        and body structure information. "Body" means headers, body
        structure information and the contents of body parts, but not
        attachments. "Attachments" indicates all elements of messages.

        email-dload          = "headers" / "structure" / "body" /
                               "inline" /  "attachments"

    email.leave-on-server.flag
        This specifies if the client should delay deleting mail from the
        server after downloading.  This is generally useful only with
        POP servers [POP3] which support this.

        email-lmos-flag      = "0" / "1"

    email.leave-on-server.days
        When email.leave-on-server.flag is set (value is "1"), this
        attribute specifies the number of days messages should remain on
        the server before being deleted by the client.  This is
        generally useful only with POP servers [POP3] which support
        leaving mail on the server.  Note that a value of "0" indicates
        that clients SHOULD never automatically delete mail from the
        server.

        email-lmos-days      = 1*DIGIT

    email.maximum.download-size
        This contains the maximum size (in octets) of messages to be
        downloaded.  This is most useful when accessing messages via POP
        [POP3], although it might also be used with IMAP [IMAP4] to
        specify a limit on the size of attachments to be downloaded.  A
        value of "0" indicates no limit.

        email-max-dsize      = 1*DIGIT

    email.mailbox-prefix
        This attribute contains a prefix required to access this
        account's IMAP folders.  This is only useful when accessing
        messages via IMAP [IMAP4].

        email-prefix         = 1*CHAR



Gellens                   Expires August 2003                   [Page 6]


Internet Draft      ACAP Email Account Dataset Class      February 2003


    email.personality
        This specifies the default personality to assign to messages
        received via this email account.  It is generally an ACAP URL to
        an entry in an Email Personality dataset.  The ACAP Email
        Personality dataset class is specified in [ACAP-PERSONALITY].
        ACAP-URLs are defined in [ACAP].

        email-personality    = url ;defined in [URL-BASIC]

    email.server.IMAP
        The indicates the default IMAP server to use with this email
        account.  It is generally an IMAP URL, as specified in
        [URL-IMAP].

        email-imap           = url ;defined in [URL-BASIC]

    email.server.POP
        This specifies the POP server associated with this email
        account.  It is generally a POP URL, as defined in [URL-POP].

        email-pop            = url ;defined in [URL-BASIC]

    email.server.Local
        This indicates that this email account refers to a mailstore on
        the local client.  When set to "1", the "email.server.IMAP" and
        "email.server.POP" attributes are ignored.

        email-local          = "0"/"1"

    email.sieve.capability
        This multivalued attribute contains a list of [SIEVE] capability
        strings.  These strings represent extensions supported by the
        Sieve execution engine which processes the Sieve script
        contained in "email.sieve.script".

        Note that this attribute SHOULD NOT be modified except by the
        Sieve execution engine or its agent.  Normally, this attribute
        is inherited from a site-specific dataset.

        email-sieve-cap      = 1*CHAR

    email.sieve.script
        This specifies the text of a Sieve script which will be applied
        by the delivery agent (if supported) to mail arriving at this
        email account.  Sieve is specified in [SIEVE].

        Note that multiple Sieve scripts may be stored.  The active
        script is always called "email.sieve.script", while additional
        scripts may be stored in names of the form "email.sieve.foo",


Gellens                   Expires August 2003                   [Page 7]


Internet Draft      ACAP Email Account Dataset Class      February 2003


        where "foo" is the name of a non-active script.

        email-sieve          = 1*UTF8-CHAR

    email.sieve.runtime.errors
        If supported by the Sieve implementation (see section 7), this
        attribute contains the count of runtime errors detected in the
        currently active Sieve script.  This count SHOULD be cleared
        when a new script is stored.  It MAY be reset at other times, at
        the discretion of the server.  Sieve is specified in [SIEVE].

        email-sieve-runerr   = 1*DIGIT

    email.sieve.runtime.warnings
        If supported by the Sieve implementation (see section 7), this
        attribute contains the count of runtime warnings detected in the
        currently active Sieve script.  This count SHOULD be cleared
        when a new script is stored.  It MAY be reset at other times, at
        the discretion of the server.  Sieve is specified in [SIEVE].

        email-sieve-runwarn  = 1*DIGIT

    email.sieve.runtime.errtxt
        If supported by the Sieve implementation (see section 7), this
        attribute contains the text of runtime errors detected in the
        currently active Sieve script.  The error text is formated into
        CRLF-separated lines, one line per error.  Each line contains
        named attributes of the error, in a MIME-header-like format.
        The currently specified attributes are: line, offset, length,
        and text.  Text MUST always be the last attribute.  This
        attribute SHOULD be cleared when a new script is stored.  It MAY
        be reset at other times, at the discretion of the server.  Sieve
        is specified in [SIEVE].

        The format is intended to be easy for a Sieve execution agent to
        generate, and easy for a Sieve user agent to parse.  The Sieve
        user agent could use the information to highlight the indicated
        section of the Sieve script text, as specified by the line,
        offset, and length.

        email-sieve-errtxt  = *(non-text-sieve-att ";" SP)
                              text-sieve-att CRLF
        non-text-sieve-att  = sieve-att-line / sieve-att-off /
                              sieve-att-len / sieve-att-ext
        text-sieve-att      = "text"      ":" SP 1*UTF8-CHAR
                                               ;MAY use ":" or ";"
                                               ;MUST NOT use CRLF
        sieve-att-line      = "line"      ":" SP 1*DIGIT
        sieve-att-off       = "offset"    ":" SP 1*DIGIT


Gellens                   Expires August 2003                   [Page 8]


Internet Draft      ACAP Email Account Dataset Class      February 2003


        sieve-att-len       = "length"    ":" SP 1*DIGIT
        sieve-att-ext       = 1*UTF8-CHAR ":" SP 1*UTF8-CHAR
                                               ;MUST NOT use ":" or ";"

    email.sieve.runtime.warntxt
        If supported by the Sieve implementation (see section 7), this
        attribute contains the text of runtime warnings detected in the
        currently active Sieve script.  The warning text is formated
        into CRLF-separated lines, one line per warning, as specified
        for "email.sieve.runtime.errtxt".  This attribute SHOULD be
        cleared when a new script is stored.  It MAY be reset at other
        times, at the discretion of the server.  Sieve is specified in
        [SIEVE].

        email-sieve-warntxt  = email-sieve-errtxt


    email.sieve.syntax.errors
        If supported by the Sieve implementation (see section 7), this
        attribute contains the count of syntax errors detected in the
        most recently stored Sieve script.  Sieve is specified in
        [SIEVE].

        email-sieve-synerr   = 1*DIGIT

    email.sieve.syntax.warnings
        If supported by the Sieve implementation (see section 7), this
        attribute contains the count of syntax warnings detected in the
        most recently stored Sieve script.  Sieve is specified in
        [SIEVE].

        email-sieve-synwarn  = 1*DIGIT

    email.sieve.syntax.errtxt
        If supported by the Sieve implementation (see section 7), this
        attribute contains the text of syntax errors detected in the
        most recently stored Sieve script.  The error text is formated
        into CRLF-separated lines, one line per error, as specified for
        "email.sieve.runtime.errtxt".  Sieve is specified in [SIEVE].

        email-sieve-synerrtxt = email-sieve-errtxt

    email.sieve.syntax.warntxt
        If supported by the Sieve implementation (see section 7), this
        attribute contains the text of syntax warnings detected in the
        most recently stored Sieve script.  The warning text is formated
        into CRLF-separated lines, one line per warning, as specified
        for "email.sieve.runtime.errtxt".  Sieve is specified in
        [SIEVE].


Gellens                   Expires August 2003                   [Page 9]


Internet Draft      ACAP Email Account Dataset Class      February 2003


        email-sieve-synwarntxt = email-sieve-errtxt

    email.trash-folder
        This attribute contains the name of a folder to which messages
        SHOULD be moved in lieu of immediately marking them deleted.  If
        empty, messages SHOULD be marked deleted.  This is only useful
        when accessing messages via IMAP [IMAP4].

        email-trash          = 1*CHAR


7.  Dataset Class Capabilities

    Certain attributes in the Email Account dataset class are only
    available if there is integrated server support or an active client
    providing them.  Availability of such attributes is indicated by
    corresponding attributes in the "email" entry of the "capability"
    dataset.  The capability attribute has the name of the attribute in
    the Email dataset, prefixed with "capability.", and has a value of
    "1" if the corresponding attribute in the Email dataset is
    supported.

        capability.email.sieve.runtime.errors
        capability.email.sieve.runtime.warnings
        capability.email.sieve.runtime.errtxt
        capability.email.sieve.runtime.warntxt
        capability.email.sieve.syntax.errors
        capability.email.sieve.syntax.warnings
        capability.email.sieve.syntax.errtxt
        capability.email.sieve.syntax.warntxt

    Note that these attributes SHOULD NOT be modified except by the
    server or an active client responsible for supporting the underlying
    capability.  These attributes are normally inherited from a
    site-specific dataset.


8.  Examples

        entry                        home
        email.connection-type        phone-modem
        email.personality            home
        email.server.pop             POP://jru;AUTH=APOP@pop.isp.com
        email.sieve.capability       ("vacation" "mark")
        email.sieve.script           if header :matches "subject"
                                            [ "*make*money*fast*",
                                              "*university*dipl*mas*" ]
                                          {
                                          discard;


Gellens                  Expires August 2003                  [Page 10]


Internet Draft      ACAP Email Account Dataset Class      February 2003


                                          }
        email.boring-headers         ("received" "message" "x400")


        entry                        work
        email.connection-type        direct
        email.personality            work
        email.server.imap            IMAP://jru@mail.bigcorp.com
        email.sieve.capability       ("fileinto" "vacation" "envelope")
        email.sieve.script           if header :is "Sender"
                                                "BigCheese@example.com"
                                         {
                                         fileinto "Blatherings";
                                         }
        email.trash-folder           Trash


9.  Normative References

    [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
    ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd.,
    November 1997. <ftp://ftp.isi.edu/in-notes/rfc2234.txt>

    [ACAP] Newman, Myers, "ACAP -- Application Configuration Access
    Protocol", RFC 2244, Innosoft, Netscape, November 1997.
    <ftp://ftp.isi.edu/in-notes/rfc2244.txt>

    [ACAP-OPTIONS] Hole, "ACAP Application Options Dataset Class", The
    Esys Corporation, work in Progress,
    <ftp://ftp.ietf.org/internet-drafts/draft-ietf-acap-options-xx.txt>

    [ACAP-PERSONALITY] Gellens, "ACAP Email Personality Dataset Class",
    QUALCOMM Incorporated, work in Progress,
    <ftp://ftp.ietf.org/internet-drafts/draft-ietf-acap-pers-xx.txt>

    [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
    Requirement Levels", RFC 2119, Harvard University, March 1997.
    <ftp://ftp.isi.edu/in-notes/rfc2119.txt>

    [SIEVE] Showalter, "Sieve:  A Mail Filtering Language", RFC 3028,
    Mirapoint, Inc, January 2001.
    <ftp://ftp.isi.edu/in-notes/rfc3028.txt>

    [URL-BASIC] Berners-Lee, Masinter, McCahill, "Uniform Resource
    Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of
    Minnesota, December 1994. <ftp://ftp.isi.edu/in-notes/rfc1738.txt>





Gellens                  Expires August 2003                  [Page 11]


Internet Draft      ACAP Email Account Dataset Class      February 2003


    [URL-IMAP] Newman, "IMAP URL Scheme", RFC 2192, Innosoft, September
    1997. <ftp://ftp.isi.edu/in-notes/rfc2192.txt>

    [URL-POP] Gellens, "POP URL Scheme", RFC 2384, QUALCOMM
    Incorporated, August 1998. <ftp://ftp.isi.edu/in-notes/rfc2384.txt>

    [UTF8] Yergeau, F. "UTF-8, a transformation format of ISO 10646",
    RFC 2279, Alis Technologies, January 1998.
    <ftp://ftp.isi.edu/in-notes/rfc2279.txt>


10.  Informative References

    [IMAP4] Crispin, "Internet Message Access Protocol - Version 4rev1",
    RFC 2060, University of Washington, December 1996.

    [POP3] Myers, Rose, "Post Office Protocol -- Version 3", RFC 1939,
    Carnegie Mellon, Dover Beach Consulting, Inc., May 1996.
    <ftp://ftp.isi.edu/in-notes/rfc1939.txt>


11.  Security Considerations

    As with ACAP datasets in general, it is important that access
    controls are set correctly on Email Account datasets.  Besides the
    server URLs, the Sieve script may contain highly personal
    information which should not be disclosed except by explicit owner
    request.


12.  Acknowledgments

    Many thanks to the participants of the IETF ACAP working group for
    their help, comments, and suggestions.


13.  Author's Address

   Randall Gellens                    +1 858 651 5115
   QUALCOMM Incorporated              randy@qualcomm.com
   5775 Morehouse Drive
   San Diego, CA  92121-2779
   U.S.A.


Intellectual Property Statement





Gellens                  Expires August 2003                  [Page 12]


Internet Draft      ACAP Email Account Dataset Class      February 2003


    The IETF takes no position regarding the validity or scope of any
    intellectual property or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; neither does it represent that it
    has made any effort to identify any such rights.  Information on the
    IETF's procedures with respect to rights in standards-track and
    standards-related documentation can be found in BCP-11.  Copies of
    claims of rights made available for publication and any assurances
    of licenses to be made available, or the result of an attempt made
    to obtain a general license or permission for the use of such
    proprietary rights by implementors or users of this specification
    can be obtained from the IETF Secretariat.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights which may cover technology that may be required to practice
    this standard.  Please address the information to the IETF Executive
    Director.


Full Copyright Statement

    Copyright (C) The Internet Society 2003.  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.



Gellens                  Expires August 2003                  [Page 13]