idnits 2.17.1 draft-ietf-lemonade-msg-context-00.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): ---------------------------------------------------------------------------- ** 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 3667, Section 5.1 on line 35. ** 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 153. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. == In addition to a regular copyright notice, the document also has a copyright notice embedded in the text. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 149 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 : ---------------------------------------------------------------------------- ** There are 39 instances of too long lines in the document, the longest one being 3 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 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 10, 2004) is 7223 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: 'Context' is mentioned on line 81, but not defined == Missing Reference: 'VPIM' is mentioned on line 91, but not defined == Unused Reference: 'IMAP' is defined on line 115, but no explicit reference was found in the text == Unused Reference: 'CONTEXT' is defined on line 117, but no explicit reference was found in the text == Unused Reference: 'VPIM2' is defined on line 120, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IMAP' Summary: 16 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Greg Vaudreuil 2 Expires in six months Lucent Technologies 3 July 10, 2004 5 IMAP Conventions for Message Context 7 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions of 12 Section 10 of RFC 2026. 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are valid for a maximum of six months and may be 20 updated, replaced, or obsoleted by other documents at any time. It is 21 inappropriate to use Internet Drafts as reference material or to cite 22 them other than as a "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Intellectual Property Notice 32 By submitting this Internet-Draft, I certify that any applicable 33 patent or other IPR claims of which I am aware have been disclosed, or 34 will be disclosed, and any of which I become aware will be disclosed, 35 in accordance with RFC 3668. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 This Internet-Draft is in conformance with Section 10 of RFC2026. 43 Overview 45 This document defined conventions for the use of IMAP flags or 46 annotations to indicate to a client the context of a message without 47 downloading the headers of the message. One illustrative use is to 48 enable a client to effeciently display an icon representing the 49 message context when displaying a list of messages. 51 Please send comments on this document to the Lemonade working group 52 mailing list 53 Working Group Summary 55 This is a work item of the Lemonade working group. 57 Table of Contents 59 1. ABSTRACT ..........................................................2 60 2. THE BEEF ..........................................................2 61 3. SECURITY CONSIDERATIONS ...........................................3 62 4. IANA CONSIDERATIONS ...............................................3 63 5. NORMATIVE REFERENCES ..............................................3 64 6. ACKNOWLEDGMENTS ...................................................3 65 7. INTELLECTUAL PROPERTY NOTICE ......................................4 66 8. COPYRIGHT NOTICE ..................................................4 67 9. AUTHORS' ADDRESS ..................................................5 69 1. Abstract 71 This document defines one or more IMAP flags for the indication of 72 message context. 74 2. The Beef 76 The name of the flag is to be determimed. 78 The flag is set upon logical deposit into the mailbox. When using a 79 server that provides context, a client requesting a list of messages 80 may expect this flag to indicate the message context set by the sender 81 in the message context header field defined in [Context]. 83 A new IMAP capability is defined to communicate to clients at 84 connection time that message context is available through the 85 indicated flag. 87 The key operational innovation of this standard is the requirement 88 that a message store populate a flag upon deposit. Up to now, flags 89 have been set only by clients. It is anticipated that a number of 90 useful deposit-time flags may be defined such as the sensitivity and 91 importance indicators as defined by [VPIM]. 93 It would be great if the WG would allow this extension to represent 94 arbitary message headers without requiring individual extensions. The 95 set of useful deposit time flags can be expected to grow over time to 96 include such proprietary innovatations as spamassin(TM) header 97 markings. The author desires assistance in identifying a scheme 98 whereby the server can indicate a list of headers that are summarized 99 as flags. 101 3. Security Considerations 103 This extension to IMAP does not create any new data not otherwise 104 available in the system. It simply optimizes the access. As such, 105 there are no anticipated security impacts. 107 4. IANA Considerations 109 This document may specify a registry of flags if the WG allows an 110 arbitrary extension mechanism. Otherwise, this will simply register 111 another extension to IMAP. (are IMAP extensions registered?) 113 5. Normative References 115 [IMAP] 117 [CONTEXT] Eric Burger, Emily Candell, Graham Klyne, Charles Eliott, 118 "Message Context for Internet Mail", RFC 3458, January 2003 120 [VPIM2] Vaudreuil, Greg, Parsons, Glen, "Voice Profile for Internet 121 Mail, Version 2", RFC 3801, June 2004. 123 6. Acknowledgments 125 It is assumed that several IMAP knowledgable people will step forward 126 to fill in the necessary protocol details as the enlisted author is a 127 novice at all things IMAP. 129 7. Intellectual Property Notice 131 The IETF takes no position regarding the validity or scope of any 132 intellectual property or other rights that might be claimed to pertain 133 to the implementation or use of the technology described in this 134 document or the extent to which any license under such rights might or 135 might not be available; neither does it represent that it has made any 136 effort to identify any such rights. Information on the IETF's 137 procedures with respect to rights in standards-track and standards- 138 related documentation can be found in BCP-11. Copies of claims of 139 rights made available for publication and any assurances of licenses 140 to be made available, or the result of an attempt made to obtain a 141 general license or permission for the use of such proprietary rights 142 by implementors or users of this specification can be obtained from 143 the IETF Secretariat. 145 The IETF invites any interested party to bring to its attention any 146 copyrights, patents or patent applications, or other proprietary 147 rights which may cover technology that may be required to practice 148 this standard. Please address the information to the IETF Executive 149 Director. 151 8. Copyright Notice 153 "Copyright (C) The Internet Society (2004). All Rights Reserved. 155 This document and translations of it may be copied and furnished to 156 others, and derivative works that comment on or otherwise explain it 157 or assist in its implementation may be prepared, copied, published and 158 distributed, in whole or in part, without restriction of any kind, 159 provided that the above copyright notice and this paragraph are 160 included on all such copies and derivative works. However, this 161 document itself may not be modified in any way, such as by removing 162 the copyright notice or references to the Internet Society or other 163 Internet organizations, except as needed for the purpose of developing 164 Internet standards in which case the procedures for copyrights defined 165 in the Internet Standards process must be followed, or as required to 166 translate it into languages other than English. 168 The limited permissions granted above are perpetual and will not be 169 revoked by the Internet Society or its successors or assigns. 171 This document and the information contained herein is provided on an 172 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 173 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 174 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 175 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 176 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 178 9. Authors' Address 180 Gregory M. Vaudreuil 181 Lucent Technologies 182 7380 Hilltop Dr. 183 Frederick, MD 21702 184 Email: GregV@ieee.org