Resolved issues

misc/temp/draft-ietf-lamps-header-protection.mkd-am

@@ -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}}.
@@ -629,7 +629,7 @@ 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
-MUST 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}}.
@@ -708,6 +708,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
@@ -731,7 +736,7 @@ 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
 
@@ -943,11 +948,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.
 
-<!--
-Alexey: while this is true, people still need to use the form 3 (for example).
-So I would rather just talk about when it is appropriate to use which form.
--->
-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.