idnits 2.17.1 draft-melnikov-email-draft-and-release-04.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 (February 17, 2021) is 1162 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'FWS' is mentioned on line 158, 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 February 17, 2021 5 Expires: August 21, 2021 7 Implementing Draft & Release and Draft & Review in Internet Mail 8 draft-melnikov-email-draft-and-release-04 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 https://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 August 21, 2021. 33 Copyright Notice 35 Copyright (c) 2021 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 (https://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. Structure of a rejection message . . . . . . . . . . . . . . 4 56 6. Message-Draft header field . . . . . . . . . . . . . . . . . 4 57 7. Registration of new IMAP Keywords . . . . . . . . . . . . . . 4 58 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 9.1. The Message-Draft Header Field registration . . . . . . . 5 61 9.2. $DraftReviewed IMAP keyword registration . . . . . . . . 6 62 9.3. $DraftAuthorized IMAP keyword registration . . . . . . . 7 63 9.4. $DraftRejected IMAP keyword registration . . . . . . . . 9 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 11. Normative References . . . . . . . . . . . . . . . . . . . . 10 66 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 69 1. Introduction 71 In some environments email messages can't be released to the MTS 72 (Mail Transfer System) and, thus delivered to recipients, unless they 73 are authorized by one or more authorizing users (e.g. Releasing 74 Officers or Release Authorities). This document describes how such 75 Draft messages can be represented as Internet Email [RFC5322] MIME 76 objects [RFC2045]. 78 2. Conventions Used in This Document 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 The formal syntax uses the Augmented Backus-Naur Form (ABNF) 85 [RFC5234] notation including the core rules defined in Appendix B of 86 RFC 5234 [RFC5234]. Terms not defined in this document are taken 87 from [RFC5322]. 89 2.1. Terminology 91 Drafter: Any email user that composes a message (Draft Message) 92 needing authorisation before it is released to its intended 93 recipients. 95 Authorizing User (also known as Releaser or Authorizer): The mailbox 96 of a user or a group of users that must inspect and authorise the 97 release of Draft Message before it can be sent. An organization may 98 require more than one Authorizing User to authorize release of a 99 Draft Message. 101 3. Structure of a draft message 103 Message encapsulating a draft message to be released or reviewed 104 (a.k.a. "outer message") is constructed as follows: 106 1. The media type of the outer message is "multipart/mixed". 108 2. The outer message contains the Message-Draft header field 109 Section 6. The initial message for release/review would contain 110 "For Release", "For Confirmed Release" or "For Review" in this 111 header field. [[CREF1: Is "For Confirmed Release" needed? Use 112 MDN request instead?]] 114 3. (REQUIRED) The first body part of the outer message contains a 115 human-readable message. The purpose of this message is to convey 116 information about the inner draft message from the drafter to 117 authorizing user. This body part can use any IANA-registered 118 MIME media type, charset, or language. But this body part is 119 typically "text/plain" or "text/html". Where a description of 120 the error is desired in several languages or several media, a 121 "multipart/alternative" or "multipart/multilingual" [RFC8255] 122 construct can be used. 124 4. (REQUIRED) The second body part is "message/rfc822" or "message/ 125 global" [RFC6532]. It wraps the draft message to be released. 126 The draft message can contain MMHS-Authorizing-Users header field 127 [RFC7912]. 129 5. (OPTIONAL) The third and subsequent body parts contain comments 130 from reviewers and/or authorizing users. These body parts are 131 typically "text/plain", "text/html", "message/rfc822" or 132 "message/global", but can be other types (e.g. "multipart/ 133 related"). 135 4. Structure of a confirmation message 137 The message confirming that the original draft message was released, 138 reviewed or rejected is sent from the reviewer/releaser to the 139 drafter. It is formatted as an Message Disposition Notification 140 (MDN) [RFC8098]. 142 5. Structure of a rejection message 144 The rejection message provides details on why the original draft 145 message was rejected by the reviewer/releaser. It is sent from 146 reviewer/releaser to the drafter. It has the same structure as a 147 regular draft message (see Section 3), but the first body part 148 contains explanation of why the draft message was rejected. 150 6. Message-Draft header field 152 Message-Draft header field specifies what should be done with a draft 153 message or what was action was performed on it. 155 This message header can appear at most once in the header. 157 Message-Draft = "Message-Draft:" 158 [FWS] Message-Draft-Type [FWS] CRLF 160 Message-Draft-Type = "For Release" / 161 "For Confirmed Release" / 162 "For Review" / 163 "Authorized" / 164 "Reviewed" / 165 "Rejected" 167 7. Registration of new IMAP Keywords 169 This document defines several new IMAP keywords [RFC3501] that can be 170 used to override values stored in the Message-Draft header field. 171 (I.e. if one of these mutually exclusive keywords is found, they take 172 precedence over the value specified in the Message-Draft header 173 field.) This allow client developers to implement easier Draft & 174 Release workflow without requiring to re-upload the modified message 175 with IMAP APPEND command. 177 All of the following IMAP keywords are mutually exclusive: 179 $DraftAuthorized corresponds to the "Authorized" value of the 180 Message-Draft header field; 182 $DraftReviewed corresponds to the "Reviewed" value of the Message- 183 Draft header field; 185 $DraftRejected corresponds to the "Rejected" value of the Message- 186 Draft header field. 188 8. Example 190 Date: Thu, 23 Oct 2014 10:07:18 -0400 191 From: TwHarrierTest 192 Message-Draft: For Confirmed Release 193 Message-Id: <634f2005-0bf1-4e07-a789-e78433a985f7@imap.example.com> 194 Mmhs-Primary-Precedence: 2 195 Subject: Cease Fire 196 To: 197 X-Mailer: Harrier 198 MIME-Version: 1.0 199 Content-Type: multipart/mixed; boundary=.562b3944-4b07-437f-be7d-1338f523a3a4 201 This is a multipart message in MIME format. 203 --.562b3944-4b07-437f-be7d-1338f523a3a4 204 content-type: text/plain; charset=utf-8 206 Alexey please release this. 207 --.562b3944-4b07-437f-be7d-1338f523a3a4 208 Content-Disposition: attachment 209 Content-Type: message/rfc822 211 Content-type: text/plain; charset=utf-8; delsp=yes; format=flowed 212 From: TwHarrierTest 213 message-draft: For Confirmed Release 214 message-id: <0a2d822c-0b14-4d02-9215-45292676137f@imap.example.com> 215 MIME-Version: 1.0 216 mmhs-copy-precedence: 5 217 mmhs-primary-precedence: 5 218 Subject: Cease Fire 219 To: 220 X-Mailer: Harrier 222 Text of cease fire message 223 --.562b3944-4b07-437f-be7d-1338f523a3a4-- 225 9. IANA Considerations 227 9.1. The Message-Draft Header Field registration 229 IANA is requested to add the Message-Draft header field to the IANA 230 "Permanent Message Header Field Names" registry, per the procedure 231 found in [RFC3864]. That entry is to be updated to reference this 232 document. The following is the registration template: 234 Header field name: Message-Draft 235 Applicable protocol: mail ([RFC5322]) 237 Status: Standard 239 Author/Change controller: IETF 241 Specification document(s): [this RFC] 243 Related information: none 245 9.2. $DraftReviewed IMAP keyword registration 247 Subject: Registration of IMAP keyword $DraftReviewed 249 IMAP keyword name: $DraftReviewed 251 Purpose (description): The $DraftReviewed IMAP keyword designates 252 the message requiring review as approved (processed). 254 Private or Shared on a server: SHARED 256 Is it an advisory keyword or may it cause an automatic action: 257 When this keyword is set, it means that the 258 message is already reviewed and doesn't need any 259 action. Lack of all of $DraftReviewed, 260 $DraftAuthorized and $DraftRejected can cause 261 the client to popup a dialog or show some other 262 UI for authorizing release of a message. 264 When/by whom the keyword is set/cleared: This keyword is 265 set by an email client when the message is 266 reviewed. 268 Related keywords: $DraftRejected 269 Related IMAP capabilities: None 271 Security considerations: 273 Published specification (recommended): [[This-RFC]] 275 Person & email address to contact for further information: 276 Alexey Melnikov 278 Intended usage: COMMON 280 Owner/Change controller: IESG 282 Note: 284 $DraftAuthorized, $DraftReviewed and 285 $DraftRejected are mutually exclusive. If more 286 than one of them is set for a message, the mail 287 client MUST treat this as if neither of them is 288 set and SHOULD remove both of them from the IMAP 289 server. 291 9.3. $DraftAuthorized IMAP keyword registration 293 Subject: Registration of IMAP keyword $DraftAuthorized 295 IMAP keyword name: $DraftAuthorized 297 Purpose (description): The $DraftAuthorized IMAP keyword designates 298 the message requiring authorization for release as 299 authorized (processed). 301 Private or Shared on a server: SHARED 303 Is it an advisory keyword or may it cause an automatic action: 304 When this keyword is set, it means that the 305 message is already authorized and doesn't need 306 any action. Lack of all of $DraftReviewed, 307 $DraftAuthorized and $DraftRejected can cause 308 the client to popup a dialog or show some other 309 UI for authorizing release of a message. 311 When/by whom the keyword is set/cleared: This keyword is 312 set by an email client when the message is 313 authorized. 315 Related keywords: $DraftRejected 317 Related IMAP capabilities: None 319 Security considerations: 321 Published specification (recommended): [[This-RFC]] 323 Person & email address to contact for further information: 324 Alexey Melnikov 326 Intended usage: COMMON 328 Owner/Change controller: IESG 329 Note: 331 $DraftAuthorized, $DraftReviewed and 332 $DraftRejected are mutually exclusive. If more 333 than one of them is set for a message, the mail 334 client MUST treat this as if neither of them is 335 set and SHOULD remove both of them from the IMAP 336 server. 338 9.4. $DraftRejected IMAP keyword registration 340 Subject: Registration of IMAP keyword $DraftRejected 342 IMAP keyword name: $DraftRejected 344 Purpose (description): The $DraftRejected IMAP keyword designates 345 the message requiring review or authorization for release 346 as rejected by releaser/reviewer (processed). 348 Private or Shared on a server: SHARED 350 Is it an advisory keyword or may it cause an automatic action: 351 When this keyword is set, it means that the 352 message is already rejected and doesn't need any 353 action. Lack of all of $DraftReviewed, 354 $DraftAuthorized and $DraftRejected can cause 355 the client to popup a dialog or show some other 356 UI for authorizing release of a message. 358 When/by whom the keyword is set/cleared: This keyword is 359 set by an email client when the message is 360 rejected by authorizer. 362 Related keywords: $DraftAuthorized, 364 $DraftReviewed 366 Related IMAP capabilities: None 368 Security considerations: 370 Published specification (recommended): [[This-RFC]] 372 Person & email address to contact for further information: 373 Alexey Melnikov 375 Intended usage: COMMON 377 Owner/Change controller: IESG 379 Note: 381 $DraftAuthorized, $DraftReviewed and 382 $DraftRejected are mutually exclusive. If more 383 than one of them is set for a message, the mail 384 client MUST treat this as if neither of them is 385 set and SHOULD remove both of them from the IMAP 386 server. 388 10. Security Considerations 390 TBD. 392 11. Normative References 394 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 395 Extensions (MIME) Part One: Format of Internet Message 396 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 397 . 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, 401 DOI 10.17487/RFC2119, March 1997, 402 . 404 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 405 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 406 . 408 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 409 Procedures for Message Header Fields", BCP 90, RFC 3864, 410 DOI 10.17487/RFC3864, September 2004, 411 . 413 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 414 Specifications: ABNF", STD 68, RFC 5234, 415 DOI 10.17487/RFC5234, January 2008, 416 . 418 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 419 DOI 10.17487/RFC5322, October 2008, 420 . 422 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 423 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 424 2012, . 426 [RFC7912] Melnikov, A., "Message Authorizing Email Header Field and 427 Its Use for the Draft and Release Procedure", RFC 7912, 428 DOI 10.17487/RFC7912, June 2016, 429 . 431 [RFC8098] Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition 432 Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098, 433 February 2017, . 435 [RFC8255] Tomkinson, N. and N. Borenstein, "Multiple Language 436 Content Type", RFC 8255, DOI 10.17487/RFC8255, October 437 2017, . 439 Appendix A. Acknowledgements 441 Thank you to Steve Kille and Tom Watson for suggestions, comments and 442 corrections on this document. 444 Author's Address 446 Alexey Melnikov (editor) 447 Isode Ltd 448 14 Castle Mews 449 Hampton, Middlesex TW12 2NP 450 UK 452 EMail: Alexey.Melnikov@isode.com