Re: Comments on the HTTP/1.0 draft.

Roy said:
> Marc VanHeningen writes:
> > - 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

Seems a bit inconsistent, since there are plenty of other things that existing
implementations don't do but remain in the 1.0 spec, but OK.

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

The only unregistered type I see employed widely without an x-prefix is
"text/html", frankly.  "Current practice" is a nebulous thing.

Content-Encoding: demonstrates that the HTTP community didn't do a very good
job of actually formalizing its procedures, preferring instead to get something
just good enough to kind of work for the immediate need and leaving it at that.
The problem was that there was no defined way to register these encodings, and
so it didn't happen.  These concerns are not applicable to media-types.

It would indeed be nice, I guess, if there were more of a continuium between
"experimental" and "standard", which effectively means a standards-track for
media types.  Perhaps there will be one at some point.  But I don't think
that's what you really want.

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

Kindly show me where the MIME RFC requires conforming implementations to
check the registry; I can't seem to find it in my copy.  (Actually, if the
registry were more machine-readable, one could imagine a registry that points
to an implementation of a viewer for that media-type for your platform, and
a UA could automatically fetch it and use it, but that's probably a pipe
dream.)

I believe your interpretation of these documents is mistaken, and that 1590
removes the email-centrisms from media type registration procedures, which
makes the draft section:

#   For mail applications, where there is
#   no type negotiation between sender and receiver, it is reasonable
#   to put strict limits on the set of allowed content types. With
#   HTTP, however, user agents can identify acceptable media types as
#   part of the connection, and thus are allowed more freedom in the
#   use of non-registered types.

at best redundant and at worst wrong; there are *not* strict limits on the set
of allowed content-types for mail, either de facto or de jure.

Content-type negotiation can only work if the client and the server both
use the same name for the same media-type, any associated parameters, etc.
Encouraging use of unregistered types (which I believe the document as
written does) merely increases the chance that either different groups will
employ different names for the same object or, much worse, use the same
name for two totally different things.  As anybody who has tried to name
a product or file a trademark knows, there's almost certainly somebody out
there using the same name for something different.

The HTTP spec should, at bare minimum, mention these issues and encourage
registration of types that are employed.

- Marc

Received on Thursday, 8 December 1994 05:04:54 UTC