more editorials / typo

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

@@ -580,16 +580,16 @@ Message.
 Before choosing this option, two issues must be assessed to ensure, no
 interoperability issues result from it:
 
-1. How current MIME parser implementations treat (non-MIME) Header
-   Fields, which are not the outer most MIME entity and not wrapped
-   into a MIME entity of media type "message", and how such messages
-   are rendered to the user.
+1. How current MIME parser implementations treat non-MIME Header
+   Fields, which are not part of the outermost MIME entity and not
+   part of a message wrapped into a MIME entity of media type
+   "message/rfc822", and how such messages are rendered to the user.
 
-   {{I-D.autocrypt-lamps-protected-headers}} provides some examples for
-   testing this.
+   {{I-D.autocrypt-lamps-protected-headers}} provides some examples
+   for testing this.
 
 2. MIME-conformance, i.e. whether or not this option is (fully)
-   MIME-conformant {RFC2045}} ff., in particular also Section 5.1. of
+   MIME-conformant {{RFC2045}} ff., in particular also Section 5.1. of
    {{RFC2046}} on "Multipart Media Type). In the following an excerpt
    of paragraphs that may be relevant in this context:
 

ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200708.html

@@ -811,7 +811,7 @@ signature.
 <p></p>
 
 <ol>
-<li>How current MIME parser implementations treat (non-MIME) Header Fields, which are not the outer most MIME entity and not wrapped into a MIME entity of media type &#8220;message&#8221;, and how such messages are rendered to the user.  <br><br> <a href="#I-D.autocrypt-lamps-protected-headers" class="xref">[I-D.autocrypt-lamps-protected-headers]</a> provides some examples for testing this.</li>
+<li>How current MIME parser implementations treat non-MIME Header Fields, which are not part of the outer most MIME entity and not wrapped into a MIME entity of media type &#8220;message&#8221;, and how such messages are rendered to the user.  <br><br> <a href="#I-D.autocrypt-lamps-protected-headers" class="xref">[I-D.autocrypt-lamps-protected-headers]</a> provides some examples for testing this.</li>
 <li>MIME-conformance, i.e. whether or not this option is (fully) MIME-conformant {RFC2045}} ff., in particular also Section 5.1. of <a href="#RFC2046" class="xref">[RFC2046]</a> on &#8220;Multipart Media Type). In the following an excerpt of paragraphs that may be relevant in this context:</li>
 </ol>
 <pre>

ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200708.txt

@@ -690,10 +690,10 @@ Internet-Draft          Header Protection S/MIME               July 2020
    Before choosing this option, two issues must be assessed to ensure,
    no interoperability issues result from it:
 
-   1.  How current MIME parser implementations treat (non-MIME) Header
-       Fields, which are not the outer most MIME entity and not wrapped
-       into a MIME entity of media type "message", and how such messages
-       are rendered to the user.
+   1.  How current MIME parser implementations treat non-MIME Header
+       Fields, which are not part of the outer most MIME entity and not
+       wrapped into a MIME entity of media type "message", and how such
+       messages are rendered to the user.
 
        [I-D.autocrypt-lamps-protected-headers] provides some examples
        for testing this.