[rfc-i] v3imp #2 Control over paginated output (with examples)

Sean Leonard dev+ietf at seantek.com
Thu Jan 29 05:20:13 PST 2015


On 1/24/2015 1:05 AM, Julian Reschke wrote:
> A concrete example would be one that shows the markup in the source 
> file, and a page break that xml2rfv has generated when it shouldn't have.

Well the problem is that xml2rfc is not generating /enough/ page breaks 
in the HTML output.

I don't have too many complaints about inappropriate page breaks in 
reviewing the *plain text* output of the current tool. Inappropriate 
page breaks refer to page breaks in the middle of a figure, in the 
middle of a table (particularly in the middle of a row--if anything, at 
least break between rows), or between section headings. Additionally, 
inappropriate page breaks refer to breaks that result in widow or orphan 
problems (a lone paragraph line at the bottom or top of a page). The 
text output gets most of these things right, most of the time.

Since folks want specific examples, take a good look at the attached 
files and the specific instances called out below.

I had to make several manual changes to draft-josefsson-pkix-textual-10 
to get it to have the correct page breaking behavior. The PDFs are 
rendered from Google Chrome on Mac OS X, which has some support for the 
CSS pagination properties. The differences are visible between 
"draft-josefsson-pkix-textual-10-original" and 
"draft-josefsson-pkix-textual-10"; a diff file is included.

There are several unacceptable problems with 
draft-josefsson-pkix-textual-10-original.pdf, that are not related to 
the stylesheet:

  * widow problem in the paragraph "Unlike legacy PEM encoding..." in
    Section 3
  * Figure 5 is page-broken
  * Figure 7 caption is page-broken from the figure
  * Figure 9 caption is page-broken from the figure
  * Figure 12 (BEGIN PRIVATE KEY) is page-broken, and also has a widow
    problem
  * Section 17.2 (Informative References)'s heading is page-broken from
    the list


Obviously these problems will manifest themselves differently depending 
on page size, font choice, margin widths, and other paginated media 
properties.

Figure 12 is an example of an absolutely non-negotiable problem. The 
specification is very clear that implementations are sensitive to 
whitespace, so the break in Figure 12 renders the figure non-conforming 
or ambiguous. It's not acceptable to be output that way in any medium.

To fix these problems, I manually added @style="page-break-inside: 
avoid;" to the <pre> artwork tags until things got good enough that the 
PDF output was acceptable. In some places I also had to add 
"page-break-after: avoid". The results are shown in 
draft-josefsson-pkix-textual-10.pdf.

Some figures might be acceptable to break arbitrarily across pages 
(e.g., a large chunk of source code); other figures might be acceptable 
only at designated points (e.g., the breaks between table rows or only 
certain rows in the tables). Some figure formats (e.g., <table>, <tr> in 
my proposal) support these intra-figure hints. Others (e.g., SVG) do not 
currently but might in the future. There is some work in the SVG 
community around pagination and page-break hinting; we should expect 
that area to evolve independently of the v3 vocabulary.

I note that the heading elements <h1>...<h6> have "page-break-after: 
avoid" applied to them by stylesheet (which is the default rule that I 
argued for a couple of e-mails ago, anyway). Thus the Section 17.2 
problem is probably an artifact of WebKit/Chrome's support for CSS 
rather than a grammar problem per-se. However, the current v3 draft-15 
has attributes for page-break-after and page-break-before, but not 
page-break-inside. We need page-break-inside.

The widow problem in Section 3 is symptomatic of a broader problem, 
namely that neither the grammar (definitions) nor the tool adequately 
address window/orphan problems in all relevant contexts.

I did a quick search through the xml2rfc Python source code. The term 
"orphan" appears in nroff.py and paginated_txt.py, but not in html.py. 
This explains a lot.

The default widow/orphan control for <t> elements should be 2 lines, 
while the default for section headings should be infinite (i.e., 
page-break-inside: avoid -- it's the same thing). If folks can agree on 
those things, then maybe we don't need @widow and @orphan attribute 
equivalents. But we do need to say in the v3 draft that widow/orphan 
controls are expected in all output media, so that authors can rely on 
common behavior.

If folks can't agree on universal widow/orphan controls, then @widow and 
@orphan attribute equivalents should go in, so that individual authors 
can vary these according to their context-sensitive needs.

------------------------------------------------------------------------
There are two other problems:

  * Authors' Addresses: first author block is page-broken


This problem seems to be tool-related rather than grammar-related. Each 
author block is enclosed in <div class="avoidbreak"> but there is no 
.avoidbreak style in the stylesheet.

  * certain elements such as <div> are not terminated properly


This problem is because the divs, particularly around figures, don't 
properly encapsulate the figure or encapsulate the figure and everything 
following it (because they are treated as unterminated). One of numerous 
examples is <div id="rfc.figure.15" /><div id="spkiexample" />, which 
because the document is treated as HTML instead of XHTML (by Chrome, 
anyway), meant that Chrome treats this as <div id="rfc.figure.15"><div 
id="spkiexample"> with no termination, so when I tried to add 
@style="page-break-inside: avoid;", that ended up applying to the rest 
of the document. You can inspect the DOM yourself in the Chrome DOM 
Inspector.

I suspect that this parsing issue is related to the header, which is 
schizophrenically declares it as XHTML strict but there is no <?xml?> at 
the top and the http-equiv <meta> tag declares it as text/html instead 
of some kind of XML. I didn't research it too thoroughly.

Clearly what was meant by this markup was

    <div id="rfc.figure.15"></div><div id="spkiexample"></div>

although

    <div id="rfc.figure.15"><div
    id="spkiexample"><pre>...artwork...</pre><p class="figure">Figure
    15: ...caption...</p></div></div>

actually makes a lot more sense. The IDs "rfc.figure.15" and 
"spkiexample" clearly apply to the entire figure and not just to the 
empty top part.

Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20150129/a3fe46e8/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-josefsson-pkix-textual.xml
Type: text/xml
Size: 42986 bytes
Desc: not available
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20150129/a3fe46e8/attachment-0001.xml>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20150129/a3fe46e8/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-josefsson-pkix-textual-10-original.pdf
Type: application/pdf
Size: 322562 bytes
Desc: not available
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20150129/a3fe46e8/attachment-0002.pdf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20150129/a3fe46e8/attachment-0005.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-josefsson-pkix-textual-10.pdf
Type: application/pdf
Size: 633371 bytes
Desc: not available
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20150129/a3fe46e8/attachment-0003.pdf>
-------------- next part --------------
diff --git "a/D:\\Penango\\Standards\\j-pkix-textual\\draft-josefsson-pkix-textual-10-original.html" "b/D:\\Penango\\Standards\\j-pkix-textual\\draft-josefsson-pkix-textual-10.html"
index 1e3d6d8..9dcefdd 100644
--- "a/D:\\Penango\\Standards\\j-pkix-textual\\draft-josefsson-pkix-textual-10-original.html"
+++ "b/D:\\Penango\\Standards\\j-pkix-textual\\draft-josefsson-pkix-textual-10.html"
@@ -50,11 +50,19 @@
 	  }
 	  body {
 	  color: black;
-	  font-family: verdana, helvetica, arial, sans-serif;
+	  font-family: Open Sans, Mayberry Pro, verdana, helvetica, arial, sans-serif;
 	  font-size: 10pt;
 	  max-width: 55em;
 	  
 	  }
+    samp {
+	  background-color: rgb(242, 242, 255);
+	  border: 1px solid #ddd;
+	  padding-left: 2px;
+	  padding-right: 2px;
+	  font-family: Andale Mono, Inconsolata, Consolas, Cousine, monospace;
+	  white-space: pre;
+	  }
 	  cite {
 	  font-style: normal;
 	  }
@@ -122,6 +130,7 @@
 	  margin-left: 3em;
 	  background-color: lightyellow;
 	  padding: .25em;
+    font-family: Andale Mono, Inconsolata, Consolas, Cousine, monospace;
 	  }
 	  pre.text2 {
 	  border-style: dotted;
@@ -343,16 +352,16 @@
 		   content: "Internet-Draft"; 
 	  } 
 	  @top-right {
-		   content: "December 2010"; 
+		   content: "December 2014"; 
 	  } 
 	  @top-center {
-		   content: "Abbreviated Title";
+		   content: "pkix-textual";
 	  } 
 	  @bottom-left {
-		   content: "Doe"; 
+		   content: "Josefsson & Leonard"; 
 	  } 
 	  @bottom-center {
-		   content: "Expires June 2011"; 
+		   content: "Expires July 2015"; 
 	  } 
 	  @bottom-right {
 		   content: "[Page " counter(page) "]"; 
@@ -491,7 +500,7 @@
 <li>17.2.   <a href="#rfc.references.2">Informative References</a></li>
 <li>Appendix A.   <a href="#rfc.appendix.A">Non-Conforming Examples</a></li>
 <li>Appendix B.   <a href="#rfc.appendix.B">DER Expectations</a></li>
-<li><a href="#rfc.authors">Authors' Addresses</a></li>
+<li><a href="#rfc.authors">Authors’ Addresses</a></li>
 
 
   </ul>
@@ -508,7 +517,7 @@
   <li><a href="#RFC5208">PKCS #8: Private-Key Information Syntax</a> <cite title="NONE">[RFC5208]</cite>, renamed to One Asymmetric Key in <a href="#RFC5958">Asymmetric Key Package</a> <cite title="NONE">[RFC5958]</cite>, and Encrypted Private-Key Information Syntax in the same standards.</li>
   <li>Attribute Certificates in <a href="#RFC5755">An Internet Attribute Certificate Profile for Authorization</a> <cite title="NONE">[RFC5755]</cite>.</li>
 </ol>
-<p id="rfc.section.1.p.3">A disadvantage of a binary data format is that it cannot be interchanged in textual transports, such as e-mail or text documents.  One advantage with text-based encodings is that they are easy to modify using common text editors; for example, a user may concatenate several certificates to form a certificate chain with copy-and-paste operations.</p>
+<p id="rfc.section.1.p.3" style="page-break-inside: avoid;">A disadvantage of a binary data format is that it cannot be interchanged in textual transports, such as e-mail or text documents.  One advantage with text-based encodings is that they are easy to modify using common text editors; for example, a user may concatenate several certificates to form a certificate chain with copy-and-paste operations.</p>
 <p id="rfc.section.1.p.4">The tradition within the RFC series can be traced back to <a href="#RFC1421">PEM</a> <cite title="NONE">[RFC1421]</cite>, based on a proposal by Marshall Rose in <a href="#RFC0934">Message Encapsulation</a> <cite title="NONE">[RFC0934]</cite>.  Originally called "PEM encapsulation mechanism", "encapsulated PEM message", or (arguably) "PEM printable encoding", today the format is sometimes referred to as "PEM encoding". Variations include <a href="#RFC2015">OpenPGP ASCII Armor</a> <cite title="NONE">[RFC2015]</cite> and <a href="#RFC4716">OpenSSH Key File Format</a> <cite title="NONE">[RFC4716]</cite>.  </p>
 <p id="rfc.section.1.p.5">For reasons that basically boil down to non-coordination or inattention, many PKIX, PKCS, and CMS libraries implement a text-based encoding that is similar to—but not identical with—PEM encoding.  This document specifies the <em style="white-space: pre-wrap;">textual encoding</em> format,
 			articulates the de-facto rules that most implementations operate by,
@@ -519,23 +528,23 @@
       <a href="#X.509SG">X.509 Style Guide</a> <cite title="NONE">[X.509SG]</cite> contains a section "base64 Encoding" that describes the formats and contains suggestions similar to what is in this document. All figures are real, functional examples, with key lengths and inner contents chosen to be as small as practicable.</p>
 <p id="rfc.section.1.p.6">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a href="#RFC2119">RFC 2119</a> <cite title="NONE">[RFC2119]</cite>.</p>
 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a href="#general" id="general">General Considerations</a></h1>
-<p id="rfc.section.2.p.1">Textual encoding begins with a line comprising <samp style="white-space: pre;">-----BEGIN </samp>,
+<p id="rfc.section.2.p.1">Textual encoding begins with a line comprising <samp>-----BEGIN </samp>,
 			 a label, and
-			 <samp style="white-space: pre;">-----</samp>,
+			 <samp>-----</samp>,
 			 and ends with a line comprising
-			 <samp style="white-space: pre;">-----END </samp>,
+			 <samp>-----END </samp>,
 			 a label, and
-			 <samp style="white-space: pre;">-----</samp>.
+			 <samp>-----</samp>.
        Between these lines, or "encapsulation boundaries", are
 			 base64-encoded data according to Section 4 of <a href="#RFC4648">[RFC4648]</a>.  (PEM referred to this data as the "encapsulated text portion".) Data before the encapsulation boundaries are permitted and parsers MUST NOT malfunction when processing such data.  Furthermore, parsers SHOULD ignore whitespace and other non-base64 characters and MUST handle different newline conventions.</p>
-<p id="rfc.section.2.p.2">The type of data encoded is labeled depending on the type label in the <samp style="white-space: pre;">-----BEGIN </samp> line (pre-encapsulation boundary).
+<p id="rfc.section.2.p.2">The type of data encoded is labeled depending on the type label in the <samp>-----BEGIN </samp> line (pre-encapsulation boundary).
 			 For example, the line may be
-       <samp style="white-space: pre;">-----BEGIN CERTIFICATE-----</samp> to indicate that the content is a
+       <samp>-----BEGIN CERTIFICATE-----</samp> to indicate that the content is a
        PKIX certificate (see further below).
 			 Generators MUST put the
-       same label on the <samp style="white-space: pre;">-----END </samp> line (post-encapsulation boundary)
+       same label on the <samp>-----END </samp> line (post-encapsulation boundary)
 			 as the corresponding
-       <samp style="white-space: pre;">-----BEGIN </samp> line.
+       <samp>-----BEGIN </samp> line.
 			 Labels are formally case-sensitive, uppercase, and comprised of zero or more characters;
 			 they do not contain consecutive spaces or hyphen-minuses, nor do
 			 they contain spaces or hyphen-minuses at either end.
@@ -544,13 +553,13 @@
        label mismatch:
 			 some extant implementations require the labels to match;
 			 others do not.</p>
-<p id="rfc.section.2.p.3">There is exactly one space character (<samp style="white-space: pre;">SP</samp>) separating the
-			 <samp style="white-space: pre;">BEGIN</samp> or <samp style="white-space: pre;">END</samp>
+<p id="rfc.section.2.p.3">There is exactly one space character (<samp>SP</samp>) separating the
+			 <samp>BEGIN</samp> or <samp>END</samp>
 			 from the label. There are exactly
 			 five hyphen-minus (also known as dash) characters
-			 (<samp style="white-space: pre;">-</samp>)
+			 (<samp>-</samp>)
 			 on both ends of the encapsulation boundaries, no more, no less.</p>
-<p id="rfc.section.2.p.4">The label type implies that the encoded data follows the specified syntax.  Parsers MUST handle non-conforming data gracefully. However, not all parsers or generators prior to this Internet-Draft behave consistently.  A conforming parser MAY interpret the contents as another label type, but ought to be aware of the security implications discussed in the <a href="#security">Security Considerations</a> section.  The labels described in this document identify container formats that are not specific to any particular cryptographic algorithm, a property consistent with algorithm agility.  These formats use the ASN.1 <samp style="white-space: pre;">AlgorithmIdentifier</samp>
+<p id="rfc.section.2.p.4">The label type implies that the encoded data follows the specified syntax.  Parsers MUST handle non-conforming data gracefully. However, not all parsers or generators prior to this Internet-Draft behave consistently.  A conforming parser MAY interpret the contents as another label type, but ought to be aware of the security implications discussed in the <a href="#security">Security Considerations</a> section.  The labels described in this document identify container formats that are not specific to any particular cryptographic algorithm, a property consistent with algorithm agility.  These formats use the ASN.1 <samp>AlgorithmIdentifier</samp>
 				 structure as described in section 4.1.1.2 of <a href="#RFC5280">[RFC5280]</a>.</p>
 <p id="rfc.section.2.p.5">Unlike <a href="#RFC1421">legacy PEM encoding</a> <cite title="NONE">[RFC1421]</cite>, OpenPGP ASCII armor, and the OpenSSH key file format, textual encoding does <strong style="white-space: pre-wrap;">not</strong>
 			 define or permit headers
@@ -559,9 +568,9 @@
 			 and the base64, but generators SHOULD NOT emit such any such spacing.
 			 (The provision for this empty area is a throwback
 			 to PEM, which defined an "encapsulated header portion".)</p>
-<p id="rfc.section.2.p.6">Implementers need to be aware that extant parsers diverge considerably on the handling of whitespace.  In this document, "whitespace" means any character or series of characters that represent horizontal or vertical space in typography.  In US-ASCII, whitespace means HT (0x09), VT (0x0B), FF (0x0C), SP (0x20), CR (0x0D) and LF (0x0A); "blank" means HT and SP; lines are divided with CRLF, CR, or LF.  The common ABNF production <samp style="white-space: pre;">WSP</samp>
+<p id="rfc.section.2.p.6">Implementers need to be aware that extant parsers diverge considerably on the handling of whitespace.  In this document, "whitespace" means any character or series of characters that represent horizontal or vertical space in typography.  In US-ASCII, whitespace means HT (0x09), VT (0x0B), FF (0x0C), SP (0x20), CR (0x0D) and LF (0x0A); "blank" means HT and SP; lines are divided with CRLF, CR, or LF.  The common ABNF production <samp>WSP</samp>
 			 is congruent with "blank";
-			 a new production <samp style="white-space: pre;">W</samp>
+			 a new production <samp>W</samp>
 			 is used for "whitespace".
 			 The ABNF in <a href="#abnf">Section 3</a> is specific to US-ASCII.  As these textual encodings can be used on many different systems as well as on long-term archival storage media such as paper or engravings, an implementer ought to use the spirit rather than the letter of the rules when generating or parsing these formats in environments that are not strictly limited to US-ASCII.</p>
 <p id="rfc.section.2.p.7">Most extant parsers ignore blanks at the ends of lines; blanks at the beginnings of lines or in the middle of the base64-encoded data are far less compatible. These observations are codified in <a href="#abnf-fig">Figure 1</a>.  The most lax parser implementations are not line-oriented at all, and will accept any mixture of whitespace outside of the encapsulation boundaries (see <a href="#abnf-lax-fig">Figure 2</a>).  Such lax parsing may run the risk of accepting text that was not intended to be accepted in the first place (e.g., because the text was a snippet or sample).</p>
@@ -571,7 +580,7 @@
 <p id="rfc.section.3.p.1">The <a href="#RFC5234">ABNF</a> <cite title="NONE">[RFC5234]</cite> of the textual encoding is:</p>
 <div id="rfc.figure.1"/>
 <div id="abnf-fig"/>
-<pre>textualmsg = preeb *WSP eol
+<pre style="page-break-inside: avoid;">textualmsg = preeb *WSP eol
              *eolWSP
              base64text
              posteb *WSP [eol]
@@ -627,7 +636,7 @@ base64fullline   = 64base64char eol
 
 strictbase64text = *base64fullline strictbase64finl</pre>
 <p class="figure">Figure 3: ABNF (Strict)</p>
-<p id="rfc.section.3.p.2">New implementations SHOULD emit <a href="#abnf-strict-fig">the strict format</a> <cite title="NONE">[abnf-strict-fig]</cite> specified above.  The choice of parsing strategy depends on the context of use.</p>
+<p id="rfc.section.3.p.2" style="page-break-inside: avoid;">New implementations SHOULD emit <a href="#abnf-strict-fig">the strict format</a> <cite title="Figure 3: ABNF (Strict)">(Figure 3)</cite> specified above.  The choice of parsing strategy depends on the context of use.</p>
 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a href="#guide" id="guide">Guide</a></h1>
 <p id="rfc.section.4.p.1">For convenience, these figures summarize the structures, encodings, and references in the following sections:</p>
 <div id="rfc.figure.4"/>
@@ -664,12 +673,12 @@ strictbase64text = *base64fullline strictbase64finl</pre>
 <p class="figure">Figure 5: ASN.1 Module Object Identifier Value Assignments</p>
 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a href="#certificate" id="certificate">Textual Encoding of Certificates</a></h1>
 <h1 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1.</a> Encoding</h1>
-<p id="rfc.section.5.1.p.1">Public-key certificates are encoded using the <samp style="white-space: pre;">CERTIFICATE</samp> label.
-       The encoded data MUST be a BER (DER strongly preferred; see <a href="#DERapp">Appendix B</a>) encoded ASN.1 <samp style="white-space: pre;">Certificate</samp>
+<p id="rfc.section.5.1.p.1">Public-key certificates are encoded using the <samp>CERTIFICATE</samp> label.
+       The encoded data MUST be a BER (DER strongly preferred; see <a href="#DERapp">Appendix B</a>) encoded ASN.1 <samp>Certificate</samp>
        structure as described in section 4 of <a href="#RFC5280">[RFC5280]</a>.</p>
 <div id="rfc.figure.6"/>
 <div id="certexample"/>
-<pre>-----BEGIN CERTIFICATE-----
+<pre style="page-break-inside: avoid;">-----BEGIN CERTIFICATE-----
 MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G
 A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y
 aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0
@@ -684,17 +693,17 @@ SM49BAMCA0gAMEUCIDGuwD1KPyG+hRf88MeyMQcqOFZD0TbVleF+UsAGQ4enAiEA
 l4wOuDwKQa+upc8GftXE2C//4mKANBC6It01gUaTIpo=
 -----END CERTIFICATE-----</pre>
 <p class="figure">Figure 6: Certificate Example</p>
-<p id="rfc.section.5.1.p.2">Historically the label <samp style="white-space: pre;">X509 CERTIFICATE</samp> and also
-			 less commonly <samp style="white-space: pre;">X.509 CERTIFICATE</samp>
+<p id="rfc.section.5.1.p.2">Historically the label <samp>X509 CERTIFICATE</samp> and also
+			 less commonly <samp>X.509 CERTIFICATE</samp>
 			 have been used.  Generators
        conforming to this document MUST generate
-			 <samp style="white-space: pre;">CERTIFICATE</samp> labels
-       and MUST NOT generate <samp style="white-space: pre;">X509 CERTIFICATE</samp>
-			 or <samp style="white-space: pre;">X.509 CERTIFICATE</samp>
+			 <samp>CERTIFICATE</samp> labels
+       and MUST NOT generate <samp>X509 CERTIFICATE</samp>
+			 or <samp>X.509 CERTIFICATE</samp>
        labels. Parsers SHOULD NOT treat
-			 <samp style="white-space: pre;">X509 CERTIFICATE</samp> or
-			 <samp style="white-space: pre;">X.509 CERTIFICATE</samp>
-			 as equivalent to <samp style="white-space: pre;">CERTIFICATE</samp>,
+			 <samp>X509 CERTIFICATE</samp> or
+			 <samp>X.509 CERTIFICATE</samp>
+			 as equivalent to <samp>CERTIFICATE</samp>,
 			 but a valid exception may be for backwards
        compatibility (potentially together with a warning).</p>
 <h1 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2.</a> Explanatory Text</h1>
@@ -717,19 +726,19 @@ ILwpnZ1izL4MlI9eCSHhVQBHEp2uQdXJB+d5Byg=
 -----END CERTIFICATE-----</pre>
 <p class="figure">Figure 7: Certificate Example with Explanatory Text</p>
 <h1 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3.</a> File Extension</h1>
-<p id="rfc.section.5.3.p.1">Although textual encodings of PKIX structures can occur anywhere, many tools are known to offer an option to output this encoding when serializing PKIX structures.  To promote interoperability and to separate DER encodings from textual encodings, the extension <samp style="white-space: pre;">.crt</samp>
+<p id="rfc.section.5.3.p.1">Although textual encodings of PKIX structures can occur anywhere, many tools are known to offer an option to output this encoding when serializing PKIX structures.  To promote interoperability and to separate DER encodings from textual encodings, the extension <samp>.crt</samp>
 					SHOULD be used for the textual encoding of a certificate.
 				  Implementations should be aware that in spite of this recommendation,
 				  many tools still default to encode certificates in this textual encoding
-				  with the extension <samp style="white-space: pre;">.cer</samp>.</p>
-<p id="rfc.section.5.3.p.2">This section does not disturb the official <a href="#RFC2585">application/pkix-cert registration</a> <cite title="NONE">[RFC2585]</cite> in any way (which states that "each '.cer' file contains exactly one certificate, encoded in DER format"), but merely articulates a widespread, de-facto alternative.</p>
+				  with the extension <samp>.cer</samp>.</p>
+<p id="rfc.section.5.3.p.2" style="page-break-inside: avoid;">This section does not disturb the official <a href="#RFC2585">application/pkix-cert registration</a> <cite title="NONE">[RFC2585]</cite> in any way (which states that "each '.cer' file contains exactly one certificate, encoded in DER format"), but merely articulates a widespread, de-facto alternative.</p>
 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a href="#crl" id="crl">Textual Encoding of Certificate Revocation Lists</a></h1>
-<p id="rfc.section.6.p.1">Certificate Revocation Lists (CRLs) are encoded using the <samp style="white-space: pre;">X509 CRL</samp> label.
-			 The encoded data MUST be a BER (DER strongly preferred; see <a href="#DERapp">Appendix B</a>) encoded ASN.1 <samp style="white-space: pre;">CertificateList</samp>
+<p id="rfc.section.6.p.1">Certificate Revocation Lists (CRLs) are encoded using the <samp>X509 CRL</samp> label.
+			 The encoded data MUST be a BER (DER strongly preferred; see <a href="#DERapp">Appendix B</a>) encoded ASN.1 <samp>CertificateList</samp>
        structure as described in Section 5 of <a href="#RFC5280">[RFC5280]</a>.</p>
 <div id="rfc.figure.8"/>
 <div id="crlexample"/>
-<pre>-----BEGIN X509 CRL-----
+<pre style="page-break-inside: avoid;">-----BEGIN X509 CRL-----
 MIIB9DCCAV8CAQEwCwYJKoZIhvcNAQEFMIIBCDEXMBUGA1UEChMOVmVyaVNpZ24s
 IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT
 PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYu
@@ -743,23 +752,23 @@ b+5y+neKN9Kn2mPF4iiun+a4o26CjJ0pArojCL1p8T0yyi9Xxvyc/ezaZ98HiIyP
 c3DGMNR+oUmSjKZ0jIhAYmeLxaPHfQwR
 -----END X509 CRL-----</pre>
 <p class="figure">Figure 8: CRL Example</p>
-<p id="rfc.section.6.p.2">Historically the label <samp style="white-space: pre;">CRL</samp> has rarely been used. Today it is
+<p id="rfc.section.6.p.2">Historically the label <samp>CRL</samp> has rarely been used. Today it is
        not common and many popular tools do not understand the
-       label. Therefore, this document standardizes <samp style="white-space: pre;">X509 CRL</samp>
+       label. Therefore, this document standardizes <samp>X509 CRL</samp>
 			 in order to promote interoperability and backwards-compatibility.
 			 Generators conforming to this document MUST generate
-       <samp style="white-space: pre;">X509 CRL</samp> labels and MUST NOT generate
-			 <samp style="white-space: pre;">CRL</samp> labels.  Parsers
-       SHOULD NOT treat <samp style="white-space: pre;">CRL</samp>
-			 as equivalent to <samp style="white-space: pre;">X509 CRL</samp>.</p>
+       <samp>X509 CRL</samp> labels and MUST NOT generate
+			 <samp>CRL</samp> labels.  Parsers
+       SHOULD NOT treat <samp>CRL</samp>
+			 as equivalent to <samp>X509 CRL</samp>.</p>
 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a href="#crs" id="crs">Textual Encoding of PKCS #10 Certification Request Syntax</a></h1>
-<p id="rfc.section.7.p.1">PKCS #10 Certification Requests are encoded using the <samp style="white-space: pre;">CERTIFICATE REQUEST</samp> label.
-			 The encoded data MUST be a BER (DER strongly preferred; see <a href="#DERapp">Appendix B</a>) encoded ASN.1 <samp style="white-space: pre;">CertificationRequest</samp>
+<p id="rfc.section.7.p.1">PKCS #10 Certification Requests are encoded using the <samp>CERTIFICATE REQUEST</samp> label.
+			 The encoded data MUST be a BER (DER strongly preferred; see <a href="#DERapp">Appendix B</a>) encoded ASN.1 <samp>CertificationRequest</samp>
 			 structure as described in
        <a href="#RFC2986">[RFC2986]</a>.</p>
 <div id="rfc.figure.9"/>
 <div id="pkcs10example"/>
-<pre>-----BEGIN CERTIFICATE REQUEST-----
+<pre style="page-break-inside: avoid;">-----BEGIN CERTIFICATE REQUEST-----
 MIIBWDCCAQcCAQAwTjELMAkGA1UEBhMCU0UxJzAlBgNVBAoTHlNpbW9uIEpvc2Vm
 c3NvbiBEYXRha29uc3VsdCBBQjEWMBQGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG
 ByqGSM49AgEGBSuBBAAhAzoABLLPSkuXY0l66MbxVJ3Mot5FCFuqQfn6dTs+9/CM
@@ -770,19 +779,19 @@ AhxBvfhxPFfbBbsE1NoFmCUczOFApEuQVUw3ZP69AhwWXk3dgSUsKnuwL5g/ftAY
 dEQc8B8jAcnuOrfU
 -----END CERTIFICATE REQUEST-----</pre>
 <p class="figure">Figure 9: PKCS #10 Example</p>
-<p id="rfc.section.7.p.2">The label <samp style="white-space: pre;">NEW CERTIFICATE REQUEST</samp> is also in wide use.
+<p id="rfc.section.7.p.2">The label <samp>NEW CERTIFICATE REQUEST</samp> is also in wide use.
       Generators conforming to this document MUST generate
-      <samp style="white-space: pre;">CERTIFICATE REQUEST</samp> labels.
+      <samp>CERTIFICATE REQUEST</samp> labels.
 			Parsers MAY treat
-			<samp style="white-space: pre;">NEW CERTIFICATE REQUEST</samp>
-			as equivalent to <samp style="white-space: pre;">CERTIFICATE REQUEST</samp>.</p>
-<h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a href="#pkcs7" id="pkcs7">Textual Encoding of PKCS #7 Cryptographic Message Syntax</a></h1>
-<p id="rfc.section.8.p.1">PKCS #7 Cryptographic Message Syntax structures are encoded using the <samp style="white-space: pre;">PKCS7</samp> label.
+			<samp>NEW CERTIFICATE REQUEST</samp>
+			as equivalent to <samp>CERTIFICATE REQUEST</samp>.</p>
+<h1 id="rfc.section.8" style="page-break-inside: avoid; page-break-after: avoid;"><a href="#rfc.section.8">8.</a> <a href="#pkcs7" id="pkcs7">Textual Encoding of PKCS #7 Cryptographic Message Syntax</a></h1>
+<p id="rfc.section.8.p.1">PKCS #7 Cryptographic Message Syntax structures are encoded using the <samp>PKCS7</samp> label.
 			 The encoded data MUST be a BER
-       encoded ASN.1 <samp style="white-space: pre;">ContentInfo</samp> structure as described in <a href="#RFC2315">[RFC2315]</a>.</p>
+       encoded ASN.1 <samp>ContentInfo</samp> structure as described in <a href="#RFC2315">[RFC2315]</a>.</p>
 <div id="rfc.figure.10"/>
 <div id="pkcs7example"/>
-<pre>-----BEGIN PKCS7-----
+<pre style="page-break-inside: avoid;">-----BEGIN PKCS7-----
 MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E
 CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz
 u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI
@@ -790,19 +799,19 @@ hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ
 OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4=
 -----END PKCS7-----</pre>
 <p class="figure">Figure 10: PKCS #7 Example</p>
-<p id="rfc.section.8.p.2">The label <samp style="white-space: pre;">CERTIFICATE CHAIN</samp> has been in use to denote a
+<p id="rfc.section.8.p.2">The label <samp>CERTIFICATE CHAIN</samp> has been in use to denote a
       degenerate PKCS #7 structure that contains only a list of
-      certificates (see Section 9 of <a href="#RFC2315">[RFC2315]</a>).  Several modern tools do not support this label.  Generators MUST NOT generate the <samp style="white-space: pre;">CERTIFICATE CHAIN</samp> label.
-      Parsers SHOULD NOT treat <samp style="white-space: pre;">CERTIFICATE CHAIN</samp> as
-      equivalent to <samp style="white-space: pre;">PKCS7</samp>.</p>
+      certificates (see Section 9 of <a href="#RFC2315">[RFC2315]</a>).  Several modern tools do not support this label.  Generators MUST NOT generate the <samp>CERTIFICATE CHAIN</samp> label.
+      Parsers SHOULD NOT treat <samp>CERTIFICATE CHAIN</samp> as
+      equivalent to <samp>PKCS7</samp>.</p>
 <p id="rfc.section.8.p.3">PKCS #7 is an old standard that has long been superseded by <a href="#RFC5652">CMS</a> <cite title="NONE">[RFC5652]</cite>.  Implementations SHOULD NOT generate PKCS #7 when CMS is an alternative.</p>
 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a href="#cms" id="cms">Textual Encoding of Cryptographic Message Syntax</a></h1>
-<p id="rfc.section.9.p.1">Cryptographic Message Syntax structures are encoded using the <samp style="white-space: pre;">CMS</samp> label.  The encoded data MUST
+<p id="rfc.section.9.p.1">Cryptographic Message Syntax structures are encoded using the <samp>CMS</samp> label.  The encoded data MUST
 			 be a BER encoded ASN.1
-       <samp style="white-space: pre;">ContentInfo</samp> structure as described in <a href="#RFC5652">[RFC5652]</a>.</p>
+       <samp>ContentInfo</samp> structure as described in <a href="#RFC5652">[RFC5652]</a>.</p>
 <div id="rfc.figure.11"/>
 <div id="cmsexample"/>
-<pre>-----BEGIN CMS-----
+<pre style="page-break-inside: avoid;">-----BEGIN CMS-----
 MIGDBgsqhkiG9w0BCRABCaB0MHICAQAwDQYLKoZIhvcNAQkQAwgwXgYJKoZIhvcN
 AQcBoFEET3icc87PK0nNK9ENqSxItVIoSa0o0S/ISczMs1ZIzkgsKk4tsQ0N1nUM
 dvb05OXi5XLPLEtViMwvLVLwSE0sKlFIVHAqSk3MBkkBAJv0Fx0=
@@ -810,28 +819,27 @@ dvb05OXi5XLPLEtViMwvLVLwSE0sKlFIVHAqSk3MBkkBAJv0Fx0=
 <p class="figure">Figure 11: CMS Example</p>
 <p id="rfc.section.9.p.2">CMS is the IETF successor to PKCS #7. Section 1.1.1 of <a href="#RFC5652">[RFC5652]</a> describes the changes since PKCS #7 v1.5. Implementations SHOULD generate CMS when it is an alternative, promoting interoperability and forwards-compatibility.</p>
 <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a href="#pkcs8" id="pkcs8">Textual Encoding of PKCS #8 Private Key Info, and One Asymmetric Key</a></h1>
-<p id="rfc.section.10.p.1">Unencrypted PKCS #8 Private Key Information Syntax structures (<samp style="white-space: pre;">PrivateKeyInfo</samp>),
+<p id="rfc.section.10.p.1">Unencrypted PKCS #8 Private Key Information Syntax structures (<samp>PrivateKeyInfo</samp>),
 				renamed to Asymmetric Key Packages
-				(<samp style="white-space: pre;">OneAsymmetricKey</samp>),
-				are encoded using the <samp style="white-space: pre;">PRIVATE KEY</samp> label.
-				The encoded data MUST be a BER (DER preferred; see <a href="#DERapp">Appendix B</a>) encoded ASN.1 <samp style="white-space: pre;">PrivateKeyInfo</samp> structure as described in
-				<a href="#RFC5208">PKCS #8</a> <cite title="NONE">[RFC5208]</cite>, or a <samp style="white-space: pre;">OneAsymmetricKey</samp> structure as described in <a href="#RFC5958">[RFC5958]</a>. The two are semantically identical, and can be distinguished by version number.  </p>
-<div id="rfc.figure.12"/>
-<div id="pkcs8example"/>
-<pre>-----BEGIN PRIVATE KEY-----
+				(<samp>OneAsymmetricKey</samp>),
+				are encoded using the <samp>PRIVATE KEY</samp> label.
+				The encoded data MUST be a BER (DER preferred; see <a href="#DERapp">Appendix B</a>) encoded ASN.1 <samp>PrivateKeyInfo</samp> structure as described in
+				<a href="#RFC5208">PKCS #8</a> <cite title="NONE">[RFC5208]</cite>, or a <samp>OneAsymmetricKey</samp> structure as described in <a href="#RFC5958">[RFC5958]</a>. The two are semantically identical, and can be distinguished by version number.  </p>
+<div id="rfc.figure.12"><div id="pkcs8example" style="page-break-inside: avoid;">
+<pre style="page-break-inside: avoid;">-----BEGIN PRIVATE KEY-----
 MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf
 jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK
 H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ
 -----END PRIVATE KEY-----</pre>
-<p class="figure">Figure 12: PKCS #8 PrivateKeyInfo (OneAsymmetricKey) Example</p>
+<p class="figure">Figure 12: PKCS #8 PrivateKeyInfo (OneAsymmetricKey) Example</p></div></div>
 <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a href="#pkcs8enc" id="pkcs8enc">Textual Encoding of PKCS #8 Encrypted Private Key Info</a></h1>
-<p id="rfc.section.11.p.1">Encrypted PKCS #8 Private Key Information Syntax structures (<samp style="white-space: pre;">EncryptedPrivateKeyInfo</samp>),
-				called the same in <a href="#RFC5958">[RFC5958]</a>, are encoded using the <samp style="white-space: pre;">ENCRYPTED PRIVATE KEY</samp> label.
-				The encoded data MUST be a BER (DER preferred; see <a href="#DERapp">Appendix B</a>) encoded ASN.1 <samp style="white-space: pre;">EncryptedPrivateKeyInfo</samp> structure as described in
+<p id="rfc.section.11.p.1">Encrypted PKCS #8 Private Key Information Syntax structures (<samp>EncryptedPrivateKeyInfo</samp>),
+				called the same in <a href="#RFC5958">[RFC5958]</a>, are encoded using the <samp>ENCRYPTED PRIVATE KEY</samp> label.
+				The encoded data MUST be a BER (DER preferred; see <a href="#DERapp">Appendix B</a>) encoded ASN.1 <samp>EncryptedPrivateKeyInfo</samp> structure as described in
 				<a href="#RFC5208">PKCS #8</a> <cite title="NONE">[RFC5208]</cite> and <a href="#RFC5958">[RFC5958]</a>.  </p>
 <div id="rfc.figure.13"/>
 <div id="pkcs8encexample"/>
-<pre>-----BEGIN ENCRYPTED PRIVATE KEY-----
+<pre style="page-break-inside: avoid;">-----BEGIN ENCRYPTED PRIVATE KEY-----
 MIHNMEAGCSqGSIb3DQEFDTAzMBsGCSqGSIb3DQEFDDAOBAghhICA6T/51QICCAAw
 FAYIKoZIhvcNAwcECBCxDgvI59i9BIGIY3CAqlMNBgaSI5QiiWVNJ3IpfLnEiEsW
 Z0JIoHyRmKK/+cr9QPLnzxImm0TR9s4JrG3CilzTWvb0jIvbG3hu0zyFPraoMkap
@@ -840,12 +848,12 @@ QC7k0NNzUHTV9yGDwfqMbw==
 -----END ENCRYPTED PRIVATE KEY-----</pre>
 <p class="figure">Figure 13: PKCS #8 EncryptedPrivateKeyInfo Example</p>
 <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <a href="#attrcert" id="attrcert">Textual Encoding of Attribute Certificates</a></h1>
-<p id="rfc.section.12.p.1">Attribute certificates are encoded using the <samp style="white-space: pre;">ATTRIBUTE CERTIFICATE</samp>
-			 label.  The encoded data MUST be a BER (DER strongly preferred; see <a href="#DERapp">Appendix B</a>) encoded ASN.1 <samp style="white-space: pre;">AttributeCertificate</samp>
+<p id="rfc.section.12.p.1">Attribute certificates are encoded using the <samp>ATTRIBUTE CERTIFICATE</samp>
+			 label.  The encoded data MUST be a BER (DER strongly preferred; see <a href="#DERapp">Appendix B</a>) encoded ASN.1 <samp>AttributeCertificate</samp>
 			 structure as described in <a href="#RFC5755">[RFC5755]</a>.</p>
 <div id="rfc.figure.14"/>
 <div id="attrcertexample"/>
-<pre>-----BEGIN ATTRIBUTE CERTIFICATE-----
+<pre style="page-break-inside: avoid;">-----BEGIN ATTRIBUTE CERTIFICATE-----
 MIICKzCCAZQCAQEwgZeggZQwgYmkgYYwgYMxCzAJBgNVBAYTAlVTMREwDwYDVQQI
 DAhOZXcgWW9yazEUMBIGA1UEBwwLU3RvbnkgQnJvb2sxDzANBgNVBAoMBkNTRTU5
 MjE6MDgGA1UEAwwxU2NvdHQgU3RhbGxlci9lbWFpbEFkZHJlc3M9c3N0YWxsZXJA
@@ -861,17 +869,16 @@ Smluak1aZIttePeTAHeJJs8izNJ5aR3Wcd3A5gLztQ==
 -----END ATTRIBUTE CERTIFICATE-----</pre>
 <p class="figure">Figure 14: Attribute Certificate Example</p>
 <h1 id="rfc.section.13"><a href="#rfc.section.13">13.</a> <a href="#spki" id="spki">Textual Encoding of Subject Public Key Info</a></h1>
-<p id="rfc.section.13.p.1">Public keys are encoded using the <samp style="white-space: pre;">PUBLIC KEY</samp> label.
-			 The encoded data MUST be a BER (DER preferred; see <a href="#DERapp">Appendix B</a>) encoded ASN.1 <samp style="white-space: pre;">SubjectPublicKeyInfo</samp> structure as described in
+<p id="rfc.section.13.p.1">Public keys are encoded using the <samp>PUBLIC KEY</samp> label.
+			 The encoded data MUST be a BER (DER preferred; see <a href="#DERapp">Appendix B</a>) encoded ASN.1 <samp>SubjectPublicKeyInfo</samp> structure as described in
 			 Section 4.1.2.7 of <a href="#RFC5280">[RFC5280]</a>.</p>
-<div id="rfc.figure.15"/>
-<div id="spkiexample"/>
+<div id="rfc.figure.15"><div id="spkiexample" style="page-break-inside: avoid;">
 <pre>-----BEGIN PUBLIC KEY-----
 MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEn1LlwLN/KBYQRVH6HfIMTzfEqJOVztLe
 kLchp2hi78cCaMY81FBlYs8J9l7krc+M4aBeCGYFjba+hiXttJWPL7ydlE+5UG4U
 Nkn3Eos8EiZByi9DVsyfy9eejh+8AXgp
 -----END PUBLIC KEY-----</pre>
-<p class="figure">Figure 15: Subject Public Key Info Example</p>
+<p class="figure">Figure 15: Subject Public Key Info Example</p></div></div>
 <h1 id="rfc.section.14"><a href="#rfc.section.14">14.</a> <a href="#security" id="security">Security Considerations</a></h1>
 <p id="rfc.section.14.p.1">Data in this format often originates from untrusted sources, thus parsers must be prepared to handle unexpected data without causing security vulnerabilities.</p>
 <p id="rfc.section.14.p.2">Implementers building implementations that rely on canonical representation or the ability to fingerprint a particular data object need to understand that this Internet-Draft does not define canonical encodings.  The first ambiguity is introduced by permitting the text-encoded representation instead of the binary BER or DER encodings, but further ambiguities arise when multiple labels are treated as similar.  Variations of whitespace and non-base64 alphabetic characters can create further ambiguities. Data encoding ambiguities also create opportunities for side channels.  If canonical encodings are desired, the encoded structure must be decoded and processed into a canonical form (namely, DER encoding).  </p>
@@ -1008,7 +1015,7 @@ Nkn3Eos8EiZByi9DVsyfy9eejh+8AXgp
 <p id="rfc.section.A.p.1">This section contains examples for the non-recommended label variants described earlier in this document.  As discussed earlier, supporting these are not required and sometimes discouraged.  Still, they can be useful for interoperability testing and for easy reference.</p>
 <div id="rfc.figure.16"/>
 <div id="certexample2"/>
-<pre>-----BEGIN X509 CERTIFICATE-----
+<pre style="page-break-inside: avoid;">-----BEGIN X509 CERTIFICATE-----
 MIIBHDCBxaADAgECAgIcxzAJBgcqhkjOPQQBMBAxDjAMBgNVBAMUBVBLSVghMB4X
 DTE0MDkxNDA2MTU1MFoXDTI0MDkxNDA2MTU1MFowEDEOMAwGA1UEAxQFUEtJWCEw
 WTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATwoQSr863QrR0PoRIYQ96H7WykDePH
@@ -1017,9 +1024,9 @@ BgNVHRMBAf8EAjAAMAkGByqGSM49BAEDRwAwRAIfMdKS5F63lMnWVhi7uaKJzKCs
 NnY/OKgBex6MIEAv2AIhAI2GdvfL+mGvhyPZE+JxRxWChmggb5/9eHdUcmW/jkOH
 -----END X509 CERTIFICATE-----</pre>
 <p class="figure">Figure 16: Non-standard 'X509' Certificate Example</p>
-<div id="rfc.figure.17"/>
-<div id="certexample3"/>
-<pre>-----BEGIN X.509 CERTIFICATE-----
+<div id="rfc.figure.17">
+<div id="certexample3" style="page-break-inside: avoid;">
+<pre style="page-break-inside: avoid;">-----BEGIN X.509 CERTIFICATE-----
 MIIBHDCBxaADAgECAgIcxzAJBgcqhkjOPQQBMBAxDjAMBgNVBAMUBVBLSVghMB4X
 DTE0MDkxNDA2MTU1MFoXDTI0MDkxNDA2MTU1MFowEDEOMAwGA1UEAxQFUEtJWCEw
 WTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATwoQSr863QrR0PoRIYQ96H7WykDePH
@@ -1027,10 +1034,10 @@ Wa0eVAE24bth43wCNc+U5aZ761dhGhSSJkVWRgVH5+prLIr+nzfIq+X4oxAwDjAM
 BgNVHRMBAf8EAjAAMAkGByqGSM49BAEDRwAwRAIfMdKS5F63lMnWVhi7uaKJzKCs
 NnY/OKgBex6MIEAv2AIhAI2GdvfL+mGvhyPZE+JxRxWChmggb5/9eHdUcmW/jkOH
 -----END X.509 CERTIFICATE-----</pre>
-<p class="figure">Figure 17: Non-standard 'X.509' Certificate Example</p>
+<p class="figure">Figure 17: Non-standard 'X.509' Certificate Example</p></div></div>
 <div id="rfc.figure.18"/>
 <div id="pkcs10example2"/>
-<pre>-----BEGIN NEW CERTIFICATE REQUEST-----
+<pre style="page-break-inside: avoid;">-----BEGIN NEW CERTIFICATE REQUEST-----
 MIIBWDCCAQcCAQAwTjELMAkGA1UEBhMCU0UxJzAlBgNVBAoTHlNpbW9uIEpvc2Vm
 c3NvbiBEYXRha29uc3VsdCBBQjEWMBQGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG
 ByqGSM49AgEGBSuBBAAhAzoABLLPSkuXY0l66MbxVJ3Mot5FCFuqQfn6dTs+9/CM
@@ -1043,7 +1050,7 @@ dEQc8B8jAcnuOrfU
 <p class="figure">Figure 18: Non-standard 'NEW' PKCS #10 Example</p>
 <div id="rfc.figure.19"/>
 <div id="pkcs7example2"/>
-<pre>-----BEGIN CERTIFICATE CHAIN-----
+<pre style="page-break-inside: avoid;">-----BEGIN CERTIFICATE CHAIN-----
 MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E
 CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz
 u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI
@@ -1060,9 +1067,10 @@ OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4=
   <li>In practice, cryptographic hashes are computed over the DER encoding for identification.</li>
   <li>In practice, the content is small. DER always encodes data values in definite length form (where the length is stated at the beginning of the encoding); thus, a parser can anticipate memory or resource usage up-front.</li>
 </ol>
+<p><a href="#why-use-DER">Figure 20</a> matches the structures in this document with the particular reasons for DER encoding:</p>
 <div id="rfc.figure.20"/>
-<div id="why-use-DER"/>
-<pre>Sec. Label                  Reasons
+<div id="why-use-DER" style="page-break-inside: avoid;">
+<pre style="page-break-inside: avoid; page-break-after: avoid;">Sec. Label                  Reasons
 ----+----------------------+-------
   5  CERTIFICATE            1  2 ~3
   6  X509 CRL               1
@@ -1073,12 +1081,11 @@ OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4=
  11  ENCRYPTED PRIVATE KEY        3
  12  ATTRIBUTE CERTIFICATE  1    ~3
  13  PUBLIC KEY                2  3</pre>
-<p><a href="#why-use-DER">Figure 20</a> matches the structures in this document with the particular reasons for DER encoding: </p>
 
-<p>*Cryptographic Message Syntax is designed for content of any length; indefinite length encoding enables one-pass processing (streaming) when generating the encoding.  Only certain parts, namely signed and authenticated attributes, need to be DER encoded.<br/>~Although not always "small", these encoded structures should not be particularly "large" (e.g., more than 16 kilobytes). The parser ought to be informed of large things up-front in any event, which is yet another reason to DER encode these things in the first place.</p>
-<p class="figure">Figure 20: Guide for DER Encoding</p>
+<p style="page-break-inside: avoid; page-break-after: avoid;">*Cryptographic Message Syntax is designed for content of any length; indefinite length encoding enables one-pass processing (streaming) when generating the encoding.  Only certain parts, namely signed and authenticated attributes, need to be DER encoded.<br/>~Although not always "small", these encoded structures should not be particularly "large" (e.g., more than 16 kilobytes). The parser ought to be informed of large things up-front in any event, which is yet another reason to DER encode these things in the first place.</p>
+<p class="figure" style="page-break-before: avoid;">Figure 20: Guide for DER Encoding</p></div>
 <h1 id="rfc.authors">
-  <a href="#rfc.authors">Authors' Addresses</a>
+  <a href="#rfc.authors">Authors’ Addresses</a>
 </h1>
 <div class="avoidbreak">
   <address class="vcard">


More information about the rfc-interest mailing list