RFC 2068                        HTTP/1.1                    January 1997


          parameter      = attribute "=" value
          attribute      = token
          value          = token | quoted-string

   The type, subtype, and parameter attribute names are case-
   insensitive.  Parameter values may or may not be case-sensitive,
   depending on the semantics of the parameter name. Linear white space
   (LWS) MUST NOT be used between the type and subtype, nor between an
   attribute and its value. User agents that recognize the media-type
   MUST process (or arrange to be processed by any external applications
   used to process that type/subtype by the user agent) the parameters
   for that MIME type as described by that type/subtype definition to
   the and inform the user of any problems discovered.

     Note: some older HTTP applications do not recognize media type
     parameters. When sending data to older HTTP applications,
     implementations should only use media type parameters when they are
     required by that type/subtype definition.

   Media-type values are registered with the Internet Assigned Number
   Authority (IANA). The media type registration process is outlined in
   RFC 2048 [17]. Use of non-registered media types is discouraged.

3.7.1 Canonicalization and Text Defaults

   Internet media types are registered with a canonical form. In
   general, an entity-body transferred via HTTP messages MUST be
   represented in the appropriate canonical form prior to its
   transmission; the exception is "text" types, as defined in the next
   paragraph.

   When in canonical form, media subtypes of the "text" type use CRLF as
   the text line break. HTTP relaxes this requirement and allows the
   transport of text media with plain CR or LF alone representing a line
   break when it is done consistently for an entire entity-body. HTTP
   applications MUST accept CRLF, bare CR, and bare LF as being
   representative of a line break in text media received via HTTP. In
   addition, if the text is represented in a character set that does not
   use octets 13 and 10 for CR and LF respectively, as is the case for
   some multi-byte character sets, HTTP allows the use of whatever octet
   sequences are defined by that character set to represent the
   equivalent of CR and LF for line breaks. This flexibility regarding
   line breaks applies only to text media in the entity-body; a bare CR
   or LF MUST NOT be substituted for CRLF within any of the HTTP control
   structures (such as header fields and multipart boundaries).

   If an entity-body is encoded with a Content-Encoding, the underlying
   data MUST be in a form defined above prior to being encoded.




 
RFC 2068                        HTTP/1.1                    January 1997


   The "charset" parameter is used with some media types to define the
   character set (section 3.4) of the data. When no explicit charset
   parameter is provided by the sender, media subtypes of the "text"
   type are defined to have a default charset value of "ISO-8859-1" when
   received via HTTP. Data in character sets other than "ISO-8859-1" or
   its subsets MUST be labeled with an appropriate charset value.

   Some HTTP/1.0 software has interpreted a Content-Type header without
   charset parameter incorrectly to mean "recipient should guess."
   Senders wishing to defeat this behavior MAY include a charset
   parameter even when the charset is ISO-8859-1 and SHOULD do so when
   it is known that it will not confuse the recipient.

   Unfortunately, some older HTTP/1.0 clients did not deal properly with
   an explicit charset parameter. HTTP/1.1 recipients MUST respect the
   charset label provided by the sender; and those user agents that have
   a provision to "guess" a charset MUST use the charset from the
   content-type field if they support that charset, rather than the
   recipient's preference, when initially displaying a document.

3.7.2 Multipart Types

   MIME provides for a number of "multipart" types -- encapsulations of
   one or more entities within a single message-body. All multipart
   types share a common syntax, as defined in  MIME [7], and MUST
   include a boundary parameter as part of the media type value. The
   message body is itself a protocol element and MUST therefore use only
   CRLF to represent line breaks between body-parts. Unlike in MIME, the
   epilogue of any multipart message MUST be empty; HTTP applications
   MUST NOT transmit the epilogue (even if the original multipart
   contains an epilogue).

   In HTTP, multipart body-parts MAY contain header fields which are
   significant to the meaning of that part. A Content-Location header
   field (section 14.15) SHOULD be included in the body-part of each
   enclosed entity that can be identified by a URL.

   In general, an HTTP user agent SHOULD follow the same or similar