Implementing Draft & Release and Draft & Review in Internet Mail
draft-melnikov-email-draft-and-release-00

Abstract

This document describes how draft messages intended for Draft & Release and Draft & Review environments can be represented in Internet Email.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 6, 2015.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Conventions Used in This Document
• 2.1. Terminology
• 3. Structure of a draft message
• 4. Structure of a confirmation message
• 5. Message-Draft header field
• 6. Registration of new IMAP Keywords
• 7. Example
• 8. IANA Considerations
• 9. Security Considerations
• 10. Normative References
• Appendix A. Acknowledgements
• Author's Address

1. Introduction

In some environments email messages can't be released to the MTS (Mail Transfer System) and, thus delivered to recipients, unless they are authorized by one or more authorizing users (e.g. Releasing Officers or Release Authorities). This document describes how such Draft messages can be represented as Internet Email [RFC5322] MIME objects [RFC2045].

2. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

The formal syntax uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation including the core rules defined in Appendix B of RFC 5234 [RFC5234]. Terms not defined in this document are taken from [RFC5322].

2.1. Terminology

Drafter: Any email user that composes a message (Draft Message) needing authorisation before it is released to its intended recipients.

Authorizing User (also Releaser or Authorizer): The mailbox of a user or a group of users that must inspect and authorise the release of Draft Message before it can be sent. An organization may require more than one Authorizing User to authorize release of a Draft Message.

3. Structure of a draft message

Message encapsulating a draft message to be released or reviewed (a.k.a. "outer message") is constructed as follows:

1. The media type of the outer message is "multipart/mixed".
2. The outer message contains the Message-Draft header field Section 5. The initial message for release/review would contain "For Release", "For Confirmed Release" or "For Review" in this header field. [CREF1]Is "For Confirmed Release" needed?
3. (REQUIRED) The first body part of the outer message contains a human-readable message. The purpose of this message is to convey information about the inner draft message from the drafter to authorizing user. This body part can use any IANA-registered MIME media type, charset, or language. But this body part is typically "text/plain". Where a description of the error is desired in several languages or several media, a "multipart/alternative" construct can be used.
4. (REQUIRED) The second body part is "message/rfc822" or "message/global". It wraps the draft message to be released. The draft message can contain MMHS-Authorizing-Users header field [I-D.melnikov-mmhs-authorizing-users].
5. (OPTIONAL) The third and subsequent body parts contain comments from reviewers and/or authorizing users. These body parts are typically "text/plain" or "text/html".

4. Structure of a confirmation message

1. The media type of the message confirming that the origina draft message was released, reviewed or rejected can be or any media type.
2. The message includes the Message-Draft header field Section 5 containing one of "Authorized", "Reviewed" or "Rejected".
3. The message should contain "In-Reply-To:" header field with the Message-ID of the original draft message.

5. Message-Draft header field

Message-Draft specifies what should be done with a draft message or what was already done with it.

This message header can appear only once in the header.

  
    Message-Draft = "Message-Draft:"
                       [FWS] Message-Draft-Type [FWS] CRLF
    
    Message-Draft-Type = "For Release" /
                         "For Confirmed Release" /
                         "For Review" /
                         "Authorized" /
                         "Reviewed" /
                         "Rejected"

6. Registration of new IMAP Keywords

TBD

7. Example

  
Date: Thu, 23 Oct 2014 10:07:18 -0400
From: TwHarrierTest <harriertest@example.com>
Message-Draft: For Confirmed Release
Message-Id: <634f2005-0bf1-4e07-a789-e78433a985f7@imap.example.com>
Mmhs-Primary-Precedence: 2
Subject: Cease Fire
To: <alexey.melnikov@example.com>
X-Mailer: Harrier
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=.562b3944-4b07-437f-be7d-1338f523a3a4

This is a multipart message in MIME format.

--.562b3944-4b07-437f-be7d-1338f523a3a4
content-type: text/plain; charset=utf-8

Alexey please release this.
--.562b3944-4b07-437f-be7d-1338f523a3a4
Content-Disposition: attachment
Content-Type: message/rfc822

Content-type: text/plain; charset=utf-8; delsp=yes; format=flowed
From: TwHarrierTest <harriertest@example.com>
message-draft: For Confirmed Release
message-id: <0a2d822c-0b14-4d02-9215-45292676137f@imap.example.com>
MIME-Version: 1.0
mmhs-copy-precedence: 5
mmhs-primary-precedence: 5
Subject: Cease Fire
To:  <commander@example.com>
X-Mailer: Harrier

Text of cease fire msg
--.562b3944-4b07-437f-be7d-1338f523a3a4--

8. IANA Considerations

TBD. Need to register "Message-Draft" header field with IANA.

9. Security Considerations

TBD.

10. Normative References

Appendix A. Acknowledgements

Thank you to Steve Kille and Tom Watson for suggestions, comments and corrections on this document.

Author's Address