Re: Round 4: moving HTTP 1.0 to informational

> The following is what I really, really hope is the last round on the
> HTTP/1.0 draft. Everything here has already been around the WG, and I've
> tried to synthesize where there was eventual agreement. I admit that I
> may have made some mistakes in choosing what was agreed on, but please
> don't go into this looking for new things to haggle about.

Overall, this looks pretty good to me. I only have a couple of minor
changes to suggest.

> HTTP/1.0 uses many of the constructs defined for Internet Mail (RFC 822
> [7]) and the Multipurpose Internet Mail Extensions (RFC 1521, MIME [5]) to
> allow entities to be transmitted in an open variety of representations and
> with extensible mechanisms. However, RFC 1521 discusses email, and HTTP has
> a few features that are different than those described in RFC 1521. These
> differences were carefully chosen to optimize performance over 8-bit
> networks, to give greatest freedom for creating new media-types, to make
> date comparisons easier, and to acknowledge the practice of some early HTTP
> servers and clients.

If you have to have the part about optimizing performance, it should say binary
networks, not 8-bit networks. This is an important distinction.

The statement is also confusing. It can be read to imply that MIME has to be
extended for use over binary transports. This is not the case; MIME was
designed to be transport neutral and to support 7bit, 8bit and binary
transports from the outset. The only "optimization" here is the omission of
capabilities that are unnecessary in an all-binary environment. As such,
changing "optimizing performance ..." to something like "removing options that
are unnecessary in an all-binary network".

> C.2  Conversion of Date Formats

> HTTP/1.0 uses a small set of date formats to simplify the process of date
> comparison; these are described in section 3.3 of this document. RFC 1521
> allows a larger set of date formats. Proxies and gateways from other
> protocols to HTTP should ensure that any Date header field present in a
> message conforms to one of the HTTP/1.0 formats and rewrite the date if
> necessary.

RFC 1521 doesn't specify date formats. These are specified in RFC 822 and RFC
1123; RFC 1521 merely makes a couple of references to these formats. As these
references are far from the only use of date/time values in Internet email and
far from the only ones that are of concern in this context, this reference
should be changed to reflect the actual documents that define the date formats
in use here.

> Proxies and gateways from HTTP to MIME-compliant protocols are responsible
> for ensuring that the message is in the correct format and encoding for
> safe transport on that protocol. "Safe transport" is defined by the
> limitations of the protocol being used. At a minimum, the CTE field of

> Content-Transfer-Encoding: binary

> should be added by the HTTP-to-MIME proxy or gateway if the gateway is
> unwilling to apply a content transfer encoding.

While legal, this isn't a good idea, especially not in a document that attempts
to deal with existing practices and issues with those practices. The problem is
that there are email systems out there that will say "I don't support binary so
this has to be bogus" and hence reject the message. They are taking this
position because they take this statement in the MIME specification

  Thus there are no circumstances in which the "binary"
  Content-Transfer-Encoding is actually valid in Internet mail.

out of context. (It is talking about the content itself, not how it is
labelled.)

Binary should be added if and only if it's appropriate and the data containined
the part is truly binary in nature. If the data is 7bit it should be labelled
as such, and if the data is 8bit it should be labelled as such. If you're not
willing to convert or to scan and label correctly you'd probably be better off
not labelling at all or labelling on the basis of what the transport you're
dealing with can handle, not what the data actually contains.

				Ned

Received on Saturday, 17 February 1996 11:21:14 UTC