idnits 2.17.1 draft-melnikov-imap-transitional-capa-00.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.5 on line 161. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 177. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 184. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 190. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 153), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages 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 ([IMAP4]), 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (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 (July 2004) is 7224 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft: Transitional IMAP capabilities A. Melnikov 2 Document: draft-melnikov-imap-transitional-capa-00.txt Isode Ltd. 3 Expires: January 2005 July 2004 4 Intended category: Informational 6 Transitional IMAP capabilities 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. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 A revised version of this draft document will be submitted to the RFC 28 editor as a Proposed Standard for the Internet Community. Discussion 29 and suggestions for improvement are requested, and should be sent to 30 the IMAPEXT Mailing list . Distribution of this 31 draft is unlimited. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 Software releases can't always wait for some document to become an 40 RFC. As the result some software products are released when they 41 implement a non-final version of an IMAP [IMAP4] extension. This may 42 cause substantial interoperability problems between clients and 43 servers that implement different revisions of the same document, as 44 syntax and semantics of operations may change substantially between 45 revisions of the same IMAP extension draft. 47 There is also a need to have transitional IMAP capabilities for 48 testing purposes. 50 This document defines a convention for IMAP capability strings that 51 allows to reference an IMAP extension as defined by a particular 52 revision of a draft. 54 1. Conventions Used in this Document 56 The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in 57 this document when typed in uppercase are to be interpreted as 58 defined in "Key words for use in RFCs to Indicate Requirement Levels" 59 [KEYWORDS]. 61 2. Transitional IMAP capabilities 63 This document reserves a prefix for referencing an IMAP extension as 64 defined by a draft revision. A draft defines a base capability name 65 , which will be used when (and if) the document is 66 approved as an RFC. For a draft revision and a ownership 67 (one of "I" - individual submission or "W" - a WG document) an 68 implementation of the draft that also conforms to this document 69 should advertise a capability "X-DRAFT--". 71 For example, if is URLAUTH and the draft revision number 72 is 09 and it is an individual submission, the advertised capability 73 string would be "X-DRAFT-I09-URLAUTH". 75 Note that the defined convention MUST NOT be used with SASL 76 capabilities. 78 One of the advantages of the proposed convention is that an IMAP 79 client can support multiple revisions of the same draft by checking 80 "X-DRAFT-" prefix and then checking the suffix (e.g. "URLAUTH"). 82 field in a transitional capability string helps to cope with a 83 situation when a draft is initially submitted as a individual 84 submission, which is later on accepted as a WG document. Without this 85 field the revision number will go back to "00" when the draft is 86 resubmitted as a WG document. 88 3. Security Considerations 90 One of the purposes of this document is to be able to distinguish two 91 implementations that comply with different versions of the same IMAP 92 extension. This might help to improve interoperability, and, 93 hopefully, security. 95 It is believed that this extension doesn't raise any additional 96 security concerns not already discussed in [IMAP4]. 98 4. Formal Syntax 100 The following syntax specification uses the Augmented Backus-Naur 101 Form (ABNF) notation as specified in [ABNF]. Non-terminals referenced 102 but not defined below are as defined by [IMAP4]. 104 Except as noted otherwise, all alphabetic characters are case- 105 insensitive. The use of upper or lower case characters to define 106 token strings is for editorial clarity only. Implementations MUST 107 accept these strings in a case-insensitive fashion. 109 capability =/ transit_capa 110 ; transit_capa falls under "X" prefix 112 transit_capa = "X-DRAFT-" ownership revision "-" atom 113 ; MUST NOT be used with SASL capabilities 114 ; starting with "AUTH=" 116 ownership = "I" / "W" 117 ; "I" means that the draft is an individual 118 ; submission; "W" means a WG document 120 revision = 2DIGIT 121 ; 2 digit draft revision number 123 5. Acknowledgments 125 <> 127 6. Normative references 129 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 130 Requirement Levels", RFC 2119, March 1997. 132 [ABNF] Crocker, D., and Overell, P. "Augmented BNF for Syntax 133 Specifications: ABNF", RFC 2234, November 1997. 135 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 136 4rev1", RFC 3501, University of Washington, March 2003. 138 7. Author's Addresses 140 Alexey Melnikov 141 Isode Ltd. 142 5 Castle Business Village, 143 36 Station Road, 144 Hampton, Middlesex, 145 TW12 2BX, United Kingdom 147 Email: Alexey.Melnikov@isode.com 149 8. Full Copyright Statement 151 Copyright (C) The Internet Society (2004). This document is subject 152 to the rights, licenses and restrictions contained in BCP 78, and 153 except as set forth therein, the authors retain all their rights. 155 This document and the information contained herein are provided on an 156 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 157 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 158 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 159 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 160 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 161 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 163 Acknowledgement 165 Funding for the RFC Editor function is currently provided by the 166 Internet Society. 168 9. Intellectual Property 170 The IETF takes no position regarding the validity or scope of any 171 Intellectual Property Rights or other rights that might be claimed to 172 pertain to the implementation or use of the technology described in 173 this document or the extent to which any license under such rights 174 might or might not be available; nor does it represent that it has 175 made any independent effort to identify any such rights. Information 176 on the procedures with respect to rights in RFC documents can be 177 found in BCP 78 and BCP 79. 179 Copies of IPR disclosures made to the IETF Secretariat and any 180 assurances of licenses to be made available, or the result of an 181 attempt made to obtain a general license or permission for the use of 182 such proprietary rights by implementers or users of this 183 specification can be obtained from the IETF on-line IPR repository at 184 http://www.ietf.org/ipr. 186 The IETF invites any interested party to bring to its attention any 187 copyrights, patents or patent applications, or other proprietary 188 rights that may cover technology that may be required to implement 189 this standard. Please address the information to the IETF at ietf- 190 ipr@ietf.org.