> I think we need the following:
> o Accept-inline:
> That should handle the issue of inline jpeg, as well as future
> possibilities such as structured graphics, postscript, epsf and rtf.
No, since the inline request is done seperately, you just need to use a
different Accept header for that request. You don't need any new
headers.
> I would argue that the server needs to be able to do multiple files
> for a URL already. I would love to store all my non-inlined images
> in JPEG format, and if I get a request from a user who doesn't have
> JPEG support.
This can be done at the moment: our server has been doing this for over
a year now, and it works for everything (except WinMosaic, which is a
bit broken in this respect). No new magic is needed, you just have to
use a server which supports multiple types and configure it up properly.
This is the whole purpose of the Accept headers (well, there may be
other reasons, but who cares :), and it allows you to even convert the
images into the correct format on the fly (we had this enabled in our
server for a while, and it kept converting gif's into ascii art on
terminal interfaces. Yuck :)
Nick Williams, Systems Architecture Research Centre, City University,
London, EC1V 0HB. UK.
Web: http://web.cs.city.ac.uk/finger?njw
E-mail: njw@cs.city.ac.uk (MIME and ATK)
Work Telephone: +44 71 477 8551
Work Fax: +44 71 477 8587