idnits 2.17.1 draft-ietf-acap-email-04.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 (March 2001) is 8442 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 450 looks like a reference -- Missing reference section? 'KEYWORDS' on line 465 looks like a reference -- Missing reference section? 'ACAP-OPTIONS' on line 454 looks like a reference -- Missing reference section? 'POP3' on line 469 looks like a reference -- Missing reference section? 'IMAP4' on line 462 looks like a reference -- Missing reference section? 'ACAP-PERSONALITY' on line 458 looks like a reference -- Missing reference section? 'ABNF' on line 446 looks like a reference -- Missing reference section? 'URL-BASIC' on line 477 looks like a reference -- Missing reference section? 'URL-IMAP' on line 481 looks like a reference -- Missing reference section? 'URL-POP' on line 484 looks like a reference -- Missing reference section? 'SIEVE' on line 473 looks like a reference -- Missing reference section? 'UTF8' on line 487 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. -------------------------------------------------------------------------------- 2 Internet Draft R. Gellens 3 Document: draft-ietf-acap-email-04.txt QUALCOMM 4 Expires: September 2001 March 2001 6 ACAP Email Account Dataset Class 8 Status of this Memo: 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet- Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 26 The list of Internet-Draft Shadow Directories can be accessed at 27 . 29 A version of this draft document is intended for submission to the 30 RFC editor as a Proposed Standard for the Internet Community. 31 Discussion and suggestions for improvement are requested. 33 Copyright Notice 35 Copyright (C) The Internet Society 2001. All Rights Reserved. 37 Table of Contents 39 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2 40 2. Conventions Used in this Document . . . . . . . . . . . . . 2 41 3. Changes Since the Previous Version . . . . . . . . . . . . . 2 42 4. Comments . . . . . . . . . . . . . . . . . . . . . . . . . 2 43 5. ACAP Standard Options . . . . . . . . . . . . . . . . . . . 3 44 6. ACAP Email Account Dataset Class . . . . . . . . . . . . . 3 45 6.1. ACAP Email Account Dataset Class Prefix . . . . . . . . 3 46 6.2. ACAP Email Account Dataset Hierarchy . . . . . . . . . 3 47 7. ACAP Email Account Dataset Attributes . . . . . . . . . . . 3 48 7.1. Basic Attributes . . . . . . . . . . . . . . . . . . . 4 49 7.2. Specific Attributes . . . . . . . . . . . . . . . . . . 4 50 8. Dataset Class Capabilities . . . . . . . . . . . . . . . . 9 51 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 52 10. References . . . . . . . . . . . . . . . . . . . . . . . . 10 53 11. Security Considerations . . . . . . . . . . . . . . . . . . 11 54 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11 55 13. Author's Address . . . . . . . . . . . . . . . . . . . . . . 11 56 14. Full Copyright Statement . . . . . . . . . . . . . . . . . 11 58 1. Abstract 60 It has become common for Internet mail users to have more than one 61 account where mail is received, to access multiple accounts from the 62 same machine, to access the same accounts from different machines, 63 and to use multiple programs which require email account 64 configuration information. 66 The Application Configuration Access Protocol [ACAP] provides an 67 ideal mechanism for storage of email account data. 69 This specification defines a standard ACAP dataset class for email 70 accounts, and a common option for indicating a default email 71 account. 73 2. Conventions Used in this Document 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 79 3. Changes Since the Previous Version 81 - Cleaned up examples. 82 - Minor text clarifications. 84 4. Comments 86 Public comments can be sent to the IETF ACAP mailing list, 87 . To subscribe, send a message to 88 with the word SUBSCRIBE as the 89 body. Private comments should be sent to the author. 91 5. ACAP Standard Options 93 This specification defines the Message User Agent (MUA) Default 94 Account standard option. This is a scaler option in the ACAP 95 Standard Option ("/option") dataset. The entry name is 96 "mua.default.account". The "option.value" attribute contains the 97 value, which is a URL. Generally, this will be an ACAP URL pointing 98 to an entry in an Email Account dataset. 100 The standard option dataset class is specified in [ACAP-OPTIONS]. 101 ACAP URLs are defined in [ACAP]. 103 6. ACAP Email Account Dataset Class 105 The ACAP Email Account dataset class defines a set of attributes 106 which specify an email account; that is, configuration information 107 used for access to mail on a POP [POP3] or IMAP [IMAP4] server. 109 Configuration information related to composing and sending mail is 110 stored in the ACAP Email Personality Dataset Class 111 [ACAP-PERSONALITY]. 113 6.1. ACAP Email Account Dataset Class Prefix 115 Datasets whose names begin with "/email" are assumed to contain 116 email account entries as defined in this specification. 118 6.2. ACAP Email Account Dataset Hierarchy 120 Each user may have a set of named email accounts. The default is 121 pointed at by the "mua.default.account" standard option. (See 122 section 5, ACAP Standard Options, for more information.) 124 Inheritance is likely to be useful both for inheriting site or group 125 defaults (for example, POP or IMAP servers, and initial client 126 configuration in general) as well as for inheriting user-specific 127 configuration when using different machines. 129 7. ACAP Email Account Dataset Attributes 131 An email account entry MUST have an "entry" attribute. All other 132 attributes are OPTIONAL. 134 Attributes are specified using Augmented Backus-Naur Form [ABNF]. 135 All attributes are single-valued and textual (non-binary) unless 136 otherwise stated. 138 The ABNF defines the content of the attribute values prior to their 139 encoding as an ACAP string. Clients MUST conform to the syntax when 140 generating these attributes, but MUST NOT assume that the attribute 141 values will conform to this syntax on access. Servers MUST NOT 142 enforce the syntax. 144 7.1. Basic Attributes 146 These attributes are defined in ACAP [ACAP] and have meaning in all 147 dataset classes. The section describes how they are used in an 148 email account dataset. 150 entry 151 The "entry" attribute is used to hold a unique name for the 152 email account. This name is used for inheritance, so when 153 customizing an account which has an entry in an inherited 154 dataset, the entry name needs to remain the same. The name 155 should also be descriptive, as it is suitable for user display. 157 subdataset 158 The "subdataset" attribute indicates that there is a subdataset 159 of this entry. The value of this attribute specifies the actual 160 location of the subdataset, per [ACAP] section 3.1.1. 162 7.2. Specific Attributes 164 These attributes are specific to the Email Account dataset class. 166 email.boring-headers 167 This multi-valued attribute is a list of header prefixes. If 168 the client has a mode where it suppresses display of certain 169 headers and/or properties of messages, headers which start with 170 a prefix included in this attribute are candidates for 171 suppression. Prefix strings are case-insensitive. 173 email-boring = 1*VCHAR 175 email.check-interval 176 This specifies the interval, in seconds, between checks (polls) 177 for new mail. A value of 0 indicates that automatic mail checks 178 SHOULD NOT be done. 180 email-check-int = 1*DIGIT 182 email.connection-type 183 This contains a token indicating the type of connection used for 184 this email account. Clients might use this information to 185 modify their use of bandwidth. 187 email-conn = "LAN" / "cable-modem" / "phone-modem" / 188 "mobile-phone" 190 email.imap.download-type 191 This specifies which elements of messages are to be downloaded 192 when populating or resynchronizing a mailbox. This is only 193 useful when accessing messages via IMAP [IMAP4]. "Headers" 194 indicates only minimal message information, such as sender, 195 recipient, and subject. "Structure" specifies important headers 196 and body structure information. "Body" means headers, body 197 structure information and the contents of body parts, but not 198 attachments. "Attachments" indicates all elements of messages. 200 email-dload = "headers" / "structure" / "body" / 201 "inline" / "attachments" 203 email.leave-on-server.flag 204 This specifies if the client should delay deleting mail from the 205 server after downloading. This is generally useful only with 206 POP servers [POP3] which support this. 208 email-lmos-flag = "0" / "1" 210 email.leave-on-server.days 211 When email.leave-on-server.flag is set (value is "1"), this 212 attribute specifies the number of days messages should remain on 213 the server before being deleted by the client. This is 214 generally useful only with POP servers [POP3] which support 215 leaving mail on the server. Note that a value of "0" indicates 216 that clients SHOULD never automatically delete mail from the 217 server. 219 email-lmos-days = 1*DIGIT 221 email.maximum.download-size 222 This contains the maximum size (in octets) of messages to be 223 downloaded. This is most useful when accessing messages via POP 224 [POP3], although it might also be used with IMAP [IMAP4] to 225 specify a limit on the size of attachments to be downloaded. A 226 value of "0" indicates no limit. 228 email-max-dsize = 1*DIGIT 229 email.mailbox-prefix 230 This attribute contains a prefix required to access this 231 account's IMAP folders. This is only useful when accessing 232 messages via IMAP [IMAP4]. 234 email-prefix = 1*CHAR 236 email.personality 237 This specifies the default personality to assign to messages 238 received via this email account. It is generally an ACAP URL to 239 an entry in an Email Personality dataset. The ACAP Email 240 Personality dataset class is specified in [ACAP-PERSONALITY]. 241 ACAP-URLs are defined in [ACAP]. 243 email-personality = url ;defined in [URL-BASIC] 245 email.server.IMAP 246 The indicates the default IMAP server to use with this email 247 account. It is generally an IMAP URL, as specified in 248 [URL-IMAP]. 250 email-imap = url ;defined in [URL-BASIC] 252 email.server.POP 253 This specifies the POP server associated with this email 254 account. It is generally a POP URL, as defined in [URL-POP]. 256 email-pop = url ;defined in [URL-BASIC] 258 email.server.Local 259 This indicates that this email account refers to a mailstore on 260 the local client. When set to "1", the "email.server.IMAP" and 261 "email.server.POP" attributes are ignored. 263 email-local = "0"/"1" 265 email.sieve.capability 266 This multivalued attribute contains a list of [SIEVE] capability 267 strings. These strings represent extensions supported by the 268 Sieve execution engine which processes the Sieve script 269 contained in "email.sieve.script". 271 Note that this attribute SHOULD NOT be modified except by the 272 Sieve execution engine or its agent. Normally, this attribute 273 is inherited from a site-specific dataset. 275 email-sieve-cap = 1*CHAR 277 email.sieve.script 278 This specifies the text of a Sieve script which will be applied 279 by the delivery agent (if supported) to mail arriving at this 280 email account. Sieve is specified in [SIEVE]. 282 Note that multiple Sieve scripts may be stored. The active 283 script is always called "email.sieve.script", while additional 284 scripts may be stored in names of the form "email.sieve.foo", 285 where "foo" is the name of a non-active script. 287 email-sieve = 1*UTF8-CHAR 289 email.sieve.runtime.errors 290 If supported by the Sieve implementation (see section 8), this 291 attribute contains the count of runtime errors detected in the 292 currently active Sieve script. This count SHOULD be cleared 293 when a new script is stored. It MAY be reset at other times, at 294 the discretion of the server. Sieve is specified in [SIEVE]. 296 email-sieve-runerr = 1*DIGIT 298 email.sieve.runtime.warnings 299 If supported by the Sieve implementation (see section 8), this 300 attribute contains the count of runtime warnings detected in the 301 currently active Sieve script. This count SHOULD be cleared 302 when a new script is stored. It MAY be reset at other times, at 303 the discretion of the server. Sieve is specified in [SIEVE]. 305 email-sieve-runwarn = 1*DIGIT 307 email.sieve.runtime.errtxt 308 If supported by the Sieve implementation (see section 8), this 309 attribute contains the text of runtime errors detected in the 310 currently active Sieve script. The error text is formated into 311 CRLF-separated lines, one line per error. Each line contains 312 named attributes of the error, in a MIME-header-like format. 313 The currently specified attributes are: line, offset, length, 314 and text. Text MUST always be the last attribute. This 315 attribute SHOULD be cleared when a new script is stored. It MAY 316 be reset at other times, at the discretion of the server. Sieve 317 is specified in [SIEVE]. 319 The format is intended to be easy for a Sieve execution agent to 320 generate, and easy for a Sieve user agent to parse. The Sieve 321 user agent could use the information to highlight the indicated 322 section of the Sieve script text, as specified by the line, 323 offset, and length. 325 email-sieve-errtxt = *(non-text-sieve-att ";" SP) 326 text-sieve-att CRLF 327 non-text-sieve-att = sieve-att-line / sieve-att-off / 328 sieve-att-len / sieve-att-ext 329 text-sieve-att = "text" ":" SP 1*UTF8-CHAR 330 ;MAY use ":" or ";" 331 ;MUST NOT use CRLF 332 sieve-att-line = "line" ":" SP 1*DIGIT 333 sieve-att-off = "offset" ":" SP 1*DIGIT 334 sieve-att-len = "length" ":" SP 1*DIGIT 335 sieve-att-ext = 1*UTF8-CHAR ":" SP 1*UTF8-CHAR 336 ;MUST NOT use ":" or ";" 338 email.sieve.runtime.warntxt 339 If supported by the Sieve implementation (see section 8), this 340 attribute contains the text of runtime warnings detected in the 341 currently active Sieve script. The warning text is formated 342 into CRLF-separated lines, one line per warning, as specified 343 for "email.sieve.runtime.errtxt". This attribute SHOULD be 344 cleared when a new script is stored. It MAY be reset at other 345 times, at the discretion of the server. Sieve is specified in 346 [SIEVE]. 348 email-sieve-warntxt = email-sieve-errtxt 350 email.sieve.syntax.errors 351 If supported by the Sieve implementation (see section 8), this 352 attribute contains the count of syntax errors detected in the 353 most recently stored Sieve script. Sieve is specified in 354 [SIEVE]. 356 email-sieve-synerr = 1*DIGIT 358 email.sieve.syntax.warnings 359 If supported by the Sieve implementation (see section 8), this 360 attribute contains the count of syntax warnings detected in the 361 most recently stored Sieve script. Sieve is specified in 362 [SIEVE]. 364 email-sieve-synwarn = 1*DIGIT 366 email.sieve.syntax.errtxt 367 If supported by the Sieve implementation (see section 8), this 368 attribute contains the text of syntax errors detected in the 369 most recently stored Sieve script. The error text is formated 370 into CRLF-separated lines, one line per error, as specified for 371 "email.sieve.runtime.errtxt". Sieve is specified in [SIEVE]. 373 email-sieve-synerrtxt = email-sieve-errtxt 375 email.sieve.syntax.warntxt 376 If supported by the Sieve implementation (see section 8), this 377 attribute contains the text of syntax warnings detected in the 378 most recently stored Sieve script. The warning text is formated 379 into CRLF-separated lines, one line per warning, as specified 380 for "email.sieve.runtime.errtxt". Sieve is specified in 381 [SIEVE]. 383 email-sieve-synwarntxt = email-sieve-errtxt 384 email.trash-folder 385 This attribute contains the name of a folder to which messages 386 SHOULD be moved in lieu of immediately marking them deleted. If 387 empty, messages SHOULD be marked deleted. This is only useful 388 when accessing messages via IMAP [IMAP4]. 390 email-trash = 1*CHAR 392 8. Dataset Class Capabilities 394 Certain attributes in the Email Account dataset class are only 395 available if there is integrated server support or an active client 396 providing them. Availability of such attributes is indicated by 397 corresponding attributes in the "email" entry of the "capability" 398 dataset. The capability attribute has the name of the attribute in 399 the Email dataset, prefixed with "capability.", and has a value of 400 "1" if the corresponding attribute in the Email dataset is 401 supported. 403 capability.email.sieve.runtime.errors 404 capability.email.sieve.runtime.warnings 405 capability.email.sieve.runtime.errtxt 406 capability.email.sieve.runtime.warntxt 407 capability.email.sieve.syntax.errors 408 capability.email.sieve.syntax.warnings 409 capability.email.sieve.syntax.errtxt 410 capability.email.sieve.syntax.warntxt 412 Note that these attributes SHOULD NOT be modified except by the 413 server or an active client responsible for supporting the underlying 414 capability. These attributes are normally inherited from a 415 site-specific dataset. 417 9. Examples 419 entry home 420 email.connection-type phone-modem 421 email.personality home 422 email.server.pop POP://jru;AUTH=APOP@pop.isp.com 423 email.sieve.capability ("vacation" "mark") 424 email.sieve.script if header :matches "subject" 425 [ "*make*money*fast*", 426 "*university*dipl*mas*" ] 427 { 428 discard; 429 } 430 email.boring-headers ("received" "message" "x400") 432 entry work 433 email.connection-type direct 434 email.personality work 435 email.server.imap IMAP://jru@mail.bigcorp.com 436 email.sieve.capability ("fileinto" "vacation" "envelope") 437 email.sieve.script if header :is "Sender" 438 "BigCheese@example.com" 439 { 440 fileinto "Blatherings"; 441 } 442 email.trash-folder Trash 444 10. References 446 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 447 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd., 448 November 1997. 450 [ACAP] Newman, Myers, "ACAP -- Application Configuration Access 451 Protocol", RFC 2244, Innosoft, Netscape, November 1997. 452 454 [ACAP-OPTIONS] Hole, "ACAP Application Options Dataset Class", The 455 Esys Corporation, work in Progress, 456 458 [ACAP-PERSONALITY] Gellens, "ACAP Email Personality Dataset Class", 459 QUALCOMM Incorporated, work in Progress, 460 462 [IMAP4] Crispin, "Internet Message Access Protocol - Version 4rev1", 463 RFC 2060, University of Washington, December 1996. 465 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 466 Requirement Levels", RFC 2119, Harvard University, March 1997. 467 469 [POP3] Myers, Rose, "Post Office Protocol -- Version 3", RFC 1939, 470 Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. 471 473 [SIEVE] Showalter, "Sieve: A Mail Filtering Language", RFC 3028, 474 Mirapoint, Inc, January 2001. 475 477 [URL-BASIC] Berners-Lee, Masinter, McCahill, "Uniform Resource 478 Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of 479 Minnesota, December 1994. 481 [URL-IMAP] Newman, "IMAP URL Scheme", RFC 2192, Innosoft, September 482 1997. 484 [URL-POP] Gellens, "POP URL Scheme", RFC 2384, QUALCOMM 485 Incorporated, August 1998. 487 [UTF8] Yergeau, F. "UTF-8, a transformation format of ISO 10646", 488 RFC 2279, Alis Technologies, January 1998. 489 491 11. Security Considerations 493 As with ACAP datasets in general, it is important that access 494 controls are set correctly on Email Account datasets. Besides the 495 server URLs, the Sieve script may contain highly personal 496 information which should not be disclosed except by explicit owner 497 request. 499 12. Acknowledgments 501 Many thanks to the participants of the IETF ACAP working group for 502 their help, comments, and suggestions. 504 13. Author's Address 506 Randall Gellens +1 858 651 5115 507 QUALCOMM Incorporated randy@qualcomm.com 508 5775 Morehouse Drive 509 San Diego, CA 92121-2779 510 U.S.A. 512 14. Full Copyright Statement 514 Copyright (C) The Internet Society 2001. All Rights Reserved. 516 This document and translations of it may be copied and furnished to 517 others, and derivative works that comment on or otherwise explain it 518 or assist in its implementation may be prepared, copied, published 519 and distributed, in whole or in part, without restriction of any 520 kind, provided that the above copyright notice and this paragraph 521 are included on all such copies and derivative works. However, this 522 document itself may not be modified in any way, such as by removing 523 the copyright notice or references to the Internet Society or other 524 Internet organizations, except as needed for the purpose of 525 developing Internet standards in which case the procedures for 526 copyrights defined in the Internet Standards process must be 527 followed, or as required to translate it into languages other than 528 English. 530 The limited permissions granted above are perpetual and will not be 531 revoked by the Internet Society or its successors or assigns. 533 This document and the information contained herein is provided on an 534 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 535 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 536 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 537 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 538 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.