idnits 2.17.1 draft-ietf-acap-email-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([ACAP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (28 February 2000) is 8823 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'ACAP' on line 466 looks like a reference -- Missing reference section? 'KEYWORDS' on line 481 looks like a reference -- Missing reference section? 'IMAP4' on line 478 looks like a reference -- Missing reference section? 'ACAP-OPTIONS' on line 470 looks like a reference -- Missing reference section? 'POP3' on line 485 looks like a reference -- Missing reference section? 'ACAP-PERSONALITY' on line 474 looks like a reference -- Missing reference section? 'ABNF' on line 462 looks like a reference -- Missing reference section? 'URL-BASIC' on line 493 looks like a reference -- Missing reference section? 'URL-IMAP' on line 497 looks like a reference -- Missing reference section? 'URL-POP' on line 500 looks like a reference -- Missing reference section? 'SIEVE' on line 489 looks like a reference -- Missing reference section? 'UTF8' on line 503 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft R. Gellens 2 Document: draft-ietf-acap-email-03.txt QUALCOMM 3 Expires: 28 August 2000 28 February 2000 5 ACAP Email Account Dataset Class 7 Status of this Memo: 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet- Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 25 The list of Internet-Draft Shadow Directories can be accessed at 26 . 28 A version of this draft document is intended for submission to the 29 RFC editor as a Proposed Standard for the Internet Community. 30 Discussion and suggestions for improvement are requested. 32 Copyright Notice 34 Copyright (C) The Internet Society 2000. All Rights Reserved. 36 Table of Contents 38 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2 39 2. Conventions Used in this Document . . . . . . . . . . . . . 2 40 3. Changes Since the Previous Version . . . . . . . . . . . . . 2 41 4. Comments . . . . . . . . . . . . . . . . . . . . . . . . . 3 42 5. ACAP Standard Options . . . . . . . . . . . . . . . . . . . 3 43 6. ACAP Email Account Dataset Class . . . . . . . . . . . . . 3 44 6.1. ACAP Email Account Dataset Class Prefix . . . . . . . . 3 45 6.2. ACAP Email Account Dataset Hierarchy . . . . . . . . . 3 46 7. ACAP Email Account Dataset Attributes . . . . . . . . . . . 4 47 7.1. Basic Attributes . . . . . . . . . . . . . . . . . . . 4 48 7.2. Specific Attributes . . . . . . . . . . . . . . . . . . 4 49 8. Dataset Class Capabilities . . . . . . . . . . . . . . . . 9 50 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 51 10. References . . . . . . . . . . . . . . . . . . . . . . . . 10 52 11. Security Considerations . . . . . . . . . . . . . . . . . . 11 53 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11 54 13. Author's Address . . . . . . . . . . . . . . . . . . . . . . 11 55 14. Full Copyright Statement . . . . . . . . . . . . . . . . . 11 57 1. Abstract 59 It has become common for Internet mail users to have more than one 60 account where mail is received, to access multiple accounts from the 61 same machine, to access the same accounts from different machines, 62 and to use multiple programs which require email account 63 configuration information. 65 The Application Configuration Access Protocol [ACAP] provides an 66 ideal mechanism for storage of email account data. 68 This specification defines a standard ACAP dataset class for email 69 accounts, and a common option for indicating a default email 70 account. 72 2. Conventions Used in this Document 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 78 3. Changes Since the Previous Version 80 - Added attributes: 81 email.mailbox-prefix, 82 email.sieve.capability, 83 email.sieve.runtime.errors, 84 email.sieve.runtime.warnings, 85 email.sieve.runtime.errtxt, 86 email.sieve.runtime.warntxt, 87 email.trash-folder. 88 - Fixed ABNF for email-sieve-errtxt. 89 - Added text for email.maximum.download-size regarding use with 90 IMAP [IMAP4]. 91 - Added mention of multiple Sieve scripts. 92 - Clarified email vs. personalities datasets. 93 - Updated Sieve script examples. 94 - Added section on items in the "capabilities" dataset. 96 4. Comments 98 Public comments can be sent to the IETF ACAP mailing list, 99 . To subscribe, send a message to 100 with the word SUBSCRIBE as the 101 body. Private comments should be sent to the author. 103 5. ACAP Standard Options 105 This specification defines the Message User Agent (MUA) Default 106 Account standard option. This is a scaler option in the ACAP 107 Standard Option ("/option") dataset. The entry name is 108 "mua.default.account". The "option.value" attribute contains the 109 value, which is a URL. Generally, this will be an ACAP URL pointing 110 to an entry in an Email Account dataset. 112 The standard option dataset class is specified in [ACAP-OPTIONS]. 113 ACAP URLs are defined in [ACAP]. 115 6. ACAP Email Account Dataset Class 117 The ACAP Email Account dataset class defines a set of attributes 118 which specify an email account; that is, configuration information 119 used for access to mail on a POP [POP3] or IMAP [IMAP4] server. 121 Configuration information related to composing and sending mail is 122 stored in the ACAP Email Personality Dataset Class 123 [ACAP-PERSONALITY]. 125 6.1. ACAP Email Account Dataset Class Prefix 127 Datasets whose names begin with "/email" are assumed to contain 128 email account entries as defined in this specification. 130 6.2. ACAP Email Account Dataset Hierarchy 132 Each user may have a set of named email accounts. The default is 133 pointed at by the "mua.default.account" standard option. (See 134 section 5, ACAP Standard Options, for more information.) 136 Inheritance is likely to be useful both for inheriting site or group 137 defaults (for example, POP or IMAP servers, and initial client 138 configuration in general) as well as for inheriting user-specific 139 configuration when using different machines. 141 7. ACAP Email Account Dataset Attributes 143 An email account entry MUST have an "entry" attribute. All other 144 attributes are OPTIONAL. 146 Attributes are specified using Augmented Backus-Naur Form [ABNF]. 147 All attributes are single-valued and textual (non-binary) unless 148 otherwise stated. 150 The ABNF defines the content of the attribute values prior to their 151 encoding as an ACAP string. Clients MUST conform to the syntax when 152 generating these attributes, but MUST NOT assume that the attribute 153 values will conform to this syntax on access. Servers MUST NOT 154 enforce the syntax. 156 7.1. Basic Attributes 158 These attributes are defined in ACAP [ACAP] and have meaning in all 159 dataset classes. The section describes how they are used in an 160 email account dataset. 162 entry 163 The "entry" attribute is used to hold a unique name for the 164 email account. This name is used for inheritance, so when 165 customizing an account which has an entry in an inherited 166 dataset, the entry name needs to remain the same. The name 167 should also be descriptive, as it is suitable for user display. 169 subdataset 170 The "subdataset" attribute indicates that there is a subdataset 171 of this entry. The value of this attribute specifies the actual 172 location of the subdataset, per [ACAP] section 3.1.1. 174 7.2. Specific Attributes 176 These attributes are specific to the Email Account dataset class. 178 email.boring-headers 179 This multi-valued attribute is a list of header prefixes. If 180 the client has a mode where it suppresses display of certain 181 headers and/or properties of messages, headers which start with 182 a prefix included in this attribute are candidates for 183 suppression. Prefix strings are case-insensitive. 185 email-boring = 1*VCHAR 187 email.check-interval 188 This specifies the interval, in seconds, between checks (polls) 189 for new mail. A value of 0 indicates that automatic mail checks 190 SHOULD NOT be done. 192 email-check-int = 1*DIGIT 194 email.connection-type 195 This contains a token indicating the type of connection used for 196 this email account. Clients might use this information to 197 modify their use of bandwidth. 199 email-conn = "LAN" / "cable-modem" / "phone-modem" / 200 "mobile-phone" 202 email.imap.download-type 203 This specifies which elements of messages are to be downloaded 204 when populating or resynchronizing a mailbox. This is only 205 useful when accessing messages via IMAP [IMAP4]. "Headers" 206 indicates only minimal message information, such as sender, 207 recipient, and subject. "Structure" specifies important headers 208 and body structure information. "Body" means headers, body 209 structure information and the contents of body parts, but not 210 attachments. "Attachments" indicates all elements of messages. 212 email-dload = "headers" / "structure" / "body" / 213 "inline" / "attachments" 215 email.leave-on-server.flag 216 This specifies if the client should delay deleting mail from the 217 server after downloading. This is generally useful only with 218 POP servers [POP3] which support this. 220 email-lmos-flag = "0" / "1" 222 email.leave-on-server.days 223 When email.leave-on-server.flag is set (value is "1"), this 224 attribute specifies the number of days messages should remain on 225 the server before being deleted by the client. This is 226 generally useful only with POP servers [POP3] which support 227 leaving mail on the server. Note that a value of "0" indicates 228 that clients SHOULD never automatically delete mail from the 229 server. 231 email-lmos-days = 1*DIGIT 233 email.maximum.download-size 234 This contains the maximum size (in octets) of messages to be 235 downloaded. This is most useful when accessing messages via POP 236 [POP3], although it might also be used with IMAP [IMAP4] to 237 specify a limit on the size of attachments to be downloaded. A 238 value of "0" indicates no limit. 240 email-max-dsize = 1*DIGIT 242 email.mailbox-prefix 243 This attribute contains a prefix required to access this 244 account's IMAP folders. This is only useful when accessing 245 messages via IMAP [IMAP4]. 247 email-prefix = 1*CHAR 249 email.personality 250 This specifies the default personality to assign to messages 251 received via this email account. It is generally an ACAP URL to 252 an entry in an Email Personality dataset. The ACAP Email 253 Personality dataset class is specified in [ACAP-PERSONALITY]. 254 ACAP-URLs are defined in [ACAP]. 256 email-personality = url ;defined in [URL-BASIC] 258 email.server.IMAP 259 The indicates the default IMAP server to use with this email 260 account. It is generally an IMAP URL, as specified in 261 [URL-IMAP]. 263 email-imap = url ;defined in [URL-BASIC] 265 email.server.POP 266 This specifies the POP server associated with this email 267 account. It is generally a POP URL, as defined in [URL-POP]. 269 email-pop = url ;defined in [URL-BASIC] 271 email.server.Local 272 This indicates that this email account refers to a mailstore on 273 the local client. When set to "1", the "email.server.IMAP" and 274 "email.server.POP" attributes are ignored. 276 email-local = "0"/"1" 278 email.sieve.capability 279 This multivalued attribute contains a list of Sieve capability 280 strings for extensions supported by the Sieve execution engine 281 which processes the Sieve script contained in 282 "email.sieve.script". 284 Note that this attribute SHOULD NOT be modified except by the 285 Sieve execution engine or its agent. Normally, this attribute 286 is inherited from a site-specific dataset. 288 email-sieve-cap = 1*CHAR 290 email.sieve.script 291 This specifies the text of a Sieve script which will be applied 292 by the delivery agent (if supported) to mail arriving at this 293 email account. Sieve is specified in [SIEVE]. 295 Note that multiple Sieve scripts may be stored. The active 296 script is always called "email.sieve.script", while additional 297 scripts may be stored in names of the form 298 "email.account.sieve.foo", where "foo" is the name of a 299 non-active script. 301 email-sieve = 1*UTF8-CHAR 303 email.sieve.runtime.errors 304 If supported by the Sieve implementation (see section 8), this 305 attribute contains the count of runtime errors detected in the 306 currently active Sieve script. This count SHOULD be cleared 307 when a new script is stored. It MAY be reset at other times, at 308 the discretion of the server. Sieve is specified in [SIEVE]. 310 email-sieve-runerr = 1*DIGIT 312 email.sieve.runtime.warnings 313 If supported by the Sieve implementation (see section 8), this 314 attribute contains the count of runtime warnings detected in the 315 currently active Sieve script. This count SHOULD be cleared 316 when a new script is stored. It MAY be reset at other times, at 317 the discretion of the server. Sieve is specified in [SIEVE]. 319 email-sieve-runwarn = 1*DIGIT 321 email.sieve.runtime.errtxt 322 If supported by the Sieve implementation (see section 8), this 323 attribute contains the text of runtime errors detected in the 324 currently active Sieve script. The error text is formated into 325 CRLF-separated lines, one line per error. Each line contains 326 named attributes of the error, in a MIME-header-like format. 327 The currently specified attributes are: line, offset, length, 328 and text. Text MUST always be the last attribute. This 329 attribute SHOULD be cleared when a new script is stored. It MAY 330 be reset at other times, at the discretion of the server. Sieve 331 is specified in [SIEVE]. 333 The format is intended to be easy for a Sieve execution agent to 334 generate, and easy for a Sieve user agent to parse. The Sieve 335 user agent could use the information to highlight the indicated 336 section of the Sieve script text, as specified by the line, 337 offset, and length. 339 email-sieve-errtxt = *(non-text-sieve-att ";" SP) 340 text-sieve-att CRLF 341 non-text-sieve-att = sieve-att-line / sieve-att-off / 342 sieve-att-len / sieve-att-ext 343 text-sieve-att = "text" ":" SP 1*UTF8-CHAR 344 ;MAY use ":" or ";" 345 ;MUST NOT use CRLF 346 sieve-att-line = "line" ":" SP 1*DIGIT 347 sieve-att-off = "offset" ":" SP 1*DIGIT 348 sieve-att-len = "length" ":" SP 1*DIGIT 349 sieve-att-ext = 1*UTF8-CHAR ":" SP 1*UTF8-CHAR 350 ;MUST NOT use ":" or ";" 352 email.sieve.runtime.warntxt 353 If supported by the Sieve implementation (see section 8), this 354 attribute contains the text of runtime warnings detected in the 355 currently active Sieve script. The warning text is formated 356 into CRLF-separated lines, one line per warning, as specified 357 for "email.sieve.runtime.errtxt". This attribute SHOULD be 358 cleared when a new script is stored. It MAY be reset at other 359 times, at the discretion of the server. Sieve is specified in 360 [SIEVE]. 362 email-sieve-warntxt = email-sieve-errtxt 364 email.sieve.syntax.errors 365 If supported by the Sieve implementation (see section 8), this 366 attribute contains the count of syntax errors detected in the 367 most recently stored Sieve script. Sieve is specified in 368 [SIEVE]. 370 email-sieve-synerr = 1*DIGIT 372 email.sieve.syntax.warnings 373 If supported by the Sieve implementation (see section 8), this 374 attribute contains the count of syntax warnings detected in the 375 most recently stored Sieve script. Sieve is specified in 376 [SIEVE]. 378 email-sieve-synwarn = 1*DIGIT 380 email.sieve.syntax.errtxt 381 If supported by the Sieve implementation (see section 8), this 382 attribute contains the text of syntax errors detected in the 383 most recently stored Sieve script. The error text is formated 384 into CRLF-separated lines, one line per error, as specified for 385 "email.sieve.runtime.errtxt". Sieve is specified in [SIEVE]. 387 email-sieve-synerrtxt = email-sieve-errtxt 389 email.sieve.syntax.warntxt 390 If supported by the Sieve implementation (see section 8), this 391 attribute contains the text of syntax warnings detected in the 392 most recently stored Sieve script. The warning text is formated 393 into CRLF-separated lines, one line per warning, as specified 394 for "email.sieve.runtime.errtxt". Sieve is specified in 395 [SIEVE]. 397 email-sieve-synwarntxt = email-sieve-errtxt 399 email.trash-folder 400 This attribute contains the name of a folder to which messages 401 SHOULD be moved in lieu of immediately marking them deleted. If 402 empty, messages SHOULD be marked deleted. This is only useful 403 when accessing messages via IMAP [IMAP4]. 405 email-trash = 1*CHAR 407 8. Dataset Class Capabilities 409 Certain attributes in the Email Account dataset class are only 410 available if there is integrated server support or an active client 411 providing them. Availability of such attributes is indicated by 412 corresponding attributes in the "email" entry of the "capability" 413 dataset. The capability attribute has the name of the attribute in 414 the Email dataset, prefixed with "capability.", and has a value of 415 "1" if the corresponding attribute in the Email dataset is 416 supported. 418 capability.email.sieve.runtime.errors 419 capability.email.sieve.runtime.warnings 420 capability.email.sieve.runtime.errtxt 421 capability.email.sieve.runtime.warntxt 422 capability.email.sieve.syntax.errors 423 capability.email.sieve.syntax.warnings 424 capability.email.sieve.syntax.errtxt 425 capability.email.sieve.syntax.warntxt 427 Note that these attributes SHOULD NOT be modified except by the 428 server or an active client responsible for supporting the underlying 429 capability. These attributes are normally inherited from a 430 site-specific dataset. 432 9. Examples 434 entry = "home" 435 email.connection-type = "phone-modem" 436 email.personality = "home" 437 email.server.pop = "POP://jru;AUTH=APOP@pop.isp.com" 438 email.sieve.capability = ("vacation" "mark") 439 email.sieve.script = "if header :matches "subject" 440 [ "*make*money*fast*", 441 "*university*dipl*mas*" ] 442 { 443 discard; 444 } 445 email.boring-headers = ("received" "message" "x400") 447 entry = "work 448 email.connection-type = "direct 449 email.personality = "work 450 email.server.imap = "IMAP://jru@mail.bigcorp.com 451 email.sieve.capability = ("fileinto" "vacation" "envelope") 452 email.sieve.script = {47} 453 if header :is "Sender" 454 "BigCheese@example.com" 455 { 456 fileinto "Blatherings"; 457 } 458 email.trash-folder = "Trash" 460 10. References 462 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 463 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd., 464 November 1997. 466 [ACAP] Newman, Myers, "ACAP -- Application Configuration Access 467 Protocol", RFC 2244, Innosoft, Netscape, November 1997. 468 470 [ACAP-OPTIONS] Hole, "ACAP Application Options Dataset Class", The 471 Esys Corporation, Work in Progress, February 1998. 472 474 [ACAP-PERSONALITY] Gellens, "ACAP Email Personality Dataset Class", 475 QUALCOMM Incorporated, Work in Progress. 476 478 [IMAP4] Crispin, "Internet Message Access Protocol - Version 4rev1", 479 RFC 2060, University of Washington, December 1996. 481 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 482 Requirement Levels", RFC 2119, Harvard University, March 1997. 483 485 [POP3] Myers, Rose, "Post Office Protocol -- Version 3", RFC 1939, 486 Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. 487 489 [SIEVE] Showalter, "Sieve -- a Mail Filtering Language", Carnegie 490 Mellon, Work in Progress. 491 \ 493 [URL-BASIC] Berners-Lee, Masinter, McCahill, "Uniform Resource 494 Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of 495 Minnesota, December 1994. 497 [URL-IMAP] Newman, "IMAP URL Scheme", RFC 2192, Innosoft, September 498 1997. 500 [URL-POP] Gellens, "POP URL Scheme", RFC 2384, QUALCOMM 501 Incorporated, August 1998. 503 [UTF8] Yergeau, F. "UTF-8, a transformation format of ISO 10646", 504 RFC 2279, Alis Technologies, January 1998. 505 507 11. Security Considerations 509 As with ACAP datasets in general, it is important that access 510 controls are set correctly on Email Account datasets. Besides the 511 server URLs, the Sieve script may contain highly personal 512 information which should not be disclosed except by explicit owner 513 request. 515 12. Acknowledgments 517 Many thanks to the participants of the IETF ACAP working group for 518 their help, comments, and suggestions. 520 13. Author's Address 522 Randall Gellens +1 858 651 5115 523 QUALCOMM Incorporated randy@qualcomm.com 524 5775 Morehouse Drive 525 San Diego, CA 92121-2779 526 U.S.A. 528 14. Full Copyright Statement 530 Copyright (C) The Internet Society 2000. All Rights Reserved. 532 This document and translations of it may be copied and furnished to 533 others, and derivative works that comment on or otherwise explain it 534 or assist in its implementation may be prepared, copied, published 535 and distributed, in whole or in part, without restriction of any 536 kind, provided that the above copyright notice and this paragraph 537 are included on all such copies and derivative works. However, this 538 document itself may not be modified in any way, such as by removing 539 the copyright notice or references to the Internet Society or other 540 Internet organizations, except as needed for the purpose of 541 developing Internet standards in which case the procedures for 542 copyrights defined in the Internet Standards process must be 543 followed, or as required to translate it into languages other than 544 English. 546 The limited permissions granted above are perpetual and will not be 547 revoked by the Internet Society or its successors or assigns. 549 This document and the information contained herein is provided on an 550 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 551 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 552 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 553 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 554 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.