Actually, the IETF "URL" working group has addressed an issue close
to yours for ftp: URLs. They wanted to be specific, when possible,
about what FTP transfer mode to use and the command to use (is the
remote thing a file or a directory). I may have the details wrong,
but the proposed solution was to add ";type=something" to the end
of the URL. So you might have:
ftp://host.dom/a/directory;type=dir
ftp://host.dom/text/file;type=ascii
ftp://host.dom/binary/file;type=image
Or whatever. For ***FTP*** URLs this is reasonable and extending
that syntax to something like
ftp://host.dom/binary/file;type=image;content-type=image/gif
seems reasonable enough. I'm not so sure that dropping that syntax
onto HTTP URLs is a good idea. If I can follow a link with my browser
that will give me back something that my browser can't deal with, I
won't be happy. Such an extension may be acceptible if it means
"image/gif is the preferred format if my browser understand it".
That way, you could say "http://host/file;content-type=application/oct..."
and expect it to work since every browser can deal with that type.
But "http://host/file;content-type=application/postscript" may
not always work out.