From 7614a24b6bcc4ba04b0e588a314680b0cdd9612c Mon Sep 17 00:00:00 2001
From: Bernie Hoeneisen <bernie.hoeneisen@pep.foundation>
Date: Mon, 6 Jul 2020 16:56:38 +0200
Subject: [PATCH] RUFM==InnerM (normally); More feedback from Alexey
 implemented (after a call); TODOs / Open Issues added (as result from call
 with Alexey

---
 .../draft-ietf-lamps-header-protection.mkd    | 55 +++++++++++++++----
 .../message_orig_outer_inner_rufm.mkd         |  4 +-
 2 files changed, 46 insertions(+), 13 deletions(-)

diff --git a/ietf-lamps-hp/draft-ietf-lamps-header-protection.mkd b/ietf-lamps-hp/draft-ietf-lamps-header-protection.mkd
index 4f34b566..d705d61c 100644
--- a/ietf-lamps-hp/draft-ietf-lamps-header-protection.mkd
+++ b/ietf-lamps-hp/draft-ietf-lamps-header-protection.mkd
@@ -206,8 +206,8 @@ determined by the IETF LAMPS WG.
   Header Fields are added by intermediary nodes).
 
 * Receiving User Facing Message (RUFM): The message used for rendering
-  at the receiving side after the Outer Message Header Section has
-  been merged with the Inner Message Header Section.
+  at the receiving side. Typically this is the same as the Inner
+  Message.
 
 * Essential Header Fields (EHF): The minimum set of Header Fields an
   Outer Message Header Section SHOULD contain; cf. {{outer-msg-hf}}.
@@ -288,7 +288,7 @@ cf. {{main-use-case}}.
 
 
 ### Backward Compatibility
-
+<!-- explain what is not correct -->
 The sending side fully supports Header protection as specified in this
 document, while the receiving side does not support the MIME
 specification {{RFC2045}}, ff. correctly; see
@@ -474,6 +474,8 @@ The Inner Message Body is the same as the Original Message Body.
 The Original Message itself may contain any MIME structure.
 
 <!--
+Alexey: I think this is just saying "The Original Message itself may contain any MIME structure"
+but in a bad way, because "multipart/mixed" is not the only choice here:
 There may also be an additional MIME layer with media type
 "multipart/mixed" in the Outer Message Body to contain the Inner
 Message (wrapped in a "message/RFC822") along with other MIME part(s).
@@ -489,10 +491,14 @@ Unlike the option described in {{option-smime-spec}}, this option does
 not use a "message/RFC822" wrapper to unambigously delimit the Inner
 Message.
 
+Note: More specific on Parsers (as there are two aspects here)
+
 Note: it is for further study, whether or not this option is (fully)
 compliant with the MIME standard, in particuar also {{RFC2046}},
 Section 5.1. (Multipart Media Type).
-
+<!--
+Maybe remove (as suggested by Alexey)
+-->
 
 The MIME structure of an Email message looks as follows:
 
@@ -564,6 +570,9 @@ The Inner Message Body is the same as the Original Message Body.
 The Original Message itself may contain any MIME structure.
 
 <!--
+Alexey: as above: I don't think this helps.
+Either add an example with a more complicated MIME structure,
+or delete this text.
 There may also be an additional MIME layer with media type
 "multipart/mixed" in the Outer Message Body to contain the Inner
 Message along with other MIME part(s).
@@ -613,8 +622,13 @@ The following Header Fields are defined as the Essential Header Fields:
 * Message-ID
 * Subject
 
-Some of these Header Fields are needed by the Transport (e.g. to
-determine the destination). Furthermore, not including certain Header
+<!-- if not SMTP, it is not relevant to IETF.
+describe that case in a sidenote
+
+verify 6409 is a good reference, split to RFC5322 and RFC6409
+-->
+Some of these Header Fields are required by the submission service
+{{RFC6409}} (e.g. From, Date). Furthermore, not including certain Header
 Fields may trigger spam detection to flag the message as spam and/or
 lead to user experience (UX) issues.
 
