idnits 2.17.1 draft-melnikov-email-draft-and-release-03.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2735 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'FWS' is mentioned on line 151, but not defined ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov, Ed. 3 Internet-Draft Isode Ltd 4 Intended status: Informational October 31, 2016 5 Expires: May 4, 2017 7 Implementing Draft & Release and Draft & Review in Internet Mail 8 draft-melnikov-email-draft-and-release-03 10 Abstract 12 This document describes how draft messages intended for Draft & 13 Release and Draft & Review environments can be represented in 14 Internet Email. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 4, 2017. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 52 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Structure of a draft message . . . . . . . . . . . . . . . . 3 54 4. Structure of a confirmation message . . . . . . . . . . . . . 3 55 5. Message-Draft header field . . . . . . . . . . . . . . . . . 4 56 6. Registration of new IMAP Keywords . . . . . . . . . . . . . . 4 57 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 8.1. The Message-Draft Header Field registration . . . . . . . 5 60 8.2. $DraftAuthorized IMAP keyword registration . . . . . . . 6 61 8.3. $DraftRejected IMAP keyword registration . . . . . . . . 7 62 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 10. Normative References . . . . . . . . . . . . . . . . . . . . 9 64 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 67 1. Introduction 69 In some environments email messages can't be released to the MTS 70 (Mail Transfer System) and, thus delivered to recipients, unless they 71 are authorized by one or more authorizing users (e.g. Releasing 72 Officers or Release Authorities). This document describes how such 73 Draft messages can be represented as Internet Email [RFC5322] MIME 74 objects [RFC2045]. 76 2. Conventions Used in This Document 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 The formal syntax uses the Augmented Backus-Naur Form (ABNF) 83 [RFC5234] notation including the core rules defined in Appendix B of 84 RFC 5234 [RFC5234]. Terms not defined in this document are taken 85 from [RFC5322]. 87 2.1. Terminology 89 Drafter: Any email user that composes a message (Draft Message) 90 needing authorisation before it is released to its intended 91 recipients. 93 Authorizing User (also Releaser or Authorizer): The mailbox of a user 94 or a group of users that must inspect and authorise the release of 95 Draft Message before it can be sent. An organization may require 96 more than one Authorizing User to authorize release of a Draft 97 Message. 99 3. Structure of a draft message 101 Message encapsulating a draft message to be released or reviewed 102 (a.k.a. "outer message") is constructed as follows: 104 1. The media type of the outer message is "multipart/mixed". 106 2. The outer message contains the Message-Draft header field 107 Section 5. The initial message for release/review would contain 108 "For Release", "For Confirmed Release" or "For Review" in this 109 header field. [[CREF1: Is "For Confirmed Release" needed? Use 110 MDN request instead?]] 112 3. (REQUIRED) The first body part of the outer message contains a 113 human-readable message. The purpose of this message is to convey 114 information about the inner draft message from the drafter to 115 authorizing user. This body part can use any IANA-registered 116 MIME media type, charset, or language. But this body part is 117 typically "text/plain" or "text/html". Where a description of 118 the error is desired in several languages or several media, a 119 "multipart/alternative" or "multipart/multilingual" construct can 120 be used. 122 4. (REQUIRED) The second body part is "message/rfc822" or "message/ 123 global" [RFC6532]. It wraps the draft message to be released. 124 The draft message can contain MMHS-Authorizing-Users header field 125 [RFC7912]. 127 5. (OPTIONAL) The third and subsequent body parts contain comments 128 from reviewers and/or authorizing users. These body parts are 129 typically "text/plain" or "text/html", but can be other types 130 (e.g. "multipart/related"). 132 4. Structure of a confirmation message 134 1. The message confirming that the original draft message was 135 released, reviewed or rejected can be of any media type. 137 2. The message includes the Message-Draft header field Section 5 138 containing one of "Authorized", "Reviewed" or "Rejected". 140 3. The message should contain "In-Reply-To:" header field with the 141 Message-ID of the original draft message. 143 5. Message-Draft header field 145 Message-Draft header field specifies what should be done with a draft 146 message or what was already done to it. 148 This message header can appear at most once in the header. 150 Message-Draft = "Message-Draft:" 151 [FWS] Message-Draft-Type [FWS] CRLF 153 Message-Draft-Type = "For Release" / 154 "For Confirmed Release" / 155 "For Review" / 156 "Authorized" / 157 "Reviewed" / 158 "Rejected" 160 6. Registration of new IMAP Keywords 162 This document defines several new IMAP keywords [RFC3501] that can be 163 used to override values stored in the Message-Draft header field. 164 (I.e. if one of these mutually exclusive keywords is found, they take 165 precedence over the value specified in the Message-Draft header 166 field.) This allow client developers to implement easier Draft & 167 Release workflow without requiring to re-upload the modified message 168 with IMAP APPEND command. 170 All of the following IMAP keywords are mutually exclusive: 172 $DraftAuthorized corresponds to the "Authorized" value of the 173 Message-Draft header field; 175 $DraftReviewed corresponds to the "Reviewed" value of the Message- 176 Draft header field; 178 $DraftRejected corresponds to the "Rejected" value of the Message- 179 Draft header field. 181 7. Example 182 Date: Thu, 23 Oct 2014 10:07:18 -0400 183 From: TwHarrierTest 184 Message-Draft: For Confirmed Release 185 Message-Id: <634f2005-0bf1-4e07-a789-e78433a985f7@imap.example.com> 186 Mmhs-Primary-Precedence: 2 187 Subject: Cease Fire 188 To: 189 X-Mailer: Harrier 190 MIME-Version: 1.0 191 Content-Type: multipart/mixed; boundary=.562b3944-4b07-437f-be7d-1338f523a3a4 193 This is a multipart message in MIME format. 195 --.562b3944-4b07-437f-be7d-1338f523a3a4 196 content-type: text/plain; charset=utf-8 198 Alexey please release this. 199 --.562b3944-4b07-437f-be7d-1338f523a3a4 200 Content-Disposition: attachment 201 Content-Type: message/rfc822 203 Content-type: text/plain; charset=utf-8; delsp=yes; format=flowed 204 From: TwHarrierTest 205 message-draft: For Confirmed Release 206 message-id: <0a2d822c-0b14-4d02-9215-45292676137f@imap.example.com> 207 MIME-Version: 1.0 208 mmhs-copy-precedence: 5 209 mmhs-primary-precedence: 5 210 Subject: Cease Fire 211 To: 212 X-Mailer: Harrier 214 Text of cease fire msg 215 --.562b3944-4b07-437f-be7d-1338f523a3a4-- 217 8. IANA Considerations 219 8.1. The Message-Draft Header Field registration 221 IANA is requested to add the Message-Draft header field to the IANA 222 "Permanent Message Header Field Names" registry, per the procedure 223 found in [RFC3864]. That entry is to be updated to reference this 224 document. The following is the registration template: 226 Header field name: Message-Draft 228 Applicable protocol: mail ([RFC5322]) 229 Status: Standard 231 Author/Change controller: IETF 233 Specification document(s): [this RFC] 235 Related information: none 237 8.2. $DraftAuthorized IMAP keyword registration 239 Subject: Registration of IMAP keyword $DraftAuthorized 241 IMAP keyword name: $DraftAuthorized 243 Purpose (description): The $DraftAuthorized IMAP keyword designates 244 the message requiring authorization for release as 245 authorized (processed). 247 Private or Shared on a server: SHARED 249 Is it an advisory keyword or may it cause an automatic action: When 250 this keyword is set, it means that the message is already 251 authorized and doesn't need any action. Lack of both 252 $DraftAuthorized and $DraftRejected can cause the client 253 to popup a dialog or show some other UI for authorizing 254 release of a message. 256 When/by whom the keyword is set/cleared: This keyword is set by an 257 email client when the message is authorized. 259 Related keywords: $DraftRejected 261 Related IMAP capabilities: None 262 Security considerations: 264 Published specification (recommended): [[This-RFC]] 266 Person & email address to contact for further information: Alexey 267 Melnikov 269 Intended usage: COMMON 271 Owner/Change controller: IESG 273 Note: 275 $DraftAuthorized and $DraftRejected are mutually 276 exclusive. If more than one of them is set for a 277 message, the mail client MUST treat this as if neither of 278 them is set and SHOULD remove both of them from the IMAP 279 server. 281 8.3. $DraftRejected IMAP keyword registration 283 Subject: Registration of IMAP keyword $DraftRejected 285 IMAP keyword name: $DraftRejected 287 Purpose (description): The $DraftRejected IMAP keyword designates 288 the message requiring authorization for release as 289 rejected by authorizer (processed). 291 Private or Shared on a server: SHARED 292 Is it an advisory keyword or may it cause an automatic action: When 293 this keyword is set, it means that the message is already 294 rejected and doesn't need any action. Lack of both 295 $DraftAuthorized and $DraftRejected can cause the client 296 to popup a dialog or show some other UI for authorizing 297 release of a message. 299 When/by whom the keyword is set/cleared: This keyword is set by an 300 email client when the message is rejected by authorizer. 302 Related keywords: $DraftAuthorized 304 Related IMAP capabilities: None 306 Security considerations: 308 Published specification (recommended): [[This-RFC]] 310 Person & email address to contact for further information: Alexey 311 Melnikov 313 Intended usage: COMMON 315 Owner/Change controller: IESG 317 Note: 319 $DraftAuthorized and $DraftRejected are mutually 320 exclusive. If more than one of them is set for a 321 message, the mail client MUST treat this as if neither of 322 them is set and SHOULD remove both of them from the IMAP 323 server. 325 9. Security Considerations 327 TBD. 329 10. Normative References 331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, 333 DOI 10.17487/RFC2119, March 1997, 334 . 336 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 337 Extensions (MIME) Part One: Format of Internet Message 338 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 339 . 341 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 342 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 343 . 345 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 346 Procedures for Message Header Fields", BCP 90, RFC 3864, 347 DOI 10.17487/RFC3864, September 2004, 348 . 350 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 351 DOI 10.17487/RFC5322, October 2008, 352 . 354 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 355 Specifications: ABNF", STD 68, RFC 5234, 356 DOI 10.17487/RFC5234, January 2008, 357 . 359 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 360 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 361 2012, . 363 [RFC7912] Melnikov, A., "Message Authorizing Email Header Field and 364 Its Use for the Draft and Release Procedure", RFC 7912, 365 DOI 10.17487/RFC7912, June 2016, 366 . 368 Appendix A. Acknowledgements 370 Thank you to Steve Kille and Tom Watson for suggestions, comments and 371 corrections on this document. 373 Author's Address 375 Alexey Melnikov (editor) 376 Isode Ltd 377 14 Castle Mews 378 Hampton, Middlesex TW12 2NP 379 UK 381 EMail: Alexey.Melnikov@isode.com