formating

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

@@ -594,41 +594,41 @@ interoperability issues result from it:
    of paragraphs that may be relevant in this context:
 
 {::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.)
-
+      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".
+{::include ../shared/fence-line.mkd}
+{::include ../shared/fence-line.mkd}
+      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.
+{::include ../shared/fence-line.mkd}
+{::include ../shared/fence-line.mkd}
+      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}