idnits 2.17.1 draft-ietf-acap-email-06.txt: 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 (February 2003) is 7738 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 453 looks like a reference -- Missing reference section? 'KEYWORDS' on line 465 looks like a reference -- Missing reference section? 'ACAP-OPTIONS' on line 457 looks like a reference -- Missing reference section? 'POP3' on line 492 looks like a reference -- Missing reference section? 'IMAP4' on line 489 looks like a reference -- Missing reference section? 'ACAP-PERSONALITY' on line 461 looks like a reference -- Missing reference section? 'ABNF' on line 449 looks like a reference -- Missing reference section? 'URL-BASIC' on line 473 looks like a reference -- Missing reference section? 'URL-IMAP' on line 477 looks like a reference -- Missing reference section? 'URL-POP' on line 480 looks like a reference -- Missing reference section? 'SIEVE' on line 469 looks like a reference -- Missing reference section? 'UTF8' on line 483 looks like a reference Summary: 7 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-06.txt QUALCOMM 4 Expires: August 2003 February 2003 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 2003. All Rights Reserved. 37 Abstract 39 It has become common for Internet mail users to have more than one 40 account where mail is received, to access multiple accounts from the 41 same machine, to access the same accounts from different machines, 42 and to use multiple programs which require email account 43 configuration information. 45 The Application Configuration Access Protocol [ACAP] provides an 46 ideal mechanism for storage of email account data. 48 This specification defines an interoperable ACAP dataset class for 49 email accounts, and a common option for indicating a default email 50 account. 52 Table of Contents 54 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 55 2. Changes Since the Previous Version . . . . . . . . . . . . . 3 56 3. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. ACAP Standard Options . . . . . . . . . . . . . . . . . . . 3 58 5. ACAP Email Account Dataset Class . . . . . . . . . . . . . . 4 59 5.1. ACAP Email Account Dataset Class Prefix . . . . . . . . 4 60 5.2. ACAP Email Account Dataset Hierarchy . . . . . . . . . . 4 61 6. ACAP Email Account Dataset Attributes . . . . . . . . . . . 4 62 6.1. Basic Attributes . . . . . . . . . . . . . . . . . . . . 5 63 6.2. Specific Attributes . . . . . . . . . . . . . . . . . . 5 64 7. Dataset Class Capabilities . . . . . . . . . . . . . . . . . 10 65 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 9. Normative References . . . . . . . . . . . . . . . . . . . . 11 67 10. Informative References . . . . . . . . . . . . . . . . . . 12 68 11. Security Considerations . . . . . . . . . . . . . . . . . . 12 69 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 12 70 13. Author's Address . . . . . . . . . . . . . . . . . . . . . 12 71 Intellectual Property Statement . . . . . . . . . . . . . . . 12 72 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 74 1. Conventions Used in this Document 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 80 2. Changes Since the Previous Version 82 - Minor text clarifications. 83 - Updated boilerplate. 85 3. Comments 87 Public comments can be sent to the IETF ACAP mailing list, 88 . To subscribe, send a message to 89 with the word SUBSCRIBE as the 90 body. Private comments should be sent to the author. 92 4. ACAP Standard Options 94 This specification defines the Message User Agent (MUA) Default 95 Account standard option. This is a scaler option in the ACAP 96 Standard Option ("/option") dataset. The entry name is 97 "mua.default.account". The "option.value" attribute contains the 98 value, which is a URL. Generally, this will be an ACAP URL pointing 99 to an entry in an Email Account dataset. 101 The standard option dataset class is specified in [ACAP-OPTIONS]. 102 ACAP URLs are defined in [ACAP]. 104 5. ACAP Email Account Dataset Class 106 The ACAP Email Account dataset class defines a set of attributes 107 which specify an email account; that is, configuration information 108 used for access to mail on a POP [POP3] or IMAP [IMAP4] server. 110 Configuration information related to composing and sending mail is 111 stored in the ACAP Email Personality Dataset Class 112 [ACAP-PERSONALITY]. 114 5.1. ACAP Email Account Dataset Class Prefix 116 Datasets whose names begin with "/email" are assumed to contain 117 email account entries as defined in this specification. 119 5.2. ACAP Email Account Dataset Hierarchy 121 Each user may have a set of named email accounts. The default is 122 pointed at by the "mua.default.account" standard option. (See 123 section 4, ACAP Standard Options, for more information.) 125 Inheritance is likely to be useful both for inheriting site or group 126 defaults (for example, POP or IMAP servers, and initial client 127 configuration in general) as well as for inheriting user-specific 128 configuration when using different machines. 130 6. ACAP Email Account Dataset Attributes 132 An email account entry MUST have an "entry" attribute. All other 133 attributes are OPTIONAL. 135 Attributes are specified using Augmented Backus-Naur Form [ABNF]. 136 All attributes are single-valued and textual (non-binary) unless 137 otherwise stated. 139 The ABNF defines the content of the attribute values prior to their 140 encoding as an ACAP string. Clients MUST conform to the syntax when 141 generating these attributes, but MUST NOT assume that the attribute 142 values will conform to this syntax on access. Servers MUST NOT 143 enforce the syntax. 145 6.1. Basic Attributes 147 These attributes are defined in ACAP [ACAP] and have meaning in all 148 dataset classes. The section describes how they are used in an 149 email account dataset. 151 entry 152 The "entry" attribute is used to hold a unique name for the 153 email account. This name is used for inheritance, so when 154 customizing an account which has an entry in an inherited 155 dataset, the entry name needs to remain the same. The name 156 should also be descriptive, as it is suitable for user display. 158 subdataset 159 The "subdataset" attribute indicates that there is a subdataset 160 of this entry. The value of this attribute specifies the actual 161 location of the subdataset, per [ACAP] section 3.1.1. 163 6.2. Specific Attributes 165 These attributes are specific to the Email Account dataset class. 167 email.boring-headers 168 This multi-valued attribute is a list of header prefixes. If 169 the client has a mode where it suppresses display of certain 170 headers and/or properties of messages, headers which start with 171 a prefix included in this attribute are candidates for 172 suppression. Prefix strings are case-insensitive. 174 email-boring = 1*VCHAR 176 email.check-interval 177 This specifies the interval, in seconds, between checks (polls) 178 for new mail. A value of 0 indicates that automatic mail checks 179 SHOULD NOT be done. 181 email-check-int = 1*DIGIT 183 email.connection-type 184 This contains a token indicating the type of connection used for 185 this email account. Clients might use this information to 186 modify their use of bandwidth. 188 email-conn = "LAN" / "cable-modem" / "phone-modem" / 189 "mobile-phone" 191 email.imap.download-type 192 This specifies which elements of messages are to be downloaded 193 when populating or resynchronizing a mailbox. This is only 194 useful when accessing messages via IMAP [IMAP4]. "Headers" 195 indicates only minimal message information, such as sender, 196 recipient, and subject. "Structure" specifies important headers 197 and body structure information. "Body" means headers, body 198 structure information and the contents of body parts, but not 199 attachments. "Attachments" indicates all elements of messages. 201 email-dload = "headers" / "structure" / "body" / 202 "inline" / "attachments" 204 email.leave-on-server.flag 205 This specifies if the client should delay deleting mail from the 206 server after downloading. This is generally useful only with 207 POP servers [POP3] which support this. 209 email-lmos-flag = "0" / "1" 211 email.leave-on-server.days 212 When email.leave-on-server.flag is set (value is "1"), this 213 attribute specifies the number of days messages should remain on 214 the server before being deleted by the client. This is 215 generally useful only with POP servers [POP3] which support 216 leaving mail on the server. Note that a value of "0" indicates 217 that clients SHOULD never automatically delete mail from the 218 server. 220 email-lmos-days = 1*DIGIT 222 email.maximum.download-size 223 This contains the maximum size (in octets) of messages to be 224 downloaded. This is most useful when accessing messages via POP 225 [POP3], although it might also be used with IMAP [IMAP4] to 226 specify a limit on the size of attachments to be downloaded. A 227 value of "0" indicates no limit. 229 email-max-dsize = 1*DIGIT 231 email.mailbox-prefix 232 This attribute contains a prefix required to access this 233 account's IMAP folders. This is only useful when accessing 234 messages via IMAP [IMAP4]. 236 email-prefix = 1*CHAR 238 email.personality 239 This specifies the default personality to assign to messages 240 received via this email account. It is generally an ACAP URL to 241 an entry in an Email Personality dataset. The ACAP Email 242 Personality dataset class is specified in [ACAP-PERSONALITY]. 243 ACAP-URLs are defined in [ACAP]. 245 email-personality = url ;defined in [URL-BASIC] 247 email.server.IMAP 248 The indicates the default IMAP server to use with this email 249 account. It is generally an IMAP URL, as specified in 250 [URL-IMAP]. 252 email-imap = url ;defined in [URL-BASIC] 254 email.server.POP 255 This specifies the POP server associated with this email 256 account. It is generally a POP URL, as defined in [URL-POP]. 258 email-pop = url ;defined in [URL-BASIC] 260 email.server.Local 261 This indicates that this email account refers to a mailstore on 262 the local client. When set to "1", the "email.server.IMAP" and 263 "email.server.POP" attributes are ignored. 265 email-local = "0"/"1" 267 email.sieve.capability 268 This multivalued attribute contains a list of [SIEVE] capability 269 strings. These strings represent extensions supported by the 270 Sieve execution engine which processes the Sieve script 271 contained in "email.sieve.script". 273 Note that this attribute SHOULD NOT be modified except by the 274 Sieve execution engine or its agent. Normally, this attribute 275 is inherited from a site-specific dataset. 277 email-sieve-cap = 1*CHAR 279 email.sieve.script 280 This specifies the text of a Sieve script which will be applied 281 by the delivery agent (if supported) to mail arriving at this 282 email account. Sieve is specified in [SIEVE]. 284 Note that multiple Sieve scripts may be stored. The active 285 script is always called "email.sieve.script", while additional 286 scripts may be stored in names of the form "email.sieve.foo", 287 where "foo" is the name of a non-active script. 289 email-sieve = 1*UTF8-CHAR 291 email.sieve.runtime.errors 292 If supported by the Sieve implementation (see section 7), this 293 attribute contains the count of runtime errors detected in the 294 currently active Sieve script. This count SHOULD be cleared 295 when a new script is stored. It MAY be reset at other times, at 296 the discretion of the server. Sieve is specified in [SIEVE]. 298 email-sieve-runerr = 1*DIGIT 300 email.sieve.runtime.warnings 301 If supported by the Sieve implementation (see section 7), this 302 attribute contains the count of runtime warnings detected in the 303 currently active Sieve script. This count SHOULD be cleared 304 when a new script is stored. It MAY be reset at other times, at 305 the discretion of the server. Sieve is specified in [SIEVE]. 307 email-sieve-runwarn = 1*DIGIT 309 email.sieve.runtime.errtxt 310 If supported by the Sieve implementation (see section 7), this 311 attribute contains the text of runtime errors detected in the 312 currently active Sieve script. The error text is formated into 313 CRLF-separated lines, one line per error. Each line contains 314 named attributes of the error, in a MIME-header-like format. 315 The currently specified attributes are: line, offset, length, 316 and text. Text MUST always be the last attribute. This 317 attribute SHOULD be cleared when a new script is stored. It MAY 318 be reset at other times, at the discretion of the server. Sieve 319 is specified in [SIEVE]. 321 The format is intended to be easy for a Sieve execution agent to 322 generate, and easy for a Sieve user agent to parse. The Sieve 323 user agent could use the information to highlight the indicated 324 section of the Sieve script text, as specified by the line, 325 offset, and length. 327 email-sieve-errtxt = *(non-text-sieve-att ";" SP) 328 text-sieve-att CRLF 329 non-text-sieve-att = sieve-att-line / sieve-att-off / 330 sieve-att-len / sieve-att-ext 331 text-sieve-att = "text" ":" SP 1*UTF8-CHAR 332 ;MAY use ":" or ";" 333 ;MUST NOT use CRLF 334 sieve-att-line = "line" ":" SP 1*DIGIT 335 sieve-att-off = "offset" ":" SP 1*DIGIT 336 sieve-att-len = "length" ":" SP 1*DIGIT 337 sieve-att-ext = 1*UTF8-CHAR ":" SP 1*UTF8-CHAR 338 ;MUST NOT use ":" or ";" 340 email.sieve.runtime.warntxt 341 If supported by the Sieve implementation (see section 7), this 342 attribute contains the text of runtime warnings detected in the 343 currently active Sieve script. The warning text is formated 344 into CRLF-separated lines, one line per warning, as specified 345 for "email.sieve.runtime.errtxt". This attribute SHOULD be 346 cleared when a new script is stored. It MAY be reset at other 347 times, at the discretion of the server. Sieve is specified in 348 [SIEVE]. 350 email-sieve-warntxt = email-sieve-errtxt 352 email.sieve.syntax.errors 353 If supported by the Sieve implementation (see section 7), this 354 attribute contains the count of syntax errors detected in the 355 most recently stored Sieve script. Sieve is specified in 356 [SIEVE]. 358 email-sieve-synerr = 1*DIGIT 360 email.sieve.syntax.warnings 361 If supported by the Sieve implementation (see section 7), this 362 attribute contains the count of syntax warnings detected in the 363 most recently stored Sieve script. Sieve is specified in 364 [SIEVE]. 366 email-sieve-synwarn = 1*DIGIT 368 email.sieve.syntax.errtxt 369 If supported by the Sieve implementation (see section 7), this 370 attribute contains the text of syntax errors detected in the 371 most recently stored Sieve script. The error text is formated 372 into CRLF-separated lines, one line per error, as specified for 373 "email.sieve.runtime.errtxt". Sieve is specified in [SIEVE]. 375 email-sieve-synerrtxt = email-sieve-errtxt 377 email.sieve.syntax.warntxt 378 If supported by the Sieve implementation (see section 7), this 379 attribute contains the text of syntax warnings detected in the 380 most recently stored Sieve script. The warning text is formated 381 into CRLF-separated lines, one line per warning, as specified 382 for "email.sieve.runtime.errtxt". Sieve is specified in 383 [SIEVE]. 385 email-sieve-synwarntxt = email-sieve-errtxt 387 email.trash-folder 388 This attribute contains the name of a folder to which messages 389 SHOULD be moved in lieu of immediately marking them deleted. If 390 empty, messages SHOULD be marked deleted. This is only useful 391 when accessing messages via IMAP [IMAP4]. 393 email-trash = 1*CHAR 395 7. Dataset Class Capabilities 397 Certain attributes in the Email Account dataset class are only 398 available if there is integrated server support or an active client 399 providing them. Availability of such attributes is indicated by 400 corresponding attributes in the "email" entry of the "capability" 401 dataset. The capability attribute has the name of the attribute in 402 the Email dataset, prefixed with "capability.", and has a value of 403 "1" if the corresponding attribute in the Email dataset is 404 supported. 406 capability.email.sieve.runtime.errors 407 capability.email.sieve.runtime.warnings 408 capability.email.sieve.runtime.errtxt 409 capability.email.sieve.runtime.warntxt 410 capability.email.sieve.syntax.errors 411 capability.email.sieve.syntax.warnings 412 capability.email.sieve.syntax.errtxt 413 capability.email.sieve.syntax.warntxt 415 Note that these attributes SHOULD NOT be modified except by the 416 server or an active client responsible for supporting the underlying 417 capability. These attributes are normally inherited from a 418 site-specific dataset. 420 8. Examples 422 entry home 423 email.connection-type phone-modem 424 email.personality home 425 email.server.pop POP://jru;AUTH=APOP@pop.isp.com 426 email.sieve.capability ("vacation" "mark") 427 email.sieve.script if header :matches "subject" 428 [ "*make*money*fast*", 429 "*university*dipl*mas*" ] 430 { 431 discard; 432 } 433 email.boring-headers ("received" "message" "x400") 435 entry work 436 email.connection-type direct 437 email.personality work 438 email.server.imap IMAP://jru@mail.bigcorp.com 439 email.sieve.capability ("fileinto" "vacation" "envelope") 440 email.sieve.script if header :is "Sender" 441 "BigCheese@example.com" 442 { 443 fileinto "Blatherings"; 444 } 445 email.trash-folder Trash 447 9. Normative References 449 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 450 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd., 451 November 1997. 453 [ACAP] Newman, Myers, "ACAP -- Application Configuration Access 454 Protocol", RFC 2244, Innosoft, Netscape, November 1997. 455 457 [ACAP-OPTIONS] Hole, "ACAP Application Options Dataset Class", The 458 Esys Corporation, work in Progress, 459 461 [ACAP-PERSONALITY] Gellens, "ACAP Email Personality Dataset Class", 462 QUALCOMM Incorporated, work in Progress, 463 465 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 466 Requirement Levels", RFC 2119, Harvard University, March 1997. 467 469 [SIEVE] Showalter, "Sieve: A Mail Filtering Language", RFC 3028, 470 Mirapoint, Inc, January 2001. 471 473 [URL-BASIC] Berners-Lee, Masinter, McCahill, "Uniform Resource 474 Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of 475 Minnesota, December 1994. 477 [URL-IMAP] Newman, "IMAP URL Scheme", RFC 2192, Innosoft, September 478 1997. 480 [URL-POP] Gellens, "POP URL Scheme", RFC 2384, QUALCOMM 481 Incorporated, August 1998. 483 [UTF8] Yergeau, F. "UTF-8, a transformation format of ISO 10646", 484 RFC 2279, Alis Technologies, January 1998. 485 487 10. Informative References 489 [IMAP4] Crispin, "Internet Message Access Protocol - Version 4rev1", 490 RFC 2060, University of Washington, December 1996. 492 [POP3] Myers, Rose, "Post Office Protocol -- Version 3", RFC 1939, 493 Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. 494 496 11. Security Considerations 498 As with ACAP datasets in general, it is important that access 499 controls are set correctly on Email Account datasets. Besides the 500 server URLs, the Sieve script may contain highly personal 501 information which should not be disclosed except by explicit owner 502 request. 504 12. Acknowledgments 506 Many thanks to the participants of the IETF ACAP working group for 507 their help, comments, and suggestions. 509 13. Author's Address 511 Randall Gellens +1 858 651 5115 512 QUALCOMM Incorporated randy@qualcomm.com 513 5775 Morehouse Drive 514 San Diego, CA 92121-2779 515 U.S.A. 517 Intellectual Property Statement 518 The IETF takes no position regarding the validity or scope of any 519 intellectual property or other rights that might be claimed to 520 pertain to the implementation or use of the technology described in 521 this document or the extent to which any license under such rights 522 might or might not be available; neither does it represent that it 523 has made any effort to identify any such rights. Information on the 524 IETF's procedures with respect to rights in standards-track and 525 standards-related documentation can be found in BCP-11. Copies of 526 claims of rights made available for publication and any assurances 527 of licenses to be made available, or the result of an attempt made 528 to obtain a general license or permission for the use of such 529 proprietary rights by implementors or users of this specification 530 can be obtained from the IETF Secretariat. 532 The IETF invites any interested party to bring to its attention any 533 copyrights, patents or patent applications, or other proprietary 534 rights which may cover technology that may be required to practice 535 this standard. Please address the information to the IETF Executive 536 Director. 538 Full Copyright Statement 540 Copyright (C) The Internet Society 2003. All Rights Reserved. 542 This document and translations of it may be copied and furnished to 543 others, and derivative works that comment on or otherwise explain it 544 or assist in its implementation may be prepared, copied, published 545 and distributed, in whole or in part, without restriction of any 546 kind, provided that the above copyright notice and this paragraph 547 are included on all such copies and derivative works. However, this 548 document itself may not be modified in any way, such as by removing 549 the copyright notice or references to the Internet Society or other 550 Internet organizations, except as needed for the purpose of 551 developing Internet standards in which case the procedures for 552 copyrights defined in the Internet Standards process must be 553 followed, or as required to translate it into languages other than 554 English. 556 The limited permissions granted above are perpetual and will not be 557 revoked by the Internet Society or its successors or assigns. 559 This document and the information contained herein is provided on an 560 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 561 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 562 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 563 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 564 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.