Re: Comments on the HTTP/1.0 draft.

Thus wrote: "Roy T. Fielding"
>Marc, I understand your concerns about MIME conformance and following
>the norms of good network behavior.  However, HTTP is not Internet
>Mail and thus its design constraints are quite different.  Although it
>may at times cause confusion, I would still prefer to use 80% of MIME
>for HTTP/1.0 instead of 0%  -- 100% is simply not an option.

Well, of the Internet standard protocols, HTTP is probably most like
FTP in its design constraints, and FTP certainly does worry about
newline issues (though its approach is obviously a bit dated, and it
doesn't worry about other forms of canonicalization.)

I think I understand your concerns, although there seem a few
different perspectives on why text canonicalization is inappropriate,
and I'd like to at least have a clear idea of what the essential
reason is.

- Existing servers and clients don't do it.  (Well, except for the
  demo prototype I hacked up myself. :-)

  If this is an informational RFC, this reason is probably sufficient,
  in which case the issue can be forgotten about and revisited when
  a standards-track document for HTTP/1.1 or whatever gets discussed.

- The performance hit is too great.

  This may be a compelling reason, though my sense of this isn't as
  strong as I'd like it to be.  Simon has hinted that he doesn't think
  it's a big performance issue in most cases, and I certainly would
  consider him *the* authority on performance issues.  It does mean
  that canonical forms should be used for everything except textual
  line breaks, presumably.

- There's no reason to do it.

  For me, the issue is whether there's sufficient reason not to; by
  default, go where the specs have paved the way before.  I suspect
  the main issue of contention is what constitutes "sufficient." :-)

>Use of "x-token" for unofficial MIME types will not be required by
>the spec -- in fact, that was one of the main reasons for a separate
>BNF from that given in MIME.  For reasons that I have discussed on
>prior mailing lists (and don't have time to repeat right now),
>use of x-tokens for anything but experiments is extremely bad
>engineering and not appropriate for systems that allow content
>negotiation.  Besides, it is not current practice (even in Mail).

Your use of the phrase "will not" suggests the final decision has
already been made on the issue and it's pointless for anyone to
suggest otherwise.  Is that what you meant to say?

It's current practice in the messages I see, but I'm sure it gets
ignored.  It's certainly the case that X-tokens can get used far more
widely and non-experimentally than is really appropriate, as x-gzip
and x-compress demonstrate clearly.

I think the appropriate solution is to make the process for
registering types good and easy enough that there isn't really any
good excuse for not doing so, which I believe RFC 1590 does a decent
job of, though there are some things we may wish to try to push for
regarding the future of the Internet media-type registry system.

>The HTTP/1.0 spec will not force any changes to existing clients and
>servers EXCEPT where those applications are known to be defficient due
>to bugs in their design (i.e. bad Content-Type parsing) or in their
>implementation (i.e. XMosaic's useless Accept: headers).

Extra Accept: headers seem mostly just sub-optimal and sort of a
waste; I don't think I'd call them "broken" the way content-type
parsing is.  Or did you mean the way Mosaic claims it will handle
anything for an inline image when it will only handle two types?
That's broken.
--
Marc VanHeyningen  <URL:http://www.cs.indiana.edu/hyplan/mvanheyn.html>

Received on Wednesday, 7 December 1994 05:32:51 UTC