Re: Round 3: moving HTTP 1.0 to informational

Looks good. A few minor points:

> If HTTP-to-MIME canonicalization is performed, the value of a
> Content-Length header field of the HTTP data must be updated to
> reflect the new body length.

MIME does not contain a content-length header (any more). In fact, I
cannot find the string "content-length" in any extant RFC. I know some
mail clients send content-length, but it is non-standard. (I might
conjecture that mail doesn't have content-length for the same reasons
why HTTP->MIME gateways should remove it: because encodings or
canonicalization might change it.)  Perhaps this should be titled
Introduction of Content-Length and rewritten accordingly.

> An HTTP client may include a Content-Transfer-Encoding as an extension
> Entity-Header in a POST request when it knows the destination of that
> request is a proxy or gateway to a MIME-compliant protocol.

How is a client to know this?? I think this paragraph should just be
removed.