media-type version information in future versions of HTTP?

In future versions of HTTP, would it be a nice feature to have
a version number as a parameter to the content-type and accept
header in HTTP?  Let me explain...

To specify that a document is HTML 3.2 compliant, one might
want to upgrade HTTP to include things like:

Content-type: text/html (v3.2)

or to specify components of HTML, how about extra parameters to
specify what capabilities are expected of the client?  For example,
if frames are used, the header might look like:

Content-type: text/html (v3.2/frames)

Likewise, the browsers might want to send something like:

Accept: text/html (v3.2)

And the server could provide HTML 3.2 instead of some future
version of HTML.  (Perhaps run a filter program to downgrade
newer html tags/parameters to be 3.2 compliant)


Here's the motivation for printing out content-type versions
and/or components:

  - Browsers know what the content is without downloading it.
    For example, if a browser can handle GIF87 but not GIF89,
    it could use HEAD to determine the GIF version number
    and skip GIF89 images.  Likewise for HTML and other media
    types.

  - Web site designers no longer need to do a "timed redirect"
    with the default page saying "if your browser doesn't switch
    pages in a few seconds, click here."  I suspect that
    they do this with the assumption that "newer" browsers
    will understand the redirection and older browsers
    won't.  From an architecture standpoint, this won't
    work well in the future.  There will be a lot more
    browsers in the future that support redirections
    but vary by HTML/applet/plugin capability.

  - One can keep statistics about the capabilities of
    web browsers and servers.  It might be possible to
    say things like "84% of our hits are from browsers
    that understand Cascading Style Sheets."

Support of media-type version information could lead to:

  - HTTP media-type content negotiation, so a browser
    can get content that makes use of its features.
    (And not receive content that it can't support)

  - With persistent connections, the content and communication
    between the client and server could become specialized
    as more transactions are performed.  Historically,
    Mosaic would print out all the MIME types it supports.
    Today, browsers only print a few MIME types in its
    Accept header, like GIF, JPEG, xbitmap, or */*.
    In future versions of HTTP, a typical connection
    might have the following logic:
    

      - Client requests a URI from a web server.
      - There are two copies of the URI at the server.
        One is HTML 3.2 compliant and the other is
        HTML 4.0 compliant.  The server tells this to the
        client and asks the client which version it would
        like.
      - The client replies to the server with
        a preference of HTML 3.2.  The server remembers
        this preference for the rest of the (persistent)
        connection until told otherwise.
      - The server responds with a HTML 3.2 version of
        the URI.

These are just a few ideas... maybe they're good ideas,
maybe not.  If you have comments, feel free to email me.

Regards,
Clinton

Received on Monday, 5 May 1997 19:42:42 UTC