Re: i28 proposed replacement text

Henrik Nordstrom wrote:
> And in this case the protocol do not really depend on the delimiting
> being detected proper. The message delimiting is the same as identity
> encoding without content-length, by closing the connection. But unlike
> identity encoding the recipient can clearly tell if the message got
> unexpectedly truncated, with the small exception of a sender sending
> multiple gzip members in the same stream and the message getting
> truncated exactly between two members.

Does this mean that it isn't possible to use deflate or gzip 
Transfer-Encoding on a persistent connection unless chunked encoding is 
applied (last)? And, doesn't the following imply that any 
transfer-encoding (besides identity) must be chunked? That is, "deflate" 
would not be a valid Transfer-Encoding, but "deflate, chunked" would me.

    2.If a Transfer-Encoding header field (section 14.41) is present and
      has any value other than "identity", then the transfer-length is
      defined by use of the "chunked" transfer-coding (section 3.6),
      unless the message is terminated by closing the connection.

Regards,
Brian