@@ -624,14 +638,13 @@ Fields MAY be obfuscated. Further Header Fields MAY be obfuscated,
 though simply not adding those to the Outer Message Header SHOULD be
 prefered over obfuscation. Header Field obfuscation is further
 specified in {{obfuscation-outer-HF}}. Header Fields not obfuscated
-SHOULD contain the same values as in the Original Message.
+should contain the same values as in the Original Message.
 
 The MIME Header Section part is the collection of MIME Header Fields
 describing the following MIME structure as defined in {{RFC2045}}.
 A MIME Header Section part typically includes the following Header
 Fields:
 
-* MIME-Version
 * Content-Type
 * Content-Transfer-Encoding
 * Content-Disposition
@@ -686,7 +699,10 @@ MAY be obfucated. Those may be replaced by e.g.
 
 * To: Obfuscated <anonymous@anonymous.invalid>
 
-Such implementations need to ensure that the Transport has access to
+<!-- define submission service as typically RFC 6409, but also propriatory implmentation exist
+-->
+
+Such implementations need to ensure that the submission service has access to
 these Header Fields in clear text and is capable of processing those.
 
 A use case for obfuscation of all Outer Message Header Fields is
@@ -698,6 +714,11 @@ Note: It is for further study to what extent Header Field obfuscation
 
 ### Receiving User Facing Message Header Fields {#rufm-hf}
 
+
+The Receiving User Facing Message SHOULD be a verbatim copy of the
+Inner Message.
+
+<!-- Alternative
 The Receiving User Facing Message is constructed as follows:
 
 * The Header Section of the Receiving User Facing Message MUST consist
@@ -709,8 +730,19 @@ The Receiving User Facing Message is constructed as follows:
   as the Inner Message Body.
 
 \[\[ TODO: Do we need to take special care for HFs, which may appear
-     multiple times, e.g. Received HF? \]\]
+     multiple times, e.g. Received HF?
 
+Alexey: None of the header fields that we want protecting are allowed to
+appear multiple times.
+The header fields that can appear multiple times are usually trace header fields:
+Received, Authentication-Results, etc. They are prepended to the outer
+Header Section and can never be protected.
+
+So I think this is just a long way of saying that no extra text is needed here,
+unless you want the document to explain the above.
+
+	 \]\]
+-->
 
 ### Header Field Flow
 
@@ -922,7 +954,8 @@ header field may appear in up to three different variants:
    usually contains the Bcc unchanged from the original message,
    i.e. with all recipient addresses.
 
-The most privacy preserving is to standardize 2a, as in the other
+The most privacy preserving of the alternatives (2a, 2b, and 2c)
+is to standardize 2a, as in the other
 cases (2b and 2c) information about hidden recipients is revealed via
 keys. In any case the message has to be cloned and adjusted depending
 on the recipient.
diff --git a/shared/ascii-arts/message_orig_outer_inner_rufm.mkd b/shared/ascii-arts/message_orig_outer_inner_rufm.mkd
index 9fa513f3..52b8a611 100644
--- a/shared/ascii-arts/message_orig_outer_inner_rufm.mkd
+++ b/shared/ascii-arts/message_orig_outer_inner_rufm.mkd
@@ -1,10 +1,10 @@
 OrigM        InnerM       Outer(S)            OuterM(R)    RUFM
 
-                                              <Trace-HF> > <Trace-HF>
+                                              <Trace-HF>
                           From (OrigM)      = From
                           To (OrigM)        = To
                           Cc (OrigM)        = Cc
-                          Bcc (OrigM)       = Bcc*       > Bcc
+                          Bcc (OrigM)       = Bcc*
                           Date (OrigM)      = Date
                           Message-ID (OrigM)= Message-ID
                           Subject (new)     = Subject