<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Just a couple of cents from someone that's been passively watching
    this discussion.  Feel free to ignore me ;-)<br>
    <br>
    If we might use one word to describe Gopher, it is "simple." 
    Gopher+ somewhat violates this, and HTTP severely violates this. 
    MIME types have their uses, and the Web and email wouldn't work so
    well without them.  However, even after all these years, they still
    aren't dealt with quite right.  If you click on a file on a Web
    server named foo.zip and the Content-Type header says it's
    image/gif, what happens?  And what happens after you do File ->
    Save in your browser, then try to open it up later?  (Note: these
    two things are not normally the same!)<br>
    <br>
    Proper mailcap and MIME type handling could of course be added to
    Gopher.  But I would ask: why?<br>
    <br>
    I think instead of adding more types, we could remove types and
    simplify.  The would be:<br>
    <br>
    <ul>
      <li>Plain text (ASCII or UTF-8)</li>
      <li>Binary data</li>
      <li>HTML text (ASCII or UTF-8)</li>
      <li>gopher directory</li>
      <li>info pseudo-type<br>
      </li>
      <li>Media</li>
    </ul>
    The "media" type would simply be binary data with a hint to the UI
    to attempt to display it based on its extension.<br>
    <br>
    There are existing item types in existing specs that all of the
    above map to.<br>
    <br>
    Let the client use its own mailcap, or whatever, to decide what to
    do with media data.<br>
    <br>
    -- John<br>
    <br>
  </body>
</html>