Re: Comments on the HTTP/1.0 draft.

Marc VanHeningen writes:

> 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.)

FTP does not share the same design goals as HTTP.  In fact, HTTP0
was specifically created because of that difference in goals.

> 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. :-)

That is the reason it is not in HTTP/1.0

> - The performance hit is too great.

That is why it probably won't be in HTTP/1.1

>   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.

The performance difference is easily measured -- I have already done so.

>>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?

Yes, for HTTP/1.0.  The spec describes how to parse media types -- NOT
which ones are standard/experimental/valid.

> 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.

As they have clearly demonstrated, using "x-" types outside of a small
experiment is a bad idea.  Requiring that ALL types be standard or
experimental is just plain brain-damaged (and yes, that term applies
equally well to those specs that have required it in the past).
Current practice is to ignore this requirement -- I prefer not to issue
it in the first place.

> 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.

Saying something and doing it are entirely different things.  The spec
does not prevent types from being registered -- it just doesn't require
that conforming implementations check the registry upon receipt of a
non-standard type.  The same is true in MIME -- they just lie in the RFC.


......Roy Fielding   ICS Grad Student, University of California, Irvine  USA
                                     <fielding@ics.uci.edu>
                     <URL:http://www.ics.uci.edu/dir/grad/Software/fielding>

Received on Wednesday, 7 December 1994 11:49:15 UTC