partial integration of Alexey's comments

ietf-lamps-hp/draft-ietf-lamps-header-protection.mkd

@@ -162,8 +162,9 @@ determined by the IETF LAMPS WG.
   Message. Typically, the Body consists of a (multipart) MIME
   {{RFC2045}} construct.
 
-* MIME Header Fields: Header Fields describing the MIME structure of
-  its body as defined in {{RFC2045}}.
+* MIME Header Fields: Header Fields describing content of a MIME entity
+  {{RFC2045}}, in particular the MIME structure. Each MIME Header Field
+  name starts with "Content-" prefix.
 
 * MIME Header Section (part): The collection of MIME Header Fields.
   "MIME Header Section" refers to a Header Sections that contains only
@@ -331,21 +332,20 @@ c)  Encryption only
 
 This section contains the specification for Header Protection in
 S/MIME to update and clarifies Section 3.1 of {{RFC8551}} (S/MIME
-4.0). This specification is likely to be integrated into S/MIME at
-some later stage.
+4.0).
 
-Furthermore, it is likely that PGP/MIME {{RFC3156}} will also take
-over this specification or parts of it.
+Furthermore, it is likely that PGP/MIME {{RFC3156}} will also incorprorate
+this specification or parts of it.
 
 This specification applies to the protection levels "signature &
 encryption" and "signature only" (cf. {{protection-levels}}):
 
-Sending and receiving sides SHOULD implement "signature and
+Sending and receiving sides MUST implement "signature and
 encryption", which is the default to use on the sending side.
 
 Certain implementations MAY decide to send "signature only" messages,
 depending on the circumstances and customer requirements.  Sending
-side MAY and receiving sides SHOULD implement "signature only".
+side MAY and receiving sides MUST implement "signature only".
 
 It generally is NOT RECOMMENDED to send a message with protection
 level "encryption only". On the other hand, messages with protection
@@ -473,10 +473,11 @@ The Inner Message Body is the same as the Original Message Body.
 
 The Original Message itself may contain any MIME structure.
 
+<!--
 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).
-
+-->
 
 #### Alternative Option Autocrypt "Protected Headers" (Ex-"Memory Hole") {#option-ex-memory-hole}
 
@@ -562,10 +563,11 @@ The Inner Message Body is the same as the Original Message Body.
 
 The Original Message itself may contain any MIME structure.
 
+<!--
 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).
-
+-->
 
 ### Inner Message Header Fields {#inner-msg-hf}
 
@@ -634,7 +636,12 @@ Fields:
 * Content-Transfer-Encoding
 * Content-Disposition
 
-The following example shows the MIME header of an S/MIME signed
+<!--
+Alexey: I don't find separation between MIME Header Section and
+full Header Section to be useful. They have exactly the same parsing
+rules.
+-->
+The following example shows the MIME Header Section part of an S/MIME signed
 message (using application/pkcs7-mime with SignedData):
 
 {::include ../shared/fence-line.mkd}
@@ -655,6 +662,9 @@ justified. Such Header Fields may include e.g.:
 * Reply-To
 * In-Reply-To
 
+<!--
+Alexey: the above header fields would be need if IMAP server side threading is to be used.
+-->
 
 #### Obfuscation of Outer Message Header Fields {#obfuscation-outer-HF}
 
@@ -732,8 +742,8 @@ Legend:
 * MIME-HSp: MIME Header Section part to describe the encryption or
   signature as per {{RFC8551}}
 
-* Trans-HF: Header Fields added in Transit (between sending and
-  receiving side)
+* Trace-HF: Header Fields added in Transit (between sending and
+  receiving side) as per {{RFC5322}}
 
 * \>: taken over / copied from last column
 

shared/ascii-arts/message_orig_outer_inner_rufm.mkd

@@ -1,6 +1,6 @@
 OrigM        InnerM       Outer(S)            OuterM(R)    RUFM
 
-                                              <Trans-HF> > <Trans-HF>
+                                              <Trace-HF> > <Trace-HF>
                           From (OrigM)      = From
                           To (OrigM)        = To
                           Cc (OrigM)        = Cc