Reflow text in doc/format.txt

doc/format.txt

@@ -56,40 +56,36 @@ opt_location:
 JSON Format
 -----------
 
-The JSON format should be a mechanical translation of the above format with the
-following specification.
+The JSON format should be a mechanical translation of the above format with
+the following specification.
 
-All fields other than the version and location fields may contain arbitrary binary data, though
-per-service conventions are free to impose stricter requirements - these
-are outside the scope of this document.
+All fields other than the version and location fields may contain arbitrary
+binary data, though per-service conventions are free to impose stricter
+requirements - these are outside the scope of this document.
 
 Locations and the version should contain Unicode strings, although as these
-are unverified data, implementations do not need to be
-strict about rejecting non-UTF-8 byte sequences when converting
-from the binary format - for example an implementation
-may choose to map unknown characters to 0xfffd values.
+are unverified data, implementations do not need to be strict about rejecting
+non-UTF-8 byte sequences when converting from the binary format - for example
+an implementation may choose to map unknown characters to 0xfffd values.
 
 The version field should contain a string holding a numeric version number.
-The initial version specified in this document is "2", indicating
-the major version.
-
-To handle binary data, other fields may be encoded as hexadecimal,
-base64 or UTF-8. If a field is named *x* below, it may be specified
-in hex with the name *x*H, or base64 with the name *x*64.
-The hex format should allow both upper and lower case digits;
-the base64 format should allow both URL-safe and standard
-base64 encodings with optional "=" pad characters. The UTF-8
-format can be used when the field contains a valid sequence of
-UTF-8 bytes that can be encoded without loss as a JSON
-string. In this case the JSON string should be interpreted as
-a sequence of UTF-8 bytes after decoding for the purposes
-of signature calculation.
-
-Implementations should reject JSON objects containing more than
-one representation of the same field.
-
-For example, all the following objects encode a caveat with the
-same id:
+The initial version specified in this document is "2", indicating the major
+version.
+
+To handle binary data, other fields may be encoded as hexadecimal, base64 or
+UTF-8. If a field is named *x* below, it may be specified in hex with the name
+*x*H, or base64 with the name *x*64.  The hex format should allow both upper
+and lower case digits; the base64 format should allow both URL-safe and
+standard base64 encodings with optional "=" pad characters. The UTF-8 format
+can be used when the field contains a valid sequence of UTF-8 bytes that can
+be encoded without loss as a JSON string. In this case the JSON string should
+be interpreted as a sequence of UTF-8 bytes after decoding for the purposes of
+signature calculation.
+
+Implementations should reject JSON objects containing more than one
+representation of the same field.
+
+For example, all the following objects encode a caveat with the same id:
 
 	{"i": "Ou?T"}
 	{"iH": "4f753f54"}