idnits 2.17.1 draft-ietf-acap-email-01.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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.) ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([ACAP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 112: '...il account entry MUST have an "entry" ...' RFC 2119 keyword, line 113: '... attributes are OPTIONAL....' RFC 2119 keyword, line 120: '...string. Clients MUST conform to the s...' RFC 2119 keyword, line 121: '... attributes, but MUST NOT assume that ...' RFC 2119 keyword, line 122: '...is syntax on access. Servers MUST NOT...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: email-sieve-errtxt = *(non-text-sieve-att ";" SP) text-sieve-att non-text-sieve-att = sieve-att-line / sieve-att-off / sieve-att-len / sieve-att-ext text-sieve-att = "text" ":" 1*UTF8-CHAR sieve-att-line = "line" ":" 1*DIGIT sieve-att-off = "offset" ":" 1*DIGIT sieve-att-len = "length" ":" 1*DIGIT sieve-att-ext = 1*UTF8-CHAR ":" 1*UTF8-CHAR ; MUST not use ":" or ";" -- 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 (18 December 1998) is 9260 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 294 looks like a reference -- Missing reference section? 'KEYWORDS' on line 306 looks like a reference -- Missing reference section? 'ACAP-OPTIONS' on line 298 looks like a reference -- Missing reference section? 'ABNF' on line 290 looks like a reference -- Missing reference section? 'POP3' on line 310 looks like a reference -- Missing reference section? 'ACAP-PERSONALITY' on line 302 looks like a reference -- Missing reference section? 'URL-BASIC' on line 314 looks like a reference -- Missing reference section? 'URL-IMAP' on line 318 looks like a reference -- Missing reference section? 'URL-POP' on line 321 looks like a reference -- Missing reference section? 'SIEVE' on line 328 looks like a reference -- Missing reference section? 'UTF8' on line 324 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 13 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-01.txt QUALCOMM 3 Expires: 18 June 1999 18 December 1998 5 ACAP Email Account Dataset Class 7 Status of this Memo: 9 This document is an Internet Draft. Internet Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet Drafts. 14 Internet Drafts are draft documents valid for a maximum of six 15 months. Internet Drafts may be updated, replaced, or obsoleted by 16 other documents at any time. It is not appropriate to use Internet 17 Drafts as reference material or to cite them other than as a 18 "working draft" or "work in progress." 20 To learn the current status of any Internet Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet Drafts shadow 22 directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 A version of this draft document is intended for submission to the 27 RFC editor as a Proposed Standard for the Internet Community. 28 Discussion and suggestions for improvement are requested. 30 Public comments can be sent to the IETF ACAP mailing list, 31 . To subscribe, send a message 32 containing SUBSCRIBE to . 33 Private comments should be sent to the author. 35 Copyright Notice 37 Copyright (C) The Internet Society 1998. All Rights Reserved. 39 Table of Contents 41 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2 42 2. Conventions Used in this Document . . . . . . . . . . . . . . 2 43 3. ACAP Standard Options . . . . . . . . . . . . . . . . . . . 2 44 4. ACAP Email Account Dataset Class . . . . . . . . . . . . . . 3 45 4.1. ACAP Email Account Dataset Class Prefix . . . . . . . . 3 46 4.2. ACAP Email Account Dataset Hierarchy . . . . . . . . . . 3 47 5. ACAP Email Account Dataset Attributes . . . . . . . . . . . 3 48 5.1. Basic Attributes . . . . . . . . . . . . . . . . . . . . 3 49 5.2. Specific Attributes . . . . . . . . . . . . . . . . . . 4 50 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 51 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 52 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 53 9. Author's Address . . . . . . . . . . . . . . . . . . . . . . 8 54 10. Full Copyright Statement . . . . . . . . . . . . . . . . . . 8 56 1. Abstract 58 It has become common for Internet mail users to have more than one 59 account where mail is received, to access multiple accounts from the 60 same machine, to access the same accounts from different machines, 61 and to use multiple programs which require account configuration 62 information. 64 The Application Configuration Access Protocol [ACAP] provides an 65 ideal mechanism for storage of email account data. 67 This specification defines a standard ACAP dataset class for email 68 accounts, and a common option for indicating a default email. 70 2. Conventions Used in this Document 72 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 73 in this document are to be interpreted as defined in "Key words for 74 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 76 3. ACAP Standard Options 78 This specification defines the Message User Agent (MUA) Default 79 Account standard option. This is a scaler option in the ACAP 80 Standard Option ("/option") dataset. The entry name is 81 "mua.default.account". The "option.value" attribute contains the 82 value, which is a URL. Generally, this will be an ACAP URL pointing 83 to an entry in an Email Account dataset. 85 The standard option dataset class is specified in [ACAP-OPTIONS]. 86 ACAP URLs are defined in [ACAP]. 88 4. ACAP Email Account Dataset Class 90 The ACAP Email Account dataset class defines a set of attributes 91 which specify an email account; that is, configuration information 92 used for access to email on a POP or IMAP server. 94 4.1. ACAP Email Account Dataset Class Prefix 96 Datasets whose names begin with "/email" are assumed to contain 97 email account entries as defined in this specification. 99 4.2. ACAP Email Account Dataset Hierarchy 101 Each user may have a set of named email accounts. The default is 102 pointed at by the "mua.default.account" standard option. (See 103 section 3 for more information.) 105 Inheritance is likely to be useful both for inheriting site or group 106 defaults (for example, POP or IMAP servers, and initial client 107 configuration in general) as well as for inheriting user-specific 108 configuration when using different machines. 110 5. ACAP Email Account Dataset Attributes 112 An email account entry MUST have an "entry" attribute. All other 113 attributes are OPTIONAL. 115 Attributes are specified using Augmented Backus-Naur Form [ABNF]. 116 All attributes are single-valued and textual unless otherwise 117 stated. 119 The ABNF defines the content of the attribute values prior to their 120 encoding as an ACAP string. Clients MUST conform to the syntax when 121 generating these attributes, but MUST NOT assume that the attribute 122 values will conform to this syntax on access. Servers MUST NOT 123 enforce the syntax. 125 5.1. Basic Attributes 127 These attributes are defined in ACAP [ACAP] and have meaning in all 128 dataset classes. The section describes how they are used in an 129 email account dataset. 131 entry 132 The "entry" attribute is used to hold a unique name for the 133 email. This name is used for inheritance, so when customizing 134 an account which has an entry in an inherited dataset, the entry 135 name needs to remain the same. The name should also be 136 descriptive. 138 subdataset 139 The "subdataset" attribute indicates there is another email 140 account dataset underneath this entry. 142 5.2. Specific Attributes 144 These attributes are specific to the Email Account dataset class. 146 email.check-interval 147 This specifies the interval, in seconds, between checks (polls) 148 for new mail. 150 email-check-int = 1*DIGIT 152 email.connection-type 153 This contains a token indicating the type of connection used for 154 this email. Clients might use this information to modify their 155 use of bandwidth. 157 email-conn = "direct" / "cable-modem" / "phone-modem" / 158 "mobile-phone" 160 email.leave-on-server.flag 161 This specifies if the client should delay deleting mail from the 162 server after downloading. This is generally useful only with 163 [POP3] servers which support this. 165 email-lmos-flag = "0" / "1" 167 email.leave-on-server.days 168 When email.leave-on-server.flag is set (value is "1"), this 169 attribute specifies the number of days messages should remain on 170 the server before being deleted by the client. This is 171 generally useful only with [POP3] servers which support leaving 172 mail on the server. 174 email-lmos-days = 1*DIGIT 176 email.maximum.download-size 177 This contains the maximum size (in octets) of messages to be 178 downloaded. This is most useful when accessing messages via 179 [POP3]. 181 email-max-dsize = 1*DIGIT 183 email.personality 184 This specifies the default personality to assign to messages 185 received via this email account. It is generally an ACAP URL to 186 an entry in an Email Personality dataset. The ACAP Email 187 Personality dataset class is specified in [ACAP-PERSONALITY]. 188 ACAP-URLs are defined in [ACAP]. 190 email-personality = url ;defined in [URL-BASIC] 192 email.server.IMAP 193 The indicates the default IMAP server to use with this email 194 account. It is generally an IMAP URL, as specified in 195 [URL-IMAP]. 197 email-imap = url ;defined in [URL-BASIC] 199 email.server.POP 200 This specifies the POP server associated with this email 201 account. It is generally a POP URL, as defined in [URL-POP]. 203 email-pop = url ;defined in [URL-BASIC] 205 email.sieve.script 206 This specifies the text of a Sieve script which will be applied 207 by the delivery agent (if supported) to mail arriving at this 208 email. Sieve is specified in [SIEVE]. 210 email-sieve = 1*UTF8-CHAR 212 email.sieve.syntax.errors 213 If supported by the Sieve implementation, this attribute 214 contains the count of syntax errors detected in the most 215 recently stored Sieve script. Sieve is specified in [SIEVE]. 217 email-sieve-synerr = 1*DIGIT 219 email.sieve.syntax.warnings 220 If supported by the Sieve implementation, this attribute 221 contains the count of syntax warnings detected in the most 222 recently stored Sieve script. Sieve is specified in [SIEVE]. 224 email-sieve-synwarn = 1*DIGIT 226 email.sieve.syntax.errtxt 227 If supported by the Sieve implementation, this attribute 228 contains the text of syntax errors detected in the most recently 229 stored Sieve script. The error text is formated into 230 CRLF-separated lines, one line per error. Each line contains 231 named attributes of the error, in a MIME-header-like format. 232 The currently specified attributes are: line, offset, length, 233 and text. Text MUST always be the last attribute. Sieve is 234 specified in [SIEVE]. 236 The format is intended to be easy for a Sieve execution agent to 237 generate, and easy for a Sieve user agent to parse. The Sieve 238 user agent could use the information to highlight the indicated 239 section of the Sieve script text, as specified by the line, 240 offset, and length. 242 email-sieve-errtxt = *(non-text-sieve-att ";" SP) text-sieve-att 243 non-text-sieve-att = sieve-att-line / sieve-att-off / 244 sieve-att-len / sieve-att-ext 245 text-sieve-att = "text" ":" 1*UTF8-CHAR 246 sieve-att-line = "line" ":" 1*DIGIT 247 sieve-att-off = "offset" ":" 1*DIGIT 248 sieve-att-len = "length" ":" 1*DIGIT 249 sieve-att-ext = 1*UTF8-CHAR ":" 1*UTF8-CHAR 250 ; MUST not use ":" or ";" 252 email.sieve.syntax.warntxt 253 If supported by the Sieve implementation, this attribute 254 contains the text of syntax warnings detected in the most 255 recently stored Sieve script. The warning text is formated into 256 CRLF-separated lines, one line per warning. Each line contains 257 named attributes of the warning, in a MIME-header-like format. 258 The currently specified attributes are: line, offset, length, 259 and text. Text MUST always be the last attribute. Sieve is 260 specified in [SIEVE]. 262 email-sieve-warntxt = email-sieve-errtxt 264 email.taboo-headers 265 This multi-valued attribute is a list of header prefixes. If 266 the client has a mode where it suppresses display of certain 267 headers and/or properties of messages, headers which start with 268 a prefix included in this attribute are candidates for 269 suppression. Prefix strings are case-insensitive. 271 email-taboo = 1*VCHAR 273 6. Examples 275 entry home 276 email.connection-type phone-modem 277 email.personality home 278 email.server.pop POP://jru;AUTH=APOP@pop.isp.com 279 email.sieve.script IF SIZE OVER 100k 280 DISCARD; 282 entry work 283 email.connection-type direct 284 email.personality work 285 email.server.imap IMAP://jru@mail.bigcorp.com 286 email.sieve.script IF HEADER "FROM" IS "BOSS" 287 FILEINTO "STUFF" 288 7. References 290 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 291 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd., 292 November 1997. 294 [ACAP] Newman, Myers, "ACAP -- Application Configuration Access 295 Protocol", RFC 2244, Innosoft, Netscape, November 1997. 296 298 [ACAP-OPTIONS] Hole, "ACAP Application Options Dataset Class", The 299 Esys Corporation, Work in Progress, February 1998. 300 302 [ACAP-PERSONALITY] Gellens, "ACAP Email Personality Dataset Class", 303 QUALCOMM Incorporated, Work in Progress. 304 306 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 307 Requirement Levels", RFC 2119, Harvard University, March 1997. 308 310 [POP3] Myers, Rose, "Post Office Protocol -- Version 3", RFC 1939, 311 Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. 312 314 [URL-BASIC] Berners-Lee, Masinter, McCahill, "Uniform Resource 315 Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of 316 Minnesota, December 1994. 318 [URL-IMAP] Newman, "IMAP URL Scheme", RFC 2192, Innosoft, September 319 1997. 321 [URL-POP] Gellens, "POP URL Scheme", RFC 2384, QUALCOMM 322 Incorporated, August 1998. 324 [UTF8] Yergeau, F. "UTF-8, a transformation format of ISO 10646", 325 RFC 2279, Alis Technologies, January 1998. 326 328 [SIEVE] Showalter, "Sieve -- a Mail Filtering Language", Carnegie 329 Mellon, Work in Progress. 330 332 8. Security Considerations 334 As with ACAP datasets in general, it is important that access 335 controls are set correctly on Email Account datasets. Besides the 336 server URLs, the Sieve script may contain highly personal 337 information which should not be disclosed except by explicit owner 338 request. 340 9. Author's Address 342 Randall Gellens +1 619 651 5115 343 QUALCOMM Incorporated Randy@Qualcomm.Com 344 6455 Lusk Blvd. 345 San Diego, CA 92121-2779 346 U.S.A. 348 10. Full Copyright Statement 350 Copyright (C) The Internet Society 1998. All Rights Reserved. 352 This document and translations of it may be copied and furnished to 353 others, and derivative works that comment on or otherwise explain it 354 or assist in its implementation may be prepared, copied, published 355 and distributed, in whole or in part, without restriction of any 356 kind, provided that the above copyright notice and this paragraph 357 are included on all such copies and derivative works. However, this 358 document itself may not be modified in any way, such as by removing 359 the copyright notice or references to the Internet Society or other 360 Internet organizations, except as needed for the purpose of 361 developing Internet standards in which case the procedures for 362 copyrights defined in the Internet Standards process must be 363 followed, or as required to translate it into languages other than 364 English. 366 The limited permissions granted above are perpetual and will not be 367 revoked by the Internet Society or its successors or assigns. 369 This document and the information contained herein is provided on an 370 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 371 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 372 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 373 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 374 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.