<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>

<rfc ipr="trust200902" category="info" docName='draft-melnikov-email-draft-and-release-04'>
  <front>
    <title abbrev="Draft &amp; Release email messages">
      Implementing Draft &amp; Release and Draft &amp; Review in Internet Mail
    </title>
    <author initials="A." surname="Melnikov" fullname="Alexey Melnikov" role="editor">
      <organization>Isode Ltd</organization>
      <address>
	<postal>
	  <street>14 Castle Mews</street>
	  <city>Hampton</city>
	  <region>Middlesex</region>
	  <code>TW12 2NP</code>
	  <country>UK</country>
	</postal>
	<email>Alexey.Melnikov@isode.com</email>
      </address>
    </author>
      
    <date year="2021" />
    
    <keyword>MMHS</keyword>
    <keyword>email</keyword>

    <abstract>

    <t>
    This document describes how draft messages intended for Draft &amp; Release and Draft &amp; Review environments
    can be represented in Internet Email.
    </t>
	
    </abstract>
    
  </front>
  <middle>

    <section title="Introduction">

      <t>
      In some environments email messages can't be released to
<!--////Is "mail transfer system" a term? Is it a proper expansion of it?-->
      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 <xref target="RFC5322"/> MIME objects <xref target="RFC2045"/>.
      </t>

    </section>
    
    <section title="Conventions Used in This Document">
      
      <t>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
	    <xref target="RFC2119"/>.</t>

      <t>The formal syntax uses the <xref target="RFC5234">Augmented
	    Backus-Naur Form (ABNF)</xref> notation including the core rules
	    defined in Appendix B of <xref target="RFC5234">RFC 5234</xref>.
      Terms not defined in this document are taken from <xref target="RFC5322"/>.
      </t>

      <section title='Terminology'>

        <t>
          Drafter: Any email user that composes a message (Draft Message) needing authorisation before it is released to its intended recipients.
        </t>

        <t>
          Authorizing User (also known as 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.
        </t>

      </section>
      
    </section>

    
    <section title="Structure of a draft message" anchor="draft-message">

      <t>
        Message encapsulating a draft message to be released or reviewed (a.k.a. "outer message") is constructed as follows:

        <list style='numbers'>

          <t>
          The media type of the outer message is "multipart/mixed".
          </t>

          <t>
          The outer message contains the Message-Draft header field <xref target="message-draft-header-field"/>.
          The initial message for release/review would contain "For Release", "For Confirmed Release" or "For Review"
          in this header field.
          <cref>Is "For Confirmed Release" needed? Use MDN request instead?</cref>
          </t>

          <t>
            (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 is not shown in Draft &amp; Release aware email clients.-->

            This body part can use any IANA-registered MIME media type, charset, or language.
            But this body part is typically "text/plain" or "text/html".
            Where a description of the error is desired in several languages or
            several media, a "multipart/alternative" or "multipart/multilingual" <xref target="RFC8255"/>
            construct can be used.
          </t>

          <t>(REQUIRED) The second body part is "message/rfc822" or "message/global" <xref target="RFC6532"/>.
          It wraps the draft message to be released. The draft message can contain
          MMHS-Authorizing-Users header field <xref target='RFC7912'/>.</t>

          <t>(OPTIONAL) The third and subsequent body parts contain comments from reviewers
          and/or authorizing users. These body parts are typically "text/plain", "text/html",
          "message/rfc822" or "message/global", but can be other types (e.g. "multipart/related").
          </t>
          
        </list>
      </t>
      
    </section>

    <section title="Structure of a confirmation message">

      <t>
      The message confirming that the original draft message was released, reviewed or rejected is sent from the reviewer/releaser to the drafter.
      It is formatted as an Message Disposition Notification (MDN) <xref target='RFC8098'/>.
      </t>

    </section>

    <section title="Structure of a rejection message">

      <t>
      The rejection message provides details on why the original draft message was rejected by the reviewer/releaser. It is sent from reviewer/releaser to the drafter.
      It has the same structure as a regular draft message (see <xref target="draft-message"/>), but the first body part contains explanation of why the draft message was rejected.
      </t>

    </section>
    
    <section title="Message-Draft header field" anchor="message-draft-header-field">

      <t>Message-Draft header field specifies what should be done with a draft message or what was action was performed on it.</t>

      <t>This message header can appear at most once in the header.</t>
      
      <!--Note: this header field can be present in both the inner and the outer message-->

      <figure><artwork type="ABNF">
  <![CDATA[
    Message-Draft = "Message-Draft:"
                       [FWS] Message-Draft-Type [FWS] CRLF
    
    Message-Draft-Type = "For Release" /
                         "For Confirmed Release" /
                         "For Review" /
                         "Authorized" /
                         "Reviewed" /
                         "Rejected"
]]></artwork></figure>

      
<!--///"For Confirmed Release" might be better implemented with MDN request header field instead?-->
      
<!--Note: 'For Release' is synonymous with 'For Authorisation'-->

    </section>    

    <section title="Registration of new IMAP Keywords" anchor="imap-keywords">

      <t>This document defines several new IMAP keywords <xref target="RFC3501"/> that can be used to override values stored
      in the Message-Draft header field. (I.e. if one of these mutually exclusive keywords is found,
      they take precedence over the value specified in the Message-Draft header field.)
      This allow client developers to implement easier Draft &amp; Release workflow without requiring
      to re-upload the modified message with IMAP APPEND command. </t>

      <t>
        All of the following IMAP keywords are mutually exclusive:

        <!--////Alternatively this can be made a table-->

        <list>
<!--////Need to change our implementation not to use any of these:          
          <t>$DraftForRelease corresponds to the "For Release" value of the Message-Draft header field;</t>

          <t>$DraftForConfirmedRelease corresponds to the "For Confirmed Release" value of the Message-Draft header field;</t>

          <t>$DraftForReview corresponds to the "For Review" value of the Message-Draft header field;</t>
-->
          <t>$DraftAuthorized corresponds to the "Authorized" value of the Message-Draft header field;</t>

          <t>$DraftReviewed corresponds to the "Reviewed" value of the Message-Draft header field;</t>

          <t>$DraftRejected corresponds to the "Rejected" value of the Message-Draft header field.</t>
        </list>
      </t>

    </section>

    <section title="Example">

<figure><artwork>
  <![CDATA[
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 message
--.562b3944-4b07-437f-be7d-1338f523a3a4--
]]></artwork></figure>

    </section>

    <section title="IANA Considerations">

      <section title="The Message-Draft Header Field registration">
        
        <t>
        IANA is requested to add the Message-Draft header field to the IANA
    <!--////Might need to use "Provisional Message Header Field Names" subregistry, depending on what the Expert Reviewer says. -->
        "Permanent Message Header Field Names" registry, per the procedure
        found in <xref target="RFC3864"/>.  That entry is to be updated to reference
        this document.  The following is the registration template:

        <list>
          <t>Header field name: Message-Draft</t>
          <t>Applicable protocol: mail (<xref target="RFC5322"/>)</t>
          <t>Status: Standard</t>
          <t>Author/Change controller: IETF</t>
          <t>Specification document(s): [this RFC]</t>
          <t>Related information: none</t>
        </list>

        </t>
      </section>

      
      <section title="$DraftReviewed IMAP keyword registration">

        <t>
          <list style="hanging" hangIndent="12">
            <t hangText="Subject:">
              Registration of IMAP keyword $DraftReviewed
              <vspace blankLines="1"/>
            </t>

            <t hangText="IMAP keyword name:">
              $DraftReviewed
              <vspace blankLines="1"/>
            </t>

            <t hangText="Purpose (description):">
              The $DraftReviewed IMAP keyword designates the message requiring review
              as approved (processed).
              <vspace blankLines="1"/>
            </t>

            <!--cref: Not sure about this-->
            <t hangText="Private or Shared on a server:">
              SHARED
              <vspace blankLines="1"/>
            </t>

            <t hangText="Is it an advisory keyword or may it cause an automatic action:">
              When this keyword is set, it means that the message is already reviewed and doesn't need
              any action. Lack of all of $DraftReviewed, $DraftAuthorized and $DraftRejected can cause the client to popup
              a dialog or show some other UI for authorizing release of a message.
              <vspace blankLines="1"/>
            </t>

            <t hangText="When/by whom the keyword is set/cleared:">
              This keyword is set by an email client when the message is reviewed.
              <vspace blankLines="1"/>
            </t>

            <t hangText="Related keywords:">
              $DraftRejected
              <vspace blankLines="1"/>
            </t>

            <t hangText="Related IMAP capabilities:">
              None
              <vspace blankLines="1"/>
            </t>

            <t hangText="Security considerations:">
<!--////
              A server implementing this keyword as a shared keyword
              may disclose that a confidential message was sent
              or is being actively sent out.
-->              
              <vspace blankLines="1"/>
            </t>

            <t hangText="Published specification (recommended):">
              [[This-RFC]]
              <vspace blankLines="1"/>
            </t>

            <t hangText="Person &amp; email address to contact for further information:">
              Alexey Melnikov &lt;alexey.melnikov@isode.com&gt;
              <vspace blankLines="1"/>
            </t>

            <t hangText="Intended usage:">
              COMMON
              <vspace blankLines="1"/>
            </t>

            <t hangText="Owner/Change controller:">
              IESG
              <vspace blankLines="1"/>
            </t>

            <t hangText="Note:">
              <vspace blankLines="1"/>
              $DraftAuthorized, $DraftReviewed and $DraftRejected are mutually exclusive. If more than one of
              them is set for a message, the mail client MUST treat this as if
              neither of them is set and SHOULD remove both of them from the IMAP
              server.
            </t>
          </list>
        </t>

      </section>
      
      <section title="$DraftAuthorized IMAP keyword registration">

        <t>
          <list style="hanging" hangIndent="12">
            <t hangText="Subject:">
              Registration of IMAP keyword $DraftAuthorized
              <vspace blankLines="1"/>
            </t>

            <t hangText="IMAP keyword name:">
              $DraftAuthorized
              <vspace blankLines="1"/>
            </t>

            <t hangText="Purpose (description):">
              The $DraftAuthorized IMAP keyword designates the message requiring authorization for release
              as authorized (processed).
              <vspace blankLines="1"/>
            </t>

            <!--cref: Not sure about this-->
            <t hangText="Private or Shared on a server:">
              SHARED
              <vspace blankLines="1"/>
            </t>

            <t hangText="Is it an advisory keyword or may it cause an automatic action:">
              When this keyword is set, it means that the message is already authorized and doesn't need
              any action. Lack of all of $DraftReviewed, $DraftAuthorized and $DraftRejected can cause the client to popup
              a dialog or show some other UI for authorizing release of a message.
              <vspace blankLines="1"/>
            </t>

            <t hangText="When/by whom the keyword is set/cleared:">
              This keyword is set by an email client when the message is authorized.
              <vspace blankLines="1"/>
            </t>

            <t hangText="Related keywords:">
              $DraftRejected
              <vspace blankLines="1"/>
            </t>

            <t hangText="Related IMAP capabilities:">
              None
              <vspace blankLines="1"/>
            </t>

            <t hangText="Security considerations:">
<!--////
              A server implementing this keyword as a shared keyword
              may disclose that a confidential message was sent
              or is being actively sent out.
-->              
              <vspace blankLines="1"/>
            </t>

            <t hangText="Published specification (recommended):">
              [[This-RFC]]
              <vspace blankLines="1"/>
            </t>

            <t hangText="Person &amp; email address to contact for further information:">
              Alexey Melnikov &lt;alexey.melnikov@isode.com&gt;
              <vspace blankLines="1"/>
            </t>

            <t hangText="Intended usage:">
              COMMON
              <vspace blankLines="1"/>
            </t>

            <t hangText="Owner/Change controller:">
              IESG
              <vspace blankLines="1"/>
            </t>

            <t hangText="Note:">
              <vspace blankLines="1"/>
              $DraftAuthorized, $DraftReviewed and $DraftRejected are mutually exclusive. If more than one of
              them is set for a message, the mail client MUST treat this as if
              neither of them is set and SHOULD remove both of them from the IMAP
              server.
            </t>
          </list>
        </t>

      </section>

      <section title="$DraftRejected IMAP keyword registration">

        <t>
          <list style="hanging" hangIndent="12">
            <t hangText="Subject:">
              Registration of IMAP keyword $DraftRejected
              <vspace blankLines="1"/>
            </t>

            <t hangText="IMAP keyword name:">
              $DraftRejected
              <vspace blankLines="1"/>
            </t>

            <t hangText="Purpose (description):">
              The $DraftRejected IMAP keyword designates the message requiring review or authorization for release
              as rejected by releaser/reviewer (processed).
              <vspace blankLines="1"/>
            </t>

            <!--cref: Not sure about this-->
            <t hangText="Private or Shared on a server:">
              SHARED
              <vspace blankLines="1"/>
            </t>

            <t hangText="Is it an advisory keyword or may it cause an automatic action:">
              When this keyword is set, it means that the message is already rejected and doesn't need
              any action. Lack of all of $DraftReviewed, $DraftAuthorized and $DraftRejected can cause the client to popup
              a dialog or show some other UI for authorizing release of a message.
              <vspace blankLines="1"/>
            </t>

            <t hangText="When/by whom the keyword is set/cleared:">
              This keyword is set by an email client when the message is rejected by authorizer.
              <vspace blankLines="1"/>
            </t>

            <t hangText="Related keywords:">
              $DraftAuthorized,
              <vspace blankLines="1"/>
              $DraftReviewed
            </t>

            <t hangText="Related IMAP capabilities:">
              None
              <vspace blankLines="1"/>
            </t>

            <t hangText="Security considerations:">
<!--////
              A server implementing this keyword as a shared keyword
              may disclose that a confidential message was sent
              or is being actively sent out.
-->              
              <vspace blankLines="1"/>
            </t>

            <t hangText="Published specification (recommended):">
              [[This-RFC]]
              <vspace blankLines="1"/>
            </t>

            <t hangText="Person &amp; email address to contact for further information:">
              Alexey Melnikov &lt;alexey.melnikov@isode.com&gt;
              <vspace blankLines="1"/>
            </t>

            <t hangText="Intended usage:">
              COMMON
              <vspace blankLines="1"/>
            </t>

            <t hangText="Owner/Change controller:">
              IESG
              <vspace blankLines="1"/>
            </t>

            <t hangText="Note:">
              <vspace blankLines="1"/>
              $DraftAuthorized, $DraftReviewed and $DraftRejected are mutually exclusive. If more than one of
              them is set for a message, the mail client MUST treat this as if
              neither of them is set and SHOULD remove both of them from the IMAP
              server.
            </t>
          </list>
        </t>

      </section>

    </section>

    <section title="Security Considerations" anchor="seccons">

      <t>TBD.</t>

    </section>
    
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?> <!-- Keywords -->
      <?rfc include="reference.RFC.2045"?> <!-- MIME, part 1 -->
      <?rfc include="reference.RFC.3501"?> <!-- IMAP -->
      <?rfc include="reference.RFC.3864"?> <!-- Header Field registration BCP -->
      <?rfc include="reference.RFC.5322"?> <!-- Email Format -->
      <?rfc include="reference.RFC.5234"?> <!-- ABNF -->
      <?rfc include="reference.RFC.6532"?> <!-- message/global -->
      <?rfc include="reference.RFC.7912"?> <!-- Message Authorizing Email Header Field and Its Use for the Draft and Release Procedure -->
      <?rfc include="reference.RFC.8255"?> <!-- multipart/multilingual -->
      <?rfc include="reference.RFC.8098"?> <!-- MDN -->

    </references>

<!--    
    <references title="Informative References">
    </references>
-->

    <section title="Acknowledgements">
	
      <t>Thank you to Steve Kille and Tom Watson for suggestions, comments and corrections on this document.</t>

    </section>

  </back>
</rfc>
