idnits 2.17.1 draft-lehmann-morg-pop3listplus-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1939, updated by this document, for RFC5378 checks: 1995-05-15) -- 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 (Aug 2011) is 4638 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Lehmann 3 Internet-Draft Strato AG 4 Updates: 1939 (if approved) Aug 2011 5 Intended status: Standards Track 6 Expires: February 2, 2012 8 The Post Office Protocol (POP3) LIST+ Extension 9 draft-lehmann-morg-pop3listplus-01 11 Abstract 13 The Post Office Protocol - Version 3 (POP3) LIST+ Extension allows a 14 POP3 client to instruct a POP3 server to send additional information 15 with the LIST command response. It also can instruct a POP3 server 16 to send only information about newly arrived messages, when polling 17 for new messages. This will help save message round trips and 18 network bandwidth, especially on large mailboxes containing several 19 messages. On public POP3 servers, serving thousands of mailboxes, 20 and being polled frequently, LIST+ will help reduce server load as 21 well as network bandwith. 23 Note 25 This document defines an extension to POP3, and updates RFC 1939. 27 Technical comments are solicited and should be addressed to Message 28 Organizations Working Group's mailing list at morg@ietf.org and/or to 29 the author. You can subscribe to that list at 30 https://www.ietf.org/mailman/listinfo/morg. 32 Editorial comments should be addressed directly to the author. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on February 2, 2012. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.2. Conventions used in this document . . . . . . . . . . 5 71 2. The LIST+ Capability . . . . . . . . . . . . . . . . . 5 73 3. The LIST Command . . . . . . . . . . . . . . . . . . . 6 75 4. Initial Set of LIST+ Flags . . . . . . . . . . . . . . 7 76 4.1. The +AGE Flag . . . . . . . . . . . . . . . . . . . . 7 77 4.2. The +ID Flag . . . . . . . . . . . . . . . . . . . . . 7 78 4.2.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 7 79 4.2.2. The ID-Identifier . . . . . . . . . . . . . . . . . . 7 80 4.2.3. Actions at server's side . . . . . . . . . . . . . . . 8 81 4.2.4. Actions at client's side . . . . . . . . . . . . . . . 9 82 4.2.5. Examples . . . . . . . . . . . . . . . . . . . . . . . 9 83 4.3. The +UIDL Flag . . . . . . . . . . . . . . . . . . . . 11 85 5. Parameter and Response Length . . . . . . . . . . . . 11 87 6. Future Extensions to LIST+ . . . . . . . . . . . . . . 11 89 7. Security Considerations . . . . . . . . . . . . . . . 11 91 8. IANA Considerations . . . . . . . . . . . . . . . . . 12 92 8.1. 'LIST+ Flags' Registry . . . . . . . . . . . . . . . . 12 93 8.2. LIST+ Registration in 'POP3 Capabilities' Registry . . 12 95 9. Conclusions . . . . . . . . . . . . . . . . . . . . . 12 97 10. Normative References . . . . . . . . . . . . . . . . . 12 99 Appendix A. Message flow examples . . . . . . . . . . . . . . . . 13 100 A.1. Typical message flow without LIST+ Extension . . . . . 13 101 A.2. Message Flow using the LIST+ Extension . . . . . . . . 13 102 A.2.1. LIST+ for all messages . . . . . . . . . . . . . . . . 14 103 A.2.2. LIST+ for a single message . . . . . . . . . . . . . . 14 104 A.2.3. LIST+ for all messages using all possible LIST+ 105 Flags, one new message arrived . . . . . . . . . . . . 14 107 Appendix B. Augmented BNF . . . . . . . . . . . . . . . . . . . . 14 109 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . . 15 111 Author's Address . . . . . . . . . . . . . . . . . . . 15 113 1. Introduction 115 1.1. Overview 117 Although POP3 is intended as a download-and-delete protocol, clients 118 can decide to leave messages on the server. If this happens on a 119 mailbox having "unlimited" mail space, such a mailbox will grow 120 continously in size, so mailboxes having thousands of mails are not 121 uncommon. The POP3 protocol has no means to poll for only new 122 arrived messages. Observations on a public POP3 server have shown 123 several POP3 clients using the LIST command, and, immediately 124 followed, the UIDL command to get the Message Number, Message Size 125 and Unique-ID, of all messages of a mailbox, to see if new messages 126 have arrived. Both commands, LIST and UIDL, always respond with a 127 list of all messages. On large mailboxes, this will waste network 128 bandwith, and will prolong the duration a mailbox is hold in locked 129 state. This situation is even stressed by the fact that POP3 clients 130 will usually poll a mailbox for new messages periodically in short 131 intervals. 133 The LIST command, on the server, has to scan through all messages of 134 a mailbox to provide the Message Number and the Message Size. The 135 subsequent UIDL command has to scan again through all messages of a 136 mailbox to provide the Message Number and the Unique-ID. The Message 137 Number sent with the UIDL command, in this scenario, is already known 138 to the client, and therefore, is a redundant information (as in 139 example shown in Appendix A.1). All the lines with Message Numbers 140 the client already knows, are of no interest by client, and 141 therefore, sent by server in vain. Using the LIST+ Extension, a 142 server has to scan through the mailbox only for a single time, and 143 can send the Message Number, Message Size and Unique-ID in a more 144 compact form to the client (as shown in Appendix A.2.1). 146 Another major benefit of the LIST+ Extension is that the client can 147 instruct the server to send only information about newly arrived 148 messages. This avoids sending of information by server, which the 149 client already knows. 151 The LIST+ Extension also offers the possibility to fetch other useful 152 information with the LIST command quasi "on the fly", like the age of 153 a message. This may be helpful for clients to decide if a message 154 has to be deleted automatically due to clients' message deleting 155 policies. There is no need to read the mail headers to make this 156 decision in this case. 158 Although it would be better to access large mailboxes by IMAP, there 159 might be reasons for customers to use POP3. 161 1.2. Conventions used in this document 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 In this document, these words will appear with that interpretation 168 only when in ALL CAPS. Lower case uses of these words are not to be 169 interpreted as carrying RFC-2119 significance. 171 In this document, the term "client" refers to a host making use of 172 the POP3 service, while the term "server" refers to a host which 173 offers the POP3 service. 175 In examples, "C:" and "S:" indicate lines sent by the client and 176 server respectively. 178 In this document, the term "scan listing" refer to the output of a 179 POP3 LIST command, containing one line for every message in a 180 mailbox, as described in [RFC1939], Section 5. 182 In this document, the terms "extended scan listing" and "full scan 183 listing" refer to a "POP3 scan listing", which can hold additional 184 information, controlled by the means of the POP3 LIST+ command, as 185 described in this document. 187 2. The LIST+ Capability 189 This section defines the LIST+ Capability according to Section 9 of 190 [RFC2449]. 192 CAPA tag: 193 LIST+ 195 Arguments: 196 Supported LIST+ Flags 198 Added commands: 199 none 201 Standard commands affected: 202 LIST 204 Announces states / possible differences: 205 both / no 207 Commands valid in states: 208 n/a 210 Specification reference: 211 This document and [RFC1939] 213 Discussion: 214 The LIST+ capability enables the use of the indicated LIST+ Flags 215 as additional parameters of the LIST command. 217 3. The LIST Command 219 This section updates the syntax of the LIST command as well as the 220 definition of the scan listing, both as defined in Section 5 of 221 [RFC1939]. 223 Formal syntax: LIST [msg] [flaglist] 225 The flaglist is a list of LIST+ Flags, separated by a single space. 226 A LIST+ Flag always starts with "+" (it means "add the following 227 information"), followed by the name of the flag. A flag name MUST 228 start with a letter ("A-Z" or "a-z"), and MUST NOT be longer than 20 229 characters. 231 A server, supporting LIST+, has to decide whether the first argument 232 of the LIST command (if any) is a message number or a LIST+ Flag. If 233 an argument starts with "+", and its second character is a letter, 234 this parameter is to be considered as a LIST+ flag. 236 If the server receives a LIST+ flag which is not supported, the 237 server MUST issue a "-ERR" response. 239 After the server has accepted a flaglist, it sends an extended scan 240 listing for each requested message back to the client. The extended 241 scan listing consists of: 243 o The message-number of the message, followed by a single space 245 o The exact size of the message in octets, followed by a single 246 space 248 o The value(s) as requested by the flaglist, separated each by a 249 single space, in the same order as given in the flaglist. A value 250 MUST consist of only ASCII characters in the range of 33-126 (hex 251 21-7E). Otherwise, it is RECOMMENDED to use BASE64 encoding 252 according to [RFC4648]. 254 See Appendix B for a formal syntax using ABNF. 256 4. Initial Set of LIST+ Flags 258 4.1. The +AGE Flag 260 The +AGE Flag requests to add the age of a message to the extended 261 scan listing. The age is expressed in units of whole days since the 262 message was delivered into the mailbox. 264 A message delivered yesterday (regardless of the time) has an age of 265 one. A message delivered today has an age of zero. The value is 266 presented as a decimal integer. 268 Servers which are unable to determine the age of a message in this 269 way MUST NOT advertise the +AGE Flag in the LIST+ capability list. 271 The +AGE Flag has no Parameter. 273 4.2. The +ID Flag 275 4.2.1. Purpose 277 The +ID Flag instructs the server to 279 o suppress all scan lines the server has already issued (except the 280 last one), 282 o send an ID-Identifier as first item in the "OK" response line. 284 The +ID Flag, when sent by client, always has a parameter. This 285 parameter can be: 287 o The ID-Identifier as received from server in a response of a 288 previous LIST+ command. 290 o An empty string. 292 4.2.2. The ID-Identifier 294 The ID-Identifier, if not empty, MUST consist of characters all in 295 the range of 33-126 (hex 21-7E). Its length should be kept as short 296 as possible, but MUST NOT exceed 255 bytes. The ID-Identifier is 297 generated by the server. The server has to put all information into 298 the ID-Identifier which it needs to find out the last issued message 299 of a mailbox. A newly created ID-Indentifier MUST be unique with 300 respect to former created ID-Identifiers. 302 The server stores the last issued ID-Indentifier in the meta-data 303 store of a mailbox. A volatile memory MAY be used. It is not 304 allowed to store more than one ID-Identifier per mailbox. The server 305 MAY delete a stored ID-Identifier at any time. 307 The client retains a received ID-Identifier, and MAY send it as a +ID 308 Flag parameter in the very next LIST+ command. After the client has 309 sent a LIST command or LIST+ command (with or without +ID Flag), a 310 stored ID-Identifier MUST be deleted by client. 312 4.2.3. Actions at server's side 314 The server deletes one or more messages from the mailbox: 315 If there is a stored ID-Identifier, delete it. 317 The server appends one or more messages to the mailbox: 318 If there is a stored ID-Identifier, leave it intact. 320 The server receives a LIST command or LIST+ command without +ID 321 Flag: 322 Send a full scan listing. If there is a stored ID-Identifier, 323 leave it intact. Send no ID-Identifier to the client. 325 The server receives a LIST+ command with an empty ID-Identifier: 326 Send a full scan listing. If there is a stored ID-Identifier, 327 leave it intact and sent it to the client. If there is no stored 328 ID-Identifier, create one and send it to the client. 330 The server receives a LIST+ command with a non-empty ID-Identifier 331 equal to the stored one: 332 If the mailbox ist empty: Send an empty scan listing, leave the 333 ID-Identifier intact and send it to the client. If the message, 334 as referenced by the ID-identifier, is still the last message in 335 the mailbox: Send a partial scan listing which constist of only 336 the last message in the mailbox, leave the ID-Identifier intact 337 and send it to the client. If the message, as referenced by the 338 ID-Identifier, is not the last message in the mailbox: Send a 339 partial scan listing which constist of all messages with message 340 numbers above the message number as referenced by the ID- 341 Identifier, create and store a new ID-Identifier and send it to 342 the client. 344 The server receives a LIST+ command with a non-empty ID-Identifier 345 not equal to the stored one: 346 Send a full scan listing. If there is a stored ID-Identifier, 347 leave it intact and send it to the client. If there is no stored 348 ID-Identifier, create one and send it to the client. 350 4.2.4. Actions at client's side 352 The client receives an empty scan listing: 353 Consider the mailbox as empty. Store the new ID-Identifier. 355 The client receives a scan listing with first message number equal to 356 one: 357 Handle the scan listing as a full scan listing. Store the new 358 ID-Identifier. 360 The client receives a scan listing with first message number greater 361 than one: 362 Handle the scan listing as a partial scan listing. Store the new 363 ID-Identifier. Note: The client could already know the message 364 as indicated in the very first scan line. In this case, the 365 clients MAY skip processing of this scan line. 367 4.2.5. Examples 369 The client has just started up. For this reason, it has no ID- 370 Identifier yet, and sends an empty ID-Identifier to request one. The 371 servers issues all messages and an ID-Identifier "Az-Df~701", which 372 is retained by client: 374 S: +OK POP3 server ready 375 C: CAPA 376 S: +OK Capability list follows: 377 S: LIST+ +AGE +ID +UIDL 378 S: . 379 C: LIST +ID= +UIDL 380 S: +OK Az-Df~701 10299 messages, listing follows: 381 S: 1 4536 7abcb6f4da22080e121f2824aef2be9a 382 S: 2 4422 577151e65ea4e62bb9b1c5830a818fe7 383 S: 3 1134 6374234adfg58cda7b4ccdf34bccacc6 384 S: ... (10295 more lines) 385 S: 10299 3828 2fe542ac6d1c29bb6a5161558f527e2e 386 S: . 387 C: QUIT 388 S: +OK Closing connection 390 Client connecting the second time when there are no changes. The 391 server issues the ID-Identifier "Az-Df~701" again, which is retained 392 by client, and sends only the the last message in a partial scan 393 listing: 395 S: +OK POP3 server ready 396 C: CAPA 397 S: +OK Capability list follows: 398 S: LIST+ +AGE +ID +UIDL 399 S: . 400 C: LIST +ID=Az-Df~701 +UIDL 401 S: +OK Az-Df~701 No changes 402 S: 10299 3828 2fe542ac6d1c29bb6a5161558f527e2e 403 S: . 404 C: QUIT 405 S: +OK Closing connection 407 Client connecting the 3rd time when there are two new messages. The 408 server issues the ID-Identifier "Az-Df~702", which is retained by 409 client. Only the two new messages are sent in a partial scan 410 listing: 412 S: +OK POP3 server ready 413 C: CAPA 414 S: +OK Capability list follows: 415 S: LIST+ +AGE +ID +UIDL 416 S: . 417 C: LIST +ID=Az-Df~701 +UIDL 418 S: +OK Az-Df~702 2 more messages, listing follows: 419 S: 10300 258 4c2674df036aba49035134701bc47401 420 S: 10301 496 764fd5a52324c683c6b33a9c4c50abe2 421 S: . 422 C: QUIT 423 S: +OK Closing connection 425 Client connecting the 4th time when message #2 was deleted. The 426 server issues a complete scan listing, because of message deletetion. 427 The new ID-Identifier is "Az-Df~703". 429 S: +OK POP3 server ready 430 C: CAPA 431 S: +OK Capability list follows: 432 S: LIST+ +AGE +ID +UIDL 433 S: . 434 C: LIST +ID=Az-Df~702 +UIDL 435 S: +OK Az-Df~703 10300 messages, listing follows: 436 S: 1 4536 7abcb6f4da22080e121f2824aef2be9a 437 S: 2 1134 6374234adfg58cda7b4ccdf34bccacc6 438 S: ... (10297 more lines) 439 S: 10300 496 764fd5a52324c683c6b33a9c4c50abe2 440 S: . 441 C: QUIT 442 S: +OK Closing connection 444 4.3. The +UIDL Flag 446 The +UIDL Flag requests to add the Unique-ID of a message to the 447 extended scan listing. The Unique-ID for a message is the same value 448 as it would be sent by the UIDL command for this message. See 449 [RFC1939], Section 7, "UIDL Command". 451 Servers not supporting the UIDL command MUST NOT advertise the +UIDL 452 Flag in the LIST+ capability list. 454 The +UIDL Flag has no Parameter. 456 5. Parameter and Response Length 458 The Parameter and Response Lengths, as defined in Section 4 of 459 [RFC2449], are not affected by the LIST+ Extension Flags as defined 460 in this document. 462 The already defined Parameter and Response Lengths are sufficient to 463 hold complete LIST+ command and response lines as defined in this 464 document, even if all possible flags are given together. 466 6. Future Extensions to LIST+ 468 The LIST+ Extension itself is expandable. New LIST+ flags may be 469 defined by future documents. If such a document defines a LIST+ flag 470 whose value contains characters outside the range as defined in 471 Section 3, it MUST declare how to encode the value, so it fulfills 472 the requirements of this document. 474 Future documents defining new LIST+ flags MUST contain a statement 475 whether the Parameter and Response Length, as defined in Section 4 of 476 [RFC2449], are sufficient to hold lines with all possible flags/ 477 values, or not. If not, new values for parameter and response length 478 MUST be defined. 480 7. Security Considerations 482 The LIST+ Extension, if not proper implemented by client or server, 483 could prevent mails to be fetched from server. Firewalls or other 484 network devices, when monitoring POP3 sessions, could be worried by 485 the protocol changes made by LIST+. 487 8. IANA Considerations 489 8.1. 'LIST+ Flags' Registry 491 IANA is asked to create and maintain the 'LIST+ Flags' registry 492 following the guidelines below. 494 The registry consists of two values: LIST+ flag and Reference. They 495 are described below. 497 1) LIST+ flag - the text string, whose syntax is defined in Section 498 3. 500 2) Reference - the reference to the document that described the 501 LIST+ flag. 503 Initial values are given below; new assignments are to be made 504 following the 'IETF Consensus' policies [RFC5226]. 506 +------------+---------------+ 507 | LIST+ Flag | Reference | 508 +------------+---------------+ 509 | +UIDL | this document | 510 | +AGE | this document | 511 | +ID | this document | 512 +------------+---------------+ 514 Table 1: Initial IANA Values 516 8.2. LIST+ Registration in 'POP3 Capabilities' Registry 518 > IANA is asked a new keyword "LIST+" in the "POP3 Capabilities" 519 registry [RFC1939] using the template in Section Section 2 of this 520 document. 522 9. Conclusions 524 All mail program/server developers are encouraged to implement LIST+. 526 All carriers of POP3 servers holding mailboxes of many, frequently 527 polling clients are encouraged to support LIST+. 529 10. Normative References 531 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 532 STD 53, RFC 1939, May 1996. 534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 535 Requirement Levels", BCP 14, RFC 2119, March 1997. 537 [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension 538 Mechanism", RFC 2449, November 1998. 540 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 541 Encodings", RFC 4648, October 2006. 543 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 544 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 545 May 2008. 547 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 548 Specifications: ABNF", STD 68, RFC 5234, January 2008. 550 Appendix A. Message flow examples 552 A.1. Typical message flow without LIST+ Extension 553 S: +OK POP3 server ready 554 C: CAPA 555 S: +OK Capability list follows: 556 S: UIDL 557 S: . 558 C: LIST 559 S: +OK 3 messages, listing follows: 560 S: 1 4536 561 S: 2 4422 562 S: ... (10296 more lines) 563 S: 10299 3828 564 S: . 565 C: UIDL 566 S: +OK 10299 messages, listing follows: 567 S: 1 7abcb6f4da22080e121f2824aef2be9a 568 S: 2 577151e65ea4e62bb9b1c5830a818fe7 569 S: ... (10296 more lines) 570 S: 10299 2fe542ac6d1c29bb6a5161558f527e2e 571 S: . 572 C: QUIT 573 S: +OK Closing connection 575 A.2. Message Flow using the LIST+ Extension 576 A.2.1. LIST+ for all messages 577 S: +OK POP3 server ready 578 C: CAPA 579 S: +OK Capability list follows: 580 S: UIDL 581 S: LIST+ +UIDL +AGE 582 S: . 583 C: LIST +UIDL 584 S: +OK 10299 messages, listing follows: 585 S: 1 4536 7abcb6f4da22080e121f2824aef2be9a 586 S: 2 4422 577151e65ea4e62bb9b1c5830a818fe7 587 S: ... (10296 more lines) 588 S: 10299 3828 2fe542ac6d1c29bb6a5161558f527e2e 589 S: . 590 C: QUIT 591 S: +OK Closing connection 593 A.2.2. LIST+ for a single message 594 S: +OK POP3 server ready 595 C: CAPA 596 S: +OK Capability list follows: 597 S: UIDL 598 S: LIST+ +UIDL +AGE 599 S: . 600 C: LIST 2 +UIDL 601 S: +OK 2 4422 577151e65ea4e62bb9b1c5830a818fe7 602 C: QUIT 603 S: +OK Closing connection 605 A.2.3. LIST+ for all messages using all possible LIST+ Flags, one new 606 message arrived 607 S: +OK POP3 server ready 608 C: CAPA 609 S: +OK Capability list follows: 610 S: UIDL 611 S: LIST+ +UIDL +AGE 612 S: . 613 C: LIST +UIDL +AGE +ID=Az-Df~701 614 S: +OK Az-Df~702 1 new message, listing follows: 615 S: 10300 4536 ead6763cdc00080f36172429ac13c1cb 0 616 S: . 617 C: QUIT 618 S: +OK Closing connection 620 Appendix B. Augmented BNF 622 This section defines the LIST+ syntax using Augmented BNF (see 624 [RFC5234] for details). The following rules are for clarification 625 only, and are not intended to supersede the definition of the LIST 626 command, as defined in [RFC1939]. 628 listplus-req = "LIST" [SP msg-num] [SP listplus-flaglist] CRLF 629 listplus-rsp = listplus-rsp-ok / listplus-rsp-err 630 listplus-rsp-ok = "+OK" [SP listplus-id] [SP *comment] CRLF 631 *listplus-scanline 632 "." CRLF 633 listplus-rsp-err = "-ERR" [SP *comment] CRLF 634 listplus-scanline = msg-num SP msg-size [*(SP listplus-value)] CRLF 635 listplus-flaglist = listplus-flag [*(SP listplus-flag)] 636 listplus-flag = "+" ALPHA [*listplus-char] ["=" listplus-value] 637 listplus-value = 1*listplus-char 638 listplus-id = 1*255listplus-char 639 listplus-char = %x21-7E 640 msg-num = 1*DIGIT 641 msg-size = 1*DIGIT 642 comment = *(WSP / VCHAR) 644 Appendix C. Acknowledgements 646 Timo Sirainen contibuted an invaluable suggestion with the +ID flag. 647 Also, thanks to Mykyta Yevstifeyev, and many others. 649 Author's Address 651 Steffen Lehmann 652 Strato AG 653 Pascalstr. 10 654 Berlin D-10587 655 GERMANY 657 Email: lehmann@strato-rz.de 658 URI: http://www.strato.de/