WAIS defines a :type field in the :document structure. Right
now, it's a string with loosely defined semantics. It's a
simple matter to obsolete the :type field with a :content-type
field with MIME semantics as follows:
obsolete MIME compliant
:type "TEXT" :content-type "text"
:type "GIF" :content-type "image/gif"
:type "TIFF" :content-type "image/x-tiff"
:type "PS" :content-type "application/postscript"
:type "WSRC" :content-type "application/x-wais-source"
:type "MIME" :content-type "message"
I believe data served up by existing WAIS servers fits the MIME
content typing system as is. A WAIS client already implements the
semantics of the text, image, audio, video, and application types:
Either you present it, hand it off to something that can,
or punt to a file.
There are other semantics defined by MIME that would be nice
in WAIS clients. But these require that you handle pretty much
the whole MIME syntax. It's not clear that WAIS should adopt
the MIME solutions in these cases.
[I would like to see the world-wide web adopt MIME solutions
for these issues, though.]
In <9206081956.AA03908@cmns.think.com.Think.COM>, Mr. Spero suggests
that WAIS might be expanded to offer data in a number of types. The MIME
solution to this problem is the "multipart/alternative" body type.
Someone else suggested that the WAIS server might return only
a pointer to the data, and the client could retrieve the actual
content. MIME defines a "message/external-body" type for this.
And I suggested that the server might return a complex document
with text, graphics, and pointers to other data. (World Wide
Web servers return text with pointers, and they're trying to
deal with graphics). I suggested a new "multipart/hypertext"
type to handle this.
Resolving these issues is going to take a lot more thought.
Let's keep interoperability in mind while we do it.
Dan