Browse Source

more editorials / typo

master
Bernie Hoeneisen 2 years ago
parent
commit
6dbab7d7f9
3 changed files with 12 additions and 12 deletions
  1. +7
    -7
      ietf-lamps-hp/draft-ietf-lamps-header-protection.mkd
  2. +1
    -1
      ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200708.html
  3. +4
    -4
      ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200708.txt

+ 7
- 7
ietf-lamps-hp/draft-ietf-lamps-header-protection.mkd View File

@ -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:


+ 1
- 1
ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200708.html View File

@ -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>


+ 4
- 4
ietf-lamps-hp/review/draft-ietf-lamps-header-protection-00-pre20200708.txt View File

@ -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.


Loading…
Cancel
Save