citation as preformat

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

@@ -593,37 +593,43 @@ interoperability issues result from it:
    {{RFC2046}} on "Multipart Media Type). In the following an excerpt
    of paragraphs that may be relevant in this context:
 
-   > A body part is an entity and hence is NOT to be interpreted as
-   > actually being an RFC 822 message.  To begin with, NO header fields
-   > are actually required in body parts.  A body part that starts with a
-   > blank line, therefore, is allowed and is a body part for which all
-   > default values are to be assumed.  In such a case, the absence of a
-   > Content-Type header usually indicates that the corresponding body has
-   > a content-type of "text/plain; charset=US-ASCII".
-   > 
-   > The only header fields that have defined meaning for body parts are
-   > those the names of which begin with "Content-".  All other header
-   > fields may be ignored in body parts.  Although they should generally
-   > be retained if at all possible, they may be discarded by gateways if
-   > necessary.  Such other fields are permitted to appear in body parts
-   > but must not be depended on.  "X-" fields may be created for
-   > experimental or private purposes, with the recognition that the
-   > information they contain may be lost at some gateways.
-   > 
-   > NOTE:  The distinction between an RFC 822 message and a body part is
-   > subtle, but important.  A gateway between Internet and X.400 mail,
-   > for example, must be able to tell the difference between a body part
-   > that contains an image and a body part that contains an encapsulated
-   > message, the body of which is a JPEG image.  In order to represent
-   > the latter, the body part must have "Content-Type: message/rfc822",
-   > and its body (after the blank line) must be the encapsulated message,
-   > with its own "Content-Type: image/jpeg" header field.  The use of
-   > similar syntax facilitates the conversion of messages to body parts,
-   > and vice versa, but the distinction between the two must be
-   > understood by implementors.  (For the special case in which parts
-   > actually are messages, a "digest" subtype is also defined.)
+{::include ../shared/fence-line.mkd}
 
+     A body part is an entity and hence is NOT to be interpreted as
+     actually being an RFC 822 message.  To begin with, NO header
+     fields are actually required in body parts.  A body part that
+     starts with a blank line, therefore, is allowed and is a body
+     part for which all default values are to be assumed.  In such a
+     case, the absence of a Content-Type header usually indicates
+	 that the corresponding body has a content-type of "text/plain;
+     charset=US-ASCII".
+  
+     The only header fields that have defined meaning for body parts
+     are those the names of which begin with "Content-".  All other
+     header fields may be ignored in body parts.  Although they
+	 should generally be retained if at all possible, they may be
+	 discarded by gateways if necessary.  Such other fields are
+	 permitted to appear in body parts but must not be depended on.
+	 "X-" fields may be created for experimental or private purposes,
+	 with the recognition that the information they contain may be
+	 lost at some gateways.
+  
+     NOTE: The distinction between an RFC 822 message and a body part
+     is subtle, but important.  A gateway between Internet and X.400
+     mail, for example, must be able to tell the difference between a
+     body part that contains an image and a body part that contains
+	 an encapsulated message, the body of which is a JPEG image.  In
+	 order to represent the latter, the body part must have
+	 "Content-Type: message/rfc822", and its body (after the blank
+	 line) must be the encapsulated message, with its own
+	 "Content-Type: image/jpeg" header field.  The use of similar
+	 syntax facilitates the conversion of messages to body parts, and
+	 vice versa, but the distinction between the two must be
+	 understood by implementors.  (For the special case in which
+	 parts actually are messages, a "digest" subtype is also
+	 defined.)
 
+{::include ../shared/fence-line.mkd}
 
 
 The MIME structure of an Email message looks as follows: