idnits 2.17.1 draft-melnikov-imap-ext-abnf-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 646. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 670. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-melnikov-imap-ext-abnf', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-melnikov-imap-ext-abnf', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-melnikov-imap-ext-abnf', but the file name used is 'draft-melnikov-imap-ext-abnf-05' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 729 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There are 5 instances of too long lines in the document, the longest one being 6 characters in excess of 72. 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 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? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 2005) is 6767 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) == Unused Reference: 'NAMESPACE' is defined on line 594, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) Summary: 7 errors (**), 1 flaw (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft A. Melnikov 2 Document: draft-melnikov-imap-ext-abnf Isode Ltd. 3 Expires: April 2006 Cyrus Daboo 4 ISAMET, Inc. 5 October 2005 7 Collected extensions to IMAP4 ABNF 8 draft-melnikov-imap-ext-abnf-05 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 A revised version of this draft document will be submitted to the 34 RFC editor as a Standard Track RFC for the Internet Community. 35 Discussion and suggestions for improvement are requested, and 36 should be sent to ietf-imapext@imc.org and/or lemonade@ietf.org. 37 Distribution of this memo is unlimited. 39 Abstract 41 Over years many documents from IMAPEXT and LEMONADE working groups, 42 as well as many individual documents have added syntactic 43 extensions to many base IMAP commands described in RFC 3501. For 44 ease of reference this document collects most of such ABNF changes 45 in one place. 47 This document updates ABNF in RFC 3501, RFC 2342 and RFC 2088. 49 Table of Contents 51 1. Conventions Used in this Document 2 52 2. IMAP ABNF extensions 3 53 2.1 Optional parameters with the SELECT/EXAMINE commands 3 54 2.2 Extended CREATE command 4 55 2.3 Extended RENAME command 5 56 2.4 Extensions to FETCH and UID FETCH Commands 5 57 2.5 Extensions to STORE and UID STORE Commands 6 58 2.6 Extensions to SEARCH Command 6 59 2.7 Extensions to APPEND Command 7 60 3. Formal Syntax 7 61 4. Security Considerations 11 62 5. IANA Considerations 12 63 6. References 12 64 6.1 Normative References 12 65 7. Acknowledgments 12 66 8. Author's Addresses 12 67 9. Full Copyright Statement 13 68 10. Intellectual Property 13 69 11. Appendix A. Editorial. 14 70 11.1 Change Log 14 71 11.2 Open issues 14 73 1. Conventions Used in this Document 75 In examples, "C:" and "S:" indicate lines sent by the client and 76 server respectively. 78 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 79 in this document are to be interpreted as defined in "Key words for 80 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 82 <> 84 2. IMAP ABNF extensions 86 This section is not normative. It provides with some background on 87 intended use of different extensions and it tries to give some 88 guidance about how future extensions should extend the described 89 commands. 91 2.1 Optional parameters with the SELECT/EXAMINE commands 93 This documents adds the ability to include one or more parameters 94 with the IMAP SELECT or EXAMINE commands, to turn on or off certain 95 standard behaviour, or to add new optional behaviours required for 96 a particular extension. 98 There are two possible modes of operation: 100 o A global state change where a single use of the optional 101 parameter will effect the session state from that time on, 102 irrespective of subsequent SELECT/EXAMINE commands. 104 o A per-mailbox state change that will effect the session only for 105 the duration of the new selected state. A subsequent SELECT/ 106 EXAMINE without the optional parameter will cancel its effect 107 For the newly selected mailbox. 109 Optional parameters to the SELECT or EXAMINE commands are added as 110 a parenthesised list of atoms or strings, and appear after the 111 mailbox name in the standard SELECT or EXAMINE command. The order 112 of individual parameters is arbitrary. Individual parameters may 113 consist of one or more atoms or strings in a specific order. If a 114 parameter consists of more than one atom or string, it SHOULD 115 appear in its own parenthesised list. Any parameter not defined by 116 extensions that the server supports must be rejected with a BAD 117 response. 119 Example: 121 C: a SELECT INBOX (ANNOTATE) 122 S: ... 123 S: a OK SELECT complete 125 In the above example, a single parameter is used with the SELECT 126 command. 128 Example: 130 C: a EXAMINE INBOX (ANNOTATE RESPONSES "UID Responses" 131 CONDSTORE) 132 S: ... 133 S: a OK EXAMINE complete 135 In the above example, three parameters are used with the EXAMINE 136 command. The second parameter consists of two items: an atom 137 followed by a quoted string. 139 Example: 141 C: a SELECT INBOX (BLURDYBLOOP) 142 S: a BAD Unknown parameter in SELECT command 144 In the above example, a parameter not supported by the server is 145 used. This results in the BAD response from the 146 server. 148 2.2 Extended CREATE command 150 Arguments: mailbox name 151 OPTIONAL list of CREATE parameters 153 Responses: no specific responses for this command 155 Result: OK - create completed 156 NO - create failure: can't create mailbox with 157 that name 158 BAD - argument(s) invalid 160 This documents adds the ability to include one or more parameters 161 with the IMAP CREATE command (see section 6.3.3 of [IMAP4]), to 162 turn on or off certain standard behaviour, or to add new optional 163 behaviours required for a particular extension. No CREATE 164 parameters are defined in this document. 166 Optional parameters to the CREATE command are added as a 167 parenthesised list of attribute/value pairs after the mailbox name. 168 Each value can be either an atom, a string or a list. The order of 169 individual parameters is arbitrary. Individual parameters may 170 consist of one or more atoms or strings in a specific order. If a 171 parameter consists of more than one atom or string, it SHOULD 172 appear in its own parenthesised list. Any parameter not defined by 173 extensions that the server supports must be rejected with a BAD 174 response. 176 2.3 Extended RENAME command 178 Arguments: existing mailbox name 179 new mailbox name 180 OPTIONAL list of RENAME parameters 182 Responses: no specific responses for this command 184 Result: OK - rename completed 185 NO - rename failure: can't rename mailbox with 186 that name, can't rename to mailbox with 187 that name, etc. 188 BAD - argument(s) invalid 190 This documents adds the ability to include one or more parameters 191 with the IMAP RENAME command (see section 6.3.5 of [IMAP4]), to 192 turn on or off certain standard behaviour, or to add new optional 193 behaviours required for a particular extension. No RENAME 194 parameters are defined in this document. 196 Optional parameters to the RENAME command are added as a 197 parenthesised list of attribute/value pairs after the new mailbox 198 name. Each value can be either an atom, a string or a list. The 199 order of individual parameters is arbitrary. Individual parameters 200 may consist of one or more atoms or strings in a specific order. If 201 a parameter consists of more than one atom or string, it SHOULD 202 appear in its own parenthesised list. Any parameter not defined by 203 extensions that the server supports must be rejected with a BAD 204 response. 206 2.4 Extensions to FETCH and UID FETCH Commands 208 Arguments: sequence set 209 message data item names or macro 210 OPTIONAL fetch modifiers 212 Responses: untagged responses: FETCH 214 Result: OK - fetch completed 215 NO - fetch error: can't fetch that data 216 BAD - command unknown or arguments invalid 218 This document extends the syntax of the FETCH and UID FETCH 219 commands (see section 6.4.5 of [IMAP4]) to include optional FETCH 220 modifiers. No fetch modifiers are defined in this document. 222 The order of individual modifiers is arbitrary. An individual 223 modifier may consist of one or more atoms or strings in a specific 224 order. If a modifier consists of more than one atom or string, it 225 SHOULD appear in its own parenthesised list. Any modifiers not 226 defined by extensions that the server supports must be rejected 227 with a BAD response. 229 2.5 Extensions to STORE and UID STORE Commands 231 Arguments: message set 232 OPTIONAL store modifiers 233 message data item name 234 value for message data item 236 Responses: untagged responses: FETCH 238 Result: OK - store completed 239 NO - store error: can't store that data 240 BAD - command unknown or arguments invalid 242 This document extends the syntax of the STORE and UID STORE 243 commands (see section 6.4.6 of [IMAP4]) to include optional STORE 244 modifiers. No store modifiers are defined in this document. 246 The order of individual modifiers is arbitrary. Individual 247 modifier may consist of one or more atoms or strings in a specific 248 order. If a modifier consists of more than one atom or string, it 249 SHOULD appear in its own parenthesised list. Any modifiers not 250 defined by extensions that the server supports must be rejected 251 with a BAD response. 253 2.6 Extensions to SEARCH Command 255 2.6.1 Extended SEARCH command 257 Arguments: OPTIONAL result specifier 258 OPTIONAL [CHARSET] specification 259 searching criteria (one or more) 261 Responses: REQUIRED untagged response: SEARCH (*) 263 Result: OK - search completed 264 NO - search error: can't search that [CHARSET] or 265 criteria 266 BAD - command unknown or arguments invalid 268 This section updates definition of the SEARCH command described in 269 section 6.4.4 of [IMAP4]. 271 The SEARCH command is extended to allow for result options. This 272 document doesn't define any result option. 274 The order of individual options is arbitrary. Individual options 275 may optionally contain parameters enclosed in parenthesises. If an 276 option has parameters, they consist of one or more atoms or strings 277 in a specific order. Any options not defined by extensions that the 278 server supports must be rejected with a BAD response. 280 (*) - An extension to SEARCH command may require another untagged 281 response, or no untagged response to be returned. 283 2.6.2 ESEARCH untagged response 285 Contents: one or more search-return-data pairs 287 The ESEARCH response SHOULD be sent as a result of an extended 288 SEARCH or UID SEARCH command specified in section 2.6.1. 290 The ESEARCH response is immediately followed by an optional search 291 correlator. If it is missing than the response was not caused by a 292 particular IMAP command, if it is present than it contains the tag 293 of the command that caused the response to be returned. 295 The search correlator is followed by an optional UID indicator. If 296 this indicator is present, all data in the ESEARCH response is 297 referring to UIDs, otherwise all returned data is referring to 298 message numbers. 300 The rest of the ESEARCH response contains one or more search data 301 pairs. Each pair starts with unique return item name, followed by a 302 space and the corresponding data. Search data pairs may be returned 303 in any order. Unless specified otherwise by an extension, any 304 return item name SHOULD appear only once in an ESEARCH response. 306 Example: S: * ESEARCH UID COUNT 5 ALL 4:19,21,28 308 Example: S: * ESEARCH (TAG "a567") UID COUNT 5 ALL 4:19,21,28 310 Example: S: * ESEARCH COUNT 5 ALL 1:17,21 312 2.7 Extensions to APPEND Command 314 The APPEND command is extended to allow the client to append data 315 containing NULs by using the syntax. The ABNF was 316 rewritten to allow for easier extensibility by IMAP extensions. 318 3. Formal Syntax 320 The following syntax specification uses the Augmented Backus-Naur 321 Form (ABNF) notation as specified in [ABNF]. 323 Non-terminals referenced but not defined below are as defined by 324 [IMAP4]. 326 Except as noted otherwise, all alphabetic characters are case- 327 insensitive. The use of upper or lower case characters to define 328 token strings is for editorial clarity only. Implementations MUST 329 accept these strings in a case-insensitive fashion. 331 append = "APPEND" SP mailbox 1*append-message 332 ;; only a single append-message may appear 333 ;; if MULTIAPPEND [MULTIAPPEND] capability 334 ;; is not present 336 append-message = append-opts SP append-data 338 append-ext = 339 ;; This rule exists solely to be augmented by 340 ;; extensions via incremental alternative 341 ;; ("=/") rules. It is strongly recommended 342 ;; that such extensions match a subset of the 343 ;; tagged-ext rule syntax 345 append-data = literal / literal8 346 ;; IMAP extensions extending append-data 347 ;; should use the tagged-ext syntax, 348 ;; i.e. a mandatory label followed 349 ;; by parameters. 351 append-opts = [SP flag-list] [SP date-time] *(SP append-ext) 353 create = "CREATE" SP mailbox 354 [create-params] 355 ;; Use of INBOX gives a NO error 357 create-params = SP "(" create-param *( SP create-param) ")" 359 create-param-name = tagged-ext-label 361 create-param = create-param-name SP create-param-value 363 create-param-value= 364 ;; This rule exists solely to be augmented by 365 ;; extensions via incremental alternative 366 ;; ("=/") rules. It is strongly recommended 367 ;; that such extensions match a subset of the 368 ;; tagged-ext-val rule syntax 370 esearch-response = "ESEARCH" [search-correlator] [SP "UID"] 371 *(SP search-return-data) 372 ;; Note that SEARCH and ESEARCH responses 373 ;; SHOULD be mutually exclusive, 374 ;; i.e. only one of them should be 375 ;; returned as a result of a command. 377 examine = "EXAMINE" SP mailbox [select-params] 378 ;; modifies the original IMAP EXAMINE command 379 ;; to accept optional parameters 381 fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / 382 "FAST" / fetch-att / 383 "(" fetch-att *(SP fetch-att) ")") 384 [SP fetch-modifiers] 385 ;; modifies the original IMAP4 FETCH command to 386 ;; accept optional modifiers 388 fetch-modifiers = "(" fetch-modifier *(SP fetch-modifier) ")" 390 fetch-modifier = fetch-modifier-name [ SP fetch-modif-params ] 391 ;; Note that the original syntax defined 392 ;; in CONDSTORE was extended to allow 393 ;; for "()" 395 fetch-modif-params = 396 ;; This rule exists solely to be augmented by 397 ;; extensions via incremental alternative 398 ;; ("=/") rules. It is strongly recommended 399 ;; that such extensions match a subset of the 400 ;; tagged-ext-val rule syntax 402 fetch-modifier-name = tagged-ext-label 404 literal8 = "~{" number ["+"] "}" CRLF *OCTET 405 ;; A string that might contain NULs. 406 ;; represents the number of OCTETs 407 ;; in the response string. 408 ;; The "+" is only allowed when both LITERAL+ 409 ;; and BINARY are present. 411 mailbox-data =/ Namespace-Response / 412 esearch-response 414 Namespace = nil / "(" 1*Namespace-Descr ")" 416 Namespace-Command = "NAMESPACE" 418 Namespace-Descr = "(" string SP 419 (DQUOTE QUOTED-CHAR DQUOTE / nil) 420 *(Namespace-Response-Extension) ")" 422 Namespace-Response-Extension = SP string SP 423 "(" string *(SP string) ")" 425 Namespace-Response = "NAMESPACE" SP Namespace 426 SP Namespace SP Namespace 427 ;; The first Namespace is the Personal Namespace(s) 428 ;; The second Namespace is the Other Users' Namespace(s) 429 ;; The third Namespace is the Shared Namespace(s) 431 rename = "RENAME" SP mailbox SP mailbox 432 [rename-params] 433 ;; Use of INBOX as a destination gives 434 ;; a NO error 436 rename-params = SP "(" rename-param *( SP rename-param) ")" 438 rename-param = rename-param-name SP rename-param-value 440 rename-param-name = tagged-ext-label 442 rename-param-value= 443 ;; This rule exists solely to be augmented by 444 ;; extensions via incremental alternative 445 ;; ("=/") rules. It is strongly recommended 446 ;; that such extensions match a subset of the 447 ;; tagged-ext-val rule syntax 449 response-data = "*" SP response-payload CRLF 451 response-payload= resp-cond-state / resp-cond-bye / 452 mailbox-data / message-data / capability-data 454 search = "SEARCH" [search-return-opts] 455 search-program 457 search-correlator = SP "(" "TAG" SP tag-string ")" 459 search-program = [SP "CHARSET" SP astring] 1*(SP search-key) 460 ;; CHARSET argument to SEARCH MUST be 461 ;; registered with IANA 463 search-return-data = search-modifier-name SP search-return-value 464 ;; Note that not every SEARCH return option 465 ;; is required to have the corresponding 466 ;; ESEARCH return data 468 search-return-opts = "RETURN" SP "(" [search-return-opt 469 *(SP search-return-opt)] ")" 471 search-return-opt = search-modifier-name [SP search-mod-params] 473 search-return-value= tagged-ext-val 474 ;; data for the returned search option. 475 ;; A single "nz-number"/"number" value 476 ;; can be returned as an atom (i.e. without 477 ;; quoting). A sequence-set can be returned 478 ;; as an atom as well. 480 search-modifier-name = tagged-ext-label 482 search-mod-params = 483 ;; This rule exists solely to be augmented by 484 ;; extensions via incremental alternative 485 ;; ("=/") rules. It is strongly recommended 486 ;; that such extensions match a subset of the 487 ;; tagged-ext-val rule syntax 489 select = "SELECT" SP mailbox [select-params] 490 ;; modifies the original IMAP SELECT command to 491 ;; accept optional parameters 493 select-params = SP "(" select-param *(SP select-param) ")" 495 select-param = select-param-name SP select-param-value 496 ;; parameters to SELECT may contain one or 497 ;; more atoms or strings - multiple items 498 ;; are always parenthesised 500 select-param-name= tagged-ext-label 502 select-param-value= 503 ;; This rule exists solely to be augmented by 504 ;; extensions via incremental alternative 505 ;; ("=/") rules. It is strongly recommended 506 ;; that such extensions match a subset of the 507 ;; tagged-ext-val rule syntax 509 status-att-list = status-att-val *(SP status-att-val) 510 ;; Redefines status-att-list from RFC 3501. 511 ;; status-att-val is defined in RFC 3501 errata 513 status-att-val = ("MESSAGES" SP number) / 514 ("RECENT" SP number) / 515 ("UIDNEXT" SP nz-number) / 516 ("UIDVALIDITY" SP nz-number) / 517 ("UNSEEN" SP number) 518 ;; Extensions to the STATUS responses 519 ;; should extend this production. 520 ;; Extensions should use the generic 521 ;; syntax defined by tagged-ext. 523 store = "STORE" SP sequence-set store-modifiers 524 SP store-att-flags 525 ;; extend [IMAP4] STORE command syntax 526 ;; to allow for optional store-modifiers 528 store-modifiers = [ SP "(" store-modifier *(SP store-modifier) 529 ")" ] 531 store-modifier = store-modifier-name [SP store-modif-params] 533 store-modif-params = 534 ;; This rule exists solely to be augmented by 535 ;; extensions via incremental alternative 536 ;; ("=/") rules. It is strongly recommended 537 ;; that such extensions match a subset of the 538 ;; tagged-ext-val rule syntax 540 store-modifier-name = tagged-ext-label 542 tag-string = string 543 ;; tag of the command that caused 544 ;; the ESEARCH response, sent as 545 ;; a string. 547 tagged-ext = tagged-ext-label SP tagged-ext-val 548 ;; recommended overarching syntax for 549 ;; extensions 551 tagged-ext-label = atom 552 ;; <> 554 tagged-ext-comp = astring / 555 tagged-ext-comp *(SP tagged-ext-comp) / 556 "(" tagged-ext-comp ")" 557 ;; extensions that follow this general 558 ;; syntax should use nstring instead of 559 ;; astring when appropriate in the context 560 ;; of the extension 562 tagged-ext-val = astring / "(" [tagged-ext-comp] ")" 564 4. Security Considerations 566 It is believed that this document doesn't add any new security 567 concerns that were not already identified in RFC 3501. 569 5. IANA Considerations 571 This document doesn't define any new IMAP extension, so no action 572 from IANA is required. 574 6. References 576 6.1 Normative References 578 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 579 Requirement Levels", RFC 2119, March 1997. 581 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 582 4rev1", RFC 3501, University of Washington, March 2003. 584 [ABNF] Crocker, D. (Ed.) and P. Overell , "Augmented BNF for Syntax 585 Specifications: ABNF", RFC 2234, November 1997.<> 588 [CHARSET] Freed, N. and J. Postel, "IANA Character Set Registration 589 Procedures", RFC 2978, October 2000. 591 [MULTIAPPEND] Crispin, M., "Internet Message Access Protocol 592 (IMAP) - MULTIAPPEND Extension", RFC 3502, March 2003. 594 [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, 595 May 1998. 597 [LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, 598 January 1997. 600 7. Acknowledgments 602 This documents is based on ideas proposed by Pete Resnick, Mark 603 Crispin, Ken Murchison, Philip Guenther, Randall Gellens and Lyndon 604 Nerenberg. 606 However all errors and omissions must be attributed to the authors 607 of the document. 609 literal8 syntax was taken from RFC 3516. 611 8. Author's Addresses 613 Alexey Melnikov 614 Isode Limited 615 5 Castle Business Village 616 36 Station Road 617 Hampton, Middlesex, TW12 2BX 618 UK 620 Email: Alexey.Melnikov@isode.com 622 Cyrus Daboo 623 ISAMET, Inc. 624 5001 Baum Blvd. 625 Suite 650 626 Pittsburgh, PA 15213 627 US 629 EMail: cyrus@daboo.name 631 9. Full Copyright Statement 633 Copyright (C) The Internet Society (2005). 635 This document is subject to the rights, licenses and restrictions 636 contained in BCP 78, and except as set forth therein, the authors 637 retain all their rights. 639 This document and the information contained herein are provided on 640 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 641 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 642 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 643 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 644 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 645 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 646 PARTICULAR PURPOSE. 648 10. Intellectual Property 650 The IETF takes no position regarding the validity or scope of any 651 Intellectual Property Rights or other rights that might be claimed 652 to pertain to the implementation or use of the technology described 653 in this document or the extent to which any license under such 654 rights might or might not be available; nor does it represent that 655 it has made any independent effort to identify any such rights. 656 Information on the procedures with respect to rights in RFC 657 documents can be found in BCP 78 and BCP 79. 659 Copies of IPR disclosures made to the IETF Secretariat and any 660 assurances of licenses to be made available, or the result of an 661 attempt made to obtain a general license or permission for the use 662 of such proprietary rights by implementers or users of this 663 specification can be obtained from the IETF on-line IPR repository 664 at http://www.ietf.org/ipr. 666 The IETF invites any interested party to bring to its attention any 667 copyrights, patents or patent applications, or other proprietary 668 rights that may cover technology that may be required to implement 669 this standard. Please address the information to the IETF at ietf- 670 ipr@ietf.org. 672 Acknowledgement 674 Funding for the RFC Editor function is currently provided by the 675 Internet Society. 677 11. Appendix A. Editorial. 679 <> 681 11.1 Change Log 683 00 Initial Revision. 684 01 Added Cyrus as co-author. Added BINARY literals. Added section 685 about APPEND. Clarified that the order of all parameters/modifiers is 686 arbitrary. Unrecognized SELECT/EXAMINE parameter should cause the BAD, 687 not the NO response. 688 02 Updated boilerplate. Extended SEARCH modifiers to be consistent 689 with STORE modifiers. Rewrote FETCH modifier syntax for consistency. 690 03 Updated as per comments from Philip (ABNF suggestions, in 691 particular addition of response-data; normative language). 692 Incorporated RFC 3501 ABNF errata from Mark. Added extensions to 693 CREATE and RENAME commands. Updated ABNF to use consistent grammer for 694 all extension elements (this changed ABNF for SELECT/EXAMINE and 695 FETCH). 696 04 Added ESEARCH response. Added search-program from IMAP URL. 697 Removed the partition parameter from CREATE/RENAME. Added NAMESPACE 698 command/response. 699 05 Added non-synchronizing literals (RFC 2088). Clarified generic 700 syntax for STATUS responses